Xn Setup Response is the successful XnAP outcome the receiving NG-RAN node returns after accepting Xn Setup Request, making the Xn relationship operational and optionally returning the peer-side served-cell and grouping view the initiator should store for later inter-node procedures.
Message Fact Sheet
Protocol
xnap
Network
5g
Spec
3GPP TS 38.423
Spec Section
Xn Setup successful outcome and related IE definitions (Release 18 baseline)
The receiving NG-RAN node accepted Xn Setup Request and now returns the successful outcome so the initiating node can treat the Xn relationship as usable.
Main purpose
Confirms that the peer NG-RAN node accepted the Xn relationship and returns any peer-side setup information the initiator must store before later Xn procedures can run.
Main specification
3GPP TS 38.423, Xn Setup successful outcome and related IE definitions (Release 18 baseline)
Xn Setup Response is the successful XnAP outcome the receiving NG-RAN node returns after accepting Xn Setup Request, making the Xn relationship operational and optionally returning the peer-side served-cell and grouping view the initiator should store for later inter-node procedures.
Confirms that the peer NG-RAN node accepted the Xn relationship and returns any peer-side setup information the initiator must store before later Xn procedures can run.
Why this message matters
Xn Setup Response is the peer node saying the Xn relationship is accepted and ready for later inter-node signaling.
Where this message appears in the call flow
Peer accepts the Xn relationship
Acceptance branch: the peer accepts Xn setup and the inter-node relationship becomes operational.
Call flow position: The receiving NG-RAN node has accepted the setup request and returns the success-side outcome that makes the Xn relationship operational.
Typical state: Transport was already available and the application-level inter-node relationship is now being finalized.
Preconditions:
The peer accepted the initiating node identity and the setup-time topology information.
The transaction is still matched to the original Xn Setup Request by Transaction ID.
The peer is ready for later inter-node signaling to use this relationship.
Next likely message: Any normal XnAP procedure, commonly Handover Request or later configuration update exchange
Peer served-cell and topology return
Peer-view branch: the successful outcome can return the peer-side topology view the initiator should store for later mobility work.
Call flow position: The peer can return its own setup-side served-cell or grouping view so the initiator stores the accepted inter-node relationship consistently.
Typical state: The setup succeeded, but the initiator still needs the peer-side result to understand the relationship fully.
Preconditions:
The peer chooses to include returned served-cell or grouping information in the successful outcome.
The initiating node is ready to store the returned peer view for later mobility work.
Next likely message: Later mobility or coordination procedures that rely on the newly accepted neighbor relationship
Mobility-ready Xn activation
Operational branch: once setup is accepted, later XnAP procedures can use the peer relationship for inter-node coordination.
Call flow position: After the response is accepted, the Xn interface is ready for later handover, status-transfer, and release signaling.
Typical state: The setup handshake is complete and the peer relationship has crossed from bootstrap to operational use.
Preconditions:
Both sides have correlated the same Transaction ID.
Any returned peer setup information has been stored successfully.
Next likely message: Handover Request or another XnAP operational message
Call flow position
Previous message(s):Xn Setup Request, Peer node identity and served-cell advertisement
Transport / encapsulation: XnAP over SCTP/IP between neighboring NG-RAN nodes
Security context: Xn Setup Response does not create a UE security context. It finalizes node-level Xn bootstrap and confirms that the peer relationship is operational.
Message Structure Overview
Xn Setup Response is the successfulOutcome of Xn Setup and marks the point where the Xn relationship becomes operational.
The message is anchored by Transaction ID and can add peer-side served-cell or grouping information the initiator should store.
Operationally, the response is the acceptance boundary that later XnAP mobility and coordination procedures depend on.
If the response is missing, later Xn procedures should not be assumed healthy even when transport looks reachable.
ASN.1 Message Syntax for 5G XnAP - Xn Setup Response
This message is not typically analyzed as ASN.1 on the wire. It is usually read as a NAS or protocol field structure instead.
Correlate the response to the original request by Transaction ID before reading any returned peer-side information.
Treat returned served-cell or grouping information as the accepted peer view, not as a duplicate of the request.
The first meaningful follow-on sign that setup really worked is usually a later operational XnAP procedure such as Handover Request.
Important Information Elements
IE
Required
Description
Transaction ID
Yes
Mandatory transaction correlate used to match the successful outcome with the original Xn Setup Request.
Served Cells NR
Optional
Peer-side NR served-cell information returned when the response includes an accepted NR neighbor view.
Served Cells E-UTRA
Optional
Optional peer-side E-UTRA served-cell information when the successful outcome exposes E-UTRA-related inter-node context.
GU Group ID List
Optional
Optional peer grouping information that helps the initiator store the accepted topology relationship.
Criticality Diagnostics
Optional
Optional diagnostics if the peer wants to expose extra protocol-processing detail despite the overall success path.
Detailed field explanation
Transaction ID
Mandatory transaction correlate used to match the successful outcome with the original Xn Setup 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.
Served Cells NR
Peer-side NR served-cell information returned when the response includes an accepted NR neighbor view.
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.
Served Cells E-UTRA
Optional peer-side E-UTRA served-cell information when the successful outcome exposes E-UTRA-related inter-node context.
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.
GU Group ID List
Optional peer grouping information that helps the initiator store the accepted topology relationship.
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.
Criticality Diagnostics
Optional diagnostics if the peer wants to expose extra protocol-processing detail despite the overall success path.
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
Match Xn Setup Response to the original Xn Setup Request by Transaction ID first.
Check whether the response is a pure acceptance or also returns peer-side served-cell or grouping information.
Store the accepted peer-side relationship before analyzing later handover or status-transfer traces.
If later Xn procedures fail immediately, verify that this response was actually received and processed by the initiator.
Common Issues and Troubleshooting
Transport is healthy, but later Xn procedures still behave as if no peer relationship exists.
Likely cause: The successful Xn Setup outcome may be missing, lost, or not processed correctly even though the request was sent.
What to inspect: Look for Xn Setup Response with the matching Transaction ID and confirm the initiator stored the returned peer relationship.
Next step: Fix setup completion first before debugging later handover or release procedures.
Peer-side neighbor behavior still looks inconsistent after successful setup.
Likely cause: The initiator may be using stale topology assumptions instead of the peer view returned in the successful outcome.
What to inspect: Compare the setup request with the response and verify which served-cell or grouping information was actually accepted.
Next step: Treat the response as the accepted peer model and align later analysis to that result.
Inter-node mobility starts only after repeated setup attempts.
Likely cause: The setup handshake may be succeeding intermittently, leaving the relationship operational only after some retries.
What to inspect: Sequence the setup requests, failures, and final successful response by Transaction ID and timing.
Next step: Stabilize the peer-admission path before focusing on downstream mobility symptoms.
LTE / 5G / Variant Comparison
Compared with Xn Setup Request
Xn Setup Request proposes the peer relationship. Xn Setup Response accepts it and can return the peer-side view the initiator should store.
Compared with Xn Setup Failure
Xn Setup Response makes the interface operational. Xn Setup Failure keeps it non-operational and carries rejection context instead.
Compared with later Xn operational messages
Xn Setup Response is still bootstrap signaling. Messages such as Handover Request and SN Status Transfer use an already established Xn relationship.
FAQ
What is Xn Setup Response in 5G XnAP?
It is the successful outcome the peer NG-RAN node returns after accepting Xn Setup Request, making the Xn relationship operational.
What is mandatory in Xn Setup Response?
Transaction ID is the core correlate. Other returned setup information depends on what the peer includes in the successful outcome.
Why is Xn Setup Response important in traces?
Because it proves the Xn relationship really became operational. Without it, later handover or status-transfer behavior may fail for setup-related reasons rather than radio reasons.
What should engineers read first in the response?
Start with Transaction ID, then check whether the response returns any peer-side served-cell or grouping information that changes the accepted neighbor view.
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.
