一个PDU会话可能已经正常运行了一段时间：UE已经获得IP地址，N3用户面路径处于激活状态，应用流量也按预期传输。随后业务条件发生变化，例如需要降低此前授权的数据速率、某个QoS Flow需要使用不同的5QI，或者网络决定将该会话的最高速率限制为10 Mbps。
在这种情况下，5GC无需拆除并重新建立整个PDU会话。现有会话可以继续保持激活，仅更新受影响的QoS规则、QoS Flow参数或用户面执行策略。这正是PDU Session Modification的作用。
PDU Session Modification与PDU Session Establishment的区别很直接。建立流程用于创建此前不存在的会话，而修改流程用于调整已经处于活动状态的会话。因此，关注点不再是SMF如何被选择或UPF如何首次建立，而是什么触发了变化、SMF如何获得新策略、UE和gNB需要更新哪些内容，以及新的QoS策略是否真正由UPF执行。
PDU会话修改的范围
PDU Session Modification有一个重要前提：目标PDU会话必须已经存在。UE、SMF、PCF以及相关RAN上下文均已与该会话建立关联，用户面通常也已正常工作。
修改流程的目的，是在会话保持激活的同时调整参数。QoS是最常见的场景之一。现有QoS Flow可能需要不同的5QI、MBR、MFBR或其他授权参数；策略变化也可能要求更新UPF中已经执行的速率控制。
QoS修改不能简单理解为只改变一个NAS字段。一次QoS更新可能同时影响系统的三个部分：
-
UE侧：UE需要接收新的QoS Rule或QoS Flow参数；
-
RAN侧：gNB可能需要修改对应的PDU Session Resource或QoS Flow资源；
-
UPF侧：如果用户面执行方式发生变化，则需要通过N4更新相关PFCP规则。
因此，PDU Session Modification更适合理解为对活动会话进行在线重配置。会话标识保持不变，修改直接作用于现有PDU Session ID及其关联的QoS Flow。
还需要注意一个重要边界。PDU Session Modification既可以更新现有QoS Flow，在适用的业务场景中也可以在同一个PDU会话内建立新的QoS Flow。例如，由应用驱动的VoNR通话策略可能要求增加一个具有特定QoS特征的Flow。不过这里重点讨论的是修改现有QoS Flow的参数，而不是创建新的Flow。
会话修改的主要触发因素
与PDU Session Establishment相比，一个显著区别是触发方并不只有UE。活动PDU会话可能因为UE请求、网络策略变化、订阅数据更新或无线条件变化而被重新配置。
常见触发源可以分为五类：
-
UE触发：UE发送PDU Session Modification Request，请求调整QoS或其他会话参数；
-
PCF触发：策略控制发生变化，例如达到用量阈值后网络降低授权速率，或者应用策略要求不同的QoS；
-
UDM触发：会话管理订阅数据发生变化，例如订户等级或订阅QoS配置被更新；
-
SMF触发：SMF根据本地策略、网络配置或当前会话状态决定重新配置会话；
-
RAN相关触发：gNB上报无线或资源条件，随后SMF判断需要修改会话参数。
这些触发最终都会汇聚到SMF，因为SMF持有PDU会话控制上下文，并负责把新的业务或策略要求转换为UE、RAN和UPF能够执行的参数。
排查PDU Session Modification时，第一步不应直接从PDU Session Modification Command开始向后查，而应先找到最早触发变化的控制事件。如果最先出现的是UE Modification Request，则属于UE发起；如果PCF通过Notification URI向SMF推送新策略，则属于策略驱动；如果最先出现UDM订阅数据更新，就应沿订阅变化路径继续分析。
UE发起的PDU会话修改
UE发起流程最容易理解为：某个应用需要不同的QoS。
假设UE当前使用PDU Session ID 5，其中一个QoS Flow仍采用原有配置。某个应用提出新的业务需求，于是UE通过发送PDU Session Modification Request请求不同的QoS参数。
NAS消息首先经gNB到达AMF，随后AMF向SMF更新现有SM Context。在基于服务的接口上，AMF使用：
POST /nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify
这与Create SM Context不同。SM Context已经存在，网络此时是在更新现有会话上下文。
UE请求中可能包含Requested QoS Rules、Requested QoS Flow Descriptions以及相关Packet Filters。SMF收到请求后，需要判断网络是否能够授权所请求的变化。如果该会话采用动态策略控制，SMF还会把业务请求发送给PCF进行授权。
例如，如果UE为某个Flow请求5QI 8，SMF可以调用PCF SM Policy Control服务来修改当前Policy Association。PCF评估用户策略、业务规则和当前网络条件，然后返回实际获准的QoS参数。
需要明确一点：UE请求的QoS不一定就是最终实际执行的QoS。UE表达业务需求，而最终参数仍需经过SMF和PCF授权。
授权参数确定后，SMF生成两类信息：
-
N1 SM：向UE携带新QoS相关参数的PDU Session Modification Command；
-
N2 SM：用于PDU Session Resource Modify流程的信息，指示gNB修改对应的QoS Flow资源。
AMF通过NGAP将N2信息发送给gNB，并把N1中携带的PDU Session Modification Command转发给UE。
gNB调整相关资源后返回PDU Session Resource Modify Response。UE接受新参数后，通过NAS发送PDU Session Modification Complete。
只有当SMF收到相关执行结果后，才能确认新的会话参数已经从策略授权真正落实到接入侧和UE侧。
PCF触发的网络侧QoS修改
网络侧修改遵循不同的逻辑。UE并未请求新的QoS，变化从策略控制层开始。
以用量阈值为例。用户已经有一个活动PDU会话并持续传输数据。PCF要求会话上报或监控用量信息，当累计用量达到配置阈值后，策略可以把会话或相关Flow的最高速率降低到10 Mbps。
随后，PCF通过建立SM Policy Association时注册的Notification URI通知SMF。通知中携带新的SM Policy Decision，例如更新后的MBR以及对应的Policy Control Trigger。
从SMF角度看，这不是创建新会话，而是修改一个仍然有效且处于活动状态的PDU会话。
如果新速率需要由UPF执行，SMF会通过N4发送PFCP Session Modification Request。例如可以把相关QER中的MBR更新为10 Mbps。只有UPF接受该修改后，新的速率限制才会真正作用于用户面。
不要混淆“Modification”一词在两个层面的含义：
-
PDU Session Modification：5GS中修改活动PDU会话的整体流程；
-
PFCP Session Modification：SMF通过N4更新UPF用户面规则的具体控制流程。
两者位于不同层次。一次PDU Session Modification可能包含PFCP Session Modification，但出现一条PFCP修改消息并不代表整个PDU会话修改已经结束。
UPF开始执行新的QER后，SMF可能仍需更新RAN和UE。N1/N2信息通过AMF传送，gNB接收PDU Session Resource Modify Request，UE接收PDU Session Modification Command。
当gNB完成无线资源更新且UE接受新的QoS参数后，两侧都会返回执行结果。随后SMF可将成功结果反馈给PCF，使策略系统能够确认该QoS决策已经真正执行，而不是仅作为策略决定被保存。
N1、N2与N4的协同修改
PDU Session Modification最容易令人混淆的一点，是同一次QoS变化可能同时在NAS、NGAP和PFCP三个层面产生修改流程。
将三条路径分开来看，逻辑会清晰得多。
N1更新UE会话参数
N1 SM在UE与SMF之间承载会话管理信息。网络决定修改会话后，SMF通过AMF向UE发送PDU Session Modification Command。
UE更新本地PDU会话参数，并通过PDU Session Modification Complete确认接受。
N2更新RAN资源
当与某个QoS Flow关联的无线资源需要变化时，SMF生成对应的N2 SM信息并通过AMF发送给gNB。gNB使用PDU Session Resource Modify流程调整相关QoS Flow资源，并返回执行结果，其中可包含成功修改的QFI。
N4更新UPF执行规则
如果变化影响用户面转发或QoS执行，SMF通过PFCP Session Modification更新相关UPF规则。
速率限制变化可能需要更新QER，其他策略变化也可能影响PDR、FAR或其他用户面规则。具体修改哪些规则取决于业务和控制策略；一次PDU Session Modification并不意味着必须重写所有PFCP规则。
因此，一次完整的QoS变化可以概括为：
策略 / UE请求
→ SMF重新计算会话参数
→ N4更新UPF执行规则
→ N2更新gNB资源
→ N1更新UE参数
→ 各侧确认执行结果
具体消息顺序可能因触发源和被修改的参数而变化。排障时，没有必要要求每个场景都必须出现完全相同的消息序列。更有效的判断方法是确认所有需要发生变化的执行点都确实收到了新参数并完成应用。
修改完成与信令排障
PDU Session Modification故障有一个区别于建立失败的特点：PDU会话可能仍保持活动，用户甚至仍能传输数据，但最终QoS与预期策略不一致。
例如，策略要求把速率降低到10 Mbps，PCF也已经下发新的策略决策，但实际吞吐测试仍显示远高于该值。PDU会话继续存在并不能证明修改成功，排查需要确定新参数在哪个环节停止了生效。
实际排障可以按以下检查点进行：
-
识别触发源：确定最先发生的是UE Modification Request、PCF Notification、UDM数据变化，还是SMF/RAN侧事件；
-
验证SMF决策：确认SMF是否接受请求，以及PCF是否返回预期的策略决策；
-
检查N4执行：如果UPF需要执行新的QoS，确认PFCP Session Modification是否成功，并检查相关QER参数是否确实发生变化；
-
检查N2执行：确认gNB是否收到PDU Session Resource Modify Request，并返回成功修改的QoS Flow；
-
检查N1确认：确认UE是否收到PDU Session Modification Command并返回PDU Session Modification Complete；
-
验证业务结果：确认实际流量现在是否按照更新后的速率、QoS或业务策略运行。
如果PCF已经授权10 Mbps，但UPF中的QER仍保留旧MBR，应重点检查SMF到N4的路径。如果UPF已经执行新速率，但gNB的QoS Flow仍使用旧参数，则需要继续检查N2 Resource Modify流程。如果网络侧已经完成所有必要修改，但UE始终没有返回Modification Complete，则应检查NAS侧是否接受了新的QoS规则。
一个消息名称也容易造成混淆。有些流程图使用“PDU Session Modification Command Ack”描述UE确认步骤，但在5GSM NAS信令中，UE接受PDU Session Modification Command后实际发送的消息是PDU Session Modification Complete。因此，抓包分析应以真实的NAS Message Type为准。
这种分层排障方式比重新从Registration Request开始分析更有效。PDU会话已经存在，问题在于活动会话没有按照新策略得到一致更新。因此，故障范围应继续聚焦当前SM Context、Policy、QoS Flow以及用户面执行过程。
常见问题
PDU Session Modification会重新分配UE的IP地址吗？
正常的QoS修改是在现有PDU会话及其QoS Flow上进行更新，而不是重新建立整个会话。其他会话属性是否变化取决于具体场景，但仅修改5QI或MBR等参数时，不应把它视为另一次PDU Session Establishment流程。
PDU Session Modification总是由UE发起吗？
不是。UE可以通过PDU Session Modification Request请求修改，但PCF策略变化、UDM订阅数据更新、SMF本地决策或RAN相关事件同样可以触发网络侧修改。通常由SMF协调UE、RAN和UPF之间所需的更新。
PDU Session Modification与PFCP Session Modification有什么区别？
PDU Session Modification是5GS中修改活动会话的整体流程，可能涉及UE、RAN、SMF、PCF和用户面。PFCP Session Modification则专指SMF与UPF之间通过N4进行的控制流程，用于修改UPF中的具体用户面规则。后者可以是前者的一部分，但两者并不等同。
如果QER已经更新，为什么gNB和UE仍需要修改？
QER负责UPF中的QoS执行，但QoS Flow并不只由UPF定义。UE可能需要新的QoS Rule或Flow描述，RAN也可能需要调整对应的无线资源。因此，一些QoS修改要求N1、N2和N4保持一致。只更新UPF并不意味着完整的PDU Session Modification流程已经完成。
PDU Session Modification可以增加新的QoS Flow吗？
可以。PDU Session Modification既能更新现有QoS Flow的参数，在适用场景中也可以在同一PDU会话内建立新的QoS Flow。例如，由应用驱动的VoNR业务可能需要增加一个具有特定5QI的QoS Flow。该场景的业务上下文与简单更新现有Flow不同，更适合单独分析。
