长文log分析：带I-UPF插入的Xn切换

在规范中是在23502的

4.9.1.2.3 Xn based inter NG-RAN handover with insertion of intermediate UPF定义。

如下图：

站在核心网的角度来看，主要就是从

第1步的N2消息：path switch request到第9步的path switch request ack结束。

那让我们来看下主要步骤的log吧。直接上log。

但不包括XnAP部分，那个属于基站之间的信令，需无线侧配合，抓不到。

使用的wireshark filter是ngap or http2 or pfcp。

2024年04月14日 15:32

具体整体分析说明：

1）看Time列，发现从#8597开始到#8729基本结束，整个过程大概是1秒多。还可以。但不包括基站侧

XnAP。

2）#8597 path switch request开始到#path switch request ack基本结束。后面是UE补一个MRU注册流

程、N4会话的修改流程（到老的UPF）。

来看具体的主要步骤log。

1）目标gNB给AMF发path switch request。

- PathSwitchRequest总共有5个item，item0到item4。

- SourceAMF-UE-NGAP-ID：AMF侧的UE ID；

- UserLocationInformation：UE当前的位置信息（注意，这个是目标gNb发的，实际上是目标TAC。UE人

已经到了目标TAC了。）

- PDUSessionResourceToBeSwitchedDLList：需要切换的PDU会话资源列表。展开后，得到俩孙参数。

• pDUSessionID: 5

• dL-NGU-UP-TNLInformation：目标gNB侧的N3口地址和TEID。用于下行数据的传送。这个是后续要

发给I-UPF的。

2）AMF调用SMF的服务，发起SM上下文的修改。

这里SMF不变，不涉及SMF的选择问题。

包括一个#8599的header帧，以及携带的数据帧#8631。通过steam id=5来关联。就是图上那个[5]。

header帧里有一个smcontextref就是上下文的ID，本例为1021526832。通过这个ID，SMF可以在本地找

到关联的上下文。这个ID是在PDU会话建立的时候由SMF分配的。

再来看data帧。

- 注意，Data帧启用了多段封装MIME Multipart Media Encapsulation。所以一个data帧可以封装不同类型

的payload数据。

- 第1段数据类型是application/json，是AMF发给SMF的参数。包含5个参数。

• ueLocation：UE当前位置

• toBeSwitched：布尔值。取值为true表示需要切换。

• failedToBeSwitched：布尔值。取值为false表示没有切换失败的。

• n2SmInfo和n2SmInfoType：N2消息的信息和类型，其中type的取值为PATH_SWITCH_REQ

- 第2段数据类型是application/vnd.3gpp.ngap，是gNB发给SMF的参数，AMF只是做一个透传。

• dL-NGU-UP-TNLInformation：目标gNB侧的N3口地址和TEID，从前面的N2消息里复制粘贴过来的。

3）SMF根据UE的位置判断，当前的UPF无法为UE服务，判读需要插入一个I-UPF来搭桥。因此触发了IUPF的选择过程。选择原则是dnn、upf支持的切片、UE位置等。本步骤没有包，属于smf内部流程。

4）SMF向选择的I-UPF发起N4会话建立流程。

- 在N4建立请求中，SMF向I-UPF发放PDR、FAR、QER等规则。其中，一定会在某个FAR中将目标gNB

的N3口地址和TEID发给I-UPF，用于下行数据的发送。

5）I-UPF回N4会话建立响应。

【为求简洁，无关的参数没有展开。】

- 在响应消息中，I-UPF需要分配两个用户面的地址和TEID，一个是给上行方向的目标gNB使用是N3，一

个是给下行方向的PSA-UPF使用是N9。这俩都是在 Created PDR（过去时态，表示分配好了）里分配

的。

• 有一个Created PDR的TEID是76000003；

• 有一个Created PDR的TEID是76000004；

• 具体谁是上行、谁是给下行的。要看关联的PDR ID在N4的会话建立请求消息中是如何描述的。这里一

个PDR ID是5，一个PDR ID是4。

【注：关于SEID、F-SEID有啥区别，请看精华合集的这篇文章。

1）N4接口PFCP协议中的SEID、CP F-SEID、UP F-SEID有啥区别？

https://t.zsxq.com/19ICZEey5】

6）SMF给PSA-UPF发N4会话修改请求，把I-UPF的N9口地址发给PSA-UPF。

- 目标gNB的N9地址和teid通过update far发给PSA-UPF。可以看到。这里的取值是76000004。上一步由

I-UPF分配的。

7）SMF给AMF回200 OK。作为对第2步（#8599帧）的响应。

同样携带了header和data帧，steam id=5用于请求和响应消息的关联。

展开data帧。

- 这个同样也是多段封装。

• 第1段是application/json，是SMF发给AMF的参数。包括n2SmInfoType取值为

PATH_SWITCH_REQ_ACK。表示需要AMF透传给目标gNB的是一个Path Switch Request Ack消息。

• 第2段是application/vnd.3gpp.ngap，是SMF需要AMF透传给gNB的参数。包括uL-NGU-UP-

TNLInformation，里边是i-UPF的N3口地址和TEID。可以看到TEID的取值是76000003。

8）AMF把Path Switch Request Ack消息透传给目标gNB。

- 消息里包含了I-UPF的N3口地址和TEID，可以看到TEID的取值为76000003。

至此，切换的上下行用户面通道完全打通了。

UE--目标gNB--I-UPF--PSA-UPF。

后续是UE补一个MRU的流程。

9）最后，SMF还要给PSA-UPF发一个N4会话修改流程。

作用是要求PSA-UPF将到源gNB的N3隧道释放掉。

这个也很重要，因为切换完成了，老的N3隧道自然就是要释放了。

从信令层面，怎么要求UPF释放隧道呢？就是把update far里的TEID和用户面地址置0，如图所示。

还有一个问题，这个怎么看出来释放的是到源gNB的N3隧道呢。这个要结合N4会话建立请求去看。光看

这一个包是看不出的。线索是，根据PFCP Session Modification Request消息里的update far的FAR ID，

找到N4会话建立请求里边关联的是哪个PDR，再根据PDR中的PDI的描述信息来判断是到哪里的。