SN Status Transfer is the XnAP message the source NG-RAN node sends to the target NG-RAN node to transfer PDCP sequence-number and HFN status, and related mobility information, so the target can continue bearer handling without duplicate or out-of-order treatment errors.
Message Fact Sheet
Protocol
xnap
Network
5g
Spec
3GPP TS 38.423
Spec Section
SN Status Transfer procedure and SN STATUS TRANSFER functional definition (Release 18 baseline)
A prepared Xn handover, dual-connectivity context transfer, or UE context retrieval branch needs PDCP status continuity between two NG-RAN nodes.
Main purpose
Transfers per-DRB PDCP receive and transmit status, and related mobility context, so the target NG-RAN node can continue user-plane handling correctly after handover, dual connectivity context transfer, or UE context retrieval.
Main specification
3GPP TS 38.423, SN Status Transfer procedure and SN STATUS TRANSFER functional definition (Release 18 baseline)
Release added
Release 15
Procedures where used
SN Status Transfer, Xn handover, Dual connectivity status preservation, UE context retrieval continuity
What is SN Status Transfer in simple terms?
SN Status Transfer is the XnAP message the source NG-RAN node sends to the target NG-RAN node to transfer PDCP sequence-number and HFN status, and related mobility information, so the target can continue bearer handling without duplicate or out-of-order treatment errors.
Transfers per-DRB PDCP receive and transmit status, and related mobility context, so the target NG-RAN node can continue user-plane handling correctly after handover, dual connectivity context transfer, or UE context retrieval.
Why this message matters
SN Status Transfer is the source gNB telling the target gNB what PDCP status each important bearer had, so the target can continue traffic cleanly after the move.
Where this message appears in the call flow
Status transfer during Xn handover
Continuity branch: after target preparation, the source transfers PDCP status so the target can continue bearer handling correctly.
Call flow position: After handover preparation succeeds, the source transfers PDCP status for the relevant DRBs so the target can continue bearer handling correctly.
Typical state: The target already has prepared UE context and now needs per-DRB status continuity before or during execution follow-on.
Preconditions:
A prepared handover exists at the target NG-RAN node.
The source and target both know the UE-associated Xn identifiers.
At least one DRB requires PDCP status preservation.
Next likely message: UE Context Release or later execution-related continuity handling
DAPS or forwarding-aware status continuity
Per-bearer branch: each listed DRB carries UL and DL count state that the target uses for continuity.
Call flow position: The source transfers status for DRBs where DAPS or forwarding-sensitive continuity handling matters.
Typical state: The target needs the status values to avoid duplicate delivery or PDCP sequence confusion.
Preconditions:
The DRB configuration and mobility branch require PDCP SN and HFN preservation.
The source has the relevant UL and DL count state for the listed DRBs.
Next likely message: Target-side delivery using the transferred count state
Conditional handover or mobility-information carryover
Mobility-context branch: SN Status Transfer can also carry CHO or mobility-related information when the prepared branch needs it.
Call flow position: The source includes CHO Configuration or Mobility Information when the prepared branch needs additional mobility context beyond pure PDCP counters.
Typical state: The transfer remains a status-preservation procedure, but the target also stores mobility-related context.
Preconditions:
The source has CHO or mobility-related information relevant to the transferred branch.
The target supports storing and using that additional context.
Next likely message: Later target-side mobility handling using the stored CHO or mobility information
Call flow position
Previous message(s):Handover Request Acknowledge, Prepared handover state at target, Dual connectivity or UE context retrieval context transfer
Next message(s):UE Context Release, User-plane forwarding continuation, Target-side data delivery using transferred PDCP status
Message direction and transport
Sender and receiver: Source NG-RAN node -> Target NG-RAN node
Interface: Xn-C between source and target NG-RAN nodes
Transport / encapsulation: XnAP over SCTP/IP between source and target NG-RAN nodes
Security context: SN Status Transfer does not create a new security context. It preserves bearer continuity by transferring PDCP state associated with already prepared or transferred DRB context.
Message Structure Overview
SN Status Transfer is a one-way XnAP initiatingMessage from source to target.
The message is centered on DRBs Subject To Status Transfer List, which carries the PDCP receive and transmit continuity values per bearer.
The procedure has no defined unsuccessful operation. If the target has no prepared handover for the UE, it ignores the message.
CHO Configuration and Mobility Information make the message broader than a pure counter transfer when special mobility branches apply.
Read the UE IDs first, then work item by item through DRBs Subject To Status Transfer List. The real engineering value is in the per-DRB count state and any optional receive-status detail, not in the message header.
Per-DRB status is the real payload. The message header only tells you which prepared UE context the counts belong to.
The target must not deliver uplink packets with a PDCP-SN lower than the transferred UL COUNT Value for each listed DRB.
The target uses DL COUNT Value as the next PDCP-SN base for the first downlink packet that still needs a new sequence number.
If the target has no prepared handover for the UE, the message is ignored rather than rejected.
Important Information Elements
IE
Required
Description
Source NG-RAN node UE XnAP ID
Yes
Mandatory source-side UE identifier used to correlate the status transfer with the UE-associated Xn connection.
Target NG-RAN node UE XnAP ID
Yes
Mandatory target-side UE identifier representing the prepared or transferred UE context at the receiving node.
DRBs Subject To Status Transfer List
Yes
Mandatory per-DRB list carrying the PDCP status preservation information for the bearers that require transfer.
UL COUNT Value
Yes
Per-DRB uplink PDCP count state that tells the target which uplink PDCP SN values are already in play.
DL COUNT Value
Yes
Per-DRB downlink PDCP count state that tells the target what downlink PDCP SN to use next when needed.
Receive Status Of UL PDCP SDUs
Optional
Optional per-DRB receive-status detail that can help the target build a more accurate radio-side status report toward the UE.
Old QoS Flow List - UL End Marker expected
Optional
Optional per-DRB indication that prepares the target to receive SDAP end markers for the relevant QoS flows.
CHO Configuration
Optional
Optional conditional-handover related configuration that the target stores when the transfer concerns a CHO branch.
Mobility Information
Optional
Optional mobility-related information the target stores for later analysis or handling.
Detailed field explanation
Source NG-RAN node UE XnAP ID
Mandatory source-side UE identifier used to correlate the status transfer with the UE-associated Xn connection.
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.
Target NG-RAN node UE XnAP ID
Mandatory target-side UE identifier representing the prepared or transferred UE context at the receiving node.
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.
DRBs Subject To Status Transfer List
Mandatory per-DRB list carrying the PDCP status preservation information for the bearers that require transfer.
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.
UL COUNT Value
Per-DRB uplink PDCP count state that tells the target which uplink PDCP SN values are already in play.
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.
DL COUNT Value
Per-DRB downlink PDCP count state that tells the target what downlink PDCP SN to use next when needed.
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.
Receive Status Of UL PDCP SDUs
Optional per-DRB receive-status detail that can help the target build a more accurate radio-side status report toward the UE.
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.
Old QoS Flow List - UL End Marker expected
Optional per-DRB indication that prepares the target to receive SDAP end markers for the relevant QoS flows.
Presence: Optional
In practice: QoS rules are the real service profile of the session. Inspect the QFI mapping, packet filters, and precedence because those values explain how user traffic will actually be classified and forwarded.
CHO Configuration
Optional conditional-handover related configuration that the target stores when the transfer concerns a CHO branch.
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.
Mobility Information
Optional mobility-related information the target stores for later analysis or handling.
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 the target already has a prepared UE context before the source sends SN Status Transfer.
Capture both UE XnAP IDs and map them to the prepared handover branch.
Inspect every DRB in DRBs Subject To Status Transfer List and record UL COUNT Value and DL COUNT Value.
If Receive Status Of UL PDCP SDUs is present, treat it as additional accuracy for target-side status handling rather than optional noise.
If CHO Configuration or Mobility Information is present, keep that mobility context attached to the status transfer branch.
Common Issues and Troubleshooting
The target sees duplicates or sequence confusion after handover.
Likely cause: PDCP count state may be missing, stale, or misread in DRBs Subject To Status Transfer List.
What to inspect: Compare UL COUNT Value and DL COUNT Value against the source-side last known PDCP state for the affected DRB.
Next step: Debug status-transfer continuity first before blaming the radio move itself.
The target ignores SN Status Transfer.
Likely cause: The target may not have a prepared handover for that UE, which the spec says leads to ignore behavior rather than failure signaling.
What to inspect: Check whether Handover Request Acknowledge created a prepared handover for the same UE IDs before SN Status Transfer arrived.
Next step: Fix preparation correlation and timing before expecting the target to apply PDCP status.
UL forwarding or status reporting still looks incomplete.
Likely cause: Receive Status Of UL PDCP SDUs or forwarding-related end-marker expectations may be missing or inconsistent for some DRBs.
What to inspect: Review the per-DRB optional fields and compare them with the forwarding branch used for the handover.
Next step: Treat the issue as per-bearer continuity handling rather than a generic Xn signaling failure.
LTE / 5G / Variant Comparison
Compared with Handover Request Acknowledge
Handover Request Acknowledge proves target preparation succeeded. SN Status Transfer gives the target the per-bearer PDCP continuity state needed after that preparation.
Compared with UE Context Release
SN Status Transfer preserves bearer continuity before or around execution. UE Context Release later tells the source that old resources may now be released.
Compared with dual-connectivity status handling
The same message structure is used outside plain Xn handover when DRB context is transferred between nodes for dual connectivity or UE context retrieval.
FAQ
What is SN Status Transfer in 5G XnAP?
It is the source NG-RAN node to target NG-RAN node message used to transfer PDCP status and related continuity information for the relevant DRBs.
Does SN Status Transfer have a response message?
No. The elementary procedure has no defined unsuccessful operation. If the target has no prepared handover for the UE, it ignores the message.
What is the key payload in SN Status Transfer?
The key payload is DRBs Subject To Status Transfer List, which carries UL COUNT Value, DL COUNT Value, and optional receive-status information per DRB.
Why is this message important in trace analysis?
Because handover admission may be fine while traffic continuity still fails due to incorrect or missing PDCP status preservation.
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.
