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的特定子情形）。它有两条触发路径：

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

两条触发路径的核心区别在于"谁先动"：

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

无论哪条路径，最终落到AMF的消息都是同一条 NAS Service Request，后续处理流程完全一致——这是5G过程设计上的优雅复用。

三、UE发起的 Service Request 完整信令流（CM-IDLE）

下面是 TS 23.502 Figure 4.2.3.2-1 所定义的UE触发Service Request完整信令时序，从CM-IDLE一直走到用户面激活：

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组织如下：

flowchart TD
    SR["Service Request 消息<br/>TS 24.501 §8.2.21"]
    SR --> M1["扩展协议鉴别符(5GMM)"]
    SR --> M2["安全头类型<br/>(Integrity Protected, 不加密)"]
    SR --> M3["消息标识=Service Request(76)"]
    SR --> M4["NAS密钥集标识 ngKSI"]
    SR --> M5["Service Type<br/>(signalling/data/MT/emergency/fallback/HPA)"]
    SR --> M6["5G-S-TMSI<br/>(定位UE上下文)"]
    SR --> O1["Allowed PDU Session Status(可选)"]
    SR --> O2["Uplink Data Status(可选)"]
    SR --> O3["NAS Message Container(可选,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原因值：

五、网络触发的 Service Request（Paging 路径）

当业务是从网络侧发起时（如下行数据、来电），UE处于CM-IDLE、AMF无法直接送达，于是先Paging再由UE回Service Request：

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链路：

# 识别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 — 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 — Service Request过程、消息IE结构、Service Accept/Reject定义
3. 3GPP TS 38.413 — NG Application Protocol (NGAP) — Initial UE Message、Initial Context Setup、PDU Session Resource Setup等IE定义
4. ShareTechnote — 5G NAS Service Setup — UE触发/网络触发两场景与5GMM-IDLE→CONNECTED状态迁移解读
5. 3glteinfo — 5G Service Request Procedure Call Flow — Paging/RRC恢复/NAS业务信令与会话恢复的端到端时序
6. Cisco Ultra Cloud Core — AMF/SMF Service Request Procedure Configuration Guide — 厂商实现视角下CM-IDLE/CM-CONNECTED用户面激活过程
7. Wireshark NAS-5GS — PDU Session Reactivation Result 解析 — 抓包侧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 等场景全覆盖。