nnginx配置接口

基于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）

without involvement of the 5GC,

规范信令流程图中的“小遗憾”

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

• 并没有结合具体的场景来介绍。例如图中的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   
 TNL information for the establishment of data forwarding tunnels towards the target NG-RAN node.
        9.2.3.30        UP Transport Layer Information

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