5GC实践篇之切片篇第11篇：RAN间直接重定向

这种场景在实际网络中经常发生，常见触发条件包括：

RAN链路故障导致的路由偏差：RAN因与目标AMF的NG链路故障，将UE的初始NAS消息路由到了一个不支持UE请求切片的AMF；
RAN配置不完整：RAN未配置所有AMF的切片支持信息，导致初始路由不够精确；
AMF Set扩容后信息未同步：新增AMF实例后，RAN未及时更新NG Setup中的切片映射信息。

理解直接重定向流程对于网络运维人员排查"UE注册失败"或"切片不可用"等问题至关重要。

2 协议规范与关键技术

2.1 相关协议规范

本篇涉及的协议规范重点在于AMF重选与NSSF交互：

TS 23.501 第6.3.5节：AMF发现与选择机制，定义了AMF重选的触发条件和处理方式。
TS 23.502 第4.2.2.2.3节：Registration with AMF re-allocation流程，详细描述了初始AMF向NSSF查询并重定向到目标AMF的完整步骤。
TS 29.531：Nnssf_NSSelection服务接口，定义了Nnssf_NSSelection_Get请求和响应的消息格式。
TS 29.507：Namf_Communication服务接口，定义了N1MessageNotify等AMF间通信消息。
TS 38.413：NGAP协议，定义了UE CONTEXT MODIFY REQUEST/RESPONSE等消息，用于RAN更新UE与AMF的关联。
TS 29.510：NRF服务接口，AMF通过Nnrf_NFDiscovery查找目标AMF的NF Profile。

2.2 直接重定向与间接重定向

5G系统定义了两种AMF重定向方式：

对比维度	直接重定向（Direct Reroute）	间接重定向（Indirect Reroute）
NAS消息传递	初始AMF直接发送给目标AMF	初始AMF通过RAN中转
使用的接口	Namf_Communication_N1MessageNotify	NGAP Reroute NAS Request
RAN感知时机	较晚（目标AMF通知RAN时）	较早（初始AMF通知RAN时）
初始AMF角色	主动将NAS消息转发给目标AMF	让RAN重新发起Initial UE Message
信令开销	较少（无需RAN中转）	较多（RAN需要重新路由）
适用场景	初始AMF与目标AMF可达	RAN需要参与路由决策

本篇聚焦直接重定向方式。

2.3 Nnssf_NSSelection_Get的关键参数

初始AMF在判断自己无法为UE服务后，向NSSF发起Nnssf_NSSelection_Get请求，获取目标AMF信息：

请求参数	说明
targetNssai	UE请求的S-NSSAI列表
homePlmnId	UE归属PLMN标识
tai	UE当前所在的跟踪区
nfType	请求的NF类型（AMF）
subscriptionInfo	UE签约切片信息

NSSF响应中返回的关键信息：

响应参数	说明
targetAmfSet	推荐的目标AMF Set
targetAmfService	目标AMF服务实例
candidateAmfList	候选AMF列表（含GUAMI和NF Profile）
allowedNssai	在目标AMF中允许的NSSAI

3 消息流程与详细解读

3.1 整体流程概览


sequenceDiagram

    participant UE as UE终端

    participant RAN as NG-RAN

    participant IAMF as Initial AMF

    participant NSSF as NSSF

    participant NRF as NRF

    participant TAMF as Target AMF

    participant UDM as UDM

    UE->>RAN: RRC Setup + NAS Registration Request<br/>携带Requested NSSAI

    Note over UE,RAN: RAN因链路故障等原因<br/>将消息路由到Initial AMF

    RAN->>IAMF: NGAP Initial UE Message<br/>NAS Registration Request + Requested NSSAI

    IAMF->>IAMF: 解析Requested NSSAI<br/>判断本AMF不支持该切片

    IAMF->>UDM: Nudm_SDM_Get(SUPI)<br/>获取UE签约数据

    UDM-->>IAMF: Subscribed NSSAI

    Note over IAMF: 校验Requested NSSAI在签约中<br/>但本AMF不支持<br/>需要查询NSSF

    IAMF->>NSSF: Nnssf_NSSelection_Get<br/>携带targetNssai + TAI

    NSSF-->>IAMF: 返回targetAmfSet + candidateAmfList

    IAMF->>NRF: Nnrf_NFDiscovery_Request<br/>查询目标AMF的NF Profile

    NRF-->>IAMF: 返回Target AMF地址

    IAMF->>TAMF: Namf_Communication_N1MessageNotify<br/>转发NAS Registration Request

    Note over IAMF,TAMF: 直接重定向<br/>初始AMF将NAS消息直接发给目标AMF

    TAMF->>TAMF: 处理Registration Request<br/>确定Allowed NSSAI

    TAMF->>RAN: NGAP UE CONTEXT MODIFY REQUEST<br/>通知RAN更新AMF关联

    Note over TAMF,RAN: 目标AMF接管UE<br/>RAN更新下行路径

    RAN-->>TAMF: NGAP UE CONTEXT MODIFY RESPONSE

    TAMF->>RAN: NGAP Downlink NAS Transport<br/>Registration Accept + Allowed NSSAI

    RAN->>UE: NAS Registration Accept<br/>Allowed NSSAI + 新5G-GUTI

3.2 流程详细解读

步骤1：UE发起注册请求

UE开机或触发移动性注册更新，在RRC Setup中携带Requested NSSAI。假设UE请求的切片为SST=2（URLLC），这是一个需要专用AMF支持的切片类型。

步骤2：RAN路由到Initial AMF

正常情况下，RAN应该根据NG Setup时获取的AMF切片支持信息，将UE路由到支持SST=2的AMF。但由于以下原因之一，RAN将消息路由到了不支持SST=2的Initial AMF：

RAN与目标AMF之间的NG链路故障；
RAN的切片路由配置不完整；
RAN负载均衡策略选择了其他AMF。

步骤3：Initial AMF解析并判断

Initial AMF收到NAS Registration Request后：

从Initial UE Message中提取Requested NSSAI（SST=2）；
查询本地配置，发现本AMF不支持SST=2（仅支持SST=1和SST=3）；
但SST=2可能是合法的（在UE签约数据中），AMF不能直接拒绝。

步骤4：Initial AMF向UDM获取签约数据

AMF通过Nudm_SDM_Get向UDM获取UE的签约NSSAI数据，确认SST=2确实在签约列表中。这证明UE的请求是合法的，只是当前AMF不支持该切片。

步骤5：Initial AMF向NSSF查询目标AMF

AMF确认自己无法为UE服务后，向NSSF发起Nnssf_NSSelection_Get请求：


Nnssf_NSSelection_Get Request:

  targetNssai: [{"sst": 2}]

  homePlmnId: {"mcc": "460", "mnc": "88"}

  tai: {"plmnId": {"mcc": "460", "mnc": "88"}, "tac": "A001"}

NSSF根据切片部署拓扑和AMF能力信息，返回目标AMF Set和候选AMF列表。

步骤6：Initial AMF通过NRF获取Target AMF地址

AMF通过Nnrf_NFDiscovery_Request查询目标AMF的具体地址信息，包括：

AMF的NF Instance ID
AMF的IP地址和端口号
AMF支持的S-NSSAI列表（验证用）

步骤7：直接重定向——Initial AMF转发NAS消息

这是本篇的核心步骤。Initial AMF通过Namf_Communication_N1MessageNotify接口将NAS Registration Request消息直接转发给Target AMF：


Namf_Communication_N1MessageNotify:

  n1MessageContainer:

    n1MessageClass: "5GMM"

    n1MessageContent:

      contentType: "application/nas"

      content: <NAS Registration Request原始消息>

  ueContextId: "imsi-4608800000XXXXXX"

Target AMF收到后，相当于直接接收了UE的Registration Request，开始正常的注册处理流程。

步骤8：Target AMF处理注册并发起UE Context Modify

Target AMF处理注册请求，确定Allowed NSSAI。由于Target AMF支持SST=2，UE请求的切片被允许。

关键的是，Target AMF需要通知RAN更新UE的AMF关联关系。因为此时RAN仍然认为UE的Serving AMF是Initial AMF。Target AMF通过NGAP UE CONTEXT MODIFY REQUEST消息通知RAN：


UE CONTEXT MODIFY REQUEST:

  AMF UE NGAP ID: <新分配>

  RAN UE NGAP ID: <从NAS消息中获取>

  Allowed NSSAI: SST=2

  ServeNFForAmfSet: <Target AMF信息>

RAN收到后更新本地UE上下文，将后续的下行NAS消息路由到Target AMF。

步骤9：Target AMF下发Registration Accept

Target AMF通过NGAP Downlink NAS Transport消息向UE发送Registration Accept，携带Allowed NSSAI（含SST=2）和新分配的5G-GUTI。

3.3 AMF直接重定向决策流程


flowchart TD

    A[Initial AMF收到Registration Request] --> B[提取Requested NSSAI]

    B --> C{本AMF是否支持Requested NSSAI}

    C --> D[支持：继续正常注册流程]

    C --> E[不支持：获取UDM签约数据]

    E --> F{Requested NSSAI是否在签约数据中}

    F --> G[不在签约中：拒绝或排除]

    F --> H[在签约中：需要AMF重选]

    H --> I[向NSSF查询Nnssf_NSSelection_Get]

    I --> J[NSSF返回目标AMF Set和候选列表]

    J --> K[通过NRF查询目标AMF具体地址]

    K --> L{采用何种重定向方式}

    L --> M[直接重定向：N1MessageNotify转发NAS]

    L --> N[间接重定向：通过RAN Reroute]

    M --> O[Target AMF处理注册]

    O --> P[Target AMF通知RAN更新UE Context]

    P --> Q[Registration Accept下发]

4 关键信令参数分析

4.1 NGAP Initial UE Message参数

参数名称	值	说明
RAN UE NGAP ID	0x0001	RAN侧分配
User Location Information	TAI: 46088-A001, Cell: 0x01	UE位置
NSSAI	SST=2	RRC层携带的切片信息
FiveG-S-TMSI	N/A	本次未携带

4.2 Nudm_SDM_Get Response（签约数据）


{

  "nssai": {

    "defaultSingleNssais": [

      {"sst": 1, "sd": "010203"},

      {"sst": 2}

    ],

    "singleNssais": [

      {"sst": 1, "sd": "010203"},

      {"sst": 2},

      {"sst": 3}

    ]

  }

}

分析：SST=2在签约列表中，证明UE的请求合法，但Initial AMF不支持。

4.3 Nnssf_NSSelection_Get请求与响应

请求参数：

参数	值	说明
targetNssai	[{"sst": 2}]	UE请求的目标切片
homePlmnId	{"mcc":"460","mnc":"88"}	归属PLMN
tai	{"plmnId":{"mcc":"460","mnc":"88"},"tac":"A001"}	UE当前位置
nfType	AMF	请求查询的NF类型

响应参数：


{

  "targetAmfSet": "460-88-02-01",

  "allowedNssai": [

    {"allowedSnssai": {"sst": 2}}

  ],

  "candidateAmfList": [

    {

      "amfInstance": "amf-02-set01-instance01",

      "guami": {

        "plmnId": {"mcc": "460", "mnc": "88"},

        "amfRegionId": "02",

        "amfSetId": "01",

        "amfPointer": "00"

      }

    }

  ]

}

4.4 Namf_Communication_N1MessageNotify消息

参数名称	值	说明
n1MessageClass	5GMM	NAS消息类型

contentType | application/nas | 消息格式 |

ueContextId	imsi-4608800000XXXXXX	UE标识
n1MessageContent	NAS Registration Request	转发的原始NAS消息

4.5 UE CONTEXT MODIFY REQUEST参数

参数名称	值	说明
AMF UE NGAP ID	0x1001	Target AMF分配的新ID
RAN UE NGAP ID	0x0001	与原RAN UE NGAP ID一致
Allowed NSSAI	SST=2	允许的切片
Security Key	<新的安全密钥>	Target AMF的安全上下文

4.6 AMF CLI验证数据

Initial AMF重定向日志（脱敏）：


# Initial AMF Reroute Log

Time: 2026-04-17 14:30:01.100

SUPI: imsi-4608800000XXXXXX

GPSI: 86138000XXXXXX

Received Initial UE Message:

  RAN UE NGAP ID: 0x0001

  NSSAI: SST=2 (URLLC)

  TAI: 46088-A001

Local Slice Capability Check:

  AMF Supported NSSAI: [SST=1, SST=3]

  Requested SST=2: NOT SUPPORTED

UDM Subscription Verification:

  Subscribed NSSAI: [SST=1/SD=010203, SST=2, SST=3]

  SST=2 in Subscription: YES

  Decision: AMF Reallocation Required

NSSF Query:

  Request: targetNssai=[SST=2], TAI=46088-A001

  Response: targetAmfSet=460-88-02-01

    candidateAmf: amf-02-set01-instance01

    GUAMI: 460-88-02-01-00

NRF Discovery:

  Target AMF FQDN: amf02.set01.mnc088.mcc460.5gc.mnc.mobilenetwork

  Target AMF IP: 10.x.x.x

  Target AMF Port: 8443

Direct Reroute Action:

  Method: Namf_Communication_N1MessageNotify

  Target: amf-02-set01-instance01

  NAS Message: Registration Request (forwarded as-is)

  Result: 200 OK

Target AMF注册处理日志（脱敏）：


# Target AMF Registration Log

Time: 2026-04-17 14:30:01.350

SUPI: imsi-4608800000XXXXXX

Received N1MessageNotify from AMF amf-01-set01-instance01

  NAS Message: Registration Request

  Requested NSSAI: SST=2 (URLLC)

Local Slice Capability Check:

  AMF Supported NSSAI: [SST=2, SST=4]

  Requested SST=2: SUPPORTED

Allowed NSSAI Calculation:

  SST=2: in Subscribed=YES, AMF Supported=YES -> ALLOWED

  Allowed NSSAI: [SST=2]

UE Context Modify to RAN:

  RAN UE NGAP ID: 0x0001

  New AMF UE NGAP ID: 0x1001

  Allowed NSSAI: SST=2

  Result: UE CONTEXT MODIFY RESPONSE received

Registration Accept sent:

  New 5G-GUTI: 460-88-02-01-00-0xNewTMSI001

  Allowed NSSAI: [SST=2]

5 测试验证与数据解读

5.1 测试预置条件

本场景的测试预置条件包括：

部署至少两组AMF，分别支持不同的切片组合；
Initial AMF支持SST=1和SST=3，不支持SST=2；
Target AMF支持SST=2和SST=4；
NSSF已配置切片与AMF Set的映射关系；
RAN与Target AMF之间的NG链路存在故障或RAN配置不完整，导致初始路由到Initial AMF；
UE在UDM中签约了SST=2切片。

5.2 验证要点

验证点1：Initial AMF正确识别不支持Requested NSSAI

在Initial AMF的消息跟踪中确认：

AMF正确解析了Requested NSSAI中的SST=2；
AMF查询本地配置发现不支持SST=2；
AMF没有直接拒绝UE（因为SST=2在签约中）。

验证点2：NSSF正确返回目标AMF信息

在Nnssf_NSSelection_Get接口跟踪中确认：

NSSF返回了正确的targetAmfSet；
candidateAmfList中包含支持SST=2的AMF实例；
Allowed NSSAI包含SST=2。

验证点3：直接重定向成功

在Namf_Communication接口跟踪中确认：

Initial AMF通过N1MessageNotify将NAS消息转发给Target AMF；
Target AMF返回200 OK；
NAS消息被完整转发（未被修改）。

验证点4：RAN更新UE Context

在NGAP消息跟踪中确认：

Target AMF向RAN发送UE CONTEXT MODIFY REQUEST；
RAN返回UE CONTEXT MODIFY RESPONSE；
后续下行NAS消息通过Target AMF发送。

验证点5：UE最终获得正确的Allowed NSSAI

在NAS消息跟踪中确认：

Registration Accept中的Allowed NSSAI包含SST=2；
UE分配到了Target AMF的5G-GUTI（GUAMI中的AMF Region/Set ID与Target AMF一致）。

5.3 数据解读

通过分析测试数据，可以得出以下关键结论：

直接重定向对UE透明：UE全程不知道发生了AMF重定向。UE发送了Registration Request，最终收到了Registration Accept，与正常注册流程体验一致。唯一的线索是5G-GUTI中AMF信息的变化。
Initial AMF的"善意中转"角色：Initial AMF虽然不能为UE提供服务，但它承担了"中转站"的角色——获取签约数据、查询NSSF、转发NAS消息。这体现了5G网络中AMF间协作的设计理念。
UE CONTEXT MODIFY的关键作用：直接重定向流程中，RAN在最后阶段才通过UE CONTEXT MODIFY REQUEST感知到AMF变更。在此之前，RAN可能仍向Initial AMF发送UE的上行消息。实际部署中需要注意这个时间窗口可能导致的消息丢失问题。
NSSF作为切片路由的核心：NSSF在网络中扮演着"切片路由表"的角色，维护着切片与AMF Set的映射关系。NSSF的配置准确性直接决定了AMF重定向的效率。

6 小结与思考

6.1 本篇小结

本篇详细分析了5G切片场景中AMF/RAN直接重定向的完整流程。关键要点如下：

触发条件：初始AMF不支持UE请求的切片，但该切片在UE签约数据中。典型原因是RAN路由偏差（链路故障、配置不完整等）。
核心流程：Initial AMF获取签约数据 -> 查询NSSF获取目标AMF -> 通过NRF获取目标AMF地址 -> 通过N1MessageNotify转发NAS消息 -> Target AMF通知RAN更新UE Context。
直接重定向的特点：AMF之间直接交互，RAN感知较晚，信令开销较少，适合AMF间网络可达的场景。
UE透明性：UE不知道发生了AMF重定向，Registration Accept中的Allowed NSSAI和新5G-GUTI是UE可感知的唯一变化。

6.2 延伸思考

思考1：直接重定向的时间窗口问题

在直接重定向流程中，从Initial AMF转发NAS消息到Target AMF发送UE CONTEXT MODIFY REQUEST之间存在一个时间窗口。在这个窗口内，RAN仍然认为Initial AMF是UE的Serving AMF。如果此时UE有上行数据（如NAS消息），RAN会将消息发送给Initial AMF而非Target AMF。Initial AMF需要将收到的消息也转发给Target AMF，或者丢弃。不同厂商的实现策略可能不同，这是运维排障时需要注意的。

思考2：NSSF配置与AMF部署的协同

NSSF的切片-AMF映射配置必须与实际AMF部署保持同步。当运营商新增AMF实例或调整AMF支持的切片时，NSSF配置也需要同步更新。否则可能导致AMF重定向到错误的AMF，形成"重定向循环"。建议在网络规划时建立AMF切片配置与NSSF映射表的联动更新机制。

思考3：直接重定向 vs 间接重定向的选择

选择哪种重定向方式取决于网络拓扑和运维策略。直接重定向信令开销小但RAN感知晚，间接重定向RAN感知早但需要RAN参与路由。在实际部署中，两种方式通常都被支持，运营商可以根据网络条件选择。部分厂商支持配置优先使用哪种方式。

5GC实践篇之切片篇第11篇：RAN间直接重定向

5GC实践篇之切片篇第11篇：RAN间直接重定向

1 测试背景与用例简介

2 协议规范与关键技术

2.1 相关协议规范

2.2 直接重定向与间接重定向

2.3 Nnssf_NSSelection_Get的关键参数

3 消息流程与详细解读

3.1 整体流程概览

3.2 流程详细解读

3.3 AMF直接重定向决策流程

4 关键信令参数分析

4.1 NGAP Initial UE Message参数

4.2 Nudm_SDM_Get Response（签约数据）

4.3 Nnssf_NSSelection_Get请求与响应

4.4 Namf_Communication_N1MessageNotify消息

4.5 UE CONTEXT MODIFY REQUEST参数

4.6 AMF CLI验证数据

5 测试验证与数据解读

5.1 测试预置条件

5.2 验证要点

5.3 数据解读

6 小结与思考

6.1 本篇小结

6.2 延伸思考

查看完整内容