F1 Reset Acknowledge is the F1AP successful outcome exchanged between the gNB-CU and gNB-DU to confirm completion of an F1 Reset procedure.
Message Fact Sheet
Protocol
f1ap
Network
5g
Spec
3GPP TS 38.473
Spec Section
F1 Reset procedure and F1 Reset Acknowledge message
Direction
gNB-CU <-> gNB-DU
Message Type
F1 Interface Management Message
Full message name
F1 Reset Acknowledge
Protocol
F1AP
Technology
5G
Direction
gNB-CU <-> gNB-DU
Interface
F1-C
Signaling bearer / channel
Non-UE-associated F1AP signaling, with possible confirmation of UE-associated context cleanup depending on the original reset scope / SCTP carried F1AP successfulOutcome
Typical trigger
The peer node has received F1 Reset, processed the requested full or partial reset, and is confirming completion back to the reset initiator.
Main purpose
Confirms reset handling, tells the reset initiator that requested resources were reset, closes the F1 Reset procedure, helps prevent repeated reset retries, and confirms cleanup after full or partial reset.
Main specification
3GPP TS 38.473, F1 Reset procedure and F1 Reset Acknowledge message
Release added
Release 15
Procedures where used
F1 Reset, F1 interface recovery confirmation, Full F1AP reset confirmation, Partial UE-associated context reset confirmation, Repeated reset loop analysis
What is F1 Reset Acknowledge in simple terms?
F1 Reset Acknowledge is the F1AP successful outcome exchanged between the gNB-CU and gNB-DU to confirm completion of an F1 Reset procedure.
Confirms reset handling, tells the reset initiator that requested resources were reset, closes the F1 Reset procedure, helps prevent repeated reset retries, and confirms cleanup after full or partial reset.
Why this message matters
F1 Reset Acknowledge means the peer says reset handling is complete. To know what was reset, always go back to the preceding F1 Reset and read Reset Type.
Where this message appears in the call flow
F1 Reset completion
Procedure pair: the peer confirms that it handled the reset request and closes the F1 Reset procedure.
Call flow position: The peer node sends F1 Reset Acknowledge after processing a matching F1 Reset request.
Typical state: The reset procedure is complete for the scope requested by the original Reset Type.
Preconditions:
F1 Reset was received.
The peer processed the requested reset.
The acknowledge is sent in the opposite direction to the reset request.
Next likely message: Normal F1AP procedures resume if the reset scope allows it
Full reset acknowledgement
Scope rule: the acknowledge confirms handling, but full or partial meaning comes from the preceding F1 Reset.
Call flow position: The acknowledge confirms handling of a full F1 reset when the preceding Reset Type requested full interface reset.
Typical state: The peer has completed broad F1AP reset handling.
Preconditions:
The preceding F1 Reset used full reset scope.
The reset receiver completed full-scope cleanup.
Next likely message: Fresh F1AP activity or F1 setup recovery if needed
Partial reset acknowledgement
Procedure distinction: reset acknowledgement is recovery confirmation, not initial setup acceptance or normal UE release completion.
Call flow position: The acknowledge confirms handling of selected affected UE-associated contexts when the preceding F1 Reset used partial scope.
Typical state: Only the selected contexts should be interpreted as reset by this procedure.
Preconditions:
The preceding F1 Reset used partial reset scope.
The affected UE-associated contexts were identified from the original reset message.
Next likely message: Affected UE contexts are recreated, released, or remain absent depending on recovery flow
Call flow position
Previous message(s):F1 Reset, Peer node processed the reset request, Requested F1AP resources or UE-associated contexts were reset
Next message(s): Reset procedure is complete, Affected F1AP state or UE contexts should be clean, Normal F1AP procedures may resume depending on reset scope
Message direction and transport
Sender and receiver: gNB-CU <-> gNB-DU
Interface: F1-C
Domain: F1 interface management and CU-DU recovery confirmation
Signaling bearer: Non-UE-associated F1AP signaling, with possible confirmation of UE-associated context cleanup depending on the original reset scope
Transport / encapsulation: F1AP over SCTP/IP between gNB-CU and gNB-DU
Security context: F1 Reset Acknowledge does not establish a UE security context. It confirms reset recovery handling for the scope requested by the preceding F1 Reset.
Message Structure Overview
F1 Reset Acknowledge is the successfulOutcome for the F1 Reset procedure.
Either gNB-CU or gNB-DU can send it, depending on which side received the original F1 Reset.
The acknowledge confirms reset handling but does not define reset scope by itself.
Reset scope must be inherited from the original F1 Reset Reset Type: full reset or partial reset.
Criticality Diagnostics, when present, helps explain unusual IE or procedure-level handling.
Decode Transaction ID to match the acknowledge to the original F1 Reset. Then return to the original Reset Type to understand whether this confirmation applies to a full reset or a partial reset of selected UE-associated contexts.
F1 Reset Acknowledge - Example Dump
F1AP-PDU
successfulOutcome
procedureCode: id-F1Reset
criticality: reject
value: F1ResetAcknowledge
protocolIEs:
- id: id-TransactionID
value: 12
- id: id-CriticalityDiagnostics
value: <optional diagnostic details>
Context from preceding F1 Reset:
Cause = protocol / transport / misc
Reset Type = full reset or partial reset
How to read this dump
Treat this as a teaching example based on the expected message structure, not as a captured network trace.
Do not infer full or partial reset scope from the acknowledge alone.
Use Transaction ID to match the acknowledge with the F1 Reset request.
If Criticality Diagnostics is present, inspect it after confirming request correlation.
Important Information Elements
IE
Required
Description
Message Type
Yes
Identifies the F1AP PDU as F1 RESET ACKNOWLEDGE.
Transaction ID
Yes
Correlates the acknowledge with the preceding F1 Reset request.
Criticality Diagnostics
Optional
Optional protocol-level diagnostics about IE handling, procedure handling, or criticality behavior during reset acknowledgement.
Detailed field explanation
Message Type
Identifies the F1AP PDU as F1 RESET ACKNOWLEDGE.
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 acknowledge with the preceding F1 Reset request.
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.
Criticality Diagnostics
Optional protocol-level diagnostics about IE handling, procedure handling, or criticality behavior during reset acknowledgement.
Presence: Optional
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
Confirm F1 Reset Acknowledge follows a matching F1 Reset.
Verify the direction is opposite the reset initiator.
Match Transaction ID to the original F1 Reset.
Read Reset Type from the original F1 Reset to understand full or partial scope.
Check Criticality Diagnostics if present.
Verify that repeated F1 Reset attempts stop after the acknowledge.
For partial reset, check that affected UE contexts are recreated, released, or cleaned consistently afterward.
Common Issues and Troubleshooting
F1 Reset Acknowledge is missing after F1 Reset.
Likely cause: The peer may not have processed the reset, the SCTP association may have failed, or the reset procedure may have been interrupted by broader recovery.
What to inspect: Check SCTP continuity, peer logs, matching Transaction ID, and any Error Indication or association restart around the reset.
Next step: Treat the reset procedure as incomplete until an acknowledge or a broader setup/recovery event appears.
Reset loops continue after an acknowledge.
Likely cause: The acknowledge completed one reset transaction, but the underlying CU-DU state mismatch or transport instability remains.
What to inspect: Compare repeated reset Causes, Reset Types, Transaction IDs, and timing.
Next step: Investigate the persistent state or transport issue rather than the acknowledge itself.
The acknowledge is interpreted as a full interface reset.
Likely cause: The original Reset Type was not checked.
What to inspect: Open the preceding F1 Reset and verify whether Reset Type was full or partial.
Next step: Use the original reset scope to decide which resources or UE contexts should have been cleaned.
Partial-reset UE contexts remain stale after the acknowledge.
Likely cause: The peer may have acknowledged reset handling but the expected post-reset recreation or release flow did not occur cleanly.
What to inspect: Map the UE-associated contexts from the original F1 Reset and follow later UE Context Setup or UE Context Release behavior.
Next step: Troubleshoot the affected UE contexts specifically, not the whole F1 interface.
LTE / 5G / Variant Comparison
Full reset acknowledgement versus partial reset acknowledgement
The same acknowledge confirms either full or partial reset handling. The distinction comes from the preceding F1 Reset Reset Type.
Compared with F1 Setup Response
F1 Setup Response accepts initial F1 interface setup. F1 Reset Acknowledge confirms reset recovery after F1 state already exists or has become inconsistent.
Compared with UE Context Release Complete
UE Context Release Complete confirms normal UE-specific release. F1 Reset Acknowledge confirms reset procedure handling, even when partial reset affects UE contexts.
FAQ
What is F1 Reset Acknowledge in F1AP?
F1 Reset Acknowledge is the successful outcome used between gNB-CU and gNB-DU to confirm that an F1 Reset request has been processed.
Who sends F1 Reset Acknowledge?
The peer node that received the F1 Reset sends F1 Reset Acknowledge back to the reset initiator.
What message triggers F1 Reset Acknowledge?
F1 Reset triggers F1 Reset Acknowledge.
Can both gNB-CU and gNB-DU send this message?
Yes. Either node can send it, depending on which side received the original F1 Reset.
Does F1 Reset Acknowledge mean the full interface was reset?
Not always. It confirms reset handling for the scope requested in the original F1 Reset, which may be full reset or partial reset.
How do you know if the reset was full or partial?
Check the Reset Type in the preceding F1 Reset message.
Is this the same as UE Context Release Complete?
No. UE Context Release Complete confirms normal UE-specific release. F1 Reset Acknowledge confirms reset recovery handling.
How do you troubleshoot missing F1 Reset Acknowledge?
Check that the reset reached the peer, verify SCTP continuity, match Transaction ID, inspect Error Indication or association restart events, and review peer-side reset handling logs.
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.
