首页 › protocols › 5G业务请求信令全链拆解

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）：

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：

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 各层）：

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 关键设计意图解读

四、关键信息单元（IE）逐字段拆解

4.1 NAS Service Request 消息结构（TS 24.501 §8.2.21.1）

graph TD
    SR["NAS Service Request 消息<br/>Message Type = 0x4C"]
    SR --> M1["Extended Protocol Discriminator<br/>= 0x7E (5GS MM)"]
    SR --> M2["Security Header Type<br/>0x0=integrity protected / 0x4=ciphered+IP"]
    SR --> M3["Message Authentication Code<br/>(MAC, 4 octets)"]
    SR --> M4["Sequence Number<br/>(1 octet, 用于重放保护)"]
    SR --> M5["Service Type<br/>(signalling/data/MT/emergency/fallback...)"]
    SR --> M6["ngKSI<br/>(NAS Key Set Identifier)"]
    SR --> M7["5G-S-TMSI<br/>(可选, 终端有合法临时身份时携带)"]
    SR --> M8["PDU Session Status<br/>(UE视角各PDU会话激活状态bitmap)"]
    SR --> M9["Uplink Data Status<br/>(有待发上行数据的会话bitmap)"]
    SR --> M10["Allowed PDU Session Status<br/>(允许激活的会话bitmap)"]
    SR --> M11["NAS Message Container<br/>(可选, 用于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 通常表现为以下过滤结果：

# 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

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 — 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 — NAS 消息结构与 IE 编码
  3. 3GPP TS 23.501 — System architecture for the 5G System; §5.3.7 Connection Management — CM-IDLE / CM-CONNECTED 状态模型
  4. ShareTechnote — 5G/NR NAS Service Setup — Service Request 流程图文解读（含网络触发与 UE 触发对比）
  5. Cisco Ultra Cloud Core 5G AMF Configuration Guide — Service Request Procedure — 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 等场景全覆盖。

51学通信知识星球海报-扫码加入

📎 本分类最新文章