# 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 为枢纽的状态迁移：
```mermaid
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 容器：
```mermaid
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
(NAS: Service Request)
AN->>AMF: N2 INITIAL UE MESSAGE
(NAS: Service Request)
Note over AMF: 校验有效安全上下文
解析 Active/Uplink data status
loop 需激活的每个PDU Session
AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Req
(PDU Session ID, Operation=Activate)
SMF->>UPF: N4 Session Modification Req
(激活DL forwarding)
UPF-->>SMF: N4 Session Modification Rsp
SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Rsp
(N2 SM: QoS Flow, N3 DL TEID)
end
AMF->>AN: N2 REQUEST (INITIAL CONTEXT SETUP REQUEST)
(N2 SM info + NAS: Service Accept)
Note over AN: 空口安全模式+DRB建立
AN->>UE: RRC Reconfiguration (+ NAS: Service Accept)
AN-->>AMF: N2 REQUEST ACK
(INITIAL CONTEXT SETUP RSP: N3 UL TEID)
loop 每个激活PDU Session
AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Req
(N2 SM: AN N3 UL TEID)
SMF->>UPF: N4 Session Modification Req
(下发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**：
| Active flag | Service Accept 后行为 |
|---|---|
| `active`（置位） | N1 NAS 连接保持，UE 留在 **CM-CONNECTED**，继续后续业务（典型：UE 即将发起新 PDU Session Establishment） |
| `not active`（未置，默认） | 用户面建立后，AMF/gNB 可在任意时刻触发 **AN Release**，UE 回到 **CM-IDLE**（典型：仅有少量上行数据要发） |
## 四、Service Request NAS 消息的 IE 结构拆解
下表按 TS 24.501 Section 9.11.3.46 给出 Service Request 的 IE 构成与作用：
| IE（TS 24.501 9.11.3.x） | 类型 | 作用 | 必备性 |
|---|---|---|---|
| Extended protocol discriminator | M | 固定为 5GMM (0x7E) | M |
| Security header type | M | 指明本消息未完整性保护（0000） | M |
| Spare half octet | M | 占位 | M |
| ngKSI | M | 指示所用安全上下文标识 | M |
| Message type (0x7C) | M | Service Request 消息身份 | M |
| **Active flag** | 9.11.3.5 | 决定 N1 连接是否保持 | O |
| **PDU session status** | 9.11.3.41 | UE 侧 active 的 PDU Session 位图 | O |
| **Uplink data status** | 9.11.3.48 | UE 待发上行数据的 PDU Session 位图 | O |
| **Allowed PDU session status** | 9.11.3.47 | 当前 Allowed Area 内 UE 期望激活的 PDU Session 位图（R16） | O |
| **NAS message container** | 9.11.3.33 | 携带一条被完整性保护的上行 NAS 消息（如 Registration/Deregistration/5GSM 消息） | O |
下图将 Service Request 的 IE 组织成"信令头 + 会话意愿 + 搭车信令"三层结构，便于理解其设计：
```mermaid
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。
| 维度 | UE 触发 Service Request | 网络触发 Service Request |
|---|---|---|
| 触发条件 | 上行数据/上行信令 | 下行数据（经 Paging）/下行 SMS |
| RRC Establishment Cause | mo-Data / mo-Signaling | mt-Access |
| 关键状态 IE | Uplink data status 主导 | 由 SMF 指定待激活 PDU Session |
| 典型时延敏感场景 | 上行业务首包、信令更新 | VoNR 被叫、下行 SMS over NAS |
| 完整性保护 | Service Request 不保护 | 同左（Paging 本身不保护） |
## 六、Service Reject 与故障定位
Service Request 失败时，AMF 返回 **Service Reject**（TS 24.501 8.2.16），携带 5GMM cause。常见 cause 与定位思路：
| 5GMM cause | 含义 | 排查方向 |
|---|---|---|
| #22 Congestion | 网络拥塞/AMF 过载 | 查 AMF 过载控制策略、`Nnrf_NFStatusNotify` 告警、是否触发 NAS backoff timer |
| #27 N1 mode not allowed | N1 模式不允许 | UE 是否被限制、区域/订阅配置 |
| 服务区/PLMN 不允许类（如 #11 PLMN not allowed） | 接入控制 | 查 UE 的 Equivalent PLMN、TA Restriction、`Access and Mobility Policy` |
| #9 / #10 身份派生失败/隐式分离 | 上下文丢失 | 查 UDM/UDR 订阅、AMF 是否已隐式分离该 UE |
### 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](https://www.3gpp.org/dynareport/23502.htm) — UE/网络触发 Service Request 流程定义
2. [3GPP TS 24.501 — NAS protocol for 5GS, Section 5.6.1 & 9.11.3.46](https://www.etsi.org/deliver/etsi_ts/124500_124599/124501/) — Service Request 消息内容与 IE 编解码
3. [ShareTechnote — 5G Service Setup](https://www.sharetechnote.com/html/5G/5G_ServiceSetup.html) — Service Request 调用流程图与 IE 解读
4. [3glteinfo — 5G Service Request Procedure Call Flow](https://www.3glteinfo.com/call-flows/5g/service-request/) — 触发条件、前置条件、信令序列
5. [3GPP TS 38.413 — NGAP, Section 8.4 INITIAL UE MESSAGE / 8.7 INITIAL CONTEXT SETUP](https://www.3gpp.org/dynareport/38413.htm) — N2 容器承载 NAS 与上下文建立
6. [3GPP TS 29.502 — Nsmf_PDUSession Service, Section 5.2.2.3 UpdateSMContext](https://www.3gpp.org/dynareport/29502.htm) — 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 等场景全覆盖。
