基于Xn接口的跨gNB基本切换流程

概述

        5GC中基于Xn接口的跨gNB基本切换流程类似于EPC中的基于X2接口的跨eNodeB切换流程。（规范中叫InterNR-RAN Handover流程）

主要触发过程如下：

1. UE已经在5G注册并建立了一个PDU会话并且正在上网， 并且已经通过某gNB（称为源gNB）接入到5GC。
2. UE发生位置移动， 离开该源gNB服务的小区即将进入新的目标gNB所在的服务小区。
3. 此时， UE发送测量报告给源gNB。gNB根据汉测量报告结果， 通知目标gNB和5GC发起本流程。

本场景中哪些网元发生了变化？

• gNB一定变了
• UPF可以变可以不变， 本PPT假设UPF没变（最常见）
• 其他网元一定都不变。

Xn基本切换流程涉及的协议：

23502：5GC信令流程
23501：5GC架构
38300：NG-RAN概述
38423：XnAP协议
29244：PFCP协议
38413：NGAP协议
29502：SMF服务
38331：NR的RRC

3GPP规范中的Xn-based切换流程（23502）

        This procedure is used to hand over a UE from a source NG-RAN to target NG-RAN using Xn when the AMF is unchanged and the SMF decides to keep the existing UPF.

3GPP规范中的Xn-based切换流程中各阶段详细步骤（38300）

        The intra-NR RAN handover performs the preparation and execution phase of the handover procedure performed without involvement of the 5GC, i.e. preparation messages are directly exchanged between the gNBs. The release of the resources at the source gNB during the handover completion phase is triggered by the target gNB. The figure below depicts the basic handover scenario where neither the AMF nor the UPF changes:

规范信令流程图中的“小遗憾”
规范中列出的信令流程图优点是大而全面，但也有小遗憾。主要体现在：

• 并没有结合具体的场景来介绍。例如图中的AMF和SMF是在哪里。拜访地归属地？
• 图中没有加入协议和主要消息和参数的说明，而是通寸图后的文字说明，不能一目了然。
• 两个规范里都是说的Xn切换流程，但38300没画和核心侧（SMF）信令、23502又没画准备阶段的信令。得人工打开多个规范对照学习。
• 图中箭头上的文字其实并不是消息的名称例如第2步写的是：Nsmf_PDUSession_UpdateSMContext Request， 但实际上上真正的消息名称是HTTP2 POST：/nsmf-pdusession/v1/sm-contexts/smContextRef/modify。这容易引起学习的困惑。

定制化（更符合实际网络）的Xn基本切换流程

基于以上“小遗憾”对规范中基本Xn切换流程进行了定制化。主要包括：

• 加入场景介绍。并标明了接口的协议和主要消息、参数。
• 结合国内EPC部署经验， 去掉不太可能在5GC中部署或早期部署的流程。使之更接近国内运营商实际网络。

定制化的Xn基本切换流程的场景如下：

• 假设北京东城区有专门的AMF、SMF以及数据中心。
• 假设北京东城区AMF的服务范围包括王府井和东单这两个gNB及所在小区。
• 某北京5G用户早上起床后开机，在王府井上了公交打开手机开始上网：即该UE已经在东城区AMF完成注册， 并已建立PIDU会话。用户平面路径为：UE→王府井gNB→东城区UPF→Internet。
• 此时， 公交向东单方向行驶， 即到东单gNB的信号越来越好， 和王府井gNB的信号越来越弱。UE发送测量报告触发了Xn基本切换流程。

切换流程的通用三部曲

1）切换准备（资源预留）

2）切换执行（赶人、走人）

3）切换完成（完全打通用户面通道）

38.423        

        If the HANDOVER REQUEST ACKNOWLEDGE message contains the UL Forwarding GTP Tunnel Endpoint IE for a given DRB in the Data Forwarding Response DRB List IE within Data Forwarding Info from target NG-RAN node IE in the PDU Session Resources Admitted List IE and the source NG-RAN node accepts the data forwarding proposed by the target NG-RAN node, the source NG-RAN node shall perform forwarding of uplink data for the DRB.

        9.2.1.16  Data Forwarding Info from target NG-RAN node   

        This IE contains TNL information for the establishment of data forwarding tunnels towards the target NG-RAN node.

        9.2.3.30        UP Transport Layer Information

        This element is used to provide the transport layer information associated with NG or Xn user plane transport. In this release it corresponds to an IP adress and a GTP Tunnel Endpoint Identifier. When the NR-DC UE is connected with an IAB, the QoS Mapping Information is used to set the IP header of packets in case that the S-NG-RAN node serves the IAB and the packets belonging to MN-terminated split bearer/SCG bearer are transmitted from M-NG-RAN node to S-NG-RAN node, and in case that the M-NG-RAN node serves the IAB and the packets belonging to SN-terminated split bearer/MCG bearer are transmitted from S-NG-RAN node to M-NG-RAN node.

反传相关：

• 源侧在发生XN HandoverRequest时携带需要建立反传的DRB

HANDOVER REQUEST-> PDU Session Resources To Be Setup List->PDU Session Resources To Be Setup Item-> Data Forwarding and Offloading Info from source NG-RAN node->

• 目标侧 在收到切换请求后标识需要反传的DRB（分配反传的Link info如Lind id、type），并在通知用户面建腿时同时建立反传隧道，获得F1-U、反传隧道的GTP-U信息。
• 目标侧通过XN HandoverRequestAcknowledge 将反传隧道GTPU信息告知切换源侧。
• 源侧收到反传隧道GTPU信息后，保存并为其分配Link info（Lind id、type）
• 源侧将反传隧道GTPU信息和link info 通知用户面（pdcp层模块）建立反传，获得pdcp sn info