PDU会话建立(TS 23.502 Section 4.3.2.2.1)之后并非一成不变。随着业务流量的产生、应用层QoS需求的变化、运营商策略的更新,会话内部的QoS Flow需要被新增、修改或删除——这就是PDU会话修改(PDU Session Modification)流程要解决的核心问题。本文聚焦 TS 23.502 Section 4.3.2.2(UE发起)与 Section 4.3.2.3(网络发起),逐条消息拆解信令流,剖析N1 SM容器内的QoS规则与QoS Flow描述、N2 SM信息、N4 PFCP联动,以及与PCF的SM Policy Association交互,并给出抓包识别与排错思路。
5G的QoS架构以QoS Flow为粒度(TS 23.501 Section 5.7.1),一个PDU会话内部可以承载多条QoS Flow:
当用户从网页浏览切换到视频通话,SMF就需要新增一条GBR QoS Flow;当通话结束,这条Flow又要被删除。PDU会话修改流程就是QoS Flow生命周期管理的载体,它在不释放整个PDU会话的前提下,完成会话内部QoS参数的精细化调整。
修改流程还可用于非QoS场景:调整Session-AMBR、激活/去激活反射QoS(Reflective QoS)、修改QoS规则映射、变更RQA(Reflective QoS Attribute)等。
PDU会话修改有且仅有两条触发路径,理解触发源是掌握整个流程的钥匙。
flowchart LR
subgraph 触发源
UE[UE/应用层]
PCF[PCF 策略变更]
SMF[SMF 内部事件]
AN[AN/AMF 事件]
end
UE -->|1. PDU SESSION MODIFICATION REQUEST| SMF1[SMF<br/>UE-initiated 4.3.2.2]
PCF -->|SMPolicyUpdateNotification| SMF2[SMF<br/>Network-initiated 4.3.2.3]
SMF -->|如UPF变更| SMF2
AN -->|如AN释放| SMF2
SMF1 --> CORE[统一执行核心<br/>SM Policy联动 + N4修改 + N1N2下发]
SMF2 --> CORE
CORE --> RAN[(R)AN RRC重配]
CORE --> UEACK[UE N1应答]
关键设计意图:无论触发源是谁,最终都要经过SMF这个"会话仲裁者"。SMF根据PCF的PCC决策(动态PCC场景)或自身策略,决定哪些QoS Flow被授权修改,再把决策通过N1(给UE)和N2(给RAN)下发,通过N4(给UPF)执行。这种"决策-授权-执行-应答"的闭环是5G PCC架构的灵魂。
这是最常见的场景:应用层(如IMS客户端、视频APP)向UE NAS层请求QoS变更,UE主动发起。
sequenceDiagram
autonumber
participant UE
participant AN as (R)AN/gNB
participant AMF
participant SMF
participant PCF
participant UPF
Note over UE: 应用层请求新增/修改/删除QoS Flow
UE->>AN: UL NAS TRANSPORT<br/>(N1: PDU SESSION MODIFICATION REQUEST)<br/>含QoS Flow description(Add/Modify/Delete)
AN->>AMF: N2消息透传N1 SM容器
AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request<br/>(PDU Session ID, N1 SM container, ReqType=modify)
Note over SMF: 本地决策/校验QoS请求
opt 动态PCC
SMF->>PCF: Npcf_SMPolicyControl_Update Request<br/>(SM Policy Modification)
PCF-->>SMF: 授权PCC规则/策略决策
end
SMF->>UPF: N4 Session Modification Request<br/>(PFCP: 增删改 PDR/QER/FAR/URR)
UPF-->>SMF: N4 Session Modification Response
SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response<br/>(N1: PDU SESSION MODIFICATION COMMAND,<br/> N2 SM info: PDU Session Resource Modify)
AMF->>AN: PDU SESSION RESOURCE MODIFY REQUEST<br/>(含N2 SM info)
AN->>UE: RRC Reconfiguration<br/>(DRB建立/修改/释放) + 转发N1
UE->>AN: RRC Reconfiguration Complete
Note over UE: UE应用QoS规则,处理QoS Flow
AN-->>AMF: PDU SESSION RESOURCE MODIFY RESPONSE
AMF->>SMF: Nsmf_PDUSession_UpdateSMContext(N2 ack)
UE->>AN: UL NAS TRANSPORT<br/>(N1: PDU SESSION MODIFICATION COMPLETE)
AN->>AMF: 透传
AMF->>SMF: UpdateSMContext(Complete)
opt 动态PCC
SMF->>PCF: Npcf_SMPolicyControl_Update Notify(结果)
end
消息1 — PDU SESSION MODIFICATION REQUEST(TS 24.501 Section 6.4.2):UE在N1 SM容器中携带的核心IE是 QoS flow descriptions。每个QoS Flow description包含:
Create new QoS flow description(1) / Delete existing(2) / Modify existing(3);UE不能凭空造一个Flow——它必须基于应用层(如Rx等效的UE本地路由选择规则、或ATSSS/URSP)发出的请求。SMF收到后不会无条件接受,而是对照PCF授权或本地配置裁剪请求。
消息3 — Nsmf_PDUSession_UpdateSMContext Request(TS 29.502 Section 6.1.3.7):AMF把N1容器原样上送,关键字段 Update SM Context Request 携带 N1 SM container、PDU Session ID、Request type、User Location Information(TAI/NCGI)。SMF由此识别"这是一次修改请求"。
消息4-5 — SM Policy Modification(TS 29.512 Section 4.2.3):SMF调用 Npcf_SMPolicyControl_Update(Npcf服务,HTTP PUT/POST到 /sm-policies/{smPolicyId}/update)。PCF根据业务事件(AF通过N5/Nnef触发)或自身状态,返回授权的 PCC rule(带QoS数据、计费键、门控状态 Gate Status Open/Close)。SMF据此绑定 PCC rule → QoS Flow → QoS rule 三元关系。
消息6-7 — N4 Session Modification(TS 29.244 PFCP):SMF向UPF下发PFCP会话修改,核心是 QER(QoS Enforcement Rule) 的增删改——QER里承载QFI、Gate Status、MBR、MFBR、GFBR等,UPF据此对每个报文执行QoS标记(在GTP-U扩展头里填QFI)和限速。同时更新 PDR(Packet Detection Rule) 的检测过滤规则和 FAR(Forwarding Action Rule) 的转发动作。
消息8 — PDU SESSION MODIFICATION COMMAND(TS 24.501 Section 6.4.3):SMF把授权结果封装为N1 SM容器下发给UE,内含 QoS rules(带操作类型add/modify/delete)和 QoS flow descriptions。UE收到后应用新的QoS规则——这正是UE侧QoS规则与网络侧PCC规则对齐的关键时刻。
消息9-10 — N2 SM信息与RRC重配:N2 SM信息是 PDU Session Resource Modify List,gNB据此进行DRB(Data Radio Bearer)的建立、修改或释放。新增GBR Flow通常需要新建专用DRB(如承载VoNR的DRB2),并触发 RRC Reconfiguration 中的 RadioBearerConfig。
消息12-13 — COMPLETE应答:UE执行完成后回 PDU SESSION MODIFICATION COMPLETE,SMF收到后才认为修改真正落地,并向PCF回报结果。
网络发起场景下,触发源在网内,UE是被动的接收方。典型触发包括:PCF因AF请求(如IMS P-CSCF请求建立专用语音承载)下发新PCC规则、SMF检测到QoS Flow需要删除(如计费时长到期)、AN/AMF发起的资源调整。
sequenceDiagram
autonumber
participant AF as AF/IMS
participant PCF
participant SMF
participant UPF
participant AMF
participant AN as (R)AN
participant UE
AF->>PCF: N5/Nnef: Application Session<br/>请求GBR QoS(如VoNR 5QI=5)
Note over PCF: 评估授权,生成PCC规则
PCF->>SMF: SMPolicyUpdateNotification<br/>(Policy Decision,新PCC rule,QoS变更)
SMF-->>PCF: 响应
SMF->>UPF: N4 Session Modification Request
UPF-->>SMF: N4 Response
SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(N1: PDU SESSION MODIFICATION COMMAND,<br/> N2 SM: PDU Session Resource Modify)
Note over AMF: UE在CM-CONNECTED?<br/>否→需先寻呼/Service Request
AMF->>AN: PDU SESSION RESOURCE MODIFY REQUEST
AN->>UE: RRC Reconfiguration + 转发N1
UE->>AN: RRC Reconfiguration Complete
UE->>AN: UL NAS TRANSPORT(MODIFICATION COMPLETE)
AN->>AMF: MODIFY RESPONSE + 转发COMPLETE
AMF->>SMF: UpdateSMContext(N2 ack + N1 COMPLETE)
opt
SMF->>PCF: Npcf_SMPolicyControl_Update(执行结果)
end
差异一:消息1由PCF主动推送。PCF通过 Namf 不直接联系,而是用 Npcf 的 SMPolicyUpdateNotification(TS 29.512 Section 4.2.3.2)回调SMF的订阅端点。SMF收到后是"被告知要改",而非"自己想改"。
差异二:UE状态前置检查。SMF通过 Namf_Communication_N1N2MessageTransfer(TS 29.518 Section 5.2.2.4)下发N1N2消息时,若UE处于 CM-IDLE,AMF会返回"UE不可达",触发寻呼与Service Request(TS 23.502 Section 4.2.3),等UE进入CM-CONNECTED后再补发N1N2。这是网络发起流程中故障率较高的环节之一。
N1N2MessageTransfer 的关键参数:n1MessageContainer、n2InfoContainer(含 smInfo 的 PduSessionId、N2SmInfoType=PDU SESSION RESOURCE MODIFY)、以及 UE Reachability 提示(让AMF订阅UE可达通知)。
修改流程的本质是QoS Flow的生命周期管理。下图展示了从PCC规则到UE QoS规则、再到RAN DRB的映射结构。
flowchart TB
subgraph PCF域
PCC[PCC Rule<br/>Rule ID, QoS Data,<br/>Gate, Charging Key]
end
subgraph SMF域
QF[QoS Flow<br/>QFI绑定<br/>5QI/ARP/GFBR/MFBR]
QR[QoS Rule<br/>Rule ID→QFI<br/>Packet Filter Set]
end
subgraph UPF域
QER1[QER QoS Enforcement<br/>QFI,Gate,MBR]
PDR1[PDR Packet Detection<br/>SDF Filter→QFI]
end
subgraph RAN域
DRB[DRB<br/>QoS Flow→DRB映射<br/>RLC/MAC配置]
end
subgraph UE域
UQR[UE QoS Rule<br/>包过滤→QoS Flow]
end
PCC -->|授权| QF
QF -->|绑定| QR
QF -->|标记报文QFI| QER1
QF -->|检测| PDR1
QR -->|N1下发| UQR
QF -->|N2 SM Info| DRB
UQR -->|上行包分类| QF
DRB -->|无线承载| UQR
设计意图:5G采用"控制面与用户面解耦+QoS Flow与DRB解耦"的设计。QoS Flow是CN粒度的QoS标识,DRB是AN粒度的无线承载。一个PDU会话可有多条QoS Flow,但DRB数量受限(最多约29个DRB),因此gNB会做 QoS Flow到DRB的多对一映射——多条Non-GBR Flow可复用一个DRB,GBR Flow通常独占DRB以保证时延。这也是为什么修改流程中新增GBR Flow必然伴随RRC重配中的DRB建立。
| 信元(IE) | 所在消息/容器 | 取值/含义 | 协议出处 |
|---|---|---|---|
| QFI | N1 QoS Flow description / N4 QER | 6bit,QoS Flow标识(0-63),0保留 | TS 24.501 9.11.4.12 |
| Operation code | N1 QoS Flow description | 1=新建,2=删除,3=修改 | TS 24.501 9.11.4.14 |
| 5QI | QoS参数 | 标准化值如5(语音),9(默认),72(视频) | TS 23.501 5.7.4 |
| ARP | QoS参数 | Priority/Capability/Vulnerability,决定抢占 | TS 23.501 5.7.2.2 |
| GFBR/MFBR | GBR QoS Flow | 保证/最大比特率,GBR Flow必带 | TS 23.501 5.7.3 |
| QoS Rule operation | N1 QoS rules | ADD/MODIFY/REMOVE/ADD_MODIFY | TS 24.501 9.11.4.11 |
| N2SmInfoType | N2 SM信息 | PDU SESSION RESOURCE SETUP/MODIFY/RELEASE | TS 38.413 9.3.1 |
| Reflective QoS Ind(RQI) | N4 QER / GTP-U扩展头 | 1=触发UE反射QoS规则建立 | TS 23.501 5.7.5 |
| Gate Status | N4 QER | OPEN/CLOSED,控制用户面开关 | TS 29.244 7.5.2 |
修改流程涉及5GSM子状态机(TS 24.501 Section 5.1.3.3.2)。理解状态转换对排错至关重要。
stateDiagram-v2
[*] --> INACTIVE
INACTIVE --> ACTIVE: PDU Session Establishment
ACTIVE --> ACTIVE: PDU Session Modification (成功)
ACTIVE --> MODIFY_PENDING: PDU SESSION MODIFICATION COMMAND下发<br/>等待UE COMPLETE
MODIFY_PENDING --> ACTIVE: 收到MODIFICATION COMPLETE/REJECT
ACTIVE --> INACTIVE: 4.3.2.4 会话去激活
INACTIVE --> ACTIVE: 4.3.2.2b Service Request重建用户面
当SMF下发 PDU SESSION MODIFICATION COMMAND 后,UE进入 PDU SESSION MODIFICATION PENDING 子状态(与PDU SESSION ACTIVE是父子关系)。此状态下若UE收到新的修改请求,会被拒绝或排队;若定时器T3583超时(修改命令无应答),SMF会发起重传或回退。COMMISSION REJECT(消息 PDU SESSION MODIFICATION COMMAND REJECT,原因值如 #43 Invalid QoS Flow description)会让Flow回滚到修改前状态。
在Wireshark/TShark中识别PDU会话修改流程,按接口分层过滤:
N1 NAS层(UE↔AMF):过滤 nas-5gs.protocol_discriminator == 0x2e 且 nas_5gs.message_type 在 {0xc1(MODIFICATION REQUEST), 0xc2(MODIFICATION COMMAND), 0xc3(MODIFICATION COMPLETE), 0xc4(MODIFICATION COMMAND REJECT)}。注意N1通常嵌在NGAP的 InitialUEMessage/UL/DL NAS Transport 或HTTP2(SBI)的 N1N2MessageTransfer 体内(需解码 base64 的 n1Message)。
N2 NGAP层(AMF↔gNB):过滤 ngap.procedureCode == 58(PDU Session Resource Modify)。关键字段 PDU Session Resource Modify List、PDU Session ID、n2SmInfoType。
N4 PFCP层(SMF↔UPF):过滤 pfcp.message_type_value == 52/53(Session Modification Request/Response)。看 Update QER、Update FAR、Create PDR 中的QFI变化。
SBI HTTP2层(SMF↔PCF/AMF):URL路径是强特征——/sm-policies/{id}/update(SMF→PCF)、/npcf-smpolicycontrol/v1/sm-policies/{id}/update、以及 Namf_Communication_N1N2MessageTransfer 的 POST /namf-comm/v1/ue-contexts/{supi}/n1-n2-messages。
快速定位技巧:先在HTTP2里找 N1N2MessageTransfer(一次修改几乎必经此消息),再回溯PCF的 PolicyUpdateNotification,最后追到UPF的PFCP变更,三条线即可串起完整链路。
故障1:修改命令下发后UE无COMPLETE应答 - 排查路径:检查T3583定时器、检查gNB是否收到NGAP MODIFY REQUEST、检查RRC Reconfiguration是否完成、检查N1 SM容器是否成功通过RRC透传。常见原因是UE应用层拒绝(如请求的5QI不支持)导致回REJECT但消息丢失。
故障2:网络发起流程卡死,UE一直不进入CM-CONNECTED
- 根因多在 N1N2MessageTransfer 返回"UE不可达"后,AMF订阅了 UE Reachability 但寻呼失败。检查 Paging 消息(NGAP procedureCode=8)是否正常下发、UE的 DRX Paging Cycle 是否配置过深导致漏呼。
故障3:UPF报文QFI未变更或QoS未生效 - 排查N4 Session Modification是否成功(看PFCP Response的cause)、QER的Gate Status是否OPEN、PDR的检测规则是否正确匹配业务流。若GTP-U扩展头里QFI还是旧值,说明UPF QER未生效或SMF下发了错误的QFI绑定。
故障4:UE发起的QoS请求被SMF拒绝
- 多为PCF未授权该PCC规则,或SMF本地配置不允许UE请求该5QI。检查 Npcf_SMPolicyControl_Update 的响应中是否含 reject 指示。
| 对比维度 | UE发起(4.3.2.2) | 网络发起(4.3.2.3) |
|---|---|---|
| 触发源 | UE应用层 | PCF/SMF/AMF/AN |
| 首条NAS消息 | MODIFICATION REQUEST(上行) | MODIFICATION COMMAND(下行) |
| PCF角色 | 校验/授权UE请求 | 主动推送PCC决策 |
| UE状态约束 | UE必然在CM-CONNECTED | 可能需先寻呼/Service Request |
| 典型场景 | 浏览器切视频、应用请求提速 | IMS建专用承载、计费变更、AN资源调整 |
| 失败影响 | 仅影响该次请求 | 可能导致业务降级(如VoNR起呼失败) |
| 信令交互量 | 较少(UE→SMF→PCF→UPF→RAN→UE) | 较多(含N1N2Transfer、可达性订阅) |
Q1:QoS Flow和DRB是什么关系?修改流程为什么有时只动DRB不动Flow? A:QoS Flow是核心网CN粒度的QoS标识,DRB是无线侧AN粒度的承载。一条PDU会话可有最多64条QoS Flow,但DRB有限。修改流程中,若仅调整Non-GBR Flow的限速(改QER/MBR),可能不动DRB(通过现有DRB传输+GTP-U扩展头QFI标识);但新增GBR Flow或调整映射关系时必须RRC重配DRB。
Q2:反射QoS(Reflective QoS)在修改流程中如何体现? A:当UPF的QER中RQI=1时,会在下行GTP-U扩展头置RQI位。UE检测到后自动建立反射QoS规则(TS 23.501 5.7.5),无需SMF显式下发。修改流程可激活或去激活这个机制——本质是改UPF的QER参数,再通过N4下发。
Q3:UE发起修改但被SMF拒绝,会话会断吗?
A:不会。SMF返回 PDU SESSION MODIFICATION COMMAND REJECT(带原因值),PDU会话保持原状,仅本次请求失败。但如果请求的是关键Flow(如IMS语音),用户体感上业务无法建立。
Q4:网络发起流程中UE处于CM-IDLE怎么办?
A:SMF的 N1N2MessageTransfer 返回"UE不可达",AMF订阅 UE Reachability Notification。AMF发起寻呼,UE响应后执行Service Request进入CM-CONNECTED,AMF再补发缓存的N1N2消息。整个过程对UE透明,但会增加时延。
Q5:修改流程和SSC模式3锚点重选是一回事吗? A:不是。修改流程(4.3.2.2/4.3.2.3)只调整会话内部的QoS Flow,PDU会话锚点UPF不变。SSC模式3锚点重选(4.3.2.2.1的会话重建)会改变UPF锚点,本质是释放旧会话+建立新会话。两者虽都涉及SMF,但语义完全不同。
本文由「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 等场景全覆盖。
