# 5G AMF重选与NAS重路由机制拆解 在5G核心网（5GC）的所有移动性管理流程中，有一条信令路径常常被忽略，却决定了切片能否真正落地——它就是**注册流程中的AMF重选（AMF Re-allocation）**。当(R)AN依据5G-GUTI或默认路由把一个注册请求投递给一个"初始AMF"，而该AMF发现自己并不支持UE请求的切片（S-NSSAI）时，整个注册请求必须被**重新路由**到一个真正能服务的目标AMF。这条"二次投递"链路，由TS 23.502第4.2.2.2.2条、TS 23.501第6.3.5/6.2.4条以及TS 38.413（NGAP）中的`Reroute NAS Request`消息共同定义，是理解5G"切片感知"网络功能选择的关键拼图。本文聚焦这一具体机制，逐步拆解其触发条件、信令时序、关键IE与设计意图。 --- ## 一、机制背景：为什么需要AMF重选 ### 1.1 从4G MME Pool到5G AMF Set 在4G EPC中，MME以Pool形式部署，Pool内的MME能力基本等价，(R)AN依据S-TMSI或负载均衡策略选择MME即可，几乎不存在"选错MME"的概念。5GC引入**网络切片（Network Slicing）**后，这一假设被打破：并非所有AMF都支持所有S-NSSAI。一个AMF Set可能只为eMBB切片服务，另一个AMF Set专门承载URLLC或运营商专网切片。 因此，5GC将AMF组织为**AMF Set**（TS 23.501 §6.2.4）： - 同一个AMF Set内的AMF共享相同的AMF Region ID； - 一个AMF Set服务一组S-NSSAI（即一组切片）； - 同一Set内的AMF可通过**UDSF（Unstructured Data Storage NF）**共享UE上下文，从而支持**无状态（stateless）AMF**。 这意味着：UE的注册请求可能被(R)AN投递到一个AMF Set A的实例，但UE订阅并请求的切片只由AMF Set B服务——此时必须发生**AMF重选**，把请求转交给Set B中的某个目标AMF。 ### 1.2 三种触发场景 AMF重选并不只在"切片不匹配"时发生。综合TS 23.501 §6.3.5与TS 23.502 §4.2.2.2，触发条件包括： | 触发场景 | 说明 | 典型依据来源 | |---------|------|-------------| | **切片不匹配** | 初始AMF所在Set不支持Allowed NSSAI中的全部S-NSSAI | TS 23.501 §6.3.5 | | **5G-GUTI失效/路由漂移** | UE使用旧5G-GUTI注册，该GUAMI指向的AMF在当前网络拓扑已不可达或非最优 | TS 23.502 §4.2.2.2 step 0 | | **运营策略/负载** | 运营商策略要求特定用户群体路由至专用AMF Set（如政企专网） | TS 23.501 §6.3.5 注 | 理解了背景，下面进入最核心的信令拆解。 --- ## 二、完整信令时序：AMF重选全过程 下图给出**经(R)AN重路由（Reroute via RAN）**这一最经典路径的完整时序，这也是TS 38.413中`Reroute NAS Request`消息的标准用法： ```mermaid sequenceDiagram participant UE participant RAN as (R)AN/gNB participant IAMF as 初始AMF
(AMF Set A) participant UDM participant NRF participant TAMF as 目标AMF
(AMF Set B) participant SMF UE->>RAN: Registration Request
(Requested NSSAI, 5G-GUTI/SUCI) Note over RAN: 依据5G-GUTI的GUAMI
或NSSAI选初始AMF RAN->>IAMF: N2 Initial UE Message
+ NAS Registration Request Note over IAMF: 识别UE(5G-GUTI)，
可能向old AMF取上下文 IAMF->>UDM: Nudm_UECM_Registration
+ Nudm_SDM_Get(订阅数据) UDM-->>IAMF: 订阅S-NSSAI / AMF Set指示 Note over IAMF: 计算Allowed NSSAI
发现自己Set无法全部服务 IAMF->>NRF: Nnrf_NFDiscovery_Request
(目标AMF Set, S-NSSAI) NRF-->>IAMF: 目标AMF Set B / 候选AMF列表 IAMF->>RAN: NGAP Reroute NAS Request
(NAS-PDU, AMF Set ID, Initial AMF Name) Note over RAN: 在Set B内选目标AMF RAN->>TAMF: N2 Initial UE Message
+ NAS-PDU + Initial AMF Name TAMF->>IAMF: Namf_Communication_UEContextTransfer
(取SUPI/MM上下文/安全上下文) IAMF-->>TAMF: UE上下文(SUPI, 安全上下文, SMF data) Note over TAMF: 续接注册流程
(鉴权/SMC可跳过) TAMF->>SMF: 会话相关处理(如需) TAMF-->>RAN: Registration Accept
(新5G-GUTI=Set B的GUAMI) RAN-->>UE: Registration Accept TAMF->>IAMF: Namf_Communication_
RegistrationCompleteStatus Note over IAMF: 释放临时UE上下文 ``` ### 2.1 逐步IE解析 **第1步 · UE → (R)AN：Registration Request（NAS）** | 关键IE | 含义 | 重选相关作用 | |--------|------|-------------| | `5GS Registration type` | 注册类型（初始/移动性/周期） | — | | `5G-GUTI` 或 `SUCI` | UE临时/永久身份 | 5G-GUTI中的GUAMI是(R)AN选初始AMF的依据 | | `Requested NSSAI` | UE请求的切片 | 若(R)AN能解析，可作为初始路由依据 | | `UE security capability` | UE支持的安全算法 | 目标AMF需据此建立SMC | (R)AN收到后，若5G-GUTI有效，依据其**GUAMI**（含AMF Region/Set/Pointer）选初始AMF；若无GUTI或GUAMI不可解析，则依据Requested NSSAI或本地默认AMF选择。 **第2步 · (R)AN → 初始AMF：N2 Initial UE Message** 这是NGAP消息（TS 38.413 §8.2.2），将NAS-PDU透传给初始AMF。此时(R)AN已与该AMF建立N2信令连接。 **第7步 · 初始AMF → UDM：Nudm_UECM_Registration + Nudm_SDM_Get** 初始AMF向UDM注册自己，并拉取订阅数据（TS 29.503）： - `Access and Mobility Subscription Data`（含订阅S-NSSAI、RFSP、地区限制等）； - `UE context in SMF data`（已建立的PDU会话锚点SMF信息）； - UDM可能返回**AMF Set指示**或对当前服务AMF的限制信息。 **关键决策点（TS 23.501 §6.3.5）**：初始AMF综合Requested NSSAI、Configured NSSAI、订阅S-NSSAI，计算出在当前TA有效的**Allowed NSSAI**。若初始AMF所属Set**不能全部支持**Allowed NSSAI中的S-NSSAI，则触发重选。 **第8步 · 初始AMF → NRF：Nnrf_NFDiscovery_Request** 初始AMF向NRF发起网络功能发现（TS 29.510），关键查询参数： - `target-nf-type = AMF` - `amf-region-id`、`amf-set-id`（目标AMF Set标识） - `slice-info`（S-NSSAI列表，限定切片支持能力） - `plmn-info` NRF返回目标AMF Set B的候选实例列表。注意：此时初始AMF可以**直接选定一个目标AMF实例**，也可以**只选定AMF Set**、把最终的实例选择交给(R)AN（后者即"经(R)AN重路由"路径，发挥(R)AN的本地负载均衡能力）。 **第9步 · 初始AMF → (R)AN：NGAP `Reroute NAS Request`（核心！）** 这是本机制的灵魂消息（TS 38.413）。其方向为AMF→NG-RAN，关键IE见下表： | IE | M/O | 作用 | |----|-----|------| | `NAS-PDU` | M | 原始的Registration Request（原封不动回传） | | `RAN UE NGAP ID` | M | 维持(R)AN侧UE关联 | | `AMF UE NGAP ID` | M | 维持AMF侧UE关联 | | `AMF Set ID` | O | 指示目标AMF Set，由(R)AN在Set内选实例 | | `Selected AMF Name` | O | 直接指定目标AMF实例（与AMF Set ID二选一） | | `Initial AMF Name` | O | 本初始AMF的标识，供目标AMF回拉上下文 | | `Allowed NSSAI` | O | 已计算的Allowed NSSAI，传递给目标AMF复用 | 设计巧妙之处：原始NAS消息**不被初始AMF改写**，只是"贴一张地址便签"（AMF Set ID / Initial AMF Name）重新投递，保证NAS层的完整性与可追溯性。 **第10步 · (R)AN → 目标AMF：N2 Initial UE Message + Initial AMF Name** (R)AN在AMF Set B内依据负载选定目标AMF，发送一条**新的**Initial UE Message。其中携带`Initial AMF Name`这一IE——它是目标AMF"找回"初始AMF的钥匙。 **第11步 · 目标AMF → 初始AMF：Namf_Communication_UEContextTransfer** 目标AMF识别到Initial AMF Name后，经N14/Namf接口（TS 29.518）向初始AMF**回拉UE上下文**，避免重复执行识别与鉴权： - **SUPI**（若初始AMF已解出）； - **MM上下文**（含安全上下文KAMF等）； - **UE context in SMF data**（已有PDU会话锚点信息）； - 已计算的Allowed NSSAI、策略数据。 ```text flowchart LR A[NAS Registration Request] --> B[Reroute NAS Request
附加: AMF Set ID + Initial AMF Name] B --> C{路由方式} C -->|经RAN重路由| D[(R)AN在Set B内选实例] C -->|AMF间直接转发| E[N14: 目标AMF直收] D --> F[Initial UE Message
+ Initial AMF Name] E --> F F --> G[UEContextTransfer
回拉安全上下文] G --> H[续接注册: SMC/注册接受] ``` **第12步以后 · 续接注册** 目标AMF拿到安全上下文后，可**跳过**5G-AKA与Security Mode Command（若初始AMF已完成），直接续接注册流程，下发： - **Registration Accept**，其中携带**新的5G-GUTI**（其GUAMI指向Set B的目标AMF）； - Allowed NSSAI； - 必要时触发PDU会话状态更新（与SMF交互）。 **收尾 · Namf_Communication_RegistrationCompleteStatus** 目标AMF向初始AMF回报重选成功，初始AMF随后**释放为本次注册临时创建的UE上下文**，完成资源回收（TS 29.518）。 --- ## 三、两种重路由方式对比 TS 23.502 §4.2.2.2.2允许两种实现路径，工程上各有取舍： | 维度 | 经(R)AN重路由（Reroute NAS Request） | AMF间直接转发（N14/Namf） | |------|-------------------------------------|---------------------------| | 标准依据 | TS 38.413 NGAP + TS 23.502 §4.2.2.2.2 | TS 23.502 §4.2.2.2.2 注、TS 29.518 | | 目标AMF实例选择 | 由(R)AN在目标Set内本地选择（发挥负载均衡） | 由初始AMF/NRF选定后直接转发 | | N2连接 | (R)AN与目标AMF建立新N2连接，链路清晰 | 初始AMF需维持中间态，拓扑更复杂 | | 上下文获取 | 经`Initial AMF Name`触发UEContextTransfer | 转发时可直接内联携带上下文 | | 典型应用 | 主流商用部署、3GPP一致性测试首选 | 部分厂商私有优化或云原生简化部署 | | 防环机制 | (R)AN统计重路由次数，超限拒绝 | 需AMF自身维护reroute计数 | **主流厂商（华为、爱立信、中兴）在5GC SA商用网中普遍采用"经(R)AN重路由"方式**，因为它复用了(R)AN既有的AMF选择与负载均衡能力，且N2连接的建立/迁移语义更清晰，便于网管与排错。 --- ## 四、关键标识符：GUAMI与AMF Set 要真正理解重选，必须吃透**GUAMI**的结构（TS 23.003 §28.2.4、TS 38.413 §9.3）： ```mermaid graph LR G[GUAMI
24bit AMF ID] --> R[AMF Region ID
8 bit] G --> S[AMF Set ID
10 bit] G --> P[AMF Pointer
6 bit] M[MCC+MNC] --> G R --> R1["标识一个AMF区域
(地理/逻辑)"] S --> S1["标识区域内一个AMF Set
最多1024个Set/Region"] P --> P1["标识Set内一个AMF实例
最多64个AMF/Set"] ``` | 字段 | 位宽 | 含义 | 重选中的角色 | |------|------|------|-------------| | MCC+MNC | — | PLMN标识 | 全局归属 | | AMF Region ID | 8 bit | AMF区域 | 重选的目标区域范围 | | AMF Set ID | 10 bit | AMF集合（共享切片支持与UDSF） | **重选的核心目标单位** | | AMF Pointer | 6 bit | Set内具体AMF实例 | (R)AN在Set内做负载选择 | **设计精髓**：重选的粒度是**AMF Set**而非具体AMF实例。这样(R)AN在目标Set内仍有选择空间，且Set内AMF通过UDSF共享上下文，即使具体实例不同，UE上下文也能无缝迁移——这就是5GC"无状态"架构在重选场景的体现。 > 注意区分：TS 23.003中SUPI(IMSI)的**Routing Indicator**用于归属网将信令路由至正确的UDM/AUSF，属于"用户面/数据库侧路由"，与本节讨论的"AMF重选路由"是两个层面，切勿混淆。 --- ## 五、为什么这样设计：三个深层意图 1. **切片与控制面解耦**。若要求(R)AN在注册第一步就精确选出支持所有切片的AMF，将迫使(R)AN维护全网的AMF-切片映射表，这与"RAN尽量简单"的原则相悖。重选机制把切片匹配的复杂性收敛在核心网内部（AMF/NSSF/NRF），(R)AN只需做"尽力而为"的初选，匹配失败时由AMF发起二次路由——**复杂逻辑上移，简单动作下沉**。 2. **AMF Set无状态化支撑弹性扩缩容**。重选以Set为粒度，配合UDSF共享上下文，使得AMF实例可自由增删而不影响在网用户。云原生5GC（如基于容器的大区集中部署）正是依赖此机制实现滚动升级与故障切换。 3. **防环与可追溯**。`Initial AMF Name`的引入使目标AMF能精确回拉上下文而非盲目重跑鉴权；NGAP层面的重路由计数防止AMF间互相"踢皮球"形成死循环；原始NAS-PDU不改写保证NAS层消息完整性可审计。三者共同构成鲁棒性保障。 --- ## 六、实战连接：抓包识别与排错 ### 6.1 抓包识别特征 在Wireshark/TShark中，AMF重选（经RAN路径）有非常鲜明的指纹： - **NGAP层**：出现一条`Reroute NAS Request`（由AMF发出，方向AMF→gNB），其后紧跟针对同一UE的**第二条**`Initial UE Message`（gNB→另一个AMF实例，通常落在不同的SCTP关联或不同目的IP）； - **SBI层**：AMF（源IP）向NRF发送`Nnrf_NFDiscovery_Request`，`target-nf-type=AMF`且携带`slice-info`/`amf-set-id`；随后出现两个AMF IP之间的`POST /namf-comm/v1/ue-contexts/{...}/transfer`（即UEContextTransfer）； - **NAS层**：UE侧只看到一次Registration Request/Accept往返，重选对UE**完全透明**。 > 抓包判据：**"一进一出两条Initial UE Message + 中间一条Reroute NAS Request"** 即可确认发生了AMF重选。 ### 6.2 常见故障与排错 | 故障现象 | 可能根因 | 排错思路 | |---------|---------|---------| | 注册反复失败、UE长时间无响应 | AMF Set切片能力配置错误，初始/目标AMF均不满足Allowed NSSAI，触发重选超限 | 检查AMF Set的S-NSSAI订阅与UDM订阅S-NSSAI一致性 | | 重选后重复鉴权，时延显著增大 | 目标AMF未执行UEContextTransfer（如Initial AMF Name未携带），被迫重跑5G-AKA | 核查NGAP Reroute NAS Request是否包含Initial AMF Name | | 切换/重选后PDU会话丢失 | UE context in SMF data未正确迁移，目标AMF未感知已有SMF | 排查UEContextTransfer响应中SMF data完整性 | | 重选循环（乒乓） | 防环计数失效或两个AMF Set切片配置互斥 | 检查(R)AN的reroute计数器与AMF Set切片映射 | ## 七、状态转换视角 整个重选对UE而言仍是注册流程，状态机变化与普通注册一致，但在网络侧AMF间有独特的上下文移交： ```mermaid stateDiagram-v2 [*] --> RM_DEREGISTERED: UE开机 RM_DEREGISTERED --> RM_REGISTERING: 发起Registration Request RM_REGISTERING --> IAMF_HANDLING: (R)AN选初始AMF IAMF_HANDLING --> IAMF_HANDLING: 切片不匹配→判定重选 IAMF_HANDLING --> TAMF_HANDLING: Reroute NAS Request TAMF_HANDLING --> TAMF_HANDLING: UEContextTransfer回拉 TAMF_HANDLING --> RM_REGISTERED: Registration Accept(新GUTI) RM_REGISTERED --> [*]: 去注册/关机 note right of IAMF_HANDLING 初始AMF为临时角色 重选完成后释放上下文 end note ``` --- ## 常见问题 **Q1：AMF重选和NSSF切片选择是什么关系？** A：NSSF负责**切片决策**（计算Allowed NSSAI、确定目标AMF Set、NSI-ID），AMF重选是**切片决策的执行动作**。初始AMF可调用`Nnssf_NSSelection_Get`（TS 29.531）获得目标AMF Set后发起重选；也可不经NSSF、依据本地配置与UDM数据自行判定。NSSF是"军师"，AMF重选是"执行者"。 **Q2：重选过程中UE会被要求重新鉴权吗？** A：不一定。若初始AMF在重选前已完成5G-AKA并建立安全上下文，目标AMF通过`Namf_Communication_UEContextTransfer`回拉安全上下文（含KAMF），即可直接续接Security Mode Command甚至跳过，无需重跑鉴权。这正是`Initial AMF Name`IE存在的核心价值。 **Q3：(R)AN如何防止重选死循环？** A：(R)AN对同一UE的`Reroute NAS Request`/`Initial UE Message`维护计数，超过最大重路由次数后拒绝继续转发，向UE返回注册拒绝（如原因值#22拥塞或合适的服务拒绝）。同时AMF Set切片配置的正确性是避免循环的根本——一个Allowed NSSAI在全网至少应存在一个可服务的AMF Set。 **Q4：AMF重选对UE透明吗？影响哪些KPI？** A：对UE完全透明，UE只感知一次注册往返。但它影响两个网络KPI：**注册时延**（增加一次N2投递与可能的上下文回拉，通常增加几十至百毫秒）和**首信令连接成功率**（重选失败会直接导致注册失败）。因此网优中"重选次数"是衡量切片规划合理性的重要指标。 **Q5：为什么不在注册一开始就选对AMF？** A：因为(R)AN无法在注册第一步就掌握UE的**订阅切片全集**（这需查UDM），而GUAMI来自上次的5G-GUTI，可能已陈旧。"先尽力投递、再核心网精确修正"是工程上成本最低的折中——它把"知道全部信息才能做的精确决策"推迟到拥有UDM数据之后，避免了(R)AN承担超出其能力的复杂查询。 --- ## 参考来源 1. [3GPP TS 23.502 V18.x — Procedures for the 5G System, §4.2.2.2 Registration, §4.2.2.2.2 AMF re-allocation](https://www.3gpp.org/dynareport/23502.htm) 2. [3GPP TS 23.501 V18.x — System Architecture, §6.2.4 AMF Set / Stateless, §6.3.5 AMF (re)selection](https://www.3gpp.org/dynareport/23501.htm) 3. [3GPP TS 38.413 V18.x — NG-RAN NGAP, §8 Reroute NAS Request / Initial UE Message IEs](https://www.3gpp.org/dynareport/38413.htm) 4. [3GPP TS 29.518 V18.x — NAMF Service, Namf_Communication_UEContextTransfer / RegistrationCompleteStatus](https://www.3gpp.org/dynareport/29518.htm) 5. [3glteinfo — 5G Reroute NAS Request NGAP Message 解析](https://www.3glteinfo.com/messages/5g/ngap/reroute-nas-request/) --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。