首页 › core-network › 5G服务请求信令流全链拆解

5G服务请求信令流全链拆解:UE触发与网络触发双路径深度解析

一、机制定位与设计意图

5G Service Request(服务请求)是TS 23.502 Section 4.2.3定义的核心网关键流程,其本质是一个"空闲态唤醒"机制——将处于CM-IDLE状态的UE重新拉回到CM-CONNECTED状态,并激活用户面(User Plane)资源。如果说Registration是UE"报到注册",PDU Session Establishment是"申请管道",那么Service Request就是"开闸放水"。

该机制解决的核心矛盾是:移动性省电需求与数据即时可达性之间的平衡。UE在无业务时进入CM-IDLE释放所有无线承载和N3隧道,仅保留核心网中的PDU Session上下文(SM Context);当上行或下行数据到达时,通过Service Request快速恢复用户面连接,而无需重新建立PDU Session。

TS 23.502 V18.x将Service Request拆分为三个子流程:

子流程编号 名称 适用场景
4.2.3.1 UE Triggered Service Request UE有上行数据/信令需求
4.2.3.2 Network Triggered Service Request 下行数据到达,UE处于CM-IDLE
4.2.3.3 Service Request for RRC-Inactive UE UE处于CM-CONNECTED但RRC-Inactive

二、UE触发Service Request完整信令流(TS 23.502 Section 4.2.3.1)

2.1 端到端时序图

sequenceDiagram
    participant UE
    participant RAN as (R)AN/gNB
    participant AMF
    participant SMF
    participant UPF as UPF(PSA)
    participant PCF

    Note over UE,RAN: Step 1-2: AN连接建立
    UE->>RAN: RRC Connection Request
    RAN->>UE: RRC Connection Setup
    UE->>RAN: RRC Connection Setup Complete<br/>(携带NAS Service Request)

    Note over RAN,AMF: Step 3: N2消息转发
    RAN->>AMF: N2 Uplink NAS Transport<br/>(NAS Service Request + UserLocationInfo)

    Note over AMF: Step 4: NAS安全验证
    AMF->>AMF: 验证Service Request完整性保护<br/>检查5G-GUTI映射的SUPI<br/>验证Service Type

    Note over AMF,UE: Step 5: NAS SMC(条件触发)
    AMF->>UE: NAS Security Mode Command
    UE->>AMF: NAS Security Mode Complete

    Note over AMF,SMF: Step 6-7: PDU Session激活请求
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request<br/>(PDU Session ID, SUPI, DNN, S-NSSAI,<br/>UserLocationInfo, ReqType="existing_pdu_session")
    SMF->>SMF: 校验PDU Session状态<br/>确定UPF(PSA)隧道信息
    SMF->>PCF: SmPolicyAssociation_Update(可选)
    PCF->>SMF: Policy Update(可选)

    Note over SMF,UPF: Step 8: N4会话修改(准备UL隧道)
    SMF->>UPF: N4 Session Modification Request<br/>(Create FAR/URR, 安装检测规则)
    UPF->>SMF: N4 Session Modification Response

    Note over SMF,AMF: Step 9: N1N2消息传递
    SMF->>AMF: N1N2Message Transfer<br/>(N2 SM Info: QoS Profile List,<br/>CN Tunnel Info=UPF N3 TEID/IP,<br/>PDU Session ID)

    Note over AMF,RAN: Step 10-11: N2请求下发
    AMF->>RAN: N2 Initial Context Setup Request<br/>或 PDU Session Resource Setup Request<br/>(含N2 SM Info + NAS Service Accept)
    RAN->>UE: RRC Reconfiguration<br/>(DRB建立, NAS Service Accept)
    UE->>RAN: RRC Reconfiguration Complete

    Note over RAN,AMF: Step 12: N2响应(AN隧道信息)
    RAN->>AMF: N2 Initial Context Setup Response<br/>(含AN Tunnel Info=gNB N3 TEID/IP)

    Note over AMF,SMF: Step 13: AN隧道信息转发
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request<br/>(AN Tunnel Info)

    Note over SMF,UPF: Step 14: N4会话修改(完成DL隧道)
    SMF->>UPF: N4 Session Modification Request<br/>(提供AN Tunnel Info作为DL转发规则)
    UPF->>SMF: N4 Session Modification Response

    Note over UE,UPF: 用户面激活完成
    UE->>RAN: Uplink Data
    RAN->>UPF: N3 Uplink Data
    UPF->>RAN: N3 Downlink Data
    RAN->>UE: Downlink Data

2.2 关键IE逐层解析

NAS Service Request消息结构(TS 24.501 Section 8.48)

IE名称 类型 长度 说明
Extended Protocol Discriminator 字段 1字节 值=0x7E(5GS Mobility Management)
Security Header Type 字段 1/2字节 值=0x2(Integrity Protected)
Spare Half Octet 字段 1/2字节 保留
Service Request Message Identity 字段 1/2字节 值=0x7C
Service Type 枚举 1/2字节 0=信令, 1=数据, 2=移动终端信令, 3=紧急呼叫, 4=紧急服务回退
5G-S-TMSI 字段 48比特
Uplink Data Status TLV 可选 指示哪些PDU Session有上行数据待发送
PDU Session Status TLV 可选 指示UE侧已建立的PDU Session列表
Allowed PDU Session Type TLV 可选 R16新增,指示允许的PDU Session类型
NAS Message Container TLV 可选 携带需要加密保护的NAS消息

设计要点:Service Request消息仅做完整性保护(Integrity Protected),不做加密。这是因为AMF需要先读取S-TMSI和Service Type才能确定安全上下文。如果消息被加密,AMF无法知道"谁在请求什么",这是一个典型的"先验明身份、后加密内容"的设计模式。

N2 SM Information结构(TS 38.413 Section 9.3.2.2)

N2 SM Information (PDU Session Resource Setup Request Transfer)
├── PDU Session ID
├── S-NSSAI
├── QoS Flow Setup Request List
│   ├── QoS Flow Identifier (QFI)
│   ├── QoS Flow Level QoS Parameters
│   │   ├── 5QI (5G QoS Identifier)
│   │   ├── ARP (Allocation and Retention Priority)
│   │   ├── GFBR (Guaranteed Flow Bit Rate) - 仅GBR QoS Flow
│   │   ├── MFBR (Maximum Flow Bit Rate) - 仅GBR QoS Flow
│   │   └── Notification Control
│   └── QoS Flow Map (QFI → DRB映射)
├── UL NG-U UP TNL Information (UPF侧N3隧道端点)
│   ├── UPF IP Address
│   └── UPF TEID
└── PDU Session Type (IPv4/IPv6/Ethernet/Unstructured)

2.3 AMF处理逻辑状态机

stateDiagram-v2
    [*] --> NAS_Security_Check: 收到Service Request
    NAS_Security_Check --> MAC_Verify: 提取5G-S-TMSI
    MAC_Verify --> Context_Retrieval: MAC-I验证通过
    MAC_Verify --> Reject_MacFail: MAC-I验证失败
    Context_Retrieval --> ServiceType_Check: 获取UE MM Context
    ServiceType_Check --> MultiSMF_Coordination: Service Type=数据
    ServiceType_Check --> Signaling_Only: Service Type=信令
    MultiSMF_Coordination --> Wait_All_SMF: 并行发送UpdateSMContext
    Wait_All_SMF --> Aggregate_N2Info: 收集所有SMF的N2 SM Info
    Aggregate_N2Info --> N2_Request_Send: 组装N2 Request
    N2_Request_Send --> Wait_N2_Response
    Wait_N2_Response --> Forward_AN_Tunnel: 收到N2 Response
    Forward_AN_Tunnel --> [*]: 用户面激活完成
    Signaling_Only --> Service_Accept: 仅建立信令连接
    Service_Accept --> [*]
    Reject_MacFail --> [*]: 发送Service Reject(#3GPP cause)

2.4 多SMF协调机制

当一个UE有多个PDU Session(可能分别由不同SMF管理)时,AMF需要并行协调多个SMF:

flowchart TB
    subgraph AMF["AMF - 多SMF协调器"]
        A1[收到Service Request<br/>UL Data Status: PS1, PS3]
        A2[查询SMF上下文表<br/>PS1→SMF-A, PS3→SMF-B]
        A3[并行发送UpdateSMContext]
        A4{等待所有SMF响应}
        A5[聚合N2 SM Info]
        A6[组装N2 Request]
    end

    subgraph SMF_A["SMF-A (管理PS1)"]
        B1[UpdateSMContext Request]
        B2[N4 Session Mod with UPF]
        B3[返回N2 SM Info for PS1]
    end

    subgraph SMF_B["SMF-B (管理PS3)"]
        C1[UpdateSMContext Request]
        C2[N4 Session Mod with UPF]
        C3[返回N2 SM Info for PS3]
    end

    A1 --> A2 --> A3
    A3 --> B1 & C1
    B1 --> B2 --> B3
    C1 --> C2 --> C3
    B3 & C3 --> A4
    A4 -->|所有响应到达| A5 --> A6

    style AMF fill:#e1f5fe
    style SMF_A fill:#f3e5f5
    style SMF_B fill:#fff3e0

关键约束:AMF在向RAN发送N2 Request之前,必须等待所有被激活的PDU Session对应的SMF响应。如果某个SMF拒绝激活(如SMF发现PDU Session已释放),AMF在Service Accept中通过PDU Session Status IE告知UE哪些Session激活失败。

三、网络触发Service Request完整信令流(TS 23.502 Section 4.2.3.2)

3.1 触发条件与数据通知机制

网络触发场景的起点是下行数据到达UPF,但UE处于CM-IDLE无N3隧道。此时UPF执行数据缓存并发送Data Notification通知SMF。

sequenceDiagram
    participant AF/DN
    participant UPF as UPF(PSA)
    participant SMF
    participant AMF
    participant RAN as (R)AN
    participant UE

    Note over AF/DN,UPF: 阶段一:下行数据触发
    AF/DN->>UPF: Downlink Data Packet
    Note over UPF: N3隧道不存在(UE在CM-IDLE)<br/>缓存DL Data<br/>启动Data Notification Timer
    UPF->>SMF: N4 Session Report Request<br/>(Report Type=DL Data Report<br/>PDU Session ID, DL Data Packets数量)

    Note over SMF: 校验UE状态=CM-IDLE<br/>检查PDU Session是否激活
    SMF->>UPF: N4 Session Report Response<br/>(指示UPF继续缓存)

    Note over SMF,AMF: 阶段二:Paging触发
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(SMF寻呼优先级PPI<br/>DNN, S-NSSAI, UE标识)

    Note over AMF,RAN: 阶段三:Paging下发
    AMF->>AMF: 确定Paging Area<br/>(UE的Registration Area列表)
    AMF->>RAN: NGAP Paging Request<br/>(5G-S-TMSI, TAI List,<br/>Paging Priority, DRX Cycle)
    RAN->>UE: Radio Interface Paging<br/>(P-RNTI触发Paging DCI)

    Note over UE,AMF: 阶段四:UE响应(复用UE Triggered流程)
    UE->>RAN: RRC Connection Request
    RAN->>UE: RRC Setup
    UE->>RAN: RRC Setup Complete<br/>(NAS Service Request<br/>Service Type=移动终端数据)
    RAN->>AMF: N2 Uplink NAS Transport<br/>(NAS Service Request)

    Note over AMF,UPF: 阶段五:用户面建立(同4.2.3.1 Step 6-14)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
    SMF->>UPF: N4 Session Modification
    SMF->>AMF: N1N2Message Transfer(N2 SM Info)
    AMF->>RAN: N2 Request
    RAN->>UE: RRC Reconfig + NAS Service Accept
    RAN->>AMF: N2 Response(AN Tunnel Info)
    AMF->>SMF: UpdateSMContext(AN Tunnel Info)
    SMF->>UPF: N4 Session Modification(DL Tunnel)

    Note over UPF,UE: 缓存数据转发
    UPF->>RAN: N3 Downlink Data(缓存数据)
    RAN->>UE: Downlink Data

3.2 Paging优先级映射

SMF在触发Paging时可以携带Paging Policy Indicator(PPI),影响RAN的Paging优先级调度:

PPI值 含义 Paging Priority (NGAP) 典型场景
不携带 默认优先级 不设置Priority 普通数据业务
1 低优先级 不设置Priority 后台同步、软件更新
2 正常优先级 不设置Priority 普通IMS语音
3 高优先级 prioprity-1或priority-2 紧急呼叫、MPS服务
4 最高优先级 priority-1 紧急呼叫

四、RRC-Inactive态的Service Request(TS 23.502 Section 4.2.3.3)

4.1 三态关系与唤醒路径

flowchart LR
    subgraph UE状态空间
        A[CM-IDLE<br/>RRC-IDLE] -->|Service Request| B[CM-CONNECTED<br/>RRC-CONNECTED]
        C[CM-CONNECTED<br/>RRC-INACTIVE] -->|RRC Resume| B
        C -->|RAN Paging| C
        A -->|Network Triggered<br/>Paging + Service Request| B
    end

    subgraph 核心网感知
        D[AMF: UE=CM-IDLE<br/>无N2连接]
        E[AMF: UE=CM-CONNECTED<br/>有N2连接但无N3隧道]
        F[AMF: UE=CM-CONNECTED<br/>有N2+N3隧道]
    end

    A --- D
    C --- E
    B --- F

    style A fill:#ffcdd2
    style C fill:#fff9c4
    style B fill:#c8e6c9

当UE处于CM-CONNECTED + RRC-INACTIVE时: - 核心网视角:AMF认为UE仍在CM-CONNECTED,N2连接仍然保持 - 无线侧视角:gNB挂起了UE的RRC连接,UE监听RAN Paging - 用户面状态:N3隧道可能已被释放或保持

此场景下,UE通过RRC Resume而非完整的Service Request恢复连接。RAN在RAN Paging收到UE响应后,直接恢复DRB并可能触发N2 Path Switch,无需AMF重新建立N2连接。

4.2 三种场景对比

对比维度 CM-IDLE→CONNECTED CM-CONNECTED(RRC-INACTIVE) CM-CONNECTED(Active)
NAS消息 Service Request 无NAS消息(仅RRC Resume) 无需
AMF参与 全流程参与 可能不参与(仅RAN Paging) 不参与
N2接口 需建立 已存在(可能触发Path Switch) 已存在
N3隧道 需建立 可能需重建 已存在
延迟 50-100ms 10-30ms 0ms
UE功耗 高(需完整RRC建立) 中(RRC Resume) 高(持续连接)

五、N4会话修改的双阶段设计

Service Request中SMF与UPF之间的N4交互采用"两阶段提交"模式,这是协议设计的一个精妙之处:

5.1 阶段一:准备UL隧道(Step 8)

SMF在收到AMF的UpdateSMContext后,首先向UPF发送N4 Session Modification,目的是准备上行转发规则:

N4 Session Modification Request (Stage 1):
├── Create FAR (Forwarding Action Rule)
│   ├── FAR ID
│   ├── Apply Action = FORK (转发)
│   └── Forwarding Parameters
│       ├── Network Instance = "access" (上行方向)
│       └── Destination Interface = "Access" (→RAN)
├── Create URR (Usage Reporting Rule) - 可选
│   ├── URR ID
│   └── Measurement Method = Volume/Duration
└── Update PDR (Packet Detection Rule)
    ├── PDR ID
    ├── Precedence
    ├── PDUI (Source Interface = Access)
    └── FAR ID → 指向上面的FAR

此时UPF只知道上行方向的转发规则(来自RAN的数据转发到DN),但还不知道AN侧的隧道端点,因为RAN还没有分配TEID。

5.2 阶段二:完成DL隧道(Step 14)

SMF收到RAN的AN Tunnel Info后,发起第二次N4 Session Modification:

N4 Session Modification Request (Stage 2):
├── Update FAR
│   ├── FAR ID (复用Stage 1的FAR)
│   └── Update Forwarding Parameters
│       ├── Destination Interface = "Access" (下行方向)
│       ├── Network Instance = "access"
│       └── Outer Header Creation
│           ├── gNB IP Address (from AN Tunnel Info)
│           ├── gNB TEID (from AN Tunnel Info)
│           └── Port Number
└── Create BAR (Buffering Action Rule) - 删除
    └── 指示UPF停止缓存, 开始转发DL数据

为什么需要两阶段? 因为N3隧道是双向的,AN侧端点(gNB TEID)只有在RAN完成DRB建立后才能获得,而UPF侧端点在PDU Session建立时已经分配。两阶段设计确保了: - UPF可以提前准备好检测和转发规则 - RAN建立DRB后立即获得UPF的隧道端点,无需等待 - 缓存数据在DL隧道完成后立即转发,减少端到端延迟

六、Service Request中的QoS Flow处理

6.1 QoS Flow映射与DRB建立

Service Request激活用户面时,SMF通过N2 SM Information将PDU Session的QoS Flow信息传递给RAN:

QoS Flow Setup Request List:
├── QoS Flow #1 (QFI=1, 5QI=9)
│   └── Non-GBR, Default QoS Flow (Internet数据)
├── QoS Flow #2 (QFI=2, 5QI=1)
│   └── Non-GBR, IMS Conversational Voice
└── QoS Flow #3 (QFI=3, 5QI=4)
    └── Non-GBR, IMS Video

RAN根据5QI值决定DRB映射策略:

5QI QoS特性 典型DRB映射策略
1 会话语音(100ms, 10^-3) 专用DRB或与QCI=2共享
2 会话视频(150ms, 10^-3) 专用DRB
4 非会话视频(300ms, 10^-6) 与Default共享DRB
5 IMS信令(100ms, 10^-6) 专用DRB(SIP信令保障)
9 默认业务(300ms, 10^-6) 默认DRB

6.2 反射QoS(Reflective QoS)在Service Request中的作用

Service Request恢复用户面后,UPF可能在下行数据包的GTP-U头中设置RQI(Reflective QoS Indicator),触发UE自动学习上行QoS Flow映射。这意味着UE不需要额外的NAS信令就知道上行数据应映射到哪个QFI。

七、异常场景与故障处理

7.1 常见失败场景

场景 失败原因 标准行为 Wireshark识别特征
Service Reject AMF验证失败/拥塞 TS 24.501 Section 8.49 NAS Downlink: Service Reject (0x7D)
PDU Session激活失败 SMF发现Session已释放 Service Accept中PDU Session Status指示 N1N2 Transfer中无该Session的N2 SM Info
N4 Session Mod失败 UPF资源不足 SMF向AMF返回失败原因 PFCP Session Mod Response中Cause≠Success
N2 Request超时 RAN资源不足 AMF重试或通知SMF释放Session 无N2 Response, AMF启动Guard Timer
隐式去注册 UE长时间无响应 AMF执行Implicit Deregistration 后续AMF发送Deregistration Request

7.2 Service Reject原因值(TS 24.501 Section 9.11.3.2)

5GMM Cause值 含义 UE行为
#3 非法UE 重新触发Registration
#6 非法ME 重新触发Registration
#7 不允许的5GS服务 进入5GMM-DEREGISTERED
#9 UE身份不能被网络派生 重新触发Registration with SUCI
#10 隐式去注册 重新触发Registration
#11 PLMN不允许 选择其他PLMN
#15 无合适Cell 重新小区选择
#22 拥塞 等待Backoff Timer后重试

7.3 排错流程图

flowchart TD
    A[Service Request失败] --> B{抓包看到什么?}
    B -->|NAS Service Reject| C{Cause值?}
    B -->|无NAS响应| D{N2消息是否到达AMF?}
    B -->|PDU Session未激活| E{N4 Session Mod是否成功?}

    C -->|#3/#6/#9| F[UE标识问题<br/>检查S-TMSI/SUPI映射]
    C -->|#7| G[订阅问题<br/>检查UDM签约数据]
    C -->|#22| H[拥塞<br/>检查AMF/SMF负载]

    D -->|N2未到达| I[RAN问题<br/>检查NGAP连接/RRC建立]
    D -->|N2到达但AMF无响应| J[AMF处理异常<br/>检查UE Context是否丢失]

    E -->|N4成功| K[RAN资源问题<br/>检查DRB建立日志]
    E -->|N4失败| L[UPF问题<br/>检查UPF Session状态/资源]

    style A fill:#ffcdd2
    style F fill:#e1f5fe
    style G fill:#e1f5fe
    style H fill:#e1f5fe
    style I fill:#e1f5fe
    style J fill:#e1f5fe
    style K fill:#e1f5fe
    style L fill:#e1f5fe

九、抓包实战指南

9.1 关键过滤器

# Wireshark过滤NAS Service Request
nas-5gs.message_type == 0x4c

# 过滤Nsmf_PDUSession_UpdateSMContext (Service Request触发)
http2.headers contains "nsmf-pdusession/v1/sm-contexts" && http2.headers contains "modify"

# 过滤N4 Session Modification (Service Request相关)
pfcp.msg_type == 53  # PFCP Session Modification Request

# 过滤NGAP Initial Context Setup (Service Request场景)
ngap.procedureCode == 30  # InitialContextSetup

# 过滤NGAP PDU Session Resource Setup
ngap.procedureCode == 39  # PDUSessionResourceSetup

# 过滤Paging (Network Triggered)
ngap.procedureCode == 23  # Paging

9.2 关键时序指标

KPI 正常范围 关注阈值 说明
UE→AMF Service Request时延 < 10ms > 50ms RRC建立 + N2转发
AMF→SMF UpdateSMContext时延 < 5ms > 20ms SBI调用,与SMF负载相关
SMF→UPF N4 Session Mod(Stage 1) < 5ms > 15ms PFCP交互
SMF→AMF N1N2 Transfer时延 < 5ms > 20ms 含SMF内部处理
AMF→RAN N2 Request时延 < 5ms > 15ms AMF聚合多个SMF响应的等待时间
RAN DRB建立时延 < 20ms > 50ms RRC Reconfig + UE响应
端到端Service Request总时延 50-100ms > 200ms 从NAS Service Request到Service Accept

9.3 Network Triggered特有抓包要点

Network Triggered Service Request的抓包起点与UE Triggered不同,关键识别标志:

  1. UPF→SMF Data Notification:N4 Session Report Request中Report Type包含DL Data Report
  2. SMF→AMF触发Paging:Namf_Communication_N1N2MessageTransfer中无N1 SM容器
  3. AMF→RAN Paging:NGAP Paging消息中包含5G-S-TMSI
  4. UE响应Service Type=2:NAS Service Request中Service Type=Mobile Terminated(值为2)

十、与4G Service Request的对比

对比维度 4G EPS (TS 23.401) 5GS (TS 23.502)
NAS消息 Extended Service Request Service Request (5GMM)
安全保护 安全模式不同(NAS Security算法不同) 5G-AKA/EAP-AKA', 更强的完整性保护
会话管理 承载(Bearer)粒度激活 PDU Session粒度激活(内含多QoS Flow)
核心网接口 S11(MME-SGW), S5/S8(SGW-PGW) N4(SMF-UPF), SBI(Nsmf/Namf)
多会话协调 MME联系多个PGW(较少见) AMF并行联系多个SMF(常见)
RRC-Inactive 不支持 支持, 降低时延和信令开销
网络触发数据缓存 SGW缓存 UPF缓存 + Data Notification
编码格式 ASN.1(NAS/GTP) ASN.1(NAS/NGAP) + JSON(SBI) + TLV(PFCP)

常见问题

Q1: Service Request和Registration的区别是什么?什么时候用哪个?

A: Registration是UE向网络声明"我来了",建立MM上下文(身份验证、安全上下文、位置更新)。Service Request是在已注册的前提下"叫醒"用户面。如果UE已经注册且有PDU Session但处于CM-IDLE,发Service Request;如果UE从未注册或注册过期,必须先Registration。一个关键判断:AMF收到Service Request但发现UE没有有效的MM Context时,会返回Service Reject(#10 Implicitly Deregistered),触发UE重新Registration。

Q2: UE在Service Request中如何告诉网络"我要激活哪些PDU Session"?

A: UE通过NAS Service Request中的Uplink Data Status IE指示哪些PDU Session有上行数据待发送。AMF收到后,仅对这些PDU Session对应的SMF发送UpdateSMContext请求。如果UE不携带此IE,AMF可能根据本地策略决定激活所有PDU Session或仅建立信令连接(取决于Service Type)。标准建议UE尽量携带此IE以减少不必要的Session激活。

Q3: Network Triggered场景中UPF缓存的数据量有限制吗?超过限制怎么办?

A: TS 23.502没有规定UPF缓存上限,但实际部署中各厂商都有配置限制(通常2-20MB/PDU Session)。当缓存超出限制时,UPF会丢弃最早的数据包(Tail Drop)并可能发送ICMP Source Quench。对于时延敏感业务(如VoNR),SMF可以通过PPI=3/4提高Paging优先级,确保缓存数据尽快转发。

Q4: Service Request能否同时激活3GPP和非3GPP接入的PDU Session?

A: 不能直接实现。TS 23.502 Section 4.2.3规定Service Request是per access type的——UE在3GPP接入上发送的Service Request只能激活3GPP接入的PDU Session。如果非3GPP接入的PDU Session也需要激活,UE需要在非3GPP接入上单独发起Service Request。但同一个PDU Session(如ATSSS场景下的Multi-Access PDU Session)可以同时在两个接入上激活。

Q5: 为什么Service Request不做NAS加密而只做完整性保护?

A: 这是一个精妙的协议设计折衷。Service Request的核心信息(S-TMSI、Service Type、Uplink Data Status)必须被AMF明文读取才能确定UE身份和安全上下文。如果加密,AMF需要先解密才能知道用哪个安全上下文解密——形成逻辑死循环。解决方案是仅做完整性保护(MAC-I),确保消息未被篡改,同时将敏感信息(如PDU Session Establishment Request)放入NAS Message Container IE中,由后续的Security Mode Command流程加密传输。

参考来源

  1. 3GPP TS 23.502 V18.10.0 — Section 4.2.3 Service Request Procedures
  2. 3GPP TS 24.501 — Section 8.48 Service Request NAS Message Format
  3. 3GPP TS 38.413 — NGAP Initial Context Setup / PDU Session Resource Setup
  4. 3GPP TS 29.244 — N4 Session Management (PFCP) Procedures
  5. ShareTechnote 5G Service Setup — 5G Service Request Procedure Overview
  6. iTecSpec TS 23.502 Section 4.2.3 — Service Request Section Index
  7. Cisco UCC 5G SMF Configuration Guide — Service Request Procedure Implementation
  8. free5GC Paging in 5G Network — Network Triggered Service Request and Paging

本文由「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学通信知识星球海报-扫码加入