# 5G UE发起的Service Request信令流程全链拆解 在5G核心网中，UE绝大多数时间处于**CM-IDLE**（连接管理空闲）状态以省电。当UE有上行信令/数据要发送，或收到网络寻呼需要响应下行数据时，必须通过**Service Request（服务请求）**流程把N1信令连接和用户面资源一次性重建起来。这是5GC里调用频次最高、却最容易被"看起来简单"误导的一个流程——它横跨NAS、NGAP、N4三条协议栈，且每一步都嵌套了安全验证与PDU会话状态同步。 本文严格依据 **TS 23.502 Section 4.2.3.2（UE Triggered Service Request）** 与 **TS 24.501 Section 8.2.17（Service Request消息）**，逐步拆解每个信令消息中的关键IE、设计意图与排错要点。 --- ## 一、机制定位：Service Request到底解决什么问题 Service Request 的本质是**从CM-IDLE回到CM-CONNECTED的状态跃迁触发器**，同时完成两件事： 1. **重建N1 NAS信令连接**（UE↔AMF），并把RRC从RRC_IDLE拉到RRC_CONNECTED； 2. **重新激活（reactivate）已存在PDU Session的用户面资源**——N3/N9隧道和DRB，使上下行数据得以收发。 它**不建立新的PDU会话**（那是PDU Session Establishment的活），也**不做主鉴权**（UE在Registration时已经鉴权过，AMF本地持有KAMF安全上下文）。这一点决定了它的轻量特性：AMF可以跳过鉴权直接验证完整性。 Service Request有四种触发类型，封装在NAS消息的 **Service type** IE里： | Service type值 | 含义 | 典型场景 | |---|---|---| | `signalling` | 仅建立信令连接 | UE有上行NAS信令（如去注册、周期注册） | | `data` | 建立连接并激活上行数据PDU Session | UE有上行用户数据要发 | | `mobile terminated access` | 响应网络寻呼 | 下行数据/信令到达，UE被Paging | | `emergency services` / `emergency services fallback` | 紧急业务 | IMS紧急呼叫、EPS Fallback | --- ## 二、关键前提：为什么Service Request"只完整性保护、不加密" 这是理解整个流程安全属性的钥匙。依据 **TS 24.501 Section 4.4.6**： - Service Request的NAS消息 **Security header type = "integrity protected"（0b0100），但NOT ciphered**。 - 原因：UE刚从空闲态醒来，第一条上行NAS消息必须能让AMF**用本地存储的KAMF派生出的完整性密钥（KNASint）验证MAC**，确认"这个5G-S-TMSI确实是对应的UE"。但此时**尚未确认对端是否处于同步的加密序列上**，强行加密反而会因count失配而无法解密——所以加密推迟到后续的NAS消息（如Service Accept）。 - 若Service Request本身需要携带额外被保护的小数据（如NAS Message Container，用于eCallBox、小数据传输），则放在 **NAS Message Container** IE里。 > 设计意图：**先验明正身（完整性），再谈机密（加密）**，避免空闲态首条消息因加密失步而"卡死"。 --- ## 三、完整信令时序图（UE发起，含SMF/UPF交互） 以最复杂的"UE有上行数据要发"（service type = data）为例，这是需要AMF→SMF→UPF反向取N2 SM信息的完整链路： ```mermaid 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 (Establishment Cause=mo-Data) gNB->>UE: RRC Setup UE->>gNB: RRC Setup Complete (携带 NAS Service Request) gNB->>AMF: NGAP Initial UE Message
(RRC Cause, 5G-S-TMSI, NAS PDU=ServiceRequest, UE Context Request) Note over AMF: 1)验证NAS MAC完整性
2)选定待激活PDU Session AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request
(PDU Session ID, Operation="Existing PDU session") SMF->>UPF: N4 Session Modification Request
(通知UPF准备接收UL数据) UPF-->>SMF: N4 Session Modification Response SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response
(携带 N2 SM info: QoS Flow, UL F-TEID) AMF->>gNB: NGAP Initial Context Setup Request
(安全上下文, UE-AMBR, Mobility Restriction,
PDU Session Resource Setup List=N2 SM info) gNB->>UE: AS Security Mode Command (SMC) UE-->>gNB: AS Security Mode Complete gNB->>UE: RRC Reconfiguration (建立DRB) UE-->>gNB: RRC Reconfiguration Complete gNB-->>AMF: NGAP Initial Context Setup Response
(+ PDU Session Resource Setup Response,
AN N3 DL F-TEID) AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request
(下发AN Tunnel Info / DL F-TEID) SMF->>UPF: N4 Session Modification (下发AN N3隧道) UPF-->>SMF: N4 Session Modification Response SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response Note over AMF: 经NGAP Downlink NAS Transport下发Service Accept AMF->>gNB: NGAP Downlink NAS Transport (Service Accept) gNB->>UE: Service Accept (更新PDU Session Status) Note over UE,UPF: 用户面双向打通，上下行数据开始收发 UPF->>gNB: DL Data (经N3隧道) gNB->>UE: DL Data UE->>gNB: UL Data gNB->>UPF: UL Data (经N3隧道) ``` > 抓包识别：在N2口先看到 `Initial UE Message`（Procedure Code=15）且其NAS PDU解码出Extended protocol discriminator=0x7E（5GMM）、Message type=0x4C（Service Request），即可锁定本流程；N4口会紧跟两条 `PFCP Session Modification Request/Response`。 --- ## 四、NAS Service Request消息IE逐字段拆解 依据 **TS 24.501 Section 8.2.17**，Service Request的消息结构如下（IE结构图）： ```mermaid flowchart TD SR["NAS Message: Service Request
(Security Header Type = Integrity Protected, NOT ciphered)"] SR --> EPD["Extended protocol discriminator
= 0x7E (5GMM)"] SR --> SHT["Security header type"] SR --> SHO["Spare half octet"] SR --> ST["Service type
(signalling/data/mt-access/emergency)"] SR --> KSI["NgKSI
(NAS key set identifier, 指明用哪套密钥)"] SR --> TMSI["5G-S-TMSI
(AMF Set ID + AMF Pointer + TMSI)"] SR --> PSS["PDU session status (位图)
UE侧当前活跃的PDU Session集合"] SR --> UDS["Uplink data status (位图)
有待发上行数据的PDU Session集合"] SR --> PSLA["PDU session list to activate
本次要激活的PDU Session ID列表"] SR --> APSS["Allowed PDU session status
(受限场景:漫游/接入限制下允许的子集)"] SR --> NMC["NAS message container (可选)
携带额外被保护内容"] SR --> DP["Device properties"] style SR fill:#e8f0fe,stroke:#1a73e8 style ST fill:#fff3e0,stroke:#f57c00 style UDS fill:#e6f4ea,stroke:#34a853 style PSLA fill:#e6f4ea,stroke:#34a853 ``` | IE（IEI） | 作用 | 工程意义 | |---|---|---| | **Service type** | 区分4类触发 | 决定是否需要激活UP；`mt-access`只激活有DL数据的会话 | | **NgKSI** | 标识本次完整性校验使用的NAS密钥集 | AMF据此派生KNASint验证MAC；mapped/native两种 | | **5G-S-TMSI** | 唯一标识UE临时身份 | AMF用它定位UE Context（含KAMF） | | **PDU session status** | 位图：UE认为哪些PDU Session还"活着" | 与AMF侧状态比对，发现"幽灵会话"则同步释放 | | **Uplink data status** | 位图：哪些会话有UL数据待发 | 决定激活哪些UP资源（仅service type=data时有效） | | **PDU session list to activate** | 本次要激活的具体PDU Session ID | UE显式点名，避免全量激活浪费空口资源 | | **Allowed PDU session status** | 受限场景下UE认为允许激活的子集 | 漫游/接入类别限制时使用 | | **NAS message container** | 额外被保护的小数据/容器 | 控制面小数据（CP CIoT）、eCallBox等 | **待激活PDU Session的选取逻辑**（这是最容易出错的地方）： ``` 最终激活集合 = PDU session status ∩ Uplink data status（UE侧有UL数据） ∩ AMF/SMF侧"该会话确实存在且未释放" ∩ Allowed PDU session status（若存在） ``` 若三者交集为空，AMF仍可接受（仅建立信令连接），但不激活任何UP——对应"signalling"型Service Request。 --- ## 五、NGAP侧关键消息与IE ### 1. Initial UE Message（gNB→AMF） - **RAN UE NGAP ID**、**User Location Information**（TAI+NCI） - **RRC Establishment Cause**（透传自空口，TS 38.331）：`mo-Signalling` / `mo-Data` / `mo-ExceptionData` / `mt-Access` / `highPriorityAccess` / `emergency` - **5G-S-TMSI**（若UE有有效GUTI） - **Selected PLMN ID**、**AMF Set ID**（用于AMF重选） - **NAS-PDU**（=Service Request） - **UE Context Request**（指示"需要AN上下文"——但注意，Service Request场景下UE通常**不置位**此IE，因为AMF后续会主动下发Initial Context Setup） ### 2. Initial Context Setup Request（AMF→gNB） 这是把安全上下文和会话资源一次性"灌"给gNB的核心消息： | IE | 内容 | |---|---| | **UE aggregate maximum bit rate** | UE-AMBR，限速整UE | | **UE security capabilities** | NR/E-UTRA加解密算法、完整性算法列表 | | **Security key** | K~NG-RAN~（由AMF从K~AMF~派生） | | **Trace Activation** | 信令跟踪配置（排障/MDT） | | **Mobility Restriction List** | 禁止TA/PLMN、服务PLMN——gNB据此限制切换目标 | | **GUAMI** | 标识服务AMF | | **PDU Session Resource Setup List** | N2 SM info（QoS Flow列表、UL N3 F-TEID、Session-AMBR） | ### 3. Initial Context Setup Response（gNB→AMF） 返回 **AN Tunnel Info**（即gNB侧N3下行F-TEID），AMF再转交SMF→UPF，打通下行隧道。 > 设计巧思：AMF把"AS安全激活 + DRB建立 + N3隧道"三件事合并进一次Initial Context Setup，相比4G显著减少空口往返次数——这是5G"信令收敛"理念的直接体现。 --- ## 六、网络发起 vs UE发起：两个变体对比 ```text flowchart LR subgraph A[网络发起 (mobile terminated access)] A1[下行数据到达UPF] --> A2[UPF缓存+通知SMF] A2 --> A3[SMF调Namf_N1N2MessageTransfer
把N2 SM info提前推给AMF] A3 --> A4[AMF Paging UE] A4 --> A5[UE响应Service Request] A5 --> A6[AMF用已缓存的N2 SM info
直接走Initial Context Setup] end subgraph B[UE发起 (data/signalling)] B1[UE有UL数据/信令] --> B2[UE发Service Request] B2 --> B3[AMF临时无N2 SM info] B3 --> B4[AMF反向问SMF要N2 SM info
Nsmf_PDUSession_UpdateSMContext] B4 --> B5[拿到后走Initial Context Setup] end style A3 fill:#fff3e0 style A4 fill:#fce4ec style B4 fill:#e8f0fe ``` | 维度 | 网络发起（mt-access） | UE发起（data/signalling） | |---|---|---| | N2 SM info来源 | SMF**提前**经Namf推送缓存于AMF | AMF**临时反向**向SMF索取 | | 额外信令开销 | 多一次Paging，少一次UpdateSMContext | 少Paging，多一次UpdateSMContext往返 | | 典型时延敏感点 | Paging响应窗口 | SMF响应速度 | | UPF动作 | 先缓存DL数据，待隧道就绪转发 | 先准备接收UL，建好下行后转发 | --- ## 七、状态机视角：CM/RRC双重跃迁 ```mermaid stateDiagram-v2 [*] --> CM_IDLE: Registration完成/RRC释放 CM_IDLE --> CM_CONNECTED: 发送Service Request\n(RRC Establishment) state CM_CONNECTED { [*] --> AS_Security_Pending AS_Security_Pending --> DRB_Establishing: AS SMC成功 DRB_Establishing --> UP_Active: DRB建立完成 } CM_CONNECTED --> CM_IDLE: N2 Release / RRC Release\n(无数据超时) UP_Active --> CM_IDLE: 空闲定时器超时 ``` NAS层 `5GMM` 状态：`RM-REGISTERED + CM-IDLE` →（Service Request）→ `RM-REGISTERED + CM-CONNECTED`；AS层 `RRC_IDLE` → `RRC_CONNECTED`。两层必须严格协同，任何一层卡住都会导致数据不通。 --- ## 八、抓包识别与常见故障排错 ### 抓包识别要点 - **N2口**：`Initial UE Message`（NGAP Procedure Code 15）→ 若NAS PDU的Message type=0x4C，即Service Request。 - **N11口（SBI）**：连续两次 `POST /pdu-sessions/{pduSessionRef}/modify`（Nsmf_PDUSession_UpdateSMContext），分别对应"取N2 SM info"与"回传AN隧道"。 - **N4口（PFCP）**：两条 `Session Modification Request/Response`，分别"准备UL"和"下发DL F-TEID"。 ### 常见故障点与排错思路 | 故障现象 | 可能原因 | 排错切入点 | |---|---|---| | AMF收到Service Request后回 **Service Reject** | ①完整性校验失败（MAC错） ②5G-S-TMSI找不到上下文 ③并发限制 | 看Reject的5GMM cause；优先查AMF是否丢失UE Context（如UDSF/重启） | | Service Reject cause #22 Congestion | AMF过载/SMF过载 | 查AMF负载、PFCP链路、SMF容量 | | Service Reject cause #28 Unknown PDU session ID | UE上报的PDU Session ID在SMF侧已释放 | 检查PDU session status位图同步；可能SMF已隐式释放而UE未感知 | | AMF发了Initial Context Setup但gNB回 **Initial Context Setup Failure** | 空口资源不足/AS SMC失败/UE Radio Capability缺失 | 查gNB日志的Cause；确认UE Radio Capability是否已获取 | | 信令通了但**用户面不通** | N3/N4隧道未建好；UPF未收到DL F-TEID | 抓N4最后一条Modification，确认AN Tunnel Info是否下发；查UPF是否转发 | | 反复Service Request"乒乓" | 空闲定时器过短/PDU Session异常释放重建 | 查N2 Release触发原因与UE侧inactive timer配置 | ## 九、设计哲学小结 Service Request看似"把UE从睡梦中叫醒"，实则是一套**安全验证 + 状态同步 + 资源重建**的三位一体机制： - 用"仅完整性保护"兼顾安全与鲁棒； - 用"PDU session status位图"在每次唤醒时隐式完成会话状态对账； - 用"Initial Context Setup合并下发"实现空口信令收敛。 理解了这套机制，就理解了5GC里"会话生命周期管理"的骨架——后续的PDU Session Modification、Release、N2 Handover，本质上都是在CM-CONNECTED基础上对这套资源的增量操作。 --- ## 常见问题 **Q1：Service Request和Registration Request有什么区别？为什么不能复用？** A：Registration完成的是"身份注册+鉴权+永久上下文建立"（含主鉴权5G AKA/EAP-AKA'，UDM取签约），是重流程；Service Request发生在**已注册**前提下，仅做"连接重建+资源激活"，AMF用本地KAMF验完整性即可，不走UDM、不做主鉴权。两者目的不同，复用会增加冗余鉴权开销。 **Q2：为什么Service Request里要带PDU session status位图？多此一举吗？** A：不是。UE在CM-IDLE期间可能与网络"失步"——比如SMF因超时隐式释放了某个会话，UE却还以为它活着。每次Service Request带上位图，AMF/SMF就能比对、发现"幽灵会话"并触发同步释放（下发Service Accept更新状态）。这是5G相比4G增强的会话一致性保障。 **Q3：service type=signalling时，用户面会建起来吗？** A：不会。signalling型Service Request只建立N1信令连接（RRC_CONNECTED + N2 UE Context），不激活任何DRB/N3隧道。UE通常用它在空闲态发起周期注册更新、Configuration Update回执等纯信令操作，最省电省资源。 **Q4：UE发起场景，AMF没有N2 SM info怎么办？** A：AMF通过 `Nsmf_PDUSession_UpdateSMContext`（Operation="Existing PDU session"）**反向向SMF索取**——SMF从UPF取UL F-TEID后，把N2 SM info（QoS Flow、隧道）返回给AMF，AMF再合并进Initial Context Setup Request下发给gNB。这是UE发起与网络发起流程在信令走向上的核心差异。 **Q5：Service Reject里常见的5GMM cause有哪些？如何快速定位？** A：高频值有 #22 Congestion（过载）、#27/#28（DNN/PDU session问题）、#23 Security mode rejected（安全失败）、#43 Invalid UE identity。定位顺序：先看cause类别→安全类查KAMF/UDSF→会话类查SMF状态→拥塞类查NF负载与PFCP链路。 --- ## 参考来源 1. [3GPP TS 23.502 V18.10.0 — Procedures for the 5G System (5GS)](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — Section 4.2.3.2 UE Triggered Service Request 2. [3GPP TS 24.501 V18.8.0 — Non-Access-Stratum (NAS) protocol for 5GS](https://www.etsi.org/deliver/etsi_ts/124500_124599/124501/18.08.00_60/ts_124501v180800p.pdf) — Section 8.2.17 Service Request message 3. [ShareTechnote — 5G Service Setup / Service Request](https://www.sharetechnote.com/html/5G/5G_ServiceSetup.html) — 信令流程图与NAS消息解读 4. [Cisco Ultra Cloud Core 5G AMF Configuration and Administration Guide](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/amf/2025-02/config-and-admin/b_ucc-5g-amf-config-and-admin-guide_2025-02/5G-AMF_Config_Guide_chapter_01000.html) — Service Request Procedure实现细节 5. [3glteinfo — 5G Initial Context Setup Request (NGAP)](https://www.3glteinfo.com/messages/5g/ngap/initial-context-setup-request/) — NGAP 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 等场景全覆盖。