一個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不同，更適合另行分析。
