# 5G业务请求流程（Service Request）信令全链拆解 ## 一、为什么需要 Service Request：CM-IDLE 与"按需恢复"的工程哲学 在 5G 核心网中，UE 完成注册后并不会一直占用 NG-RAN 与核心网之间的 N2、N3 资源。为了节省空口与传输资源、降低 gNB 与 UPF 的内存压力，当 UE 一段时间没有上下行数据时，网络会执行 **AN Release**（TS 23.502 clause 4.2.6），将 UE 从 `CM-CONNECTED` 迁移到 `CM-IDLE`，释放 N2 信令连接、N3 用户面隧道以及 RRC 连接。此时 UE 进入 `RRC_IDLE`（或经过 RRC_INACTIVE 的 `CM-CONNECTED`），网络侧仅保留 UE 的注册上下文（在 UDSF/UDM 与 AMF/SMF 中），N2/N3 资源全部回收。 当 UE 再次需要收发数据或信令时，必须有一套机制把"已释放但已注册"的 UE **重新拉回在线状态**，重新建立 NAS 信令连接、N2 连接以及 N3 用户面隧道。这套机制就是 **Service Request（业务请求）流程**，定义在 TS 23.502 clause 4.2.3，对应的 NAS 消息 SERVICE REQUEST 定义在 TS 24.501 section 8.2（消息内容表）与 section 9.11.3（各 IE 定义）。 它的设计意图可以归纳为三点： 1. **资源按需恢复**：只在该 UE 真正有业务时才重建用户面，避免海量空闲 UE 长期占用 N2/N3。 2. **批量、差异化重建**：通过 `Uplink data status` / `PDU session status` 等位图 IE，一次性精确告诉网络"哪几个 PDU Session 需要恢复、哪几个有上行数据待发"，而不是逐条重建，减少信令往返。 3. **安全优先**：即使在 CM-IDLE 首条上行消息中，SERVICE REQUEST 也要在已有 NAS 安全上下文下做完整性保护（带 NgKSI + MAC），防止伪造的业务请求把虚假 UE 拉入在线状态。 业务请求存在两条触发路径：**UE 触发**（UE 主动，对应 TS 23.502 clause 4.2.3.2）和**网络触发**（网络有下行数据/信令要送给空闲 UE，对应 clause 4.2.3.3 与 clause 4.2.3.4 的移动终接数据场景）。两者最终汇合到同一段"用户面重建"逻辑上。 下图给出 UE 在两种触发下共同经历的核心状态迁移： ```mermaid stateDiagram-v2 [*] --> CM_IDLE: 注册成功后 AN Release note right of CM_IDLE: 无N2/N3/RRC连接\n仅保留注册上下文 CM_IDLE --> CM_CONNECTED: UE触发 SERVICE REQUEST\n或响应Paging note left of CM_CONNECTED: 有NAS信令连接+N2+N3\n可立即收发用户面 CM_CONNECTED --> CM_IDLE: AN Release (N2 Release) ``` ## 二、UE 触发的业务请求：信令全链与 IE 逐步解析 当 UE 处于 CM-IDLE 且有上行信令/数据，或要响应寻呼时，UE 主动发起。完整信令链如下（TS 23.502 clause 4.2.3.2）： ```mermaid sequenceDiagram participant UE participant gNB as gNB (NG-RAN) participant AMF participant SMF participant UPF Note over UE: CM-IDLE / RRC_IDLE\n有上行数据或响应寻呼 UE->>gNB: RRCSetupRequest (5G-S-TMSI, cause) gNB-->>UE: RRCSetup UE->>gNB: RRCSetupComplete\n(NAS: SERVICE REQUEST, NgKSI, Service type) gNB->>AMF: NGAP Initial UE Message (NAS-PDU) Note over AMF: 校验MAC完整性\n比对KAMF与NAS COUNT AMF->>SMF: Nsmf_PDUSession_UpdateSMContext\n(Activate, N2 SM: PDU Session Resource Setup) SMF->>UPF: N4 Session Modification\n(更新FAR, 通知RAN N3地址) SMF-->>AMF: UpdateSMContext Response (含 N2 SM) AMF->>gNB: NGAP Initial Context Setup Request\n(PDU Session Resource Setup List, NAS: SERVICE ACCEPT) gNB->>UE: SecurityModeCommand + RRCReconfiguration\n(建立DRB, 携带 NAS: SERVICE ACCEPT) UE-->>gNB: RRCReconfigurationComplete gNB-->>AMF: Initial Context Setup Response (N3 TEID) AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (上报N3地址) Note over UE,UPF: CM-CONNECTED, N3用户面建立完成 ``` 逐消息解析关键 IE： - **RRCSetupRequest（TS 38.331）**：UE 在 `rrcSetupRequest-UE-identity` 中携带 `ng-5G-S-TMSI`（响应寻呼时）或 random value，并带 `establishmentCause`（如 `mo-Data`、`mo-Signalling`、`mt-Access`）。`mt-Access` 让 gNB 立刻识别这是寻呼响应。 - **NGAP Initial UE Message（TS 38.413 clause 8.4）**：gNB 用它把 NAS-PDU 交给 AMF，携带 `RAN UE NGAP ID`、`User Location Information`、`RRC Establishment Cause`。AMF 依据安全上下文校验 NAS 完整性。 - **Nsmf_PDUSession_UpdateSMContext（SBI，TS 29.502）**：AMF 给每个待恢复的 PDU Session 调用，`Operation` = activate，请求 SMF 生成 N2 SM 信息（PDU Session Resource Setup）。这就是把"建立请求"翻译成 N2 接口动作的桥梁。 - **N4 Session Modification（PFCP，TS 29.244）**：SMF 修改 UPF 的 FAR（Forwarding Action Rule），把下行转发目标更新为 gNB 分配的 N3 TEID；并清除"仅缓冲不转发"的标记。 - **NGAP Initial Context Setup Request（TS 38.413 clause 8.3.1）**：AMF 一次性下发 `PDU Session Resource Setup List`、安全上下文（KgNB 推演参数）、QoS 流参数，并把 NAS 消息 **SERVICE ACCEPT** 捎带在内——这是 5G 把"激活"与"建链"合并的高效做法。 - **SERVICE ACCEPT（TS 24.501）**：作为业务请求的成功响应，可携带 `PDU session status`、`PDU session reactivation result`、`PDU session reactivation result error cause`，告诉 UE 哪些 Session 恢复成功、哪些失败及原因。 > 设计要点：AMF 选择 **Initial Context Setup** 而非单独的"PDU Session Resource Setup"，是因为此时 UE 同时缺少 RRC 安全模式与 DRB。把 NAS Service Accept 捎带进 Initial Context Setup，省去一条独立的 NAS 直传消息——这是 5G 信令合并（piggyback）哲学的典型体现。 ## 三、网络触发的业务请求：下行数据通知 → 寻呼 → 上行响应 当 UE 处于 CM-IDLE、网络侧有下行数据要送达时，由网络触发。下行数据通知是这条链的真正起点（TS 23.502 clause 4.2.3.3 / 4.2.3.4）： ```mermaid sequenceDiagram participant DN as 外部DN participant UPF participant SMF participant AMF participant gNB as gNB participant UE Note over UE: CM-IDLE, 无N2/N3 DN->>UPF: 下行数据 (无活动N3隧道) Note over UPF: 缓存 + 触发 Data Notification UPF->>SMF: PFCP Session Report Request\n(Downlink Data Report) SMF-->>UPF: PFCP Session Report Response SMF->>AMF: Namf_Communication_N1N2MessageTransfer\n(N2 SM: 下行数据通知) alt UE 在 CM-CONNECTED AMF->>gNB: N2 PDU Session Resource Setup (直接建链) else UE 在 CM-IDLE AMF->>gNB: NGAP Paging (5G-S-TMSI, TAI列表) gNB->>UE: RRC Paging (Paging Frame/Occasion) UE->>gNB: RRCSetupRequest (mt-Access) UE->>gNB: RRCSetupComplete (NAS: SERVICE REQUEST, Service type=MT) gNB->>AMF: Initial UE Message (NAS-PDU) Note over AMF: 投递缓存的N1N2, 建UP end Note over UE,UPF: 用户面恢复, 下行数据送达 ``` 关键机制解读： - **下行数据通知的真正载体是 PFCP Session Report**（TS 29.244 clause 5.7）。SMF 在建立 PDU Session 时已经向 UPF 下发了缓冲策略与"有 DL 数据到达时上报"的规则；UPF 检测到下行数据且无可用 N3 隧道时，向 SMF 发 `Session Report Request`，其中 `Report Type = DLPD`（下行数据报告），并按 `PDR ID` 标识是哪个 QoS 流/会话。SMF 回 `Session Report Response` 并可选择下发进一步缓冲参数。 - **Namf_Communication_N1N2MessageTransfer（TS 29.518）**：SMF 把"N2 SM 信息（下行数据通知）"送给 AMF。若 UE 在 CM-IDLE，AMF 会回复"UE 不可达"的指示并把该 N1N2 消息**缓存**；随后发起 NGAP Paging。 - **NGAP Paging（TS 38.413 clause 9.2）**：AMF 在 UE 注册的跟踪区列表（TAI list）内向相关 gNB 发 Paging，携带 `UE Paging Identity = 5G-S-TMSI`、`TAI List for Paging`、可选 `Paging Priority`（按 ARP/5QI 提升优先级）。gNB 据 5G-S-TMSI 与 UE DRX 周期计算 `Paging Frame`/`Paging Occasion`，在空口发 RRC Paging。 - **寻呼响应即一次 UE 触发的业务请求**：UE 在对应 PO 收到寻呼后，发 SERVICE REQUEST，`Service type = mobile terminated services`，`establishmentCause = mt-Access`。AMF 据此把缓存的 N1N2 投递并完成 UP 恢复。可以看到，两条触发路径在"用户面重建"这一段完全汇合。 ## 四、SERVICE REQUEST 消息 IE 结构与 Service type 详解 下图给出 SERVICE REQUEST 的 IE 构成（依据 TS 24.501 消息内容表），其中 M=必选、O=可选： ```mermaid flowchart TB SR["SERVICE REQUEST 消息\n(TS 24.501 sec.8.2)"] SR --> M1["扩展协议鉴别符 EPD=5GMM (M)"] SR --> M2["安全头类型 Security header type (M)"] SR --> M3["空半字节 Spare half octet (M)"] SR --> M4["NgKSI 5GS密钥集标识 (M)\n指示用哪个 KAMF 做完整性保护"] SR --> M5["Service type 服务类型 (M)\n决定业务优先级与建链语义"] SR --> O1["Uplink data status (O)\n有上行数据的 PSI 位图"] SR --> O2["PDU session status (O)\nUE 侧活动 PSI 位图"] SR --> O3["Allowed PDU session status (O)\n希望网络恢复的 PSI"] SR --> O4["NAS message container (O)\n捎带封装其他NAS消息"] style M4 fill:#e3f2fd style M5 fill:#fff3e0 style O1 fill:#f1f8e9 style O2 fill:#f1f8e9 style O3 fill:#f1f8e9 ``` 核心 IE 说明表： | IE（TS 24.501 参考） | 存在性 | 作用与工程含义 | |---|---|---| | NgKSI（5GS key set identifier，9.11.3.27） | M | 指明完整性保护所用 NAS 安全上下文（native 或 mapped），含 TSC 与 KSI 值（7=无可用密钥）。AMF 据此找 KAMF 校验 MAC。 | | Service type（9.11.3.47） | M | 区分信令/数据/移动终接/紧急/紧急回落/提升级信令，决定是否建 UP、是否走 EPS Fallback、是否提升优先级。 | | Uplink data status（9.11.3.69） | O | PSI 位图，置位即该 Session 有上行数据待发；AMF 仅对其触发 UP 恢复，避免全量重建。 | | PDU session status（9.11.3.42） | O | UE 侧"活动 Session"位图，AMF 与本地状态比对，发现不一致即触发 Release/重建，做状态同步。 | | Allowed PDU session status（9.11.3.40） | O | UE 期望网络恢复的 PSI 子集，进一步收窄恢复范围。 | | NAS message container（9.11.3.31） | O | 在业务请求内捎带封装额外 NAS 消息，减少信令往返。 | `Service type` 取值（TS 24.501 9.11.3.47，半字节编码）： | 编码（十进制） | 取值 | 触发场景与行为差异 | |---|---|---| | 0 | signalling | 仅建 NAS 信令连接，不建 UP；常用于纯信令（如周期性注册替代、UP 策略更新）。 | | 1 | data | 建信令连接并恢复带 `Uplink data status` 的 Session 用户面。 | | 2 | mobile terminated services | 响应网络寻呼/通知的标准取值。 | | 3 | emergency services | 紧急业务，提升接入优先级（AC 11–15）。 | | 4 | emergency services fallback | **紧急回落**：AMF 据此触发 EPS Fallback（TS 23.502 clause 4.13.2），把 UE 切到 EPC 承载紧急语音。 | | 5 | elevated signalling | MPS/优先级用户的提升级信令。 | 两条触发路径对比： | 维度 | UE 触发（4.2.3.2） | 网络触发（4.2.3.3 / 4.2.3.4） | |---|---|---| | 起点 | UE 有上行数据/信令 | UPF 收到下行数据（或 SMF 有 N1 信令要发） | | 是否寻呼 | 否（UE 自发接入） | CM-IDLE 时必须先 Paging | | Service type 典型值 | data / signalling | mobile terminated services（UE 侧响应） | | 关键前置消息 | RRCSetupRequest(mo-Data) | PFCP Session Report → N1N2 Transfer → NGAP Paging | | 信令往返数 | 较少 | 多一次 Paging 往返 | | 共同终点 | CM-CONNECTED + N2/N3 用户面恢复 | 同左 | ## 五、设计意图：为什么是这样写的 1. **位图 IE 取代逐会话消息**：`Uplink data status` / `PDU session status` / `Allowed PDU session status` 用一张位图同时表达多个 PDU Session 的状态与诉求。这在 UE 同时有多个 Session（如一个 IMS、一个 internet）时，把 N 条潜在信令压成一次，是 5GC 相比 EPC 的显著信令优化。 2. **完整性优先于身份**：CM-IDLE 下首条上行消息不做 AKA，但必须带 NgKSI + MAC 完整性。攻击者即便伪造 SERVICE REQUEST，因无法计算正确 MAC 而被 AMF 丢弃，从源头防止伪造在线化攻击。 3. **状态自检同步**：`PDU session status` 让 AMF 与 UE 对"哪些 Session 还活着"做对账。一旦某 Session 在网络侧已释放而 UE 不知情（如 N4 故障），AMF 可主动发 Release，避免半开状态。 4. **Service type 统一优先级语义**：把"是不是紧急、要不要回落 EPS、是不是优先用户"压进一个半字节，让 AMF/RAN 在接入阶段就完成 QoS 与抢占决策，省去后续协商。 5. **Service Accept 捎带 + 合并 Initial Context Setup**：把"接受请求""建 RRC 安全""建 DRB""建 N3"合并到一条 NGAP 下行，最大化减少空口往返。 ## 六、抓包识别与故障排查 **抓包识别（TShark/Wireshark）**： - NAS 业务请求：`nas-5gs` 协议，5GMM `Message type` = `0x4c`（SERVICE REQUEST），`Service accept` = `0x4e`，`Service reject` = `0x4d`。建议用 `nas-5gs.mm.message_type == 0x4c` 定位。 - NGAP：`ngap` 过滤，关注 `InitialUEMessage`（含 NAS-PDU）、`InitialContextSetupRequest/Response`、`Paging`（procedure code 0x02）。 - PFCP：`pfcp` 过滤，定位 `Session Report Request` 中 `report_type.downlink_data_report == 1`，即可确认网络触发的真正起点。 - SBI：HTTP/2 上 `POST /namf-comm/v1/ue-contexts/{supi}/n1-n2-messages`（N1N2MessageTransfer）。 **常见故障与排错思路**： - **寻呼无响应（Paging failure）**：先确认 NGAP Paging 的 TAI 列表与 UE 注册区一致、5G-S-TMSI 正确；再核对 UE 的 DRX 周期、Paging Frame/PO 计算；最后看空口覆盖与 RRC 重建原因。 - **完整性校验失败导致丢弃**：AMF 日志常见 MAC mismatch，多因 UE 侧 KAMF 推演错误或本地 NgKSI 与 AMF 不一致——排查历史安全模式（Security Mode Command）与 horizontal/vertical key derivation。 - **SERVICE REJECT**：原因值 #22（拥塞）、#27（无法到达）、#11（PLMN 不允许）等。#27 常伴随反复寻呼失败，需要回看 Paging 链。 - **PDU Session 恢复失败**：检查 Service Accept 中 `PDU session reactivation result` 与 `error cause`，常见因 SMF/UPF 间 N4 Session Modification 失败或 N3 地址协商异常。 - **EPS Fallback 不触发**：确认 UE 发的 Service type 是否为 4（emergency services fallback），以及 UE 能力 `IMS voice over PS session supported Indication` 与 NR 覆盖下的 voice support。 ## 常见问题 **Q: SERVICE REQUEST 和 Registration Request 都能建立 NAS 信令连接，区别是什么？** A: Registration 用于（重新）建立/更新 UE 与网络的注册关系，伴随身份、安全模式的可能重建；Service Request 用于已注册、处于 CM-IDLE 的 UE **快速恢复**在线与用户面，不再做注册级鉴权，只做完整性校验。前者是"建档"，后者是"唤醒"。 **Q: 网络触发的业务请求，UPF 怎么知道要通知 SMF？** A: PDU Session 建立时 SMF 已通过 N4 给 UPF 下发缓冲策略与"DL 数据到达上报"规则。当 UE 处于 CM-IDLE 无 N3 隧道时，UPF 缓冲数据并通过 PFCP `Session Report Request`（Downlink Data Report）上报 SMF，SMF 再发 N1N2MessageTransfer 给 AMF 触发 Paging。 **Q: `Uplink data status` 和 `Allowed PDU session status` 都讲恢复，为什么要两个？** A: `Uplink data status` 是"事实"——哪些 Session 确实有上行数据待发；`Allowed PDU session status` 是"意愿"——UE 希望网络恢复哪些。AMF 通常取二者交集决定恢复范围，既避免恢复没数据的 Session，也尊重 UE 的偏好。 **Q: 响应寻呼的 Service Request 为什么 Service type 取 mobile terminated services？** A: 这告诉 AMF 本请求是寻呼响应而非 UE 主动发起，AMF 据此把此前缓存的 N1N2 消息（下行数据通知/N1 信令）投递并完成用户面恢复，与 UE 触发的"主动发数据"路径在语义上区分，便于计费与流程分支判定。 **Q: CM-CONNECTED 时还会有网络触发的业务请求吗？** A: 会。当 UE 在 CM-CONNECTED 但某 PDU Session 的 N3 用户面因空口释放等原因不可用（如 RRC_INACTIVE、AN 内部资源回收）时，网络可直接发 N2 PDU Session Resource Setup 重建用户面，无需 Paging。这也是网络触发分支中 CM-CONNECTED 与 CM-IDLE 两条子路径的由来。 ## 参考来源 1. [3GPP TS 23.502 V19.x — System procedures for the 5G System](https://www.3gpp.org/dynareport/23502.htm) — clause 4.2.3 Service Request（4.2.3.2 UE 触发、4.2.3.3 / 4.2.3.4 网络触发）、clause 4.2.6 AN Release、clause 4.13.2 EPS Fallback。 2. [3GPP TS 24.501 V19.x — NAS protocol for 5G](https://www.3gpp.org/dynareport/24501.htm) — section 8.2 SERVICE REQUEST/SERVICE ACCEPT 消息内容表，section 9.11.3 各 IE（NgKSI、Service type、Uplink/PDU session status）。 3. [3GPP TS 38.413 V19.x — NGAP](https://www.3gpp.org/dynareport/38413.htm) — clause 8.3.1 Initial Context Setup、clause 8.4 Initial UE Message、clause 9.2 Paging。 4. [3GPP TS 29.244 V19.x — PFCP](https://www.3gpp.org/dynareport/29244.htm) — clause 5.7 Session Report 与 Downlink Data Report（下行数据通知机制）。 5. [3GPP TS 29.518 / 29.502 — NAMF / NSMF SBI](https://www.3gpp.org/dynareport/29518.htm) — Namf_Communication_N1N2MessageTransfer、Nsmf_PDUSession_UpdateSMContext 服务操作。 --- > 本文由「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 等场景全覆盖。