# 5G业务请求（Service Request）信令流程全链拆解 ## 一、机制定位：为什么需要 Service Request 在5G系统中，UE完成注册（Registration）之后，并不会一直占用空口与N2信令连接。当一段时间没有上下行业务时，网络会通过 **N2 Release** 过程释放AN信令连接，使UE进入 **CM-IDLE** 态；此时UE的N1 NAS信令连接、N2连接和用户面（N3/N9）资源全部释放，但核心网侧仍保留UE的 **注册上下文（MM Context）** 和 **PDU Session的SM上下文**。 当UE再次需要收发数据或信令时，并不需要重新执行完整的Registration（那代价过高），而是使用一个轻量级的 **业务请求过程（Service Request Procedure）** 来"唤醒"已有上下文，重建N1/N2信令连接并按需重建用户面。这正是TS 23.502 §4.2.3 所定义的核心机制。 TS 24.501 §5.6.1.1 对其目的的官方表述非常精准： > "The purpose of the service request procedure is to change the 5GMM mode from 5GMM-IDLE to 5GMM-CONNECTED mode." 也就是说，Service Request的本质是 **状态迁移过程**：把5GMM模式从 IDLE 迁移到 CONNECTED，并在此过程中完成三件事——重建N1 NAS连接、重建N2连接、按需重建用户面N3隧道。 理解这一过程的关键，在于把握它"**复用已有上下文而非重建**"的设计哲学，以及它"**完整性保护但不加密**"的特殊安全处理。本文将基于 TS 23.502 §4.2.3.2（UE触发）、§4.2.3.3（网络触发）与 TS 24.501 §5.6、§8.2，逐消息、逐IE拆解完整信令链。 ## 二、前置状态模型与触发条件 Service Request 只能在一个 **已注册（RM-REGISTERED）** 的UE上发起，且UE处于 **CM-IDLE**（或CM-CONNECTED-RRC-INACTIVE的特定子情形）。它有两条触发路径： ```mermaid stateDiagram-v2 [*] --> RM_DEREGISTERED RM_DEREGISTERED --> RM_REGISTERED: Registration成功 state RM_REGISTERED { [*] --> CM_IDLE CM_IDLE --> CM_CONNECTED: Service Request成功 CM_CONNECTED --> CM_IDLE: N2 Release(释放AN信令连接) state CM_CONNECTED { [*] --> RRC_CONNECTED RRC_CONNECTED --> RRC_INACTIVE: N2+RRC Suspend RRC_INACTIVE --> RRC_CONNECTED: RRC Resume(数据恢复) } } RM_REGISTERED --> RM_DEREGISTERED: Deregistration ``` 两条触发路径的核心区别在于"谁先动"： ```mermaid flowchart LR subgraph UE触发["UE触发 §4.2.3.2"] A1["UE有上行数据/信令"] --> A2["直接发起Service Request"] end subgraph 网络触发["网络触发 §4.2.3.3"] B1["下行数据/N1信令/MT SMS到达"] --> B2["SMF向AMF N1N2MessageTransfer"] B2 --> B3["AMF Paging UE"] B3 --> B4["UE响应发起Service Request"] end ``` | 维度 | UE触发（§4.2.3.2） | 网络触发（§4.2.3.3） | |------|--------------------|----------------------| | 触发源 | UE有上行数据/信令 | 下行数据/N1信令/MT SMS到达UPF或AMF | | 是否先Paging | 否 | 是，AMF先对TA List内UE发起Paging | | Service type 取值 | signalling / data / emergency / fallback / HPA | mobile terminated services | | 上游驱动消息 | 无 | SMF→AMF Namf_Communication_N1N2MessageTransfer | | 典型场景 | App发起连接、MO SMS、位置上报 | 来电、推送通知、下行数据 | 无论哪条路径，最终落到AMF的消息都是同一条 **NAS Service Request**，后续处理流程完全一致——这是5G过程设计上的优雅复用。 ## 三、UE发起的 Service Request 完整信令流（CM-IDLE） 下面是 TS 23.502 Figure 4.2.3.2-1 所定义的UE触发Service Request完整信令时序，从CM-IDLE一直走到用户面激活： ```mermaid sequenceDiagram participant UE participant gNB as (R)AN/gNB participant AMF participant SMF participant UPF Note over UE: CM-IDLE, RM-REGISTERED, 已有NAS安全上下文 UE->>gNB: RRCSetupRequest(cause)+Service Request(NAS) gNB-->>UE: RRCSetup UE->>gNB: RRCSetupComplete(NAS-PDU=Service Request) gNB->>AMF: N2 Initial UE Message(NAS-PDU, RAN UE NGAP ID, ULI, 5G-S-TMSI) Note over AMF: 用5G-S-TMSI定位UE上下文, 仅校验完整性(不解密) loop 每个待激活PDU Session AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Req(请求N2 SM info) SMF->>UPF: N4 Session Modification(恢复/建立N3下行隧道) SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Rsp(N2 SM info) end AMF->>gNB: N2 Initial Context Setup Req(KgNB, N2 SM info, NAS-PDU=Service Accept) gNB->>UE: AS SMC(Security Mode Command)+RRCReconfiguration(建DRB) UE-->>gNB: RRCReconfigurationComplete gNB-->>AMF: N2 Initial Context Setup Rsp(AN Tunnel Info=N3 UL TEID) loop 每个PDU Session AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Req(AN Tunnel Info) SMF->>UPF: N4 Session Modification(下发AN Tunnel Info供下行转发) end UPF->>gNB: 下行数据/End Marker Note over UE: 进入CM-CONNECTED, 用户面激活 ``` ### 逐步关键IE解析 **Step 1-3（空口建立与消息承载）**：UE先发起RRC连接建立，把Service Request这条NAS消息封装在 `RRCSetupComplete` 中。由于此时还没有N2连接，gNB通过 **NGAP Initial UE Message**（TS 38.413）将NAS-PDU带给AMF，并附带 `RAN UE NGAP ID`、`User Location Information`（TAI+NR-CGI）、`RRCEstablishmentCause` 等。 **Step 4（AMF处理，本过程最精妙之处）**：AMF收到Service Request后，**不做解密**，而是直接用NAS-PDU中的 `5G-S-TMSI` 在本地定位UE的MM上下文，取出已存储的NAS安全上下文（基于KAMF的派生密钥），对消息做 **完整性校验**。如果通过，则证明这条消息确实来自那个已注册的UE。这一"先定位、后校验、不解密"的设计，是Service Request区别于其他NAS消息的关键——后文会专门讲它的安全意图。 **Step 5-7（用户面按需恢复，AMF↔SMF↔UPF三段交互）**：如果Service Request中带了 `Allowed PDU Session Status`，AMF会对其中每个待激活的PDU Session，调用 `Nsmf_PDUSession_UpdateSMContext` 请求SMF。SMF通过 **N4 Session Modification** 让UPF准备好N3下行隧道（分配UPF侧N3 UL TEID），然后把N2 SM信息（QoS Flow、隧道信息）经AMF透传给gNB。 **Step 8（一次性下发Initial Context Setup）**：AMF向gNB下发 **NGAP Initial Context Setup Request**，这条消息一次性打包了：`Security Key (KgNB)` 用于AS层安全激活、`N2 SM information list`（PDU Session Resource Setup）、`UE Security Capabilities`、以及封装在NAS-PDU里的 **Service Accept**。这是5G相对4G的一个效率优化——把"建上下文+激活安全+建用户面+回NAS响应"合并为一条N2消息。 **Step 9-12（DRB建立与下行隧道闭环）**：gNB执行AS Security Mode Command、通过 `RRCReconfiguration` 建立DRB，把Service Accept投递给UE；随后gNB把 `AN Tunnel Info`（gNB侧N3 UL TEID）通过 Initial Context Setup Response 回给AMF。AMF再次 `UpdateSMContext` 把AN隧道信息转发给SMF，SMF第二次 `N4 Session Modification` 把AN隧道下发给UPF，至此下行隧道完全打通，UPF可以下发缓存数据。 ## 四、NAS Service Request 消息 IE 结构与安全设计 Service Request 是一个结构紧凑的NAS消息（TS 24.501 §8.2.21），其IE组织如下： ```mermaid flowchart TD SR["Service Request 消息
TS 24.501 §8.2.21"] SR --> M1["扩展协议鉴别符(5GMM)"] SR --> M2["安全头类型
(Integrity Protected, 不加密)"] SR --> M3["消息标识=Service Request(76)"] SR --> M4["NAS密钥集标识 ngKSI"] SR --> M5["Service Type
(signalling/data/MT/emergency/fallback/HPA)"] SR --> M6["5G-S-TMSI
(定位UE上下文)"] SR --> O1["Allowed PDU Session Status(可选)"] SR --> O2["Uplink Data Status(可选)"] SR --> O3["NAS Message Container(可选,R16小数据/CP-CIoT)"] ``` | IE | 必选/可选 | 作用 | 设计要点 | |----|-----------|------|----------| | Extended protocol discriminator | M | 标识为5GMM消息 | 固定值，不参与完整性计算 | | Security header type | M | 指示完整性保护、不加密 | 特殊安全头，明文可见 | | Service request message identity | M | 消息类型=76 | | | NAS key set identifier（ngKSI） | M | 指示使用的NAS安全上下文 | AMF据此选用正确KAMF派生密钥 | | Service type | M | 业务类型 | signalling/data/mobile-terminated/emergency/fallback/high priority access | | 5G-S-TMSI | M（已分配） | UE临时标识 | AMF据此在本地寻上下文 | | Allowed PDU Session Status | O | 声明要激活用户面的PDU Session | 用户面按需建立，省无线资源 | | Uplink Data Status | O | 声明有上行数据的PDU Session | 触发SMF快速恢复下行 | | NAS message container | O | 携带额外NAS负载 | R16小数据/CP-CIoT优化承载 | ### 安全设计意图：为什么"完整性保护但不加密" 这是整个机制最值得品味的设计。Service Request是 **完整性保护（integrity protected）但不加密（not ciphered）** 的。原因是：AMF必须先读取消息里明文的 `5G-S-TMSI` 才能找到对应的UE上下文、取出该UE的安全密钥——**这是一个鸡生蛋问题**：要用密钥解密，就得先有UE上下文；要找UE上下文，就得先读明文标识。标准给出的折中是：标识类IE明文，但整条消息用已存储的安全上下文算一个MAC做完整性校验，既能防篡改、防伪造，又不阻碍AMF定位。前4个字节（鉴别符/安全头/spare/消息标识）不参与MAC计算，其余部分参与。 ### Service Accept / Service Reject 的回执机制 成功时AMF通过Service Accept（TS 24.501 §8.2.17）回执，关键IE是 **PDU Session Status**（网络视角下还存在的PDU Session）、**PDU Session Reactivation Result**（哪些被成功重新激活）、**PDU Session Reactivation Result Error Cause**（哪些失败及5GSM原因值）。失败时回 **Service Reject**（§8.2.20），携带5GMM原因值： | 5GMM Cause | 含义 | UE处理 | |------------|------|--------| | #11 PLMN not allowed | 当前PLMN不允许 | 删除上下文，选其他PLMN | | #13 Roaming not allowed in this TA | 漫游区不允许 | 回到等效PLMN列表重选 | | #22 Congestion | 网络拥塞 | 按T3346退避后重试 | | #27/39 Cannot be reached/Unspecified | 网络无法服务 | 视情况本地释放 | ## 五、网络触发的 Service Request（Paging 路径） 当业务是从网络侧发起时（如下行数据、来电），UE处于CM-IDLE、AMF无法直接送达，于是先Paging再由UE回Service Request： ```mermaid sequenceDiagram participant UPF participant SMF participant AMF participant gNB as (R)AN participant UE Note over UE: CM-IDLE(无RRC连接) UPF->>SMF: 下行数据到达N6/N19, 无N3隧道->缓存或丢弃 SMF->>AMF: Namf_Communication_N1N2MessageTransfer(PDU Session ID, Paging Policy Info) Note over AMF: 判定UE为CM-IDLE不可达 AMF->>gNB: N2 Paging(5G-S-TMSI, TA List, Paging DRX) gNB->>UE: RRC Paging(空口寻呼) UE->>gNB: Service Request(NAS) via RRCSetupComplete Note over AMF,UE: 后续流程与UE触发完全一致 gNB->>AMF: N2 Initial UE Message(Service Request) AMF->>SMF: UpdateSMContext(恢复用户面) SMF-->>UPF: 释放并转发下行缓存数据 ``` 这里有几个工程细节值得注意：第一，SMF通过 `Namf_Communication_N1N2MessageTransfer` 把"PDU Session ID + Paging策略"告诉AMF，AMF据此决定Paging优先级（如Voice比普通数据优先）；第二，UE收到Paging后回的Service Request，其 **Service type = mobile terminated services**，与UE触发不同；第三，从Paging发出到UE真正可达之间存在"寻呼时延"，这也是运营商优化RRC-Inactive阈值、缩短寻呼响应的关键动因之一。 ## 六、与 RRC Resume（CM-CONNECTED-RRC-INACTIVE）的关系 很多工程师会把"恢复数据"误认为只有Service Request一条路。实际上5G提供了两层"省电+快速恢复"机制： - **CM-IDLE → CM-CONNECTED**：用Service Request，必须重建N2连接和AN侧UE上下文（走Initial Context Setup），开销较大； - **CM-CONNECTED-RRC-INACTIVE → RRC-CONNECTED**：UE的AN侧UE上下文 **仍缓存在gNB**，恢复时只发一个极简的 `RRCResumeRequest`（携带shortMAC-I校验），gNB本地就能恢复，无需AMF重新下发Initial Context Setup，时延极低。 两者的关系是：当gNB把UE挂起到RRC-Inactive时（N2+RRC Suspend），核心网视角UE仍是CM-CONNECTED；只有当gNB因RNA超时等触发 **N2 Release** 后，UE才进入CM-IDLE，此后恢复就必须走完整的Service Request。这也是网优中"调优Inactive Timer"能够显著降低Service Request信令风暴的根本原理。 ## 七、抓包识别与故障排查 ### Wireshark 过滤与识别 在5G核心网抓包（NGAP/NAS-5GS/PFCP）中识别Service Request链路： ```text # 识别NAS Service Request消息(message type=76) nas-5gs.mm.message_type == 76 # 识别Service Accept / Service Reject nas-5gs.mm.message_type == 77 || nas-5gs.mm.message_type == 78 # 聚焦NGAP Service Request相关过程 ngap && (nas-5gs.mm.message_type == 76) # 定位N4会话修改(PFCP)失败 pfcp && pfcp.cause ``` 观察一条完整Service Request，应能看到这条因果链：`Initial UE Message(Service Request)` → `PDU Session Resource Setup` → `Initial Context Setup Request/Response` → `N4 Session Modification`(两次) → 业务数据流。 ### 常见故障点与排错思路 1. **5G-S-TMSI 过时 / AMF上下文已清**：AMF找不到对应上下文，可能回Service Reject或触发Identification过程重新获取SUPI/Identity。排查：检查AMF日志中"context not found"、确认是否发生AMF重启或UE长期未活动被清理。 2. **NAS完整性校验失败**：UE与AMF的KAMF不同步（如旧安全上下文失效），AMF丢弃消息或回Service Reject。排查：核对AMF与USIM/ME侧的安全上下文计数器，必要时强制重注册。 3. **SMF拒绝恢复 / PDU Session已释放**：用户面恢复失败，Service Accept中 `PDU Session Reactivation Result Error Cause` 会给出5GSM原因值（如#38 Network failure、#39 Reactivation requested）。排查：查SMF会话状态、UPF N4是否成功。 4. **AS安全激活失败**：gNB下发Security Mode Command后未收到Complete，或Initial Context Setup Failure，AMF将清理上下文。排查：核查KgNB派生、UE安全能力协商、加密算法是否被策略禁用。 5. **拥塞（#22 Congestion）**：AMF过载时回退，UE按T3346定时器退避重试；若大量UE同时退避又同时重试，可能形成二次信令风暴，需配合AMF过载控制（Overload Control）策略。 ## 八、设计意图总结 Service Request看似是一条简单消息，实则凝结了5G系统的几项核心设计权衡：**复用已有上下文避免重注册的高开销**、**完整性保护但不加密以解决"先有鸡还是先有蛋"的安全定位难题**、**通过Allowed PDU Session Status实现用户面按需建立以节省无线资源**、**把Initial Context Setup设计为一次性打包安全/用户面/NAS响应以提升效率**、**用RRC-Inactive分层缓解CM-IDLE恢复的高时延**。真正理解这条流程，是掌握5G会话与连接管理（CM/SM）的入门钥匙，也是排障5G"连不上、上不了网、业务卡顿"类问题的第一现场。 ## 常见问题 **Q1：Service Request 和 Registration Request 都能从CM-IDLE建立连接，区别是什么？** A：Registration是"全量"过程——用于首次入网、周期更新、改变切片/移动性等，会重新协商完整上下文、可重新选择AMF、产生新5G-GUTI；Service Request是"轻量唤醒"过程——只在已注册前提下复用现有上下文，目的是恢复N1/N2连接和按需恢复用户面，开销远小于Registration。两者 NAS message type 也不同（Registration Request=65，Service Request=76）。 **Q2：Service Request 消息是否加密？为什么？** A：不加密，但完整性保护。因为AMF必须先读取明文的5G-S-TMSI才能定位UE上下文取出密钥——若加密就无法定位，陷入循环。标准折中为：标识明文可见，整条消息用已有安全上下文算MAC做完整性校验，兼顾"可定位"与"防伪造"。 **Q3：网络触发的Service Request，UE必须回应吗？能否忽略Paging？** A：UE收到Paging（且寻呼身份匹配）后，应在规范规定时间内响应Service Request（Service type=mobile terminated services）。若因覆盖、DRX、UE休眠等未响应，AMF会在TA List内重发；持续无响应则SMF/UPF会丢弃下行缓存或按策略处理，业务层表现为"对方不在线"。 **Q4：PDU Session Reactivation Result 失败时，UE和网络如何处理？** A：Service Accept中 `PDU Session Reactivation Result Error Cause` 会标明失败PDU Session及5GSM原因值。UE据此知道哪些会话用户面未恢复，可针对失败会话重新发起PDU Session Establishment；失败会话的SM上下文在核心网可能仍存在或被释放，取决于具体原因值（如#43 Invalid PDU Session ID表示已被释放）。 **Q5：CM-CONNECTED-RRC-INACTIVE 时UE发数据，走Service Request还是RRC Resume？** A：走 **RRC Resume**，不是Service Request。RRC-Inactive时AN侧UE上下文仍缓存在gNB，UE只需发携带shortMAC-I的RRCResumeRequest，gNB本地恢复即可，时延极低；此时核心网视角UE仍是CM-CONNECTED。只有当发生N2 Release、UE真正进入CM-IDLE后，恢复才必须用Service Request。 ## 参考来源 1. [3GPP TS 23.502 — Procedures for the 5G System, §4.2.3 Service Request](https://www.3gpp.org/dynareport/23502.htm) — UE触发（§4.2.3.2）与网络触发（§4.2.3.3）信令流程定义与Figure 4.2.3.2-1 2. [3GPP TS 24.501 — NAS protocol for 5GS, §5.6.1 / §8.2.21 / §8.2.17 / §8.2.20](https://www.3gpp.org/dynareport/24501.htm) — Service Request过程、消息IE结构、Service Accept/Reject定义 3. [3GPP TS 38.413 — NG Application Protocol (NGAP)](https://www.3gpp.org/dynareport/38413.htm) — Initial UE Message、Initial Context Setup、PDU Session Resource Setup等IE定义 4. [ShareTechnote — 5G NAS Service Setup](https://www.sharetechnote.com/html/5G/5G_ServiceSetup.html) — UE触发/网络触发两场景与5GMM-IDLE→CONNECTED状态迁移解读 5. [3glteinfo — 5G Service Request Procedure Call Flow](https://www.3glteinfo.com/call-flows/5g/service-request/) — Paging/RRC恢复/NAS业务信令与会话恢复的端到端时序 6. [Cisco Ultra Cloud Core — AMF/SMF Service Request Procedure Configuration Guide](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.pdf) — 厂商实现视角下CM-IDLE/CM-CONNECTED用户面激活过程 7. [Wireshark NAS-5GS — PDU Session Reactivation Result 解析](https://gitlab.com/wireshark/wireshark/-/issues/16842) — 抓包侧Service Accept中Reactivation Result IE的解析参考 --- > 本文由「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 等场景全覆盖。