F1 Reset is the F1AP interface management message used between the gNB-CU and gNB-DU to reset F1AP resources, either globally or for selected UE-associated contexts.
Message Fact Sheet
Protocol
f1ap
Network
5g
Spec
3GPP TS 38.473
Spec Section
F1 Reset procedure and F1 Reset message
Direction
gNB-CU <-> gNB-DU
Message Type
F1 Interface Management Message
Full message name
F1 Reset
Protocol
F1AP
Technology
5G
Direction
gNB-CU <-> gNB-DU
Interface
F1-C
Signaling bearer / channel
Non-UE-associated F1AP signaling, with possible impact on UE-associated contexts depending on reset scope / SCTP carried F1AP initiatingMessage followed by successfulOutcome
Typical trigger
The gNB-CU or gNB-DU detects inconsistent F1AP state, lost context correlation, abnormal recovery conditions, or an interface cleanup condition after transport, protocol, or node-side failure.
Main purpose
Resets F1AP signalling state, clears inconsistent UE-associated contexts when partial reset is used, supports recovery after transport, protocol, or node-side failure, prevents stale context handling between CU and DU, and provides a controlled reset procedure instead of relying only on SCTP restart.
Main specification
3GPP TS 38.473, F1 Reset procedure and F1 Reset message
Release added
Release 15
Procedures where used
F1 interface recovery, CU-DU state resynchronization, Full F1AP context cleanup, Partial UE-associated context cleanup, SCTP recovery correlation
What is F1 Reset in simple terms?
F1 Reset is the F1AP interface management message used between the gNB-CU and gNB-DU to reset F1AP resources, either globally or for selected UE-associated contexts.
Resets F1AP signalling state, clears inconsistent UE-associated contexts when partial reset is used, supports recovery after transport, protocol, or node-side failure, prevents stale context handling between CU and DU, and provides a controlled reset procedure instead of relying only on SCTP restart.
Why this message matters
F1 Reset is the controlled CU-DU recovery message. Read Cause to learn why reset was requested, then read Reset Type to know whether the whole F1 interface or only selected UE contexts are affected.
Where this message appears in the call flow
F1 Reset
Procedure pair: the reset request is complete only when the peer returns F1 Reset Acknowledge.
Call flow position: The gNB-CU or gNB-DU sends F1 Reset after detecting that F1AP state is inconsistent or must be recovered.
Typical state: The peer resets the requested F1 resources or UE-associated contexts and confirms with F1 Reset Acknowledge.
Preconditions:
The F1 interface is established or was recently established.
One side has detected a state, context, transport, or recovery problem.
The reset sender can choose full reset or partial reset scope.
Next likely message: F1 Reset Acknowledge
Full F1 interface reset
Procedure pair: the reset request is complete only when the peer returns F1 Reset Acknowledge.
Call flow position: Reset Type requests broad cleanup of all relevant F1AP contexts and resources between CU and DU.
Typical state: The reset has a wider blast radius and may interrupt many UE-associated procedures.
Preconditions:
The sender cannot safely limit the recovery action to selected UE contexts.
Interface-level recovery is needed.
Next likely message: F1 Reset Acknowledge followed by fresh F1AP activity
Partial UE-context reset
Lifecycle distinction: partial reset can affect UE contexts, but it is still recovery signalling, not a normal UE release flow.
Call flow position: Reset Type limits cleanup to selected UE-associated contexts or resources.
Typical state: Only the affected UE-associated contexts should be cleared while the rest of F1 operation continues.
Preconditions:
The sender can identify the affected UE-associated contexts.
The issue is scoped to part of the F1 interface rather than the whole CU-DU relationship.
Next likely message: F1 Reset Acknowledge and later UE-context setup or release behavior for affected UEs
Call flow position
Previous message(s): F1 interface is established, Inconsistent F1AP state is detected, Transport, protocol, node restart, or context recovery condition occurs
Domain: F1 interface management and CU-DU recovery
Signaling bearer: Non-UE-associated F1AP signaling, with possible impact on UE-associated contexts depending on reset scope
Logical channel: SCTP carried F1AP initiatingMessage followed by successfulOutcome
Transport / encapsulation: F1AP over SCTP/IP between gNB-CU and gNB-DU
Security context: F1 Reset does not establish a UE security context. It is a node-level recovery message that may clear selected UE-associated F1AP contexts when partial reset is used.
Message Structure Overview
F1 Reset is a bidirectional initiatingMessage in the F1 interface management family.
Either the gNB-CU or the gNB-DU can initiate it.
Cause explains why reset recovery is needed.
Reset Type is the operational pivot: full reset is broad, while partial reset targets selected UE-associated contexts.
F1 Reset Acknowledge confirms that the peer has handled the requested reset.
The key decoding path is Transaction ID for correlation, Cause for reason, and Reset Type for scope. Full reset affects the wider F1 interface; partial reset requires careful mapping of the selected UE-associated contexts.
Treat this as a teaching example based on the expected message structure, not as a captured network trace.
If Reset Type is full reset, do not look for a selected UE context list.
If Reset Type is partial reset, map the affected UE-associated contexts before interpreting later UE setup or release behavior.
F1 Reset Acknowledge should match the reset request by Transaction ID.
Important Information Elements
IE
Required
Description
Message Type
Yes
Identifies the F1AP PDU as F1 RESET.
Transaction ID
Yes
Correlates the reset request with the F1 Reset Acknowledge response.
Cause
Yes
Explains why the reset is being requested and is the main troubleshooting field.
Reset Type
Yes
Defines whether the reset applies to the full F1 interface or to selected UE-associated contexts.
Detailed field explanation
Message Type
Identifies the F1AP PDU as F1 RESET.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Transaction ID
Correlates the reset request with the F1 Reset Acknowledge response.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Cause
Explains why the reset is being requested and is the main troubleshooting field.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Reset Type
Defines whether the reset applies to the full F1 interface or to selected UE-associated contexts.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
What to check in logs and traces
Identify which side initiated the reset: gNB-CU or gNB-DU.
Decode Cause first to understand why recovery was requested.
Check Reset Type and separate full reset from partial reset.
For partial reset, identify the affected UE-associated contexts.
Confirm F1 Reset Acknowledge follows with the matching Transaction ID.
Correlate the reset with any SCTP association restart or instability around the same time.
Common Issues and Troubleshooting
A trace shows repeated F1 Reset messages.
Likely cause: The underlying CU-DU state problem may not be clearing, or the SCTP association may be unstable.
What to inspect: Compare Cause, Reset Type, Transaction ID, and timing across reset attempts.
Next step: Fix the repeated transport, protocol, or context mismatch before treating each reset as an isolated event.
Only some UEs lose F1AP continuity after reset.
Likely cause: The reset may be partial rather than a full F1 interface failure.
What to inspect: Read Reset Type and map the selected UE-associated contexts.
Next step: Troubleshoot only the listed UE contexts first instead of assuming the whole interface failed.
F1 Reset Acknowledge is missing.
Likely cause: The peer may not have completed reset handling, the SCTP association may have failed, or the reset request may not have been accepted at protocol level.
What to inspect: Check SCTP continuity, peer logs, Transaction ID correlation, and any Error Indication around the same time.
Next step: Treat the reset procedure as incomplete until the acknowledge or a broader interface recovery event appears.
Engineers confuse partial reset with UE Context Release.
Likely cause: Partial F1 Reset can list UE contexts, but it remains an interface-management recovery procedure.
What to inspect: Check procedureCode and message family: F1 Reset versus UE Context Release.
Next step: Use reset logic for state recovery; use UE Context Release logic for normal UE-specific teardown.
LTE / 5G / Variant Comparison
Full reset versus partial reset
Full reset clears all relevant F1AP contexts/resources between CU and DU. Partial reset clears only selected UE-associated contexts or resources.
Compared with F1 Setup
F1 Setup establishes the F1-C interface. F1 Reset recovers already established or previously established F1 state.
Compared with UE Context Release
UE Context Release is normal UE-specific cleanup. F1 Reset is interface-management recovery, even when partial reset affects selected UE contexts.
FAQ
What is F1 Reset in F1AP?
F1 Reset is an F1AP interface management message used between the gNB-CU and gNB-DU to reset F1AP resources or selected UE-associated contexts.
Who sends F1 Reset?
Either the gNB-CU or the gNB-DU can initiate F1 Reset.
Can both gNB-CU and gNB-DU initiate F1 Reset?
Yes. The procedure is bidirectional and is used by whichever side detects the recovery condition.
What is the difference between full and partial reset?
Full reset clears all relevant F1AP contexts/resources between CU and DU. Partial reset clears only selected UE-associated contexts or resources.
What does the Cause IE mean?
Cause explains why the reset is requested, such as protocol inconsistency, transport recovery, node restart, or abnormal context handling.
What is the response to F1 Reset?
The peer responds with F1 Reset Acknowledge after handling the requested reset.
Is F1 Reset the same as UE Context Release?
No. UE Context Release is UE-specific cleanup, while F1 Reset is an interface management recovery procedure that may affect UE contexts only when partial reset is used.
How do you troubleshoot repeated F1 Reset messages?
Check which side initiates the resets, decode Cause and Reset Type, verify F1 Reset Acknowledge, inspect affected UE contexts for partial reset, and correlate the resets with SCTP restart or node recovery events.
Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.
