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 |
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
| 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 (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)
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)
当一个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激活失败。
网络触发场景的起点是下行数据到达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
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 | 紧急呼叫 |
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连接。
| 对比维度 | 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) | 高(持续连接) |
Service Request中SMF与UPF之间的N4交互采用"两阶段提交"模式,这是协议设计的一个精妙之处:
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。
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激活用户面时,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 |
Service Request恢复用户面后,UPF可能在下行数据包的GTP-U头中设置RQI(Reflective QoS Indicator),触发UE自动学习上行QoS Flow映射。这意味着UE不需要额外的NAS信令就知道上行数据应映射到哪个QFI。
| 场景 | 失败原因 | 标准行为 | 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 |
| 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后重试 |
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
# 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
| 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 |
Network Triggered Service Request的抓包起点与UE Triggered不同,关键识别标志:
| 对比维度 | 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流程加密传输。
本文由「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 等场景全覆盖。
