# 5G Service Request（业务请求）信令流程全链拆解：CM-IDLE 态连接恢复与用户面重建机制 ## 一、为什么 Service Request 是 5GS 协议栈最频繁的信令 在 5G 系统中，UE 一旦进入 **CM-IDLE 态**，意味着它与 AMF 之间的 NAS 信令连接被释放、与 (R)AN 之间的 N2 信令连接和 N3 用户面隧道也全部释放，仅保留注册状态和 PDU 会话上下文。当这个 UE 需要重新发送上行数据，或者网络有下行数据要送达它时，必须先恢复这条"端到端通道"——执行这一恢复动作的核心协议过程就是 **Service Request（业务请求）**。 按 3GPP TS 24.501 §5.6.1.1 的定义，Service Request 的根本目的是 **"将 5GMM 模式从 5GMM-IDLE 改变为 5GMM-CONNECTED 模式"**；按 TS 23.502 §4.2.3.1，它由处于 CM-IDLE 态的 UE 或 5GC 发起，用于：(1) 请求与 AMF 建立安全连接；(2) 恢复一个或多个 PDU 会话的用户面连接。 Service Request 与初始注册（Initial Registration）有本质区别：注册是 UE 首次接入网络、获取服务的"开户"动作，会建立完整的 UE 上下文；而 Service Request 是在已经注册的前提下，对一个"已注册但暂时离线"的 UE 进行"唤醒 + 重连"。从协议演进看，Service Request 继承自 4G EPC 的同名流程，但 5G 引入了 **多 PDU 会话并行恢复、Uplink Data Status 位图、Allowed PDU Session Status、MICO/扩展空闲模式 DRX、异步通信、寻呼策略差异化** 等新机制，使其复杂度远超 4G。 今天聚焦 **TS 23.502 §4.2.3（Release 18）**，逐消息、逐 IE 拆解三类 Service Request 信令链，并给出抓包识别与排错实战。 ## 二、触发条件：谁会发起 Service Request ### 2.1 UE 触发的场景（TS 24.501 §5.6.1.1） | 触发条件 | 典型业务 | Service Request 携带内容 | |---------|---------|------------------------| | 上行用户数据待发（PDU 会话已激活） | 刷短视频、发微信 | Uplink Data Status 位图 | | 上行信令待发（非 PDU 会话相关 NAS 信令） | MO-SMS、移动性更新触发的信令 | Service type = "signalling" | | 响应网络的 Paging 或 Notification | 下行数据/呼叫到达 | Service type = 对应业务 | | UE 处于"高优先级信令"（elevated signalling） | 紧急业务回落、监管优先服务 | Service type = "elevated signalling" | | 移动终止 SMS 通知响应 | 接收短信 | 触发用户面恢复 | ### 2.2 网络触发的场景（TS 23.502 §4.2.3.3） 网络触发 Service Request 的核心是 **"下行数据/下行信令到达，但 UE 离线"**，常见于： - **场景 A**：UPF 收到某 PDU 会话的下行数据，但 UPF 中没有该 PDU 会话的 AN 隧道信息（N3 隧道已释放）→ UPF 上报 Data Notification → SMF → AMF 发起 Paging； - **场景 B**：SMF/SMSF/PCF/LMF 等需要用 `Namf_Communication_N1N2MessageTransfer` 向 UE 投递 N1 消息，且 UE 处于 CM-IDLE； - **场景 C**：NF 使用 `Namf_MT_EnableUEReachability` 请求 AMF 建立与 UE 的 NAS 连接（如移动终止 SMS、定位）。 ## 三、UE 触发的 Service Request：完整信令时序（TS 23.502 §4.2.3.2） 这是现网中最常见的形态——UE 从口袋里掏出手机准备发数据，触发的就是这条链路。 ```mermaid sequenceDiagram autonumber participant UE participant RAN as (R)AN/gNB participant AMF participant SMF participant UPF Note over UE: 处于 CM-IDLE，PDU会话上下文已存在但N3隧道释放 UE->>RAN: RRC Setup Request (RRC Establishment Cause) RAN->>UE: RRC Setup UE->>RAN: RRC Setup Complete
(携带 NAS Service Request) RAN->>AMF: N2 Initial UE Message (NAS Service Request, RRC Cause, User Location) Note over AMF: 解析Uplink Data Status，识别待恢复的PDU会话 AMF->>AMF: 校验安全上下文(可能触发Security Mode Control) loop 对每个待恢复的PDU会话 AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(PDU Session ID, Operation="Activate", N2 SM Info pending) SMF->>UPF: N4 Session Modification Request
(为该PDU会话重新分配/确认N3/N9隧道) UPF-->>SMF: N4 Session Modification Response SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response
(N2 SM Info: QFI, QoS Profile, CN Tunnel Info) end AMF->>RAN: N2 Request (N2 SM Info, NAS Service Accept) RAN->>UE: RRC Reconfiguration (建立DRB, N3隧道对端地址) UE-->>RAN: RRC Reconfiguration Complete RAN->>AMF: N2 Request Ack (RAN Tunnel Info = TEID) AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(AN Tunnel Info) SMF->>UPF: N4 Session Modification (AN Tunnel Info) Note over UE,UPF: N3用户面隧道恢复，上下行数据可双向传输 ``` ### 3.1 关键信令消息解析 **① NAS Service Request 消息（TS 24.501 §8.2.16）** 这条 NAS 消息是整个流程的灵魂，它"搭载"在 RRC Setup Complete 中，经 gNB 透传给 AMF。其消息类型字段（Message type）固定为 **0x4c**，是抓包时识别该流程的第一指纹。 | Information Element | 是否必选 | 作用 | 抓包字段 | |-------------------|---------|------|---------| | Extended protocol discriminator | 必选 | 标识 5GS Mobility Management | `nas-5gs.mm` | | Security header type | 必选 | 标识是否加密/完整性保护 | — | | Message type | 必选 | = Service request (0x4c) | `message_type = 76 (0x4c)` | | Service type | 必选 | 标识触发原因：signalling / data / elevated signalling / emergency 等 | `service_type` | | **NAS key set identifier** | 必选 | 指示 UE 期望使用的密钥集（KSI） | `ngksi` | | **PDU session status** | 条件必选 | 位图，指示 UE 侧当前认为哪些 PDU 会话仍 active | `pdu_session_status` | | **Uplink data status** | 条件必选 | 位图，指示哪些 PDU 会话有上行待发数据（驱动用户面恢复） | `uplink_data_status` | | **Allowed PDU session status** | 可选 | UE 建议网络可恢复的 PDU 会话集合 | `allowed_pdu_session_status` | | MA PDU session information | 可选 | 多接入 PDU 会话场景指示 | — | | Additional information | 可选 | 运营商扩展 | — | **设计意图**：UE 在一条 NAS 消息里用位图一次性表达"我现在有哪些会话、哪些急着想发数据、哪些请你别动"三重信息，让 AMF 可以批量为多个 PDU 会话并行触发用户面恢复，避免逐会话往返——这是 5G 相对 4G 在"恢复效率"上的关键优化。 **② N2 Initial UE Message（TS 38.413）** gNB 收到 RRC 消息后，用 NGAP 的 `Initial UE Message` 把 NAS PDU 上交给 AMF，并携带 **RRC Establishment Cause**（如 `mo-Signalling`、`mo-Data`、`mt-Access`）、**User Location Information**（TAI+NR-CGI）、**UE Context Request** 等关键 IE。其中 RRC Cause 反过来帮助 AMF 判断这是 UE 主动发起还是响应 Paging。 **③ Nsmf_PDUSession_UpdateSMContext（TS 23.502 §4.2.3.2 step 4）** AMF 对每个待恢复的 PDU 会话，向其锚点 SMF 发起 SBI 更新，关键参数包括 **PDU Session ID**、**PDU Session Resource Setup Transfer（N2 SM Info）**、**Operation type = "Activate"**。SMF 据此通过 **N4 Session Modification** 让 UPF 准备好接收下行数据（安装转发规则、确认 N9 隧道），并把 N2 SM Info（含 QFI、QoS Profile、CN N3 Tunnel Info）回给 AMF。 **④ N2 Request（PDU Session Resource Setup）与 RRC Reconfiguration** AMF 把 N2 SM Info 装进 NGAP 下行消息发给 gNB，gNB 通过 **RRC Reconfiguration** 建立 DRB（数据无线承载），并把 UPF 的 N3 隧道对端地址告诉 UE 侧协议栈。UE 回复 RRC Reconfiguration Complete 后，gNB 用 **N2 Request Ack** 把自己分配的 AN Tunnel Info（TEID）上报，AMF 再回传给 SMF/UPF，至此 **N3 用户面隧道双向打通**。 ## 四、网络触发的 Service Request：从下行数据到 Paging 再到连接（TS 23.502 §4.2.3.3） 网络触发链路的"前半段"在核心网内部完成（UPF→SMF→AMF），后半段才转化为 Paging，最终落到 UE 触发的 Service Request。 ```mermaid sequenceDiagram autonumber participant UE participant RAN participant AMF participant SMF participant UPF Note over UPF: 收到下行数据包，但无AN隧道信息(N3已释放) alt UPF缓存模式 UPF->>UPF: 缓存下行数据(步骤2a/2b) UPF->>SMF: Data Notification(N4 Session ID, QFI, DSCP) SMF-->>UPF: Data Notification Ack else SMF缓存模式 UPF->>SMF: 转发下行数据包(步骤2c) end SMF->>AMF: Namf_Communication_N1N2MessageTransfer
(SUPI, PDU Session ID, N2 SM Info:
QFI/QoS Profile/CN N3 Tunnel Info/S-NSSAI, ARP, Paging Policy Indicator) alt UE在AMF为CM-CONNECTED AMF-->>SMF: 响应(N1/N2已下发) Note over AMF: 流程跳转至步骤6，直接走N2下发 else UE在AMF为CM-IDLE AMF-->>SMF: 响应(尝试联系UE，N2 SM Info可能需重发) AMF->>RAN: Paging(UE Paging Identity, TAI List,
Paging Priority, 服务类型) RAN->>UE: 空口 Paging UE->>RAN: 触发UE Initiated Service Request(响应Paging) Note over UE,SMF: 接续第三节流程，恢复用户面 SMF->>UPF: 缓存数据/转发下行数据经N3 end ``` ### 4.1 Data Notification 与缓冲策略（TS 23.501 §5.8.3） 这是网络触发流程最精妙的设计。当 UPF 收到下行数据却发现"对端隧道没了"，并不会直接丢弃，而是： - **UPF 缓冲（UPF-based buffering）**：UPF 自行缓存数据包，向 SMF 发送 **Data Notification**（携带 N4 Session ID、QFI、DSCP）；SMF 回复 Data Notification Ack。 - **SMF 缓冲（SMF-based buffering）**：若 SMF 指示，UPF 直接把数据包转发给 SMF 缓存，待用户面恢复后再发。 这种"缓冲 + 通知"机制保证了 CM-IDLE UE 在被唤醒期间到达的下行数据不丢失。当 **扩展缓冲（Extended Buffering）** 启用时（典型于 MICO 模式或扩展空闲 DRX），SMF 会在 N1N2MessageTransfer 中携带 "扩展缓冲支持"指示，AMF 若判定 UE 暂不可达，会在拒绝响应里回送 **"估计的最大等待时间"**（依据 UE 下次周期性注册时间或下一个寻呼时间窗口推算），供 SMF 决定缓冲多久。 ### 4.2 寻呼策略差异化（Paging Policy Differentiation，TS 23.501 §5.4.3） 当 PDU 会话类型为 IP 时，UPF 会从下行数据包的 IP 头取出 **DSCP（IPv4）/ TC（IPv6）**，连同 QFI 一起放进 Data Notification。SMF 据此推导出 **Paging Policy Indicator（PPI）**，再通过 N1N2MessageTransfer 交给 AMF，最终影响空口 Paging 的优先级。这意味着高优先级业务（如 IMS 语音）的下行数据能更快唤醒 UE。 ### 4.3 AMF 的多重可达性判定 收到 N1N2MessageTransfer 后，AMF 并非无条件 Paging，而是要逐项判定： - UE 是否处于 **CM-IDLE** 且 AMF 能寻呼到； - 是否存在 **Paging Restriction（寻呼限制，TS 23.501 §5.38.1）**； - UE 是否处于 **MICO 模式 / 扩展空闲 DRX / 仅非 3GPP 注册** 等导致不可达； - UE 是否在 **不允许区域（Non-Allowed Area）**； - 是否启用了 **异步通信（Asynchronous Type Communication）**——若是，AMF 先缓存消息，等 UE 进 CM-CONNECTED 再投递。 任一判定失败，AMF 都会以带原因值的响应拒绝 SMF，避免无效寻呼风暴。 ## 五、Service Accept / Service Reject：流程的收尾与异常分支 ```mermaid stateDiagram-v2 [*] --> CM_IDLE: UE注册成功后释放NAS连接 CM_IDLE --> CM_CONNECTED: UE/NW触发Service Request成功
(Service Accept) CM_CONNECTED --> CM_IDLE: AN Release(UE Context Release) CM_IDLE --> CM_IDLE: Service Reject(保持5GMM-REGISTERED) CM_CONNECTED --> CM_CONNECTED: Service Request
(CM-CONNECTED态激活用户面) note right of CM_IDLE 仅5GMM-REGISTERED.ATTEMPTING在non-allowed area 可发elevated signalling end note ``` - **Service Accept**：当 AMF 成功恢复信令连接/用户面，回复 Service Accept，可携带 **PDU Session Status**（网络侧视角）与 **PDU Session Reactivation Result**（哪些会话恢复成功/失败），让 UE 与网络对齐状态。 - **Service Reject**：当 UE 处于不允许区域、网络拒绝时，回送 Service Reject（TS 24.501 §8.2.18）。UE 进入 5GMM-REGISTERED 但停止 T3517，若非紧急业务，UE 需重新发起注册；若消息携带 **T3346**（退避定时器），UE 在该定时器超时前不得重发，除非高优先级/紧急/响应 Paging。 ### 5.1 PDU Session Status 对齐机制 这是 Service Request 易被忽视但极重要的副作用。UE 与 AMF 各自维护一份 PDU 会话状态位图，Service Request/Service Accept 是双方"对账"的时刻：若 AMF 发现 UE 上报的某会话状态与自己存储的不一致（如 UE 侧已释放但网络侧还认为 active），AMF 可通过 **Configuration Update Command** 或后续过程发起去激活，保持 UE 与 5GC 的会话视图同步。 ## 六、抓包实战：如何识别一条 Service Request **工具**：Wireshark + ngap / nas-5gs / pfcp 解析器（需配合 KSEa / SQN 解密 NAS）。 **过滤表达式速查**： | 目的 | Wireshark Display Filter | |------|--------------------------| | 抓 Service Request NAS 消息 | `nas-5gs.mm.message_type == 0x4c` 或 `nas-5gs.mm.message_type == 76` | | 抓 Service Accept | `nas-5gs.mm.message_type == 0x4e` | | 抓 Service Reject | `nas-5gs.mm.message_type == 0x4f` | | 看触发的 N2 初始消息 | `ngap.procedure_code == 15` (InitialUEMessage) | | 看 N4 会话修改 | `pfcp.msg_type == 53` (Session Modification Request) | | 看 Paging | `ngap.procedure_code == 1` | **识别要点**： 1. 在空口/N2 侧，先看到 RRC Setup（三步接入）→ RRC Setup Complete 里嵌 NAS message type = 0x4c，即可确认 Service Request； 2. 展开 NAS 消息，检查 **Service type** 字段：`data`（0x01）= 有上行数据；`signalling`（0x00）= 仅有信令；`elevated signalling`（0x03）= 高优先级； 3. 检查 **Uplink Data Status** 位图，与紧随其后的 N4 Session Modification 一一对应，验证用户面恢复范围； 4. 若是网络触发，先于 Paging 出现的应是 UPF→SMF 的 Data Notification（N4 接口）与 SMF→AMF 的 N1N2MessageTransfer（HTTP/2 SBI）。 ## 七、常见故障点与排错思路 | 故障现象 | 可能根因 | 排查方向 | |---------|---------|---------| | UE 发 Service Request 后长期无 Service Accept | AMF 与 SMF 间 Nsmf_PDUSession_UpdateSMContext 失败（SMF 找不到该会话上下文） | 查 SMF 日志 PDU Session ID 是否存在；查 UDM 订阅；确认注册时上下文是否已写回 | | 下行数据到 UPF 但 UE 一直收不到 Paging | AMF 判定 UE 不可达（MICO/扩展 DRX）或寻呼限制 | 查 AMF 的 UE 上下文：是否 MICO、Paging Restriction、UE Reachability 配置 | | 用户面恢复后仍不通 | N3/N9 隧道信息（TEID/IP）在 SMF↔UPF↔gNB 间不一致 | 抓 N4 Session Modification 与 N2 Request Ack，比对 AN/CN Tunnel Info | | UE 反复发起 Service Request | PDU Session Status 不一致，AMF/SMF 去激活导致 UE 反复重连 | 查 Configuration Update / 是否触发去注册；排查会话状态对齐 | | Service Reject 携带 T3346 | 网络过载或拒绝策略 | 查 AMF 拥塞控制配置；确认 UE 是否在不允许区域 | ## 八、Release 18 中的增强点 R18 在 Service Request 框架下持续演进，值得关注的增强包括： - **异步通信（Asynchronous Communication）**与 MICO 的协同：NF 触发的消息可在 AMF 缓存，待 UE 可达再投递，减少寻呼； - **多接入 PDU 会话（ATSSS）场景**下 Service Request 的 MA PDU session information 处理； - **卫星/非地面网络（NTN）**场景下，配合更长往返时延对 Service Request 计时器与寻呼窗口的调整； - **RedCap / CIoT** 终端下扩展缓冲与用户面 IoT 优化（TS 23.501 §5.31.8）对 Service Request 的精简。 ## 九、常见问题 **Q1: Service Request 和 Registration 有什么本质区别？** A: Registration 是"开户/接入"——UE 首次或重新建立注册关系，建立/更新 UE 上下文（包括鉴权、获取临时 ID、TAI List 等）；Service Request 是"唤醒/重连"——在已注册前提下，把一个 CM-IDLE 的 UE 重新拉回 CM-CONNECTED 并恢复用户面，不改变注册关系本身。Service Request 失败可能要求重新 Registration，但二者目的和信令内容完全不同。 **Q2: UE 触发和网络触发的 Service Request，最终信令链路是否相同？** A: 后半段相同。网络触发的前半段在核心网内（UPF Data Notification → SMF → AMF N1N2MessageTransfer → AMF Paging），一旦 UE 收到 Paging 并响应，就转化为标准的 UE 触发 Service Request（§4.2.3.2），后续用户面恢复链路完全一致。 **Q3: Uplink Data Status 和 PDU Session Status 这两个位图有什么区别？** A: PDU Session Status 表达"UE 侧认为当前哪些 PDU 会话是 active 的"（状态对账用）；Uplink Data Status 表达"哪些 PDU 会话此刻有上行数据急着想发"（驱动用户面恢复）。前者是"有什么"，后者是"现在要什么"。AMF 主要依据后者决定为哪些会话发起 N2 SM Info 下发。 **Q4: 为什么 CM-CONNECTED 态也会用 Service Request？** A: CM-CONNECTED 态下 N2/N1 信令连接还在，但某个 PDU 会话的用户面连接可能被去激活（User Plane Deactivated，TS 23.502 §4.2.3 描述 SR 在 CM-IDLE 和 CM-CONNECTED 均可用于激活用户面）。此时 Service Request 不需要重建 RRC/N2，仅触发 N4 修改与 N2 SM Info 恢复用户面，是"局部"用户面激活。 **Q5: Service Reject 里的 T3346 和注册拒绝里的 T3346 是一回事吗？** A: 概念上都是"退避定时器"，让 UE 在拥塞时退避，但触发场景不同：注册流程的 T3346 用于 Registration Reject，Service Request 的 T3346 用于 Service Reject。两者都要求 UE 在超时前不得重发（紧急/高优先级/响应 Paging 除外）。 ## 参考来源 1. [3GPP TS 23.502 — Procedures for the 5G System, §4.2.3 Service Request](https://www.3gpp.org/dynareport/23502.htm) — UE 触发与网络触发业务请求流程定义 2. [3GPP TS 24.501 — NAS protocol for 5G, §5.6.1.1 / §8.2.16](https://www.3gpp.org/dynareport/24501.htm) — Service Request 过程目的与 NAS 消息 IE 结构 3. [3GPP TS 38.413 — NG-RAN NGAP, Initial UE Message / Paging](https://www.3gpp.org/dynareport/38413.htm) — N2 接口信令 IE 4. [ShareTechnote — 5G Service Setup](https://www.sharetechnote.com/html/5G/5G_ServiceSetup.html) — Service Request 触发条件与 NAS 消息字段图解 5. [Cisco Ultra Cloud Core 5G SMF — UP Session Activation/Deactivation Service Request Procedures](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/smf/2024-03/config-admin/b_ucc-5g-smf-config-and-admin-guide_2024-03/m_up-session-activation-and-deactivation-service-request-procedures.html) — SMF 侧用户面激活/去激活实现细节 6. [通信大视野 / 博客园 — 5G 系统流程 Service Request 网络触发](https://www.cnblogs.com/bitmetaverse/articles/18020232) — Data Notification 与 N1N2MessageTransfer 中文流程解析 --- > 本文由「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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)