# 5G业务请求（Service Request）信令全链拆解：从CM-IDLE到CM-CONNECTED的协议级深度解析 > 本文聚焦 **3GPP TS 23.502 Section 4.2.3.2（UE Triggered Service Request）** 与 **TS 24.501 Section 5.6.1 / 8.2.21** 定义的 Service Request 过程，逐信令、逐 IE 拆解 UE 从 CM-IDLE 回到 CM-CONNECTED、并重建 N3 用户面的完整协议链路。这是 5GS 中最高频的 NAS 过程之一，也是协议开发与排错中"必经之路"。 --- ## 一、为什么 Service Request 如此关键 ### 1.1 一句话定义 TS 24.501 Section 5.6.1.1 对 Service Request 过程的定位非常明确： > *"The purpose of the Service Request procedure is to change the 5GMM mode from 5GMM-IDLE to 5GMM-CONNECTED mode."* 换句话说，Service Request 是 5G 中**让空闲态（CM-IDLE）终端重新"上线"的控制面入口**。它完成三件事： 1. **重建 NAS 信令连接**（即 N1 连接 + N2 连接）； 2. **有条件地重新激活 PDU 会话的用户面**（N3/N9 隧道、DRB）； 3. **触发 AMF 的连接管理状态迁移**（CM-IDLE → CM-CONNECTED）。 与 4G EPS 中的 Service Request 不同，5G 的 Service Request 在消息体设计上引入了 **PDU Session Status / Uplink Data Status / Allowed PDU Session Status** 三个"会话感知"IE，使 AMF 能在一条消息内完成"哪些会话要建面、哪些会话已失效"的同步。 ### 1.2 两大触发场景 | 触发方 | 场景 | 标准出处 | |--------|------|----------| | **UE 触发（UE-Initiated）** | 终端有上行数据/信令（MO Data、MO Signalling、紧急呼叫 fallback 等） | TS 23.502 §4.2.3.2 | | **网络触发（Network-Initiated）** | UPF 收到下行数据/SMF 有下行信令 → 通知 AMF → AMF 发起 **Paging** → UE 以 Service Request 应答 | TS 23.502 §4.2.3.2（注：Paging 见 §4.2.3.3 / TS 23.502 §4.2.3.x） | | **CM-CONNECTED 但 N3 已释放** | UE 仍在 CM-CONNECTED（N2 连接在），但 RRC 释放或 N3 用户面被去激活，需重建用户面 | TS 23.502 §4.2.3.2（用户面重激活变体） | 实际现网中，**UE 触发的场景远多于网络触发**——因为大量业务是终端主动发起的（应用心跳、上行小包等），而下行触发的 Service Request 前面必须先有一次 Paging。 --- ## 二、连接管理状态模型与触发条件 ### 2.1 RM 与 CM 双层状态机 5G 把"注册"和"连接"解耦为两层状态机（TS 23.501 §5.3.3 RM、§5.3.7 CM）： ```mermaid stateDiagram-v2 [*] --> RM_DEREGISTERED RM_DEREGISTERED --> RM_REGISTERED: Registration 成功 RM_REGISTERED --> RM_DEREGISTERED: Deregistration RM_REGISTERED --> CM_IDLE: N1/N2 连接释放 CM_IDLE --> CM_CONNECTED: Service Request 成功 CM_CONNECTED --> CM_IDLE: N2 Release (AN Release) CM_CONNECTED --> CM_CONNECTED_RRC_INACTIVE: RAN 释放 RRC\n(仍保持 N2) CM_CONNECTED_RRC_INACTIVE --> CM_CONNECTED: RRC Resume\n(SDT/RNA Update) ``` 关键点：**Service Request 只解决 CM-IDLE → CM-CONNECTED**。如果 UE 已经是 CM-CONNECTED（只是 RRC_INACTIVE 或 N3 释放），则走的是 **RRC Resume / RNA Update / 用户面重激活**，而不是完整 Service Request。这一点在抓包时极易混淆（详见第五章排错）。 ### 2.2 触发条件清单（TS 24.501 §5.6.1.2） UE 在 CM-IDLE 时，满足以下任一条件即发起 Service Request： - 上层有 **移动台发起的数据**（MO Data）待发送； - 上层有 **移动台发起的信令**（MO Signalling）； - 收到网络 **Paging**（响应 MT Data/MT Signalling）； - 需要进行**紧急业务回退**（Emergency Services Fallback）； - 触发**高优先级接入**（MPS）。 Service type IE 字段（4 bit，TS 24.501 §9.11.3.49）直接编码这些语义，AMF 据此选择资源分配策略。 --- ## 三、UE 触发 Service Request 全链时序图 下面给出 **TS 23.502 Figure 4.2.3.2-1** 对应的端到端信令流（融合 RRC/NAS/NGAP/SBI/PFCP 各层）： ```mermaid sequenceDiagram participant UE participant gNB as NG-RAN (gNB) participant AMF participant SMF participant UPF Note over UE: CM-IDLE, RRC_IDLE UE->>gNB: RRC Setup Request (建立原因) gNB->>UE: RRC Setup UE->>gNB: RRC Setup Complete (NAS Service Request) gNB->>AMF: NGAP Initial UE Message (NAS-PDU=Service Request, RRC建立原因, 用户位置) Note over AMF: 校验完整性保护 (MAC) opt 完整性校验失败/无安全上下文 AMF->>UE: NAS Authentication Request UE->>AMF: NAS Authentication Response AMF->>UE: NAS Security Mode Command UE->>AMF: NAS Security Mode Complete end Note over AMF: 需要为PDU会话重建用户面 AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request (PDU会话ID, N2 SM信息请求) SMF->>UPF: N4 Session Modification Request (申请N3 UL TEID) UPF-->>SMF: N4 Session Modification Response (CN Tunnel Info) SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response (N2 SM信息: UL TEID, QoS Flow) AMF->>gNB: NGAP Initial Context Setup Request (NAS Service Accept, PDU会话资源建立列表) gNB->>UE: RRC Reconfiguration (建立/激活DRB) UE-->>gNB: RRC Reconfiguration Complete gNB-->>AMF: NGAP Initial Context Setup Response (AN Tunnel Info = N3 DL TEID) AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request (AN Tunnel Info) SMF->>UPF: N4 Session Modification Request (下发AN Tunnel Info) UPF-->>SMF: N4 Session Modification Response Note over UPF,UE: N3用户面打通, 下行缓冲数据开始转发 ``` ### 3.1 关键设计意图解读 - **为什么 Service Request 不走完整鉴权？** TS 24.501 规定 Service Request 必须以**完整性保护（integrity protected）**形式发送（Security header type = "integrity protected"，但**不加密**）。AMF 一旦用本地安全上下文验过 MAC，即可跳过鉴权——这是为**降低空闲态唤醒的端到端时延**而做的优化。只有当 UE 的安全上下文不可用或 MAC 失败时，才回退到 Authentication + Security Mode Control（图中 opt 分支）。 - **为什么 AMF 先问 SMF 要 N2 SM 信息，再下发 RAN？** 因为 N3 上行隧道的对端 F-TEID 由 **UPF 分配**，必须经 SMF（N4）取回后，封装成 N2 SM Information（PDU Session Resource Setup List）随 NGAP 下发，gNB 才知道上行数据该发往哪个 UPF 的哪个 TEID。这是 **SMF 作为会话锚点协调者**的职责体现。 - **NAS Service Accept 为什么"夹带"在 Initial Context Setup Request 里？** 为了**省一次 NAS 往返**。Service Accept 既要确认 CM 状态迁移、又要回告 PDU Session Status 与 Reactivation Result，把它和 NGAP Initial Context Setup 合并在一条下行 N2 消息中携带（NAS-PDU 放在 Downlink NAS Transport 容器内），是典型的"信令合并"优化。 --- ## 四、关键信息单元（IE）逐字段拆解 ### 4.1 NAS Service Request 消息结构（TS 24.501 §8.2.21.1） ```mermaid graph TD SR["NAS Service Request 消息
Message Type = 0x4C"] SR --> M1["Extended Protocol Discriminator
= 0x7E (5GS MM)"] SR --> M2["Security Header Type
0x0=integrity protected / 0x4=ciphered+IP"] SR --> M3["Message Authentication Code
(MAC, 4 octets)"] SR --> M4["Sequence Number
(1 octet, 用于重放保护)"] SR --> M5["Service Type
(signalling/data/MT/emergency/fallback...)"] SR --> M6["ngKSI
(NAS Key Set Identifier)"] SR --> M7["5G-S-TMSI
(可选, 终端有合法临时身份时携带)"] SR --> M8["PDU Session Status
(UE视角各PDU会话激活状态bitmap)"] SR --> M9["Uplink Data Status
(有待发上行数据的会话bitmap)"] SR --> M10["Allowed PDU Session Status
(允许激活的会话bitmap)"] SR --> M11["NAS Message Container
(可选, 用于Paging应答场景)"] ``` ### 4.2 关键 IE 参数说明表 | IE 名称 | 标准出处 | 作用 | 抓包要点 | |---------|----------|------|----------| | **Service type** | TS 24.501 §9.11.3.49 | 区分 signalling/data/MT/emergency fallback/high priority | 决定 RRC 建立原因与 AMF 资源优先级 | | **ngKSI** | TS 24.501 §9.10 | 标识本次使用的 NAS 安全上下文（KAMF 推导集） | 与 Security Mode Complete 中的 ngKSI 对应 | | **5G-S-TMSI** | TS 23.003 / §9.11.3.4 | 让 gNB/AMF 快速定位 UE 上下文（选 AMF Set） | 缺失→AMF 可能发起 Identity Request 取 SUPI | | **PDU Session Status** | TS 24.501 §9.11.3.44 | UE 上报"我认为还活着的 PDU 会话" | AMF 比对，触发 PDU 会话释放（UE/网络不一致） | | **Uplink Data Status** | TS 24.501 §9.11.3.55 | 标记有待发上行数据的会话 | AMF 决定为哪些会话建 N3 | | **Allowed PDU Session Status** | TS 24.501 §9.11.3.46 | 限制可激活的会话（与接入类型有关） | 区分 3GPP / non-3GPP 接入 | | **NAS Message Container** | TS 24.501 §9.11.3.34 | 携带额外保护信息（如 Paging 应答） | 见 5G AKA 相关安全增强 | ### 4.3 Service type 取值语义 | 值 | 含义 | 典型应用 | |----|------|----------| | 0 | Signalling | 仅建信令连接（如周期性更新） | | 1 | Mobile Terminated services | 响应 Paging | | 2 | Data (Mobile Originated) | 应用上行数据 | | 3 | Emergency services | 紧急呼叫 | | 4 | Emergency services fallback | 紧急呼叫回退到目标 RAT | | 5 | High priority access | MPS/MCS 高优先级 | > 注：Service type 为 4 比特，部分取值用于 5G-AKA 及后续版本扩展。AMF 会据此向 RAN 透传优先级（5QI/ARP），影响 DRB 建立顺序。 --- ## 五、抓包识别与实战排错 ### 5.1 抓包如何识别该流程 在 Wireshark/TShark 中，一次完整的 UE 触发 Service Request 通常表现为以下过滤结果： ```bash # NAS-5GS Service Request (消息类型 0x4C) tshark -r trace.pcapng -Y "nas-5gs.message_type == 0x4c" # NGAP Initial UE Message (承载 NAS-PDU) tshark -r trace.pcapng -Y "ngap.procedureCode == 14" # InitialUEMessage = 14 # NGAP Initial Context Setup tshark -r trace.pcapng -Y "ngap.procedureCode == 15" # InitialContextSetup = 15 # N4 会话修改 (PFCP Session Modification) tshark -r trace.pcapng -Y "pfcp.msg_type == 56" # SBI: SMF<->AMF tshark -r trace.pcapng -Y "http2 && http2.headers.path contains \"pdusession\"" ``` ### 5.2 常见故障点与排错思路 | 症状 | 可能根因 | 排查方向 | |------|----------|----------| | **AMF 不下发 Service Accept，反而发 Authentication Request** | UE 上行 Service Request 的 MAC 校验失败 / 无有效安全上下文 | 检查 ngKSI、KAMF 是否一致；UE 是否此前未完成 Security Mode Control | | **Service Reject（NAS）** | 资源不足 / 会话无效 | 关注 Cause：#27（DNN/S-NSSAI 缺失）、#22（拥塞）、#28（未知 PDU 会话类型）、#73（LADN 不可用） | | **N3 建立后无下行数据** | SMF 未将 AN Tunnel Info（N3 DL TEID）下发给 UPF | 检查第二条 N4 Session Modification 是否携带 gNB 的 F-TEID | | **重复 Service Request** | RRC Inactive 误判 / RNA 边界抖动 | 确认 UE 当前是 RRC_IDLE（需完整 SR）还是 RRC_INACTIVE（应走 RRC Resume） | | **5G-S-TMSI 未携带** | 终端无合法临时身份 | AMF 会触发 Identity Request 取 SUPI，多一次往返，应排查注册阶段 TMSI 分配 | ## 六、与相关过程的对比 ### 6.1 Service Request vs Registration（初始注册） | 维度 | Service Request | Registration (Initial) | |------|----------------|------------------------| | 触发态 | CM-IDLE | RM-DEREGISTERED | | 目标 | 建 N1/N2 连接 + 激活用户面 | 取得 5G 接入授权 + 建立上下文 | | 是否鉴权 | 通常跳过（已有安全上下文） | 必须（5G AKA / EAP-AKA'） | | 涉及 NF | AMF/SMF/UPF/gNB | UDM/AUSF/AMF/SMF/PCF/gNB | | 消息量 | 较小（2~6 条 NAS/NGAP） | 较大（多轮鉴权 + 策略建立） | | 标准出处 | TS 23.502 §4.2.3.2 | TS 23.502 §4.2.2.2 | ### 6.2 UE 触发 vs 网络触发 Service Request ```mermaid flowchart TD subgraph UE触发["UE-Initiated (主动唤醒)"] A1["UE上层有数据/信令"] --> A2["RRC Setup + NAS Service Request"] A2 --> A3["Service type=Data/Signalling"] end subgraph 网络触发["Network-Initiated (被动唤醒)"] B1["UPF收到下行数据"] --> B2["SMF→AMF: N1N2Transfer(DataNotification)"] B2 --> B3["AMF→gNB: Paging"] B3 --> B4["UE响应: NAS Service Request\nService type=MT"] end A3 --> C["共同: 用户面重建"] B4 --> C ``` 两者最终都汇聚到"用户面重建"，但前置路径不同：网络触发多了一次 Paging 往返，时延更大。这也是为什么 IoT/低时延场景会倾向于让 UE 维持 CM-CONNECTED + RRC_INACTIVE（SDT）以规避 Paging。 --- ## 七、设计哲学小结 1. **完整性保护优于加密**：Service Request 不加密、只完整性保护，是在"安全"与"唤醒时延"之间的精妙折中——既能防篡改重放，又避免解密依赖。 2. **状态同步内联化**：PDU Session Status / Uplink Data Status 让一条 NAS 消息同时完成"连接建立 + 会话对账"，减少后续 Configuration Update 信令。 3. **SMF 居中协调 N3**：UPF 分配 UL TEID、gNB 分配 DL TEID，两者由 SMF 通过 N4 + N2 SM Information 串起来，体现"控制面集中、用户面分布式"的 5GC 架构理念。 4. **CM 与 RRC 解耦**：CM-CONNECTED 允许 RRC_INACTIVE，使网络能灵活地在"省电"与"快速唤醒"间调度，是 RRC_INACTIVE + SDT 优化的基础。 --- ## 常见问题 **Q1: Service Request 一定要走鉴权吗？** A: 不一定。只要 UE 持有有效 NAS 安全上下文且 Service Request 的完整性校验通过，AMF 可跳过鉴权，直接进入用户面重建。只有 MAC 失败或上下文缺失时，才回退到 Authentication + Security Mode Control。 **Q2: UE 在 CM-CONNECTED 但 RRC_INACTIVE 时，发的还是 Service Request 吗？** A: 不是。此时 NAS 层仍处于 5GMM-CONNECTED，终端走的是 **RRC Resume Request**（携带 resumeCause、I-RNTI），属于接入层恢复；若伴随小数据则使用 SDT。只有 N2/NAS 信令连接都断开（CM-IDLE）时才发完整 NAS Service Request。 **Q3: Service Accept 和 Service Reject 怎么区分？** A: 看下行 NAS 消息类型与 Cause IE。Service Accept（TS 24.501 §8.2.16）携带 PDU Session Status / Reactivation Result，无 Cause；Service Reject（§8.2.17）必带 Cause（如 #22 拥塞、#27 DNN 缺失等）及回退定时器 T3346。 **Q4: 为什么抓包里有时看不到 N4？** A: N4（PFCP）是 SMF 与 UPF 之间、基于 IP 的接口，多数抓包环境仅在 SMF/UPF 网段可见。若仅在 gNB–AMF 侧抓包，N4 对你是不可见的，需结合 SBI（Nsmf）日志间接判断用户面是否就绪。 **Q5: Service Request 会触发计费吗？** A: Service Request 本身是控制面过程，不直接产生用户面计费事件；但它重建的 N3 用户面会恢复用户面流量，SMF 据此恢复计费数据采集。连接管理信令通常不计费，但 SUPI 级连接时长可用于连接管理统计。 --- ## 参考来源 1. [3GPP TS 23.502 — System procedures for the 5G System; §4.2.3.2 UE Triggered Service Request](https://www.3gpp.org/dynareport/23502.htm) — Service Request 主流程定义与 Figure 4.2.3.2-1 2. [3GPP TS 24.501 — NAS protocol for 5G; §5.6.1 Service request procedure / §8.2.21 Service Request message](https://www.3gpp.org/dynareport/24501.htm) — NAS 消息结构与 IE 编码 3. [3GPP TS 23.501 — System architecture for the 5G System; §5.3.7 Connection Management](https://www.3gpp.org/dynareport/23501.htm) — CM-IDLE / CM-CONNECTED 状态模型 4. [ShareTechnote — 5G/NR NAS Service Setup](https://www.sharetechnote.com/html/5G/5G_ServiceSetup.html) — Service Request 流程图文解读（含网络触发与 UE 触发对比） 5. [Cisco Ultra Cloud Core 5G AMF Configuration Guide — Service Request Procedure](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/amf/2025-03/config-and-admin/ucc-5g-amf-configuration-and-administration-guide-release-2025-03/5G-AMF_Config_Guide_chapter_01000.html) — AMF 侧 UE-Triggered / Network-Triggered 实现说明 --- > 本文由「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 等场景全覆盖。