假设一个已经建立且一直正常承载业务流量的PDU会话。UE已分配IP地址，gNB维护对应的PDU会话资源和QoS流，UPF中也存在用于用户面转发的活动中的PFCP会话。如果用户决定断开数据连接、策略功能要求终止会话，或网络判定该会话不应继续保持，5GC此时所执行的就不再是修改少量QoS参数，而是需要同时拆除控制面与用户面中的相关会话状态。
这正是 PDU会话释放的作用。该过程规定如何移除已建立的PDU会话：清除UE侧5GSM上下文，释放RAN资源，删除UPF中的N4会话及转发状态，并在适用情况下终止关联的策略关系。最终目的是使AMF、SMF、gNB、UPF和UE达到一致状态，即该PDU会话已不复存在。
该流程与注册流程并非同一层面的操作。UE可以释放一个PDU会话而继续保持5GS注册状态，其他处于活动状态的PDU会话也可以继续运行。分析这类信令时，重点应放在跟踪 特定PDU会话ID所关联的资源如何从UE、RAN、SMF、UPF及策略控制层中被移除，而不是从Registration Request重新开始分析整段信令。
会话释放与建立、修改及去注册的边界
PDU会话建立、修改、释放以及5GS去注册可能出现在同一组信令跟踪中，但它们解决的是完全不同的问题。
| 流程 | 主要目的 | 最终状态 |
|---|---|---|
| PDU会话建立 | 创建新的数据会话及用户面资源 | 新的PDU会话进入活动状态 |
| PDU会话修改 | 修改QoS、策略或现有会话资源 | PDU会话继续保持活动状态 |
| PDU会话释放 | 终止指定PDU会话并释放其资源 | 该PDU会话不再存在 |
| 5GS去注册 | 终止UE与5GS之间的注册关系 | UE退出相应的5GS已注册状态 |
会话释放与去注册尤其容易混淆。假设UE同时维护一个用于互联网接入的PDU会话和另一个用于企业专网的PDU会话。释放其中一个不会自动删除另一个，也不一定会清除AMF中的UE注册上下文。
同样不能把RRC Release视为PDU会话释放。RRC Release主要改变UE与gNB之间的无线连接状态，此时核心网中的PDU会话仍可能保持活动。相比之下，PDU会话释放会移除与指定 PDU会话ID关联的会话资源。
有关会话最初如何建立，可参阅5GC核心网PDU会话建立流程。如果会话仍保持活动状态，只是QoS或策略参数发生变化，可参阅5GC核心网PDU会话修改流程。
PDU会话释放的主要触发条件
PDU会话释放可以从网络中的不同位置发起。活动会话可能因UE操作、策略控制决策、网络状态不一致或资源相关条件而被终止。
常见的触发情形包括：
UE触发： 当不再需要当前数据会话时，UE发送PDU Session Release Request；
PCF触发： 由于业务授权、使用条件或其他策略要求不再允许会话保持活动，策略控制要求终止会话；
AMF触发： AMF发现UE与网络中的PDU会话状态不一致，或关联的网络切片已不可用；
RAN触发： 例如，某PDU会话关联的所有QoS流均已释放，RAN向核心网报告相应状态；
SMF触发： SMF依据本地策略或从UDM、CHF等网元获得的信息，判定该会话应当终止。
由于初始触发可能来自不同网元，前几步信令并不总是相同。但流程最终都会由SMF协调，因为SMF维护PDU会话控制上下文，并负责协调UPF用户面、AMF/RAN接入资源以及PCF策略关系。
分析报文跟踪时，首先识别 最初由哪个实体请求释放 ，通常比直接从PDU Session Release Command开始更有价值。UE发送的Release Request表明流程由UE发起；PCF发出的终止通知表明释放由策略驱动；AMF请求释放SM Context则属于另一种网络触发分支。
UE发起释放时的N1、N2与N4信令
UE发起的释放流程能清晰展示不同层面上的会话资源如何被移除。
假设UE当前使用PDU会话ID 5接入数据业务。当设备不再需要该会话时，会生成 PDU Session Release Request ，并通过N1 SM Container发送。gNB使用UL NAS Transport将NAS消息转发给AMF，随后AMF确定负责该PDU会话ID的SMF。
在基于服务的接口上，AMF通过已有的SM Context转发释放请求，例如调用Nsmf_PDUSession_UpdateSMContext。这里并不是新建SM Context；上下文已经存在，AMF是在通知SMF该活动会话已进入释放流程。
随后SMF处理用户面清理。对于已有的N4会话，SMF向UPF发送 PFCP Session Deletion Request 。UPF移除相应PFCP会话关联的用户面状态，并返回PFCP Session Deletion Response。
这与PDU会话修改期间的PFCP Session Modification有本质区别。Modification是在已有N4会话中更新规则，而Deletion则从UPF中删除整个会话级状态。
开始清理用户面后，SMF为RAN和UE准备相关信息：
N2 SM： 指示gNB释放对应的PDU会话资源；
N1 SM： 向UE传递PDU Session Release Command。
AMF通过NGAP向gNB发送PDU Session Resource Release Command，该消息可以携带需要转发给UE的NAS PDU Session Release Command。gNB释放与该PDU会话相关的接入侧资源后，返回PDU Session Resource Release Response。
UE收到Release Command后，删除本地PDU会话上下文，并发送 PDU Session Release Complete 作为5GSM层面的确认。
典型的UE发起释放流程可概括为：
UE释放请求 → AMF → SMF → PFCP会话删除 → N2资源释放 → PDU会话释放命令 → UE释放完成
如果UE最初处于CM-IDLE状态，实际网络可能需要先执行Service Request，以恢复继续释放流程所需的信令连接。因此，不能预期所有报文跟踪都从相同的无线连接状态开始。
网络发起释放与PCF策略终止
在网络发起的释放过程中，UE不会先发送PDU Session Release Request。状态变化可能从策略控制层或其他核心网功能开始。
以PCF触发为例：PDU会话原本正常承载流量，但PCF随后依据策略决定终止该会话。PCF通过为现有策略关联建立的通知机制向SMF发送通知。
SMF收到策略驱动的释放触发后，仍须拆除用户面。因此，在SMF经AMF发送所需的N1和N2信息之前，信令跟踪中就可能出现PFCP Session Deletion Request及Response：
SMF → AMF → gNB / UE
AMF的N1N2 Message Transfer可以同时携带与PDU会话资源释放相关的N2信息，以及发往UE的PDU Session Release Command。
从UE角度看，无论初始释放由PCF、SMF还是其他网元触发，只要执行显式NAS释放流程，网络仍会发送 PDU Session Release Command，随后UE返回 PDU Session Release Complete。
但从核心网信令跟踪角度看，仅凭这两条NAS消息无法确定最初的触发源。重要证据出现在Release Command之前：可能是PCF策略终止、AMF请求释放SM Context、RAN相关事件或SMF本地决策。
这一区别对技术分析和故障排查都很重要： PDU Session Release Command表示网络正在指示UE终止会话，但该消息本身并不能说明最初由哪个实体触发释放。
UPF、RAN及策略上下文中的资源清理
不能仅因UE无法继续发送数据，就认定PDU会话释放已经完成。对于具体释放场景，该PDU会话关联的资源还必须在相关网元中得到清理。
N4删除UPF会话
PFCP Session Deletion是用户面清理的关键步骤。当UPF删除对应的N4会话后，该会话关联的PDR、FAR、QER、URR及其他适用转发状态不再作为已释放PDU会话的一部分发挥作用。
随着会话生命周期结束，与该PDU会话相关的N3资源及其他适用的用户面终止资源也会被释放。
N2释放gNB资源
gNB维护与PDU会话及其QoS流关联的接入侧资源。收到PDU Session Resource Release Command后，RAN删除相关资源，并通过对应的响应消息向核心网报告结果。
因此，PFCP Session Deletion成功本身不足以证明整个PDU会话释放已完成。如果UPF已完成清理，但gNB仍保留PDU会话资源，网络依然处于状态不一致的情况。
UE删除自身的5GSM会话上下文
UE收到PDU Session Release Command后清除本地会话上下文，并以PDU Session Release Complete确认。对于IP类型的PDU会话，关联的IP地址或前缀也进入释放流程。
SMF通知AMF并清理策略状态
当会话进入Released状态时，SMF可以向AMF发送SM Context Status Notification，使AMF同步其保存的会话状态。
如果该PDU会话具有SM Policy Association，相应PCF策略关系也须按适用分支终止或删除。如果它是最后一个需要特定DNN、S-NSSAI或订阅相关状态的会话，在符合条件时，SMF还可能进一步执行涉及UDM或UDR的订阅或注册状态清理。这些都是有条件的操作，并非每次释放都会发生。
因此，清理对象是围绕PDU会话ID建立的一组状态，而不只是单条隧道：
UE上下文 + RAN资源 + SM上下文 + UPF N4会话 + 策略关联
通过信令跟踪验证释放是否完成
从用户体验上不一定容易发现PDU会话释放失败。UE可能已停止传输数据，但一个或多个核心网网元中仍保留过期状态。另一些情况下，UE已删除本地会话，而UPF中的PFCP会话仍处于活动状态。
比起死记各种可能的消息顺序，更有效的排障方式是围绕受影响的PDU会话ID建立一组检查点。
确认被释放的会话： 将分析锁定在正确的PDU会话ID上，避免把其他并发会话的信令混入当前跟踪；
确认触发源： 判断最初事件是UE Release Request、PCF终止通知、AMF请求，还是其他网络侧事件；
验证SMF处理： 确认请求已到达负责该PDU会话的SMF，且SMF已进入释放流程；
检查N4资源： 确认PFCP Session Deletion Request和Response已完成，原有UPF会话规则已删除；
检查N2资源： 确认gNB收到PDU会话资源释放信令，并返回相应的释放结果；
检查N1状态： 在适用的显式NAS释放流程中，确认UE已收到Release Command并返回PDU Session Release Complete；
验证最终状态： 确认AMF中的PDU会话状态、SMF上下文以及任何PCF关联均与Released结果一致。
例如，如果UE已返回PDU Session Release Complete，但UPF中仍存在对应PFCP会话，应首先排查SMF和N4资源清理。如果PFCP状态已删除，但gNB仍保存相关PDU会话资源，则下一步应检查N2释放路径。
反过来，如果没有PDU Session Release Request、Release Command或相应核心网资源清理，仅看到RRC Release也不足以认定PDU会话已经终止。
不同规范层级使用的消息名称也可能造成混淆。某些流程说明可能将某一步称为“PDU Session Release Ack”，而UE接收PDU Session Release Command后实际发送的5GSM NAS消息是 PDU Session Release Complete。分析空口及NAS信令跟踪时应以实际Message Type为准。
因此，更可靠的完成判据是： 与原PDU会话ID关联的状态是否已从UE、RAN、SMF和UPF中移除，而不是某条特定的“最终”消息是否出现？
常见问题
PDU会话释放会使UE去注册吗？
不一定。PDU会话释放只终止指定的数据会话。UE可以继续保持5GS已注册状态，也可以继续使用其他活动PDU会话。去注册才是终止UE与5GS之间注册关系的流程。
PDU会话释放会释放UE的IP地址吗？
对于IP类型的PDU会话，与之关联的IP地址或前缀属于需要释放的资源。流程完成后，该地址不应再作为已释放PDU会话的有效用户面地址使用。地址池回收及后续是否重新分配取决于网络实现。
PFCP会话删除等同于PDU会话释放吗？
不是。PFCP Session Deletion是SMF通过N4删除UPF会话及其用户面规则的流程。它通常是PDU会话释放的重要环节，但完整释放还可能涉及UE、RAN、AMF、PCF及其他相关上下文。
PDU会话释放与PDU会话修改的主要区别是什么？
PDU会话修改是在保持原会话活动的同时调整QoS、策略或相关资源。PDU会话释放则终止指定会话并移除相关资源。如果同一PDU会话ID仍有效且继续承载流量，通常不能认为释放已经完成。
UE已发起释放请求，网络为什么还要发送PDU Session Release Command？
UE Release Request表达的是UE终止会话的请求，但SMF仍须协调UPF、RAN及UE中的状态。网络进入释放流程后，PDU Session Release Command指示UE清除对应的5GSM会话上下文，随后UE以PDU Session Release Complete作出响应。
