5G Service Request 服务请求信令全链拆解

一、为什么 Service Request 是核心网最高频的信令

在 5G 系统（5GS）中，UE 的连接管理被划分为两个基本状态：CM-IDLE（空闲态）与 CM-CONNECTED（连接态）。UE 完成初始 Registration 后，为了省电和节省无线空口资源，绝大多数时间停留在 CM-IDLE 态，此时 N1（UE–AMF）NAS 信令连接、N2（AN–AMF）N2 连接、N3（AN–UPF）用户面隧道全部释放，仅保留 UE 与网络中的注册上下文与订阅数据。

然而一旦出现下列任一触发，UE 必须在毫秒级内"重新上线"并恢复用户面：

• UE 应用层产生上行数据，但对应 PDU Session 的用户面资源已释放；
• UE 需要发送移动性 NAS 信令（如 Mobility Registration Update、Periodic Registration、Deregistration）或会话管理信令（如 PDU Session Establishment/Modification）；
• 网络侧收到下行数据/信令（如被叫 VoNR 呼叫、下行 SMS over NAS），AMF 触发 Paging，UE 响应。

承担"从 CM-IDLE 重建 N1/N2/N3 一次到位"这一职责的，正是 Service Request 过程，定义在 TS 23.502 Section 4.2.3.2，其 NAS 层编解码定义在 TS 24.501 Section 5.6.1 与 9.11.3.46。它是 5GC 信令面频次最高、对端到端时延影响最大的过程之一——一次 VoNR 被叫的接续时延，几乎一半消耗在 Service Request 上。理解它的每一个 IE 和每一段交互，是核心网协议工程师与排错工程师的基本功。

本文聚焦 TS 23.502 R18 Section 4.2.3.2 中的 UE 触发型 Service Request（含与网络触发型的差异），逐消息、逐 IE 拆解，并给出抓包识别与典型故障点。

二、整体状态视角：Service Request 在 CM 状态机中的位置

Service Request 是 CM-IDLE → CM-CONNECTED 的唯一标准入口（异常路径是隐式分离后的重新注册）。下图给出以 Service Request 为枢纽的状态迁移：

stateDiagram-v2
    [*] --> RM_REGISTERED_CM_IDLE : Registration完成
    RM_REGISTERED_CM_IDLE --> RM_REGISTERED_CM_CONNECTED : Service Request(UE触发)\nTS23.502 §4.2.3.2
    RM_REGISTERED_CM_CONNECTED --> RM_REGISTERED_CM_IDLE : N1/N2释放(AN释放)\nTS23.502 §4.2.6
    RM_REGISTERED_CM_CONNECTED --> RM_REGISTERED_CM_CONNECTED : Service Request(网络触发)\n恢复N3用户面
    RM_REGISTERED_CM_IDLE --> RM_REGISTERED_CM_IDLE : Periodic Registration Update
    RM_REGISTERED_CM_CONNECTED --> RM_DEREGISTERED : Deregistration

设计要点：5G 把"信令连接建立"与"用户面激活"合并到同一个过程里完成。这与 EPS 的 Service Request（TS 23.401）一脉相承，但 5G 借助 PDU Session 粒度的 Uplink data status / PDU session status / Allowed PDU session status 三个 IE，实现了按需、按会话粒度地重建用户面，避免一次性激活所有 PDU Session 造成信令风暴。

三、UE 触发型 Service Request 完整信令时序

下图严格对应 TS 23.502 Section 4.2.3.2 Figure 4.2.3.2-1（UE 触发），并标注每条消息所属的接口与承载它的 RRC/N2 容器：

sequenceDiagram
    autonumber
    participant UE
    participant AN as (R)AN/gNB
    participant AMF
    participant SMF
    participant UPF

    Note over UE: CM-IDLE, 上下行数据触发
    UE->>AN: RRC Setup Request (含5G-S-TMSI)
    AN->>UE: RRC Setup
    UE->>AN: RRC SetupComplete<br/>(NAS: Service Request)
    AN->>AMF: N2 INITIAL UE MESSAGE<br/>(NAS: Service Request)
    Note over AMF: 校验有效安全上下文<br/>解析 Active/Uplink data status
    loop 需激活的每个PDU Session
        AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Req<br/>(PDU Session ID, Operation=Activate)
        SMF->>UPF: N4 Session Modification Req<br/>(激活DL forwarding)
        UPF-->>SMF: N4 Session Modification Rsp
        SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Rsp<br/>(N2 SM: QoS Flow, N3 DL TEID)
    end
    AMF->>AN: N2 REQUEST (INITIAL CONTEXT SETUP REQUEST)<br/>(N2 SM info + NAS: Service Accept)
    Note over AN: 空口安全模式+DRB建立
    AN->>UE: RRC Reconfiguration (+ NAS: Service Accept)
    AN-->>AMF: N2 REQUEST ACK<br/>(INITIAL CONTEXT SETUP RSP: N3 UL TEID)
    loop 每个激活PDU Session
        AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Req<br/>(N2 SM: AN N3 UL TEID)
        SMF->>UPF: N4 Session Modification Req<br/>(下发AN N3 UL TEID)
        UPF-->>SMF: N4 Session Modification Rsp
    end
    Note over UE,UPF: 上下行用户面打通

3.1 步骤 1–4：Service Request 如何"搭便车"穿越空口

UE 在 CM-IDLE 态没有 RRC 连接，因此 Service Request 必须经历四步接入（4-step RACH）：

1. RRC Setup Request 携带 UE 标识（首选 5G-S-TMSI，回退 random value），gNB 据此决定是否启动竞争解决；
2. RRC Setup 给 UE 分配 C-RNTI 与 SRB1；
3. UE 在 RRCSetupComplete 的 selectedPLMN-Identity、registeredAMF 之上，把初始 NAS 消息（即 Service Request）放进 dedicatedNAS-Message 字段（TS 38.331）；
4. gNB 不解析 NAS，按 NGAP INITIAL UE MESSAGE（TS 38.413 Section 8.4）原样上交给 AMF，并带上 User Location Information、RRC Establishment Cause（如 mo-Signaling / mo-Data / mt-Access）。

设计意图：Service Request NAS 消息本身不做完整性保护、不做加密（这是 5GMM 的特殊例外，TS 24.501 4.4.4.3），目的是让 gNB 与 AMF 能在尚未激活 N1 安全连接的 CM-IDLE 入口就识别并转发它。安全保证转由"上层有效安全上下文 + 后续 SMC"承担——AMF 收到 Service Request 后会用本地存储的 KAMF 派生密钥校验紧随其后的、被完整性保护的 NAS 信令，或在上下文不可用时触发 Authentication/SMC。

3.2 步骤 5–9：AMF 与 SMF/UPF 的"先建后通"

AMF 收到 Service Request 后执行三件事：

1. 解析会话意愿：依据 Uplink data status（UE 指明哪些 PDU Session 有待发上行数据）与 Allowed PDU session status（UE 指明哪些 PDU Session 在当前 Allowed Area 内允许激活），决定要激活的 PDU Session 子集；
2. 状态对齐：用 UE 上报的 PDU session status（UE 侧 active 的 PDU Session 位图）与本地存储对比，对"网络侧 active、UE 侧 inactive"的 PDU Session 触发本地释放（Local Release），避免悬挂会话；
3. 逐会话激活：对每个待激活 PDU Session，向 SMF 发 Nsmf_PDUSession_UpdateSMContext Request，其中 Operation 取值为 ACTIVATE（TS 29.502 Section 5.2.2.3.5.1，表 6.1.6.3.3-1）。SMF 随即通过 N4 PFCP Session Modification Request（TS 29.244 Section 5.6）"恢复" UPF 的下行转发（激活已配置的 PDR/FAR，使下行缓存数据可发往 AN 方向）。

先建后通的关键：UPF 在收到 N4 修改请求后才知道下行 N3 隧道（DL TEID）。但此时 AN 侧上行 N3 隧道（UL TEID）尚未确定——它要等 AMF 在 INITIAL CONTEXT SETUP REQUEST 里把 N2 SM 信息下发给 AN，AN 建立 DRB 后才能回填。因此用户面建立必须分两轮 N4 修改完成：第一轮让 UPF "准备好"下行，第二轮才把 AN 的 UL TEID 告诉 UPF。这种"半连接"窗口是 Service Request 时延的主要来源，也是排错时观察的重点。

3.3 步骤 10–11：Service Accept 与 Active Flag 的命运分叉

Service Request 的"应答"不是 Service Request Accept，而是 Service Accept（TS 24.501 8.2.15）。它通过 N2 INITIAL CONTEXT SETUP REQUEST 携带，由 gNB 在 RRC Reconfiguration 透传给 UE。Service Accept 内含：

• PDU session reactivation result：成功重新激活的 PDU Session 位图；
• PDU session reactivation result error cause：激活失败的 PDU Session 及 5GMM/5GSM cause；
• PDU session status（可选）：网络侧最终状态，供 UE 二次对齐。

此处决定 UE 后续走向的是 Service Request 中的 Active flag：

四、Service Request NAS 消息的 IE 结构拆解

下表按 TS 24.501 Section 9.11.3.46 给出 Service Request 的 IE 构成与作用：

下图将 Service Request 的 IE 组织成"信令头 + 会话意愿 + 搭车信令"三层结构，便于理解其设计：

flowchart TD
    subgraph H["信令头层（不可省）"]
        H1["Extended protocol discriminator=5GMM"]
        H2["Security header type=未保护"]
        H3["ngKSI 安全上下文索引"]
        H4["Message type=0x7C"]
    end
    subgraph S["会话意愿层（按需）"]
        S1["Active flag\n是否保持N1"]
        S2["Uplink data status\n哪些有上行数据"]
        S3["PDU session status\nUE侧active全集"]
        S4["Allowed PDU session status\n允许激活子集"]
    end
    subgraph C["搭车信令层（可选）"]
        C1["NAS message container\n带一条完整保护的NAS消息"]
    end
    H --> S --> C

4.1 三个 Status IE 的协同——按需激活的核心

这是 5G 相对 EPS 最精巧的演进之一，三者的逻辑关系如下：

• PDU session status：UE 告诉网络"我手上还活着哪些会话"——用于清理悬挂会话；
• Uplink data status：UE 告诉网络"我现在急着发哪些会话的数据"——用于优先级激活；
• Allowed PDU session status：UE 告诉网络"在当前 Allowed Area 内我希望激活哪些"——用于漫游区域一致性（R16 引入，配合 LADN/区域受限 PDU Session）。

AMF 的激活决策可形式化为：待激活 = Uplink data status ∪ Allowed PDU session status，再与 PDU session status（UE 侧确实 active）求交，剔除已被 UE 本地释放的会话。

4.2 NAS message container——Service Request 的"顺风车"机制

这是协议工程师容易忽视、却极具工程价值的 IE。当 UE 想在恢复连接的同时立即发送一条需要完整性保护的 NAS 消息（如 Deregistration Request、移动性注册更新、甚至 PDU Session Establishment Request）时，可把它整体放进 NAS message container 一并发送。这样Service Request 一次往返就完成"建链 + 发信令"两件事，省去一次额外的 NAS 交互。

注意：NAS message container 内部的消息必须是完整性保护的（用已有 KAMF 派生），而 Service Request 外壳本身不保护——这一"外明内密"的设计，既满足 gNB 透明转发，又保证了搭车信令的完整性。

五、网络触发型 Service Request：Paging 驱动的镜像流程

当网络有下行数据或下行信令时，AMF 先在 UE 的 Registration Area 内发 Paging（TS 23.502 4.2.3.3），UE 响应的 Service Request 即为网络触发型。它与 UE 触发型的主要差异：

1. 触发源：UPF 收到下行数据但 N3 隧道已释放，向 SMF 上报 Data Notification（N4），SMF 经 Namf_Communication_N1N2MessageTransfer 通知 AMF 触发 Paging；
2. RRC Establishment Cause：UE 响应 Paging 时填 mt-Access，便于网络侧识别；
3. 激活范围：网络通常只激活有下行数据的 PDU Session（受 SMF 指定），UE 的 Uplink data status 一般为空；
4. 安全时序：若 UE 安全上下文失效，AMF 可在 Service Request 之后插入 Authentication + Security Mode Command，再继续 INITIAL CONTEXT SETUP。

六、Service Reject 与故障定位

Service Request 失败时，AMF 返回 Service Reject（TS 24.501 8.2.16），携带 5GMM cause。常见 cause 与定位思路：

6.1 抓包识别要点

在 Wireshark 中，Service Request 全流程可拆为三层：

1. NGAP 层：过滤 ngap 且 ngap.procedureCode == initialUEMessage，NAS-PDU 字段解出即为 Service Request；
2. 5GMM 层：消息类型 Service request (0x7C)，重点看 active flag、PDU session status、uplink data status 三个位图；
3. 5GSM/N4 层：跟踪 PDU Session ID，看两轮 N4 Session Modification 是否都成功——若仅第一轮成功而第二轮 PFCP Session Modification Response 的 cause 非 Success，用户面将半通，表现为上行可达 UPF 而下行不通。

6.2 典型故障：半连接状态

最隐蔽的故障是"第一轮 N4 已下发、但 AN 回 N2 REQUEST ACK 失败或 AMF 未把 AN UL TEID 回传给 SMF"。此时 UPF 仍按旧 TEID 发下行，全部丢弃。抓包表现为：Service Accept 已到 UE，但下行 ping 不通、上行正常。排错的关键是检查 Nsmf_PDUSession_UpdateSMContext Request 是否携带 n2Info 中的 AN Tunnel Info（含 UL F-TEID），以及 SMF 是否在第二轮 N4 中正确更新。

常见问题

Q1：Service Request 为什么不完整性保护，安全性如何保证？ A：CM-IDLE 入口处 N1 安全连接尚未激活，Service Request 必须以明文穿越 RRC/N2 才能被 gNB 透明转发。安全保证来自两点：一是它只携带"会话意愿"等无敏感性信息，不携带身份敏感字段（身份用 5G-GUTI 表达，且 SUCI 仅在 Registration 出现）；二是后续的 NAS 信令与用户面建立均受已有 KAMF 派生的完整性/加密保护。若上下文可疑，AMF 可随时插入 Authentication + SMC。

Q2：PDU session status 与 Uplink data status 有何本质区别？ A：PDU session status 是"全集声明"——UE 告知网络自己仍持有的所有 active PDU Session，用于悬挂会话清理；Uplink data status 是"子集请求"——声明哪些 PDU Session 此刻有上行数据待发，驱动 AMF 优先激活它们。前者关乎一致性，后者关乎激活选择。

Q3：网络触发时 UE 不知道有下行数据，Service Request 里的 IE 怎么填？ A：UE 响应 Paging 而发起的 Service Request，Uplink data status 通常为空，PDU session status 仍按 UE 实际状态填写。激活哪些 PDU Session 由 AMF 根据 SMF 在 Namf_Communication_N1N2MessageTransfer 中指定的 PDU Session ID 决定，UE 的状态 IE 仅用于状态对齐而非激活驱动。

Q4：一次 Service Request 能激活多个 PDU Session 吗？ A：能。AMF 会对"待激活集合"中的每个 PDU Session 分别发 Nsmf_PDUSession_UpdateSMContext（Operation=ACTIVATE），并在 INITIAL CONTEXT SETUP REQUEST 中把多个 PDU Session 的 N2 SM 信息一并发给 AN，AN 一次性建立多个 DRB。Service Accept 中用 PDU session reactivation result 位图分别回报每个会话的激活结果。

Q5：Service Accept 后 UE 立即回 CM-IDLE 是 bug 吗？ A：不一定。若 Service Request 中 Active flag 未置位，且 AMF/gNB 的 RRC 不活动定时器较短，则在用户面建立、上下行数据放通后，网络会主动触发 AN Release 让 UE 回 CM-IDLE——这是正常的省电优化路径。仅当 Active flag=active 却仍被立即释放时，才需排查 AMF 是否正确解析 Active flag 或定时器配置是否过激。

参考来源

1. 3GPP TS 23.502 V18.x — Procedures for the 5G System, Section 4.2.3.2 Service Request — UE/网络触发 Service Request 流程定义
2. 3GPP TS 24.501 — NAS protocol for 5GS, Section 5.6.1 & 9.11.3.46 — Service Request 消息内容与 IE 编解码
3. ShareTechnote — 5G Service Setup — Service Request 调用流程图与 IE 解读
4. 3glteinfo — 5G Service Request Procedure Call Flow — 触发条件、前置条件、信令序列
5. 3GPP TS 38.413 — NGAP, Section 8.4 INITIAL UE MESSAGE / 8.7 INITIAL CONTEXT SETUP — N2 容器承载 NAS 与上下文建立
6. 3GPP TS 29.502 — Nsmf_PDUSession Service, Section 5.2.2.3 UpdateSMContext — SM Context 更新与 Operation 取值

本文由「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 等场景全覆盖。