Xn Setup Request is the first XnAP interface-management message an NG-RAN node sends after the Xn-C transport association becomes operational so the peer node can learn the initiating node identity, served-cell inventory, and grouping information before normal inter-node signaling starts.
Non-UE-associated XnAP signaling / SCTP-carried XnAP initiatingMessage followed by successfulOutcome or unsuccessfulOutcome
Typical trigger
An NG-RAN node startup, restart, transport recovery, or new peer relationship requires the Xn interface to be established before handover, status transfer, or other inter-node procedures can run.
Main purpose
Bootstraps an Xn-C interface instance by transferring the initiating NG-RAN node identity and served-cell view so the peer node can decide whether the Xn relationship becomes operational.
Xn Setup Request is the first XnAP interface-management message an NG-RAN node sends after the Xn-C transport association becomes operational so the peer node can learn the initiating node identity, served-cell inventory, and grouping information before normal inter-node signaling starts.
Bootstraps an Xn-C interface instance by transferring the initiating NG-RAN node identity and served-cell view so the peer node can decide whether the Xn relationship becomes operational.
Why this message matters
Xn Setup Request is the inter-node bootstrap message that makes a new Xn interface usable by telling the peer node who is connecting and which cells it serves.
Where this message appears in the call flow
Initial inter-node bootstrap
Base branch: the initiating node advertises its identity and served cells, the peer accepts, and the Xn relationship becomes operational.
Call flow position: The initiating NG-RAN node has transport connectivity to a peer node and now advertises its node identity and served-cell view so the Xn relationship can become operational.
Typical state: This is the first XnAP procedure for the Xn-C interface instance after the transport path becomes operational.
Preconditions:
The Xn-C transport association is operational.
The initiating node knows which identity and served-cell information it wants to expose to the peer.
The receiving peer is ready to accept or reject the Xn relationship.
Next likely message: Xn Setup Response
Neighbor admission and topology alignment
Admission branch: the peer reads the served-cell view and decides whether the new inter-node relationship fits the configured topology.
Call flow position: The receiving peer checks whether the initiating node identity, served-cell inventory, and grouping information fit the configured inter-node topology.
Typical state: Transport is up, but the Xn relationship is not usable yet for mobility or coordination procedures.
Preconditions:
Peer-level admission or topology policy can evaluate the incoming node and cell advertisement.
The receiving node can map the served-cell information to its neighbor model.
Next likely message: Xn Setup Response or Xn Setup Failure
Controlled retry after rejection
Rejection branch: the peer cannot accept the Xn relationship, returns failure with backoff guidance, and the initiator retries later.
Call flow position: The peer rejects the requested Xn relationship and can instruct the initiator to back off before retrying.
Typical state: The Xn interface remains non-operational until a later successful setup exchange completes.
Preconditions:
The receiving node found the request unacceptable, unsupported, or inconsistent with its configuration.
A cause can be generated for the unsuccessful outcome.
Next likely message: Later Xn Setup Request retry after the Time To Wait window if one was returned
Call flow position
Previous message(s): Operational SCTP or TNL association establishment, NG-RAN node startup or restart, Xn interface recovery
Logical channel: SCTP-carried XnAP initiatingMessage followed by successfulOutcome or unsuccessfulOutcome
Transport / encapsulation: XnAP over SCTP/IP between neighboring NG-RAN nodes
Security context: Xn Setup Request does not create a UE security context. It is a node-level bootstrap and capability advertisement procedure for the peer relationship.
Message Structure Overview
Xn Setup Request is the first XnAP procedure on a new Xn-C interface instance once transport is operational.
The request is node-centric rather than UE-centric: it advertises node identity, served-cell view, and optional grouping data.
The successful outcome makes the Xn relationship operational for later mobility and coordination procedures.
The unsuccessful outcome keeps the interface non-operational and can carry Time To Wait for controlled retry.
In trace analysis, Xn Setup is the boundary between raw transport reachability and usable inter-node signaling.
ASN.1 Message Syntax for 5G XnAP - Xn Setup Request
This message is not typically analyzed as ASN.1 on the wire. It is usually read as a NAS or protocol field structure instead.
Read Xn Setup in layers: first Transaction ID and node identity, then served-cell advertisement, then any grouping data.
The request is not a UE-context message. It prepares the peer relationship that later UE-related Xn procedures depend on.
If the exchange fails, correlate the same Transaction ID into Xn Setup Failure before reading Cause or Time To Wait.
Important Information Elements
IE
Required
Description
Transaction ID
Yes
Mandatory transaction correlate used by the receiving node to match the request with the response or failure.
Global NG-RAN Node ID
Yes
Mandatory initiating-node identity that tells the peer which NG-RAN node is requesting the Xn relationship.
Served Cells NR
Optional
NR served-cell inventory advertisement used by the peer to understand which NR cells the initiating node exposes across Xn.
Served Cells E-UTRA
Optional
Optional E-UTRA served-cell inventory when the initiating node exposes E-UTRA-related inter-node context on Xn.
GU Group ID List
Optional
Optional grouping information that helps the peer understand how the initiating node is organized for inter-node coordination.
Detailed field explanation
Transaction ID
Mandatory transaction correlate used by the receiving node to match the request with the response or failure.
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.
Global NG-RAN Node ID
Mandatory initiating-node identity that tells the peer which NG-RAN node is requesting the Xn relationship.
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
NR served-cell inventory advertisement used by the peer to understand which NR cells the initiating node exposes across Xn.
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 E-UTRA served-cell inventory when the initiating node exposes E-UTRA-related inter-node context on Xn.
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 grouping information that helps the peer understand how the initiating node is organized for inter-node coordination.
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 Xn Setup is the first XnAP procedure after the Xn-C transport association became operational.
Match Transaction ID across request, response, or failure before interpreting any detailed field.
Read the Global NG-RAN Node ID first to confirm which peer is actually initiating the Xn relationship.
Check the served-cell inventory carefully because later mobility behavior depends on the neighbor view learned at setup.
If setup fails, treat Time To Wait as controlled retry guidance rather than a transport timer.
Common Issues and Troubleshooting
Transport is up, but later Xn mobility procedures never start.
Likely cause: Xn Setup may have failed or never completed, so the peer relationship never became operational.
What to inspect: Look for Xn Setup Response or Xn Setup Failure with the same Transaction ID immediately after the request.
Next step: Fix Xn setup acceptance first before debugging handover or status-transfer procedures.
Neighboring nodes disagree on which cells exist across Xn.
Likely cause: The served-cell advertisement in Xn Setup Request may be incomplete, stale, or inconsistent with peer expectations.
What to inspect: Compare the initiating node served-cell inventory with the peer's configured neighbor view and any later configuration updates.
Next step: Repair setup-time cell advertisement before treating later handover failure as a pure RF problem.
The node keeps retrying Xn setup after rejection.
Likely cause: The peer is rejecting the relationship due to topology, protocol, or configuration mismatch.
What to inspect: Read Cause and Time To Wait in Xn Setup Failure and correlate them with the node identities and served cells in the original request.
Next step: Resolve the peer-admission mismatch, then retry after the instructed wait window.
LTE / 5G / Variant Comparison
Compared with NG Setup Request
NG Setup Request boots the access-to-core relationship on N2. Xn Setup Request boots the inter-node relationship inside NG-RAN.
Compared with F1 Setup Request
F1 Setup Request is internal to a split gNB between CU and DU. Xn Setup Request is between peer NG-RAN nodes preparing inter-node mobility and coordination.
Success versus failure outcome
Success makes the Xn relationship operational for later XnAP procedures. Failure keeps it non-operational and can instruct the initiator to back off before retry.
FAQ
What is Xn Setup Request in 5G XnAP?
It is the first non-UE-associated XnAP message used to establish an operational Xn relationship between NG-RAN nodes after the transport association becomes available.
What does Xn Setup Request carry?
At minimum it carries a Transaction ID and the initiating node identity. It can also advertise served-cell information and optional grouping data that the peer uses for inter-node coordination.
Why does Xn Setup matter in trace analysis?
Because later Xn handover, status transfer, and release procedures depend on the Xn relationship already being operational. If setup fails, those later procedures may never start.
What happens if the peer rejects the request?
The peer returns Xn Setup Failure with a cause and may include Time To Wait, which tells the initiating node to back off before retrying.
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.
