《5G核心网原理与实践》实践篇 · UDM 网元功能
作者：爱卫生
在本系列第21篇中，我们详细剖析了UDM如何通过Nudm_SDM_Notification向AMF推送接入和移动性管理签约数据（AM-Data）的变更通知。本篇将视线转向另一个同等重要的通知场景——UDM向SMF推送会话管理签约数据（SM-Data）的变更通知。
SM-Data的变更在实际运营中同样频繁发生。常见的触发场景包括：
QoS策略调整：运营商为特定用户群调整默认QoS参数，如修改5QI值或ARP优先级；
DNN配置变更：为用户新增或修改DNN（数据网络名称）的签约配置；
计费策略变更：用户的计费特性（Charging Characteristics）需要更新；
PDU会话类型变更：运营商调整用户允许的PDU会话类型或SSC模式。
当这些SM-Data发生变更时，正在为该用户提供会话管理服务的SMF必须及时感知，以便采取相应的处理动作——例如触发PDU会话修改流程来更新Session-AMBR、调整QoS参数等。
SMF的通知机制在原理上与AMF的通知机制完全一致——都是基于"订阅-通知"模式。但在实际应用中，两者存在一些重要差异：
flowchart TD
subgraph AMF通知机制
A1["AMF在注册流程中订阅"] --> A2["通知触发: AM-Data变更"]
A2 --> A3["AMF处理: 更新接入控制策略"]
A3 --> A4["影响: 可能触发Configuration Update"]
end
subgraph SMF通知机制
S1["SMF在PDU会话建立中订阅"] --> S2["通知触发: SM-Data变更"]
S2 --> S3["SMF处理: 更新会话管理参数"]
S3 --> S4["影响: 可能触发PDU Session Modification"]
end
style A1 fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
style A4 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style S1 fill:#fff3e0,stroke:#e65100,stroke-width:2px
style S4 fill:#fce4ec,stroke:#c62828,stroke-width:2px
AMF通知 vs SMF通知对比表：
| 对比维度 | AMF通知（第21篇） | SMF通知（本篇） |
|---|---|---|
| 订阅时机 | UE注册流程中 | PDU会话建立流程中 |
| 订阅服务 | Nudm_SDM_Subscribe | Nudm_SDM_Subscribe |
| resourceId | am-data | sm-data |
| 通知触发 | AM-Data被修改 | SM-Data被修改 |
| 典型变更内容 | S-NSSAI、UE-AMBR、RFSP | Session-AMBR、5QI、DNN配置 |
| 通知后处理 | 更新接入策略，可能触发Config Update | 更新会话参数，可能触发PDU Session Modification |
| 订阅生命周期 | 跟随注册生命周期 | 跟随PDU会话生命周期 |
sequenceDiagram
participant BOSS as BOSS/OAM
participant UDR
participant UDM
participant SMF
participant AMF
participant UE
Note over BOSS, UE: 前提: PDU会话已建立, SMF已订阅SM-Data变更
rect rgb(230, 255, 230)
Note over BOSS, UDR: 阶段1: 数据变更触发
BOSS->>UDR: 修改Session Management Subscription Data
Note right of BOSS: 如修改Session-AMBR、QoS Profile等
end
rect rgb(255, 240, 230)
Note over UDR, SMF: 阶段2: 通知推送
UDR-->>UDM: 数据变更通知
Note left of UDR: UDR检测到sm-data变更
UDM->>SMF: Nudm_SDM_Notification (POST)
Note left of UDM: POST到SMF的callbackReference
Note left of UDM: 携带notifyItems: sm-data变更
SMF-->>UDM: 204 No Content
Note right of SMF: SMF确认收到通知
end
rect rgb(230, 245, 255)
Note over SMF, UE: 阶段3: 会话修改
SMF->>SMF: 解析变更内容, 更新本地会话参数
SMF->>AMF: Nsmf_PDUSession_UpdateSMContext Request
Note right of SMF: 触发PDU Session Modification
AMF->>UE: PDU Session Modification Command
UE-->>AMF: PDU Session Modification Complete
AMF-->>SMF: Nsmf_PDUSession_UpdateSMContext Response
end
flowchart TD
TRIGGER["触发源: 运营商修改SM签约数据<br/>如调整Session-AMBR"] --> UDR["UDR<br/>统一数据仓库"]
UDR -->|"检测到sm-data变更"| UDM["UDM<br/>查找SM-Data订阅记录"]
UDM --> SUB_REC["SDM Subscription记录<br/>callbackReference指向SMF"]
SUB_REC --> NOTIFY["Nudm_SDM_Notification<br/>POST到SMF回调地址"]
NOTIFY --> SMF["SMF<br/>会话管理功能"]
SMF --> PARSE["解析变更内容"]
PARSE --> UPDATE["更新本地SM-Data缓存"]
UPDATE --> MODIFY["触发PDU Session Modification<br/>更新Session-AMBR / QoS等"]
MODIFY --> UPF["通知UPF更新N4规则"]
MODIFY --> UE["通知UE更新会话参数"]
style TRIGGER fill:#fce4ec,stroke:#c62828,stroke-width:2px
style NOTIFY fill:#fff3e0,stroke:#e65100,stroke-width:2px
style MODIFY fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style UE fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
验证当运营商修改用户的会话管理签约数据（SM-Data）后，UDM能够通过Nudm_SDM_Notification服务向SMF发送数据变更通知，通知消息中包含正确的变更项（notifyItems，resourceId为sm-data）、变更操作类型（REPLACE）和变更数据内容（如新的sessionAmbr），SMF能够正确接收并确认通知，并可能触发PDU会话修改流程。
SA网络中各网元系统及操作维护台运行正常。
终端和网络连接正常。
UE在UDM开户，签约5G业务，且已完成5GC注册。
UE已成功建立至少一个PDU会话（如internet DNN）。
SMF在PDU会话建立流程中已通过Nudm_SDM_Subscribe成功订阅了SM-Data变更通知，UDM已保存SMF的callbackReference。
服务化接口的信令监控、分析的工具准备就绪。
确认SMF已订阅SM-Data变更通知（在PDU会话建立流程中已完成）。
运营人员通过BOSS系统或OAM平台修改测试用户的SM签约数据，例如：
调整Session-AMBR值（上调或下调会话级速率上限）；
修改5GS QoS Profile中的5QI或ARP参数；
更新允许的PDU会话类型或SSC模式。
观察UDM是否向SMF发送Nudm_SDM_Notification通知。
检查通知消息中的notifyItems是否包含正确的变更操作和数据内容。
Frame: 1847 & 1849
检查SMF是否正确返回204 No Content确认。
检查SMF是否根据变更内容触发PDU会话修改流程。
Frame: 1853 & 1858
UDM在检测到SM-Data变更后，主动向SMF的callbackReference地址发送Nudm_SDM_Notification（HTTP POST），通知消息格式符合3GPP规范。
通知消息的notifyItems中包含正确的resourceId（指向sm-data）、changes（包含REPLACE操作和变更路径/数据，如/sessionAmbr）。
SMF正确接收通知后，返回204 No Content，并更新本地缓存的会话管理签约数据。
SMF根据变更内容触发PDU会话修改流程，更新UPF的N4会话规则和UE的会话参数。
在本测试中，核心关注点是UDM如何将SM-Data变更通知推送给SMF，以及SMF如何处理这个通知。我们将深入剖析通知消息的构造、字段含义，以及SMF收到通知后的PDU会话修改流程。
（注：为保护网络安全，以下log中的SUPI/IMSI标识、网元IP、UUID、DNN及回调地址等敏感信息已做严格脱敏处理）
当运营人员在BOSS系统中修改了用户的会话管理签约数据后，变更被写入UDR。UDR检测到SM-Data变更后通知UDM。UDM查找该用户在SM-Data上的活跃订阅记录——这个订阅是SMF在PDU会话建立时通过Nudm_SDM_Subscribe创建的。UDM根据订阅记录中保存的callbackReference，向SMF发送HTTP POST通知。
本测试场景中，运营人员将用户的internet DNN的Session-AMBR从上行1 Gbps / 下行2 Gbps上调为上行2 Gbps / 下行5 Gbps，模拟一次典型的"套餐提速"操作。
sequenceDiagram
participant UDR
participant UDM
participant SMF
Note over UDR, UDM: 数据变更触发
UDR->>UDM: 检测到sm-data变更通知
Note over UDM: UDM查找SM-Data订阅记录
Note over UDM: 找到callbackReference指向SMF
rect rgb(255, 240, 230)
Note over UDM, SMF: Nudm_SDM_Notification
UDM->>SMF: POST {callbackReference}
Note right of UDM: 请求体: notifyItems数组
Note right of UDM: resourceId: sm-data
Note right of UDM: changes: REPLACE /sessionAmbr
SMF-->>UDM: 204 No Content
Note left of SMF: SMF确认收到通知
Note left of SMF: 更新本地缓存的SM-Data
end
rect rgb(230, 255, 230)
Note over SMF: SMF触发PDU会话修改
Note over SMF: 向PCF请求策略更新
Note over SMF: 向UPF更新N4规则
Note over SMF: 通过AMF通知UE
end
信令抓包解析：
# 1. UDM -> SMF（会话管理签约数据变更通知 POST请求）
Frame: 1847
HEADERS[5]: POST http://172.16.XX.XX:31384/nsmf-callback/v1/sdm-notification/imsi-460XX00000XXXX
Content-Type: application/json
# 请求方法: POST
# 目标地址: SMF的callbackReference（PDU会话建立时SMF提供的回调地址）
# 资源路径: /nsmf-callback/v1/sdm-notification/{supi}
# 说明: UDM将通知POST到SMF在Nudm_SDM_Subscribe时提供的回调地址
# 注意: SMF的回调地址端口(31384)与AMF的回调地址端口(31382)不同
# 这是因为不同的NF实例使用不同的SBI服务端口
JavaScript Object Notation: application/json
Object
Member Key: notifyItems
Array
Object
# ===== 变更项标识 =====
Member Key: resourceId
String value: "sm-data"
# 指向会话管理签约数据
# 表示本次变更是针对SM-Data
# 与AMF通知中的"am-data"不同
Member Key: value
Object
# ===== 变更操作类型 =====
Member Key: op
String value: "REPLACE"
# 操作类型: REPLACE（替换）
# 将path指定位置的旧值替换为新的value
Member Key: path
String value: "/dnnConfigurations/internet/sessionAmbr"
# 变更路径: /dnnConfigurations/internet/sessionAmbr
# 精确指向internet DNN下的sessionAmbr字段
# 路径采用JSON Pointer语法（RFC 6901）
Member Key: value
Object
# ===== 新的Session-AMBR（提速后的值） =====
Member Key: uplink
String value: "2000000000"
# 上行AMBR: 2000000000 bps = 2 Gbps
# 变更前: 1000000000 bps = 1 Gbps（提速100%）
Member Key: downlink
String value: "5000000000"
# 下行AMBR: 5000000000 bps = 5 Gbps
# 变更前: 2000000000 bps = 2 Gbps（提速150%）
# 2. SMF -> UDM（通知确认响应）
Frame: 1849
HEADERS[3]: 204 No Content
# HTTP状态码: 204 No Content
# 说明: SMF成功接收并处理了变更通知
# 无响应体，仅通过状态码确认
与AMF通知类似，SMF通知的核心同样是notifyItems数组。但由于SM-Data和AM-Data的数据结构不同，通知中的字段取值和处理逻辑也有所差异。下面逐一解读。
| 字段 | 取值 | 含义 |
|---|---|---|
resourceId: "sm-data" | 指向用户的会话管理签约数据 |
本场景中resourceId为"sm-data"，表示SMF在Nudm_SDM_Get中获取的Session Management Subscription Data发生了变化。SMF收到通知后，会根据这个标识判断变更的数据类型，从而调用相应的处理逻辑。
AMF通知与SMF通知的resourceId对比：
| 通知对象 | resourceId | 数据类型 | 数据结构 |
|---|---|---|---|
| AMF | am-data | AccessAndMobilitySubscriptionData | 含nssai、ueAmbr、rfsp等 |
| SMF | sm-data | SessionManagementSubscriptionData | 含dnnConfigurations、singleNssai等 |
协议参考：根据3GPP TS 29.503 第5.2.2.3节，
resourceId的取值对应SDM服务的资源名称。SMF通过/sm-data资源获取数据，因此通知中的resourceId为"sm-data"。
| 字段 | 取值 | 含义 |
|---|---|---|
| path | "/dnnConfigurations/internet/sessionAmbr" | 精确指向internet DNN的sessionAmbr字段
与AMF通知中path直接指向顶层字段（如/nssai）不同，SM-Data的path通常需要深入到dnnConfigurations内部的特定DNN配置。这是因为SM-Data的层级结构更深：
SM-Data (根对象 /)
├── /singleNssai
│ ├── /singleNssai/sst
│ └── /singleNssai/sd
├── /dnnConfigurations
│ ├── /dnnConfigurations/internet
│ │ ├── /dnnConfigurations/internet/pduSessionTypes
│ │ ├── /dnnConfigurations/internet/sscModes
│ │ ├── /dnnConfigurations/internet/5gQosProfile
│ │ │ ├── .../5qi
│ │ │ ├── .../arp
│ │ │ └── .../priorityLevel
│ │ ├── /dnnConfigurations/internet/sessionAmbr
│ │ │ ├── .../uplink
│ │ │ └── .../downlink
│ │ └── /dnnConfigurations/internet/staticIpAddress
│ └── /dnnConfigurations/ims
│ └── ...
└── /chargingCharacteristics
SM-Data中常见的变更路径：
| path值 | 指向的数据 | 变更场景 |
|---|---|---|
/dnnConfigurations/internet/sessionAmbr |
internet DNN的会话AMBR | 套餐提速/降速 |
|---|---|---|
/dnnConfigurations/internet/5gQosProfile |
internet DNN的QoS配置 | QoS策略调整 |
/dnnConfigurations/internet/5gQosProfile/5qi |
5QI值 | 业务优先级变更 |
/dnnConfigurations/internet/pduSessionTypes |
PDU会话类型 | 会话类型授权变更 |
/dnnConfigurations/internet/sscModes |
SSC模式 | 连续性策略调整 |
/chargingCharacteristics |
计费特性 | 计费策略变更 |
/dnnConfigurations/ims |
IMS DNN整体配置 | IMS语音策略更新 |
协议参考：根据3GPP TS 29.503 第5.2.2.2.2节，
dnnConfigurations是一个map结构，key为DNN名称（如"internet"、"ims"），value为DnnConfiguration对象。JSON Pointer路径中的/dnnConfigurations/internet/...即对应这个map的嵌套访问。
| 字段 | 取值 | 含义 |
|---|---|---|
value.uplink |
"2000000000" | 新的上行AMBR = 2 Gbps |
|---|---|---|
value.downlink |
"5000000000" | 新的下行AMBR = 5 Gbps |
提速前后的对比：
| 维度 | 变更前 | 变更后 | 变化幅度 |
|---|---|---|---|
| 上行AMBR | 1,000,000,000 bps (1 Gbps) | 2,000,000,000 bps (2 Gbps) | +100% |
| 下行AMBR | 2,000,000,000 bps (2 Gbps) | 5,000,000,000 bps (5 Gbps) | +150% |
Session-AMBR与UE-AMBR的关系：
在5G核心网中，速率控制存在两级AMBR体系：
| AMBR类型 | 控制范围 | 配置位置 | 执行网元 |
|---|---|---|---|
| UE-AMBR | 单个UE所有PDU会话的总速率 | AM-Data中的subscribedUeAmbr | RAN（gNB） |
| Session-AMBR | 单个PDU会话的速率上限 | SM-Data中的sessionAmbr | UPF |
简单理解：UE-AMBR是"总水管"的口径，Session-AMBR是每根"分支水管"的口径。分支水管的流量不能超过总水管，所以Session-AMBR的实际生效值同时受限于UE-AMBR。
flowchart LR
UE_AMBR["UE-AMBR<br/>总速率上限<br/>下行 1.235 Gbps<br/>(来自AM-Data)"] --> S1["Session-AMBR 1<br/>internet DNN<br/>下行 5 Gbps<br/>实际生效: min(5G, 1.235G)"]
UE_AMBR --> S2["Session-AMBR 2<br/>ims DNN<br/>下行 100 Mbps<br/>实际生效: min(100M, 1.235G)"]
style UE_AMBR fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
style S1 fill:#fff3e0,stroke:#e65100,stroke-width:2px
style S2 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
重要提示：本测试中Session-AMBR提速到下行5 Gbps，但如果用户的UE-AMBR（在AM-Data中）仍为下行1.235 Gbps，则实际生效的下行速率为两者取小值——即1.235 Gbps。运营商在进行"套餐提速"时，通常需要同时修改AM-Data中的UE-AMBR和SM-Data中的Session-AMBR，确保两者协调一致。
SMF收到Nudm_SDM_Notification后的处理比AMF更为复杂，因为SMF通常需要触发PDU会话修改流程来将变更推送到UPF和UE。以下是SMF处理SM-Data变更通知的完整逻辑：
flowchart TD
A["SMF收到Nudm_SDM_Notification"] --> B["解析notifyItems"]
B --> C["检查resourceId是否为sm-data"]
C -->|"是"| D["遍历changes数组"]
C -->|"否"| LOG["记录日志: 非SM-Data变更"]
D --> E["解析每项change的path"]
E --> F{path类型判断}
F -->|"/sessionAmbr"| G["更新本地Session-AMBR缓存"]
F -->|"/5gQosProfile"| H["更新本地QoS Profile缓存"]
F -->|"/pduSessionTypes"| I["更新允许的PDU会话类型"]
F -->|"/sscModes"| J["更新允许的SSC模式"]
F -->|"/chargingCharacteristics"| K["更新计费特性"]
G --> L["触发PDU Session Modification"]
H --> L
K --> M["通知CHF更新计费规则"]
L --> N["向PCF请求策略更新"]
N --> O["向UPF更新N4会话规则"]
O --> P["通过AMF向UE发送Modification Command"]
P --> Q["UE确认修改"]
Q --> R["返回204 No Content给UDM"]
M --> R
R --> DONE["通知处理完成"]
style DONE fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
style LOG fill:#fff9c4,stroke:#f57f17
style L fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
SMF对各类SM-Data变更的处理策略：
| 变更路径 | SMF处理动作 | 是否触发会话修改 | 影响的网元 |
|---|---|---|---|
.../sessionAmbr |
更新速率上限，修改UPF的QoS规则 | 是 | UPF、UE |
|---|---|---|---|
.../5gQosProfile |
更新默认QoS，修改QoS Flow参数 | 是 | UPF、PCF、UE |
.../pduSessionTypes |
更新允许的PDU会话类型 | 否，下次建立时生效 | 无 |
.../sscModes |
更新允许的SSC模式 | 否，下次建立时生效 | 无 |
/chargingCharacteristics |
更新计费特性 | 否，通知CHF | CHF |
协议参考：根据3GPP TS 29.503 第5.2.2.3节，SMF收到通知后应更新本地存储的签约数据。如果变更影响当前活跃的PDU会话（如Session-AMBR或QoS变更），SMF应触发PDU Session Modification流程（TS 23.502 第4.3.3节）。
在本测试中，SMF收到Session-AMBR变更通知后，触发PDU会话修改流程。以下是修改流程中的关键信令：
PDU会话修改信令抓包：
# 3. SMF -> AMF（PDU会话修改请求）
Frame: 1853
HEADERS[5]: POST /nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify
Content-Type: application/json
JavaScript Object Notation: application/json
Object
Member Key: jsonPatchSeq
Array
Object
Member Key: op
String value: "replace"
# 操作类型: 替换
Member Key: path
String value: "/sessionAmbr"
# 替换路径: /sessionAmbr
Member Key: value
Object
Member Key: uplink
String value: "2000000000"
# 新上行AMBR: 2 Gbps
Member Key: downlink
String value: "5000000000"
# 新下行AMBR: 5 Gbps
# 说明:
# SMF在收到UDM的变更通知后，通过Nsmf_PDUSession_UpdateSMContext
# 向AMF发起PDU会话修改请求，携带新的Session-AMBR参数
# AMF将通过N2接口将修改请求转发给RAN，再通过NAS信令通知UE
# 4. AMF -> SMF（PDU会话修改响应）
Frame: 1858
HEADERS[3]: 200 OK
# HTTP状态码: 200 OK
# 说明: PDU会话修改成功
# UE已收到新的Session-AMBR参数并确认
PDU会话修改的完整信令链路：
sequenceDiagram
participant SMF
participant PCF
participant UPF
participant AMF
participant RAN
participant UE
Note over SMF, UE: SMF收到UDM的Session-AMBR变更通知后触发
rect rgb(230, 245, 255)
Note over SMF, PCF: 策略更新（可选）
SMF->>PCF: SM Policy Association Modification
Note right of SMF: 携带新的Session-AMBR
PCF-->>SMF: 200 OK + Updated Policy
Note left of PCF: PCF可能更新QoS规则
end
rect rgb(230, 255, 230)
Note over SMF, UPF: N4规则更新
SMF->>UPF: N4 Session Modification Request
Note right of SMF: 更新Session-AMBR限速规则
UPF-->>SMF: N4 Session Modification Response
Note left of UPF: UPF更新用户面速率管控规则
end
rect rgb(255, 240, 230)
Note over SMF, UE: UE会话参数更新
SMF->>AMF: Nsmf_PDUSession_UpdateSMContext
Note right of SMF: 携带新的Session-AMBR
AMF->>RAN: N2 PDU Session Resource Modify
RAN->>UE: PDU Session Modification Command
Note right of UE: 携带新的Session-AMBR
UE-->>RAN: PDU Session Modification Complete
RAN-->>AMF: N2 PDU Session Resource Modify Ack
AMF-->>SMF: Nsmf_PDUSession_UpdateSMContext Response
end
协议参考：根据3GPP TS 23.502 第4.3.3节（PDU Session Modification），SMF可以在网络侧发起PDU会话修改流程。当签约数据变更导致Session-AMBR或QoS参数变化时，SMF应触发此流程。修改流程涉及SMF-PCF（策略更新）、SMF-UPF（N4规则更新）、SMF-AMF-UE（会话参数更新）三个维度的交互。
在实际工程调试中，我们可以使用curl命令行工具手动模拟UDM向SMF发送SM-Data变更通知，以验证SMF的通知处理和PDU会话修改逻辑。
curl模拟通知请求（Session-AMBR变更）：
curl -i -X POST http://172.16.XX.XX:31384/nsmf-callback/v1/sdm-notification/imsi-460XX00000XXXX \
-H "Content-Type: application/json" \
-d '{
"notifyItems": [
{
"resourceId": "sm-data",
"changes": [
{
"op": "REPLACE",
"path": "/dnnConfigurations/internet/sessionAmbr",
"value": {
"uplink": "2000000000",
"downlink": "5000000000"
}
}
]
}
]
}'
curl命令参数解析：
| 参数 | 值 | 说明 |
|---|---|---|
-i |
- | 在输出中包含HTTP响应头 |
|---|---|---|
-X POST |
POST | HTTP方法为POST |
| URL | http://172.16.XX.XX:31384/nsmf-callback/... | SMF的callbackReference地址 |
Content-Type |
application/json | 请求体为JSON格式 |
与AMF通知curl命令的对比：
| 对比项 | AMF通知（第21篇） | SMF通知（本篇） |
|---|---|---|
| 目标地址 | AMF callbackReference (10.XX.XX.XX:31382) | SMF callbackReference (172.16.XX.XX:31384) |
| 回调路径 | /namf-callback/v1/sdm-notification/ | /nsmf-callback/v1/sdm-notification/ |
| resourceId | am-data | sm-data |
| path | /nssai | /dnnConfigurations/internet/sessionAmbr |
| 后续动作 | AMF更新接入策略 | SMF触发PDU会话修改 |
另一个场景：curl模拟QoS Profile变更通知：
curl -i -X POST http://172.16.XX.XX:31384/nsmf-callback/v1/sdm-notification/imsi-460XX00000XXXX \
-H "Content-Type: application/json" \
-d '{
"notifyItems": [
{
"resourceId": "sm-data",
"changes": [
{
"op": "REPLACE",
"path": "/dnnConfigurations/internet/5gQosProfile",
"value": {
"5qi": 8,
"arp": {
"priorityLevel": 6,
"preemptCap": "MAY_PREEMPT",
"preemptVuln": "NOT_PREEMPTABLE"
},
"priorityLevel": 10
}
}
]
}
]
}'
上述curl命令模拟了运营商将用户的默认QoS从5QI=9（尽力而为）升级为5QI=8（高优先级数据），同时将ARP优先级从8提升到6，并赋予抢占能力的场景。SMF收到此通知后，会触发PDU会话修改流程，更新UPF的QoS Flow规则。
SMF预期响应：
HTTP/1.1 204 No Content
Date: Thu, 16 Apr 2026 10:35:00 GMT
SMF返回204 No Content，表示通知已成功接收。SMF会在后台异步处理变更并触发PDU会话修改流程。
通知失败的重试机制：
如果SMF返回错误状态码（如4xx或5xx）或未响应，UDM应根据以下策略进行重试：
| 重试参数 | 建议值 | 说明 |
|---|---|---|
| 最大重试次数 | 3~5次 | 超过后记录告警 |
| 重试间隔 | 指数退避 | 如5s, 15s, 45s |
| 重试超时 | 单次30秒 | 每次请求的超时时间 |
| 失败处理 | 记录告警 | 通知运维人员人工介入 |
协议参考：根据3GPP TS 29.503 第5.2.2.3节，
Nudm_SDM_Notification的请求体结构与AMF通知完全一致，都使用SdmNotification数据类型。SMF的回调路径在Nudm_SDM_Subscribe时由SMF通过callbackReference字段提供给UDM。
一个用户可能同时拥有多个PDU会话（如internet、ims），每个PDU会话可能由不同的SMF管理。当SM-Data变更时，UDM需要将通知发送到所有订阅了该用户SM-Data的SMF。
flowchart TD
UDM_NOTIFY["UDM检测到SM-Data变更"] --> CHECK["查找所有SM-Data订阅记录"]
CHECK --> SUB1["订阅记录1<br/>SMF-1 (internet DNN)<br/>callbackRef: 172.16.XX.XX:31384"]
CHECK --> SUB2["订阅记录2<br/>SMF-2 (ims DNN)<br/>callbackRef: 172.16.XX.XX:31385"]
SUB1 --> SEND1["向SMF-1发送通知<br/>internet DNN的sessionAmbr变更"]
SUB2 --> SEND2["向SMF-2发送通知<br/>ims相关配置变更"]
SEND1 --> ACK1["SMF-1返回204确认<br/>触发internet PDU会话修改"]
SEND2 --> ACK2["SMF-2返回204确认<br/>检查ims配置是否受影响"]
style UDM_NOTIFY fill:#fff3e0,stroke:#e65100,stroke-width:2px
style SEND1 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style SEND2 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
多SMF通知场景的注意事项：
| 场景 | UDM行为 | 说明 |
|---|---|---|
| 同一SMF管理多个PDU会话 | 发送一次通知，包含所有受影响的变更 | SMF根据变更path判断哪些PDU会话受影响 |
| 不同SMF管理不同PDU会话 | 分别向每个SMF发送通知 | 每个SMF有独立的callbackReference |
| 变更仅影响特定DNN | 只有管理该DNN的SMF会收到通知 | UDM可根据订阅时的DNN过滤条件精准通知 |
| SMF未订阅SM-Data变更 | 不发送通知 | SMF只会在下次PDU会话建立时获取最新数据 |
协议参考：根据3GPP TS 29.503 第5.2.2.2节和TS 29.505 第5.2节，SMF在
Nudm_SDM_Subscribe时可以指定dnn和s-nssai作为过滤条件。UDM在发送通知时，可以根据变更的数据和订阅的过滤条件，决定是否需要通知特定的SMF。
在实际运营中，一次"套餐提速"操作通常需要同时修改AM-Data和SM-Data，此时AMF和SMF都会收到变更通知：
sequenceDiagram
participant BOSS as BOSS/OAM
participant UDR
participant UDM
participant AMF
participant SMF
Note over BOSS, SMF: 套餐提速: 修改UE-AMBR和Session-AMBR
BOSS->>UDR: 修改AM-Data: subscribedUeAmbr
BOSS->>UDR: 修改SM-Data: sessionAmbr
rect rgb(230, 245, 255)
Note over UDR, AMF: AM-Data变更通知
UDR-->>UDM: AM-Data变更
UDM->>AMF: Nudm_SDM_Notification
Note right of UDM: resourceId: am-data
Note right of UDM: path: /subscribedUeAmbr
AMF-->>UDM: 204 No Content
end
rect rgb(230, 255, 230)
Note over UDR, SMF: SM-Data变更通知
UDR-->>UDM: SM-Data变更
UDM->>SMF: Nudm_SDM_Notification
Note right of UDM: resourceId: sm-data
Note right of UDM: path: .../sessionAmbr
SMF-->>UDM: 204 No Content
end
rect rgb(255, 240, 230)
Note over AMF, SMF: 协同生效
Note over AMF: AMF更新UE-AMBR
Note over SMF: SMF触发PDU会话修改
Note over AMF, SMF: 新速率 = min(UE-AMBR, Session-AMBR)
end
联合通知的关键时间线：
| 时间 | 事件 | 说明 |
|---|---|---|
| T0 | BOSS修改签约数据 | 同时修改AM-Data和SM-Data |
| T1 | UDM通知AMF | AM-Data中的UE-AMBR变更 |
| T2 | UDM通知SMF | SM-Data中的Session-AMBR变更 |
| T3 | SMF触发PDU会话修改 | 更新UPF速率规则和UE会话参数 |
| T4 | 新速率生效 | 实际生效速率 = min(新UE-AMBR, 新Session-AMBR) |
工程提示：在实际网络中，T1和T2的顺序不固定，取决于UDR中AM-Data和SM-Data变更通知的到达顺序。SMF在收到通知后应等待一小段时间（如100~500ms），以避免在AMF还未更新UE-AMBR时就向UPF下发新的Session-AMBR规则，导致速率管控不一致。
| 验证项 | 结果 | 说明 |
|---|---|---|
| UDM发送SM-Data变更通知 | OK | UDM在检测到sm-data变更后，主动向SMF的callbackReference发送POST通知 |
| resourceId正确性 | OK | notifyItems中resourceId为"sm-data"，正确指向会话管理签约数据 |
| 变更操作正确性 | OK | changes中op=REPLACE，path="/dnnConfigurations/internet/sessionAmbr"，正确描述Session-AMBR变更 |
| 变更数据正确性 | OK | 新的sessionAmbr上行2 Gbps、下行5 Gbps，与BOSS修改后的数据一致 |
| SMF确认通知 | OK | SMF返回204 No Content，确认成功接收并处理通知 |
| PDU会话修改触发 | OK | SMF根据通知内容触发PDU会话修改，更新UPF N4规则和UE会话参数 |
本测试用例完美通过！当运营人员通过BOSS系统修改用户的会话管理签约数据（SM-Data中的Session-AMBR）后，UDM成功通过Nudm_SDM_Notification服务向SMF推送了数据变更通知。通知消息中的notifyItems正确包含了resourceId（sm-data）和changes（REPLACE操作、/dnnConfigurations/internet/sessionAmbr路径、新的Session-AMBR数据），SMF正确接收并返回204 No Content确认，随后触发了PDU会话修改流程，将新的速率参数推送到UPF和UE。整个通知和处理流程与3GPP TS 29.503和TS 23.502规范完全吻合。
关键收获总结：
SMF通知机制与AMF通知机制同宗同源：两者都基于Nudm_SDM_Notification服务，使用相同的SdmNotification数据结构，只是resourceId和path不同；
SM-Data的path层级更深：由于SM-Data采用dnnConfigurations map结构，变更路径通常需要深入到具体的DNN配置内部（如/dnnConfigurations/internet/sessionAmbr）；
SMF通知通常触发PDU会话修改：与AMF仅更新本地缓存不同，SMF在收到Session-AMBR或QoS变更通知后，需要触发PDU Session Modification流程，将变更推送到UPF和UE；
AM-Data与SM-Data需协调变更：在实际的"套餐提速"场景中，运营商需同时修改UE-AMBR（AM-Data）和Session-AMBR（SM-Data），确保两者的速率限制协调一致；
多SMF场景需要精准通知：当一个用户有多个PDU会话由不同SMF管理时，UDM需要根据订阅记录的callbackReference和过滤条件，将通知精准发送到受影响的SMF。
关于作者：爱卫生，从事通信教学18年，出版过《5G核心网原理与实践》等4本专业书籍。学5G核心网、IMS，来51学通信就对了！知识星球：200+小时视频、3000+精华文章、1年答疑群。公众号/知识星球：51学通信，微信：gprshome201101