首页 › core-network › 5G服务请求信令流程深度拆解

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的状态跃迁触发器，同时完成两件事：

重建N1 NAS信令连接（UE↔AMF），并把RRC从RRC_IDLE拉到RRC_CONNECTED；
重新激活（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信息的完整链路：

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<br/>(RRC Cause, 5G-S-TMSI, NAS PDU=ServiceRequest, UE Context Request)

    Note over AMF: 1)验证NAS MAC完整性<br/>2)选定待激活PDU Session
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request<br/>(PDU Session ID, Operation="Existing PDU session")
    SMF->>UPF: N4 Session Modification Request<br/>(通知UPF准备接收UL数据)
    UPF-->>SMF: N4 Session Modification Response
    SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response<br/>(携带 N2 SM info: QoS Flow, UL F-TEID)

    AMF->>gNB: NGAP Initial Context Setup Request<br/>(安全上下文, UE-AMBR, Mobility Restriction,<br/>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<br/>(+ PDU Session Resource Setup Response,<br/>AN N3 DL F-TEID)

    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request<br/>(下发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结构图）：

flowchart TD
    SR["NAS Message: Service Request<br/>(Security Header Type = Integrity Protected, NOT ciphered)"]
    SR --> EPD["Extended protocol discriminator<br/>= 0x7E (5GMM)"]
    SR --> SHT["Security header type"]
    SR --> SHO["Spare half octet"]
    SR --> ST["Service type<br/>(signalling/data/mt-access/emergency)"]
    SR --> KSI["NgKSI<br/>(NAS key set identifier, 指明用哪套密钥)"]
    SR --> TMSI["5G-S-TMSI<br/>(AMF Set ID + AMF Pointer + TMSI)"]
    SR --> PSS["PDU session status (位图)<br/>UE侧当前活跃的PDU Session集合"]
    SR --> UDS["Uplink data status (位图)<br/>有待发上行数据的PDU Session集合"]
    SR --> PSLA["PDU session list to activate<br/>本次要激活的PDU Session ID列表"]
    SR --> APSS["Allowed PDU session status<br/>(受限场景:漫游/接入限制下允许的子集)"]
    SR --> NMC["NAS message container (可选)<br/>携带额外被保护内容"]
    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发起：两个变体对比

flowchart LR
    subgraph A[网络发起 (mobile terminated access)]
        A1[下行数据到达UPF] --> A2[UPF缓存+通知SMF]
        A2 --> A3[SMF调Namf_N1N2MessageTransfer<br/>把N2 SM info提前推给AMF]
        A3 --> A4[AMF Paging UE]
        A4 --> A5[UE响应Service Request]
        A5 --> A6[AMF用已缓存的N2 SM info<br/>直接走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<br/>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双重跃迁

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链路。

参考来源

3GPP TS 23.502 V18.10.0 — Procedures for the 5G System (5GS) — Section 4.2.3.2 UE Triggered Service Request
3GPP TS 24.501 V18.8.0 — Non-Access-Stratum (NAS) protocol for 5GS — Section 8.2.17 Service Request message
ShareTechnote — 5G Service Setup / Service Request — 信令流程图与NAS消息解读
Cisco Ultra Cloud Core 5G AMF Configuration and Administration Guide — Service Request Procedure实现细节
3glteinfo — 5G Initial Context Setup Request (NGAP) — 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 等场景全覆盖。

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