深度解析 3GPP TS 38.423：8.2.2 SN Status Transfer (序列号状态传递)

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.2.2 SN Status Transfer”的核心章节，旨在为读者提供一个关于5G切换中如何保证数据无缝传输的关键技术——序列号状态传递的全景视图。

1. 从“准备就绪”到“无缝接力”

在上一篇文章中，我们的主角工程师小林在陈工的指导下，深入学习了切换准备流程（Handover Preparation）。他了解到，源基站A已经成功地与目标基站B“沟通”完毕，B确认“万事俱备”，并回复了HANDOVER REQUEST ACKNOWLEDGE。控制层面的“交接意向”已经达成。

小林兴奋地说：“陈工，既然目标基站B已经准备好了，是不是源基站A马上就可以让李雷的手机切换过去了？”

陈工微笑着摇了摇头：“从控制层面看，是的。但从用户体验，尤其是数据传输的连续性来看，还差了至关重要的一步。想象一下，李雷正在下载一份几百兆的重要文件，同时他的视频会议也在持续上传数据流。在切换的瞬间，如果处理不当，下载的文件可能会出错重传，视频画面可能会出现马赛克甚至卡顿。为了避免这一切，基站A必须在‘放手’前，精确地告诉基站B，数据的‘接力棒’应该从哪里接起。这个过程，就是我们今天要学习的——SN Status Transfer。”

这一流程的核心使命，在规范8.2.2.1节“General”（概述）中被清晰定义：

The purpose of the SN Status Transfer procedure is to transfer the uplink PDCP SN and HFN receiver status and the downlink PDCP SN and HFN transmitter status either, from the source to the target NG-RAN node during an Xn handover… for each respective DRB of the source DRB configuration for which PDCP SN and HFN status preservation applies.

这段话揭示了该流程的本质：它是一个在切换期间，由源基站向目标基站单向传递PDCP层序列号（SN）和超帧号（HFN）状态的过程，目的是确保数据承载（DRB）的传输状态得以保留和延续。

2. 核心概念：为什么需要传递SN和HFN？

在深入流程细节之前，陈工决定先给小林补一堂基础课，讲解清楚为何“SN状态传递”如此关键。

“小林，你要理解，数据在空中传输时，为了保证可靠性和顺序，PDCP层会给每个数据包（PDU）打上一个序列号（Sequence Number, SN）。这就像邮局寄送一本书，会把每一页都编上页码。”

• 序列号 (SN) 的作用：接收方根据SN来判断数据包是否按顺序到达、是否有丢失。如果发现丢包，就可以触发重传机制。
• SN的局限性：PDCP SN的长度是有限的（例如12位或18位），在高速数据传输下，它会很快“回环”（wrap around），即从最大值跳回0。这就好比一本只有4096页（2^12）的书，你看完最后一页再翻就是第一页了。如果不对回环进行管理，接收方可能会混淆新的第100页和旧的第100页，导致数据错乱。
• 超帧号 (HFN) 的引入：为了解决SN回环问题，协议引入了超帧号（Hyper Frame Number, HFN）。HFN可以看作是书的“卷号”或“册号”。完整的序列号由HFN和SN共同组成，这个组合被称为COUNT值。COUNT = HFN * (SN的最大值 + 1) + SN。这样一来，即使SN回环了，HFN也会增加，保证了COUNT值的唯一性和单调递增，在一个极大的范围内都不会重复。这对于数据保序和安全（加密算法的输入参数之一）都至关重要。

“所以，”陈工总结道，“SN Status Transfer的本质，就是源基站A要告诉目标基站B，对于李雷的每一个数据业务（DRB），上行和下行方向的COUNT值分别进行到了哪里。这样，B站接手后，就能完美地续上，实现‘ lossless handover’（无损切换）。”

3. Class 2的效率：一场简洁的单向通知

陈工指着规范中的Figure 8.2.2.2-1: SN Status Transfer, successful operation。这是一个极其简洁的流程图，只有一个从source NG-RAN node指向target NG-RAN node的SN STATUS TRANSFER消息。

“你看，这个流程被划分为Class 2，还记得是什么意思吗？”

小林立刻回答：“记得！Class 2流程是单向通知，发起方发送消息后不等待响应。”

“完全正确！”陈工赞许道，“源基站A只是在它认为合适的时机，将状态信息‘告知’B即可。这个时机通常是在它决定触发切换，即将向UE发送RRC切换指令之前。在这个时间点，源站会‘冻结’(freeze)其收发状态，生成一份状态快照，然后通过SN STATUS TRANSFER消息发出去。这样做效率极高，因为A不需要等待B的确认，可以立即进行后续操作。”

3.1 消息的内核：UL和DL的“交接清单”

让我们深入SN STATUS TRANSFER这个消息，看看它的“交接清单”里究竟写了什么。

For each DRB in the DRBs Subject To Status Transfer List IE, the source NG-RAN node shall include the DRB ID IE, the UL COUNT Value IE and the DL COUNT Value IE.

1. DL COUNT Value IE (下行COUNT值)

• 含义：这个值代表了源基站A作为发送方的状态。它告诉目标基站B，对于某个DRB（比如李雷的文件下载），下一个要发送的下行数据包的COUNT值应该是多少。换句话说，所有COUNT值比它小的数据包，基站A要么已经成功发送，要么正在转发给B。
• 目标基站B的行为：

  For each DRB in the DRBs Subject To Status Transfer List IE, the target NG-RAN node shall use the value of the PDCP SN contained within the DL COUNT Value IE for the first downlink packet for which there is no PDCP-SN yet assigned. 陈工解释说：“基站B收到这个值后，就如同拿到了发货清单的下一行。它知道，它需要给第一个新生成的下行数据包赋予这个COUNT值。同时，对于从A转发过来的旧数据包，B会先将它们发送出去，然后再开始发送自己新产生的数据包，从而保证了下行数据的完美衔接。”

2. UL COUNT Value IE (上行COUNT值)

• 含义：这个值代表了源基站A作为接收方的状态。它告诉目标基站B，对于某个DRB（比如李雷的视频会议上传），它期望从UE收到的下一个上行数据包的COUNT值应该是多少。所有比这个值小的COUNT，基站A都已经成功接收。
• 目标基站B的行为：

  For each DRB in the DRBs Subject To Status Transfer List IE, the target NG-RAN node shall not deliver any uplink packet which has a PDCP-SN lower than the value contained within the UL COUNT Value IE. 陈工进一步说明：“基站B拿到这个值后，就有了‘收货标准’。它知道，任何比这个值小的上行数据包都是重复的（因为A已经收过了），可以直接丢弃。这避免了上行数据的重复处理和乱序。B会从这个COUNT值开始，继续接收UE发送的新的上行数据。”

3.2 优化的艺术：UL PDCP SDU的接收状态位图

除了上下行的COUNT值，SN STATUS TRANSFER消息中还有一个非常精巧的可选IE，用于进一步优化上行传输。

The source NG-RAN node may also include in the SN STATUS TRANSFER message the missing and the received uplink SDUs in the Receive Status Of UL PDCP SDUs IE for each DRB for which the source NG-RAN node has accepted the request from the target NG-RAN node for uplink forwarding.

陈工的解读：“这个IE就像一份详细的‘收货勘误表’。UL COUNT Value只是告诉B，‘我期望收到第501号包裹’，但这隐含了一个假设，即501号之前的所有包裹都收到了。但实际情况可能是在A‘冻结’状态时，它已经收到了501、502，但中间的498号包裹因为空口丢包还没到。这时，Receive Status Of UL PDCP SDUs IE就派上用场了。”

它是一个位图（bitmap），以UL COUNT Value为基准，向前描述一定窗口内每个上行数据包的接收状态（“0”代表没收到，“1”代表已收到）。

• 目标基站B的行为：

  If the Receive Status Of UL PDCP SDUs IE is included … the target NG-RAN node may use it in a Status Report message sent to the UE over the radio interface. “基站B拿到这张‘勘误表’后，它可以生成一个精确的PDCP状态报告（Status Report）发给李雷的手机，告诉它：‘498号包裹我没收到，请重传’。这样就避免了UE对已成功接收的数据进行不必要的重传，或者等待超时才重传丢失的数据，极大地优化了上行恢复的效率和时延。”

4. 流程的边界：异常与特殊场景

4.1 8.2.2.3 Unsuccessful Operation (失败操作)

规范中明确指出：“Not applicable.”。

陈工的解释：“因为这是Class 2流程，它天生就没有‘失败’的概念。源基站只负责发送，不关心目标基站是否成功接收或处理。底层SCTP协议会保证消息的可靠送达，如果SCTP链路本身断了，那属于更底层的故障，会在其他层面（如第6章所述）进行处理，而不属于XnAP流程本身的失败。”

4.2 8.2.2.4 Abnormal Conditions (异常条件)

If the target NG-RAN node receives this message for a UE for which no prepared handover exists at the target NG-RAN node, the target NG-RAN node shall ignore the message.

陈工的解读：“这是一个健壮性设计。设想一下，基站B收到了一个关于李雷的SN STATUS TRANSFER消息，但它在自己的记录里查不到任何关于李雷的切换准备信息（可能之前的HANDOVER REQUEST消息丢失了，或者流程已经超时取消了）。这时候，B不能因此而崩溃或产生错误状态。规范要求它必须**忽略（ignore）**这个消息。这就像你收到了一个陌生人的包裹清单，正确的做法就是直接扔掉，而不是试图去处理它。”

5. 总结：切换体验的“定海神针”

小林恍然大悟，他现在明白，SN Status Transfer流程虽然简单，却在切换过程中扮演着不可或缺的角色。它像一座桥梁，将源基站的用户平面状态精确、高效地同步给目标基站，确保了数据流在控制权交接的瞬间，依然能够平滑、无损地继续传输。

• 它是无损切换的核心：通过传递DL/UL COUNT值，避免了数据的丢失和重复。
• 它是高效切换的保障：采用Class 2单向通知模式，最大程度地减少了信令交互时延。
• 它是智能优化的体现：通过可选的接收状态位图，实现了上行数据重传的精确控制。

对于协议开发者小林而言，实现这个流程需要对PDCP层有深刻的理解，并能精确地在“冻结”状态的时刻点抓取和封装COUNT值。对于网络优化工程师而言，当遇到切换过程中的数据业务中断或速率抖动问题时，SN STATUS TRANSFER消息的内容将是定位问题的关键线索。

在下一篇文章中，我们将继续探讨移动性管理中的另一个重要流程：Handover Cancel (切换取消)，看看在切换决策发生变化时，基站之间又是如何优雅地“反悔”的。

FAQ

Q1：PDCP SN和HFN具体是多长？ A1：PDCP SN的长度是可配置的，通常为12位或18位。对于一个12位的SN，其取值范围是0-4095；对于18位的SN，其取值范围是0-262143。HFN的长度则取决于SN的长度，其目的是与SN组合成一个足够长的COUNT值，以防止在很长时间内发生回环。例如，对于12位SN，HFN长度为20位，组成的COUNT总长32位。

Q2：SN Status Transfer消息是在切换的哪个具体时间点发送的？ A2：规范定义为“at the time point when it considers the transmitter/receiver status to be frozen”。这是一个由具体实现决定的时刻。通常，源基站会在RRC层生成了发往UE的切换指令（RRCReconfiguration消息）之后，但在真正通过空口发送该指令之前，发送SN STATUS TRANSFER消息。因为一旦UE收到切换指令，它就会立刻尝试接入目标小区，此时源站的PDCP状态必须被“冻结”并传递出去。

Q3：对于DAPS（Dual Active Protocol Stack）切换，SN Status Transfer流程有何不同？ A3：DAPS切换是一种“先连接再断开”的更平滑切换方式，在切换过程中UE会同时与源站和目标站保持连接。规范在8.2.2.1节中提到：In case that the Xn handover is a DAPS handover, the SN Status Transfer procedure may also be used to transfer the ... status for a DRB associated with RLC-UM...。对于使用RLC-UM（非确认模式）的DRB（通常是低时延业务），也可以通过SN Status Transfer来同步状态，帮助目标站更快地接管业务，尽管UM模式本身不保证100%可靠。对于RLC-AM（确认模式）的DRB，在DAPS期间，上下行数据可以继续在源站传输，直到路径切换到目标站，SN Status Transfer的发送时机和处理会更加复杂，需要确保两个节点间的状态精确同步。

Q4：如果SCTP链路出现故障，导致SN STATUS TRANSFER消息丢失了会怎么样？ A4：SCTP协议本身提供了可靠传输机制，会进行重传，因此消息丢失是小概率事件。但如果链路彻底中断，或者在SCTP重传超时后消息仍未送达，目标基站B就收不到这份“交接清单”。其后果是：B不知道应该从哪个下行COUNT值开始发送新数据，可能会导致数据重复或丢失。同时，B也不知道UE的上行数据接收到了哪里，可能会将UE发来的正常数据当作重传包丢弃。最终，这种状态不一致会依靠更上层的TCP/IP协议或应用层的重传来纠正，但必然会导致用户体验的明显下降，如视频卡顿、下载速度骤降等。

Q5：SN Status Transfer流程是否也用于双连接（Dual Connectivity）场景？ A5：是的。规范在8.2.2.1节的概述中明确提到，该流程也用于“between the NG-RAN nodes involved in dual connectivity”。例如，当一个承载从主节点（MN）切换到次节点（SN）时（承载类型变更），MN就需要将该承载的SN状态传递给SN，以保证数据流平滑地切换路径。在这种场景下，“source NG-RAN node”就对应于MN，“target NG-RAN node”对应于SN。