5GC实践篇之UDM篇第21篇：签约数据改变通知AMF

区域限制调整：企业用户的允许活动区域发生变化，需要更新serviceAreaRestriction；
RAT限制修改：用户从纯5G用户变为5G+4G用户，需要移除ratRestrictions中的EUTRA限制。

当这些签约数据发生变化时，一个关键问题随之而来：已经在服务该用户的AMF如何得知签约数据已经改变？

答案就是本篇要深入剖析的核心机制——Nudm_SDM_Notification（签约数据变更通知）。

通知机制的前置条件：AMF的SDM订阅

要理解通知机制，首先要明白它的前置条件。在注册流程中，AMF在成功获取用户的AM-Data之后，会执行一个关键的"订阅"操作——通过Nudm_SDM_Subscribe向UDM注册一个数据变更回调地址（callbackReference）。这个流程如下：


sequenceDiagram

    participant AMF

    participant UDM

    participant UDR

    participant BOSS as BOSS/OAM

    Note over AMF, UDM: 注册流程中的订阅阶段

    AMF->>UDM: Nudm_SDM_Subscribe (POST)

    Note right of AMF: POST /nudm-sdm/v1/{supi}/sdm-subscriptions

    Note right of AMF: 携带callbackReference: AMF的通知回调地址

    UDM-->>AMF: 201 Created + subscriptionId

    Note over BOSS, UDR: 运营人员通过BOSS修改签约数据

    BOSS->>UDR: 修改用户的AccessAndMobilitySubscriptionData

    Note right of BOSS: 如修改S-NSSAI、UE-AMBR等

    rect rgb(255, 240, 230)

        Note over UDR, AMF: 本篇重点：数据变更通知链路

        UDR-->>UDM: 数据变更通知触发

        Note left of UDR: UDR检测到am-data变更

        UDM->>AMF: Nudm_SDM_Notification (POST)

        Note left of UDM: POST到AMF的callbackReference

        Note left of UDM: 携带notifyItems: 变更内容和操作类型

        AMF-->>UDM: 204 No Content (通知确认)

        Note right of AMF: AMF更新本地缓存的签约数据

    end

通知机制的数据流全景图


flowchart TD

    TRIGGER["触发源：运营商通过BOSS/OAM修改签约数据"] --> UDR["UDR<br/>统一数据仓库<br/>存储签约数据"]

    UDR -->|"检测到am-data变更"| UDM["UDM<br/>统一数据管理<br/>查找订阅记录"]

    UDM -->|"查找callbackReference"| SUB_REC["订阅记录<br/>SDM Subscription"]

    SUB_REC -->|"回调地址指向AMF"| NOTIFY["Nudm_SDM_Notification<br/>POST到AMF回调地址"]

    NOTIFY -->|"notifyItems"| AMF["AMF<br/>接入和移动性管理功能"]

    AMF -->|"解析变更内容"| UPDATE["更新本地AM-Data缓存"]

    UPDATE -->|"根据变更类型执行策略"| ACTION["执行相应动作：<br/>1. 更新Allowed NSSAI<br/>2. 修改UE-AMBR<br/>3. 更新RFSP策略<br/>4. 调整区域限制"]

    style TRIGGER fill:#fce4ec,stroke:#c62828,stroke-width:2px

    style UDR fill:#e3f2fd,stroke:#1565c0,stroke-width:2px

    style NOTIFY fill:#fff3e0,stroke:#e65100,stroke-width:2px

    style ACTION fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

测试目的

验证当运营商修改用户的接入和移动性管理签约数据（AM-Data）后，UDM能够通过Nudm_SDM_Notification服务向AMF发送数据变更通知，通知消息中包含正确的变更项（notifyItems）、变更操作类型（REPLACE/ADD/REMOVE）和变更数据内容，AMF能够正确接收并确认通知。

测试前置条件

SA网络中各网元系统及操作维护台运行正常。
终端和网络连接正常。
UE在UDM开户，签约5G业务，且已完成5GC注册。
AMF在注册流程中已通过Nudm_SDM_Subscribe成功订阅了AM-Data变更通知，UDM已保存AMF的callbackReference。
服务化接口的信令监控、分析的工具准备就绪。

测试步骤

确认AMF已订阅AM-Data变更通知（在注册流程中已完成）。
运营人员通过BOSS系统或OAM平台修改测试用户的AM签约数据，例如：
修改签约S-NSSAI列表（增加或删除切片）；
调整签约UE-AMBR值（上调或下调速率）；
更新RFSP Index（修改频点优先级策略）。
观察UDM是否向AMF发送Nudm_SDM_Notification通知。
检查通知消息中的notifyItems是否包含正确的变更操作和数据内容。
Frame: 1256 & 1258
检查AMF是否正确返回204 No Content确认。

测试结果验证（预期）

UDM在检测到AM-Data变更后，主动向AMF的callbackReference地址发送Nudm_SDM_Notification（HTTP POST），通知消息格式符合3GPP规范。
通知消息的notifyItems中包含正确的resourceId（指向am-data）、changes（包含REPLACE操作和变更路径/数据）。
AMF正确接收通知后，返回204 No Content，并更新本地缓存的签约数据。

2 信令深度解析

在本测试中，核心关注点是UDM如何将签约数据变更通知推送给AMF。这涉及三个关键环节：UDR数据变更检测、UDM查找订阅记录并发送通知、AMF接收通知并确认。我们将深入剖析通知消息的每一个字段。

（注：为保护网络安全，以下log中的SUPI/IMSI标识、网元IP、UUID及回调地址等敏感信息已做严格脱敏处理）

2.1 通知消息的触发与发送（Nudm_SDM_Notification）

当运营人员在BOSS系统中修改了用户的签约数据后，数据变更被写入UDR。UDR检测到数据变更后，通知UDM。UDM查找该用户是否有活跃的SDM订阅记录，如果存在，则根据订阅时保存的callbackReference向对应的NF（本场景中是AMF）发送通知。

通知使用HTTP POST方法，目标地址是AMF在订阅时提供的callbackReference URL。通知体是一个JSON数组，包含一个或多个notifyItem，每个notifyItem描述了一项数据变更。


sequenceDiagram

    participant UDR

    participant UDM

    participant AMF

    Note over UDR, UDM: 数据变更触发

    UDR->>UDM: 检测到am-data变更通知

    Note over UDM: UDM查找subscription记录

    Note over UDM: 找到callbackReference指向AMF

    rect rgb(255, 240, 230)

        Note over UDM, AMF: Nudm_SDM_Notification

        UDM->>AMF: POST {callbackReference}

        Note right of UDM: 请求体: notifyItems数组

        Note right of UDM: resourceId: am-data

        Note right of UDM: changes: REPLACE /nssai

        AMF-->>UDM: 204 No Content

        Note left of AMF: AMF确认收到通知

        Note left of AMF: 更新本地缓存的AM-Data

    end

信令抓包解析：


# 1. UDM -> AMF（签约数据变更通知 POST请求）

Frame: 1256

HEADERS[5]: POST http://10.XX.XX.XX:31382/namf-callback/v1/sdm-notification/imsi-460XX00000XXXX

Content-Type: application/json

# 请求方法: POST

# 目标地址: AMF的callbackReference（订阅时AMF提供）

# 资源路径: /namf-callback/v1/sdm-notification/{supi}

# 说明: UDM将通知POST到AMF在Nudm_SDM_Subscribe时提供的回调地址

JavaScript Object Notation: application/json

  Object

    Member Key: notifyItems

      Array

        Object

          # ===== 变更项标识 =====

          Member Key: resourceId

            String value: "am-data"

            # 指向接入和移动性管理签约数据

            # 表示本次变更是针对AM-Data

          Member Key: value

            Object

              # ===== 变更操作类型 =====

              Member Key: op

                String value: "REPLACE"

                # 操作类型: REPLACE（替换）

                # 说明: 对指定路径的数据进行整体替换

                # 其他可能的操作类型:

                #   ADD - 新增数据项

                #   REMOVE - 删除数据项

                #   REPLACE - 替换已有数据项

              Member Key: path

                String value: "/nssai"

                # 变更路径: /nssai

                # 表示本次变更的是S-NSSAI签约切片信息

                # 路径采用JSON Pointer语法（RFC 6901）

              Member Key: value

                Object

                  # ===== 新的S-NSSAI数据（替换后的值） =====

                  Member Key: singleNssais

                    Array

                      Object

                        Member Key: sst

                          Number value: 1

                          # SST=1，eMBB切片

                        Member Key: sd

                          String value: "000001"

                          # 切片差异化标识

                      Object

                        Member Key: sst

                          Number value: 1

                        Member Key: sd

                          String value: "000002"

                          # 新增切片: SST=1, SD=000002

                      Object

                        Member Key: sst

                          Number value: 4

                        Member Key: sd

                          String value: "000003"

                          # 保留原有切片: SST=4, SD=000003

                    # 变更后，用户签约了3个S-NSSAI切片

                  Member Key: defaultSingleNssais

                    Array

                      Object

                        Member Key: sst

                          Number value: 1

                        Member Key: sd

                          String value: "000001"

                          # 默认切片保持不变

# 2. AMF -> UDM（通知确认响应）

Frame: 1258

HEADERS[3]: 204 No Content

# HTTP状态码: 204 No Content

# 说明: AMF成功接收并处理了变更通知

# 无响应体，仅通过状态码确认

2.2 notifyItems字段深度解读

通知消息的核心是notifyItems数组，每个元素描述一项具体的签约数据变更。下面逐一解读各关键字段。

2.2.1 resourceId（变更资源标识）

字段	取值	含义

resourceId: "am-data" | 指向用户的接入和移动性管理签约数据 |

resourceId标识了本次变更所影响的数据资源类型。在本场景中为"am-data"，表示AMF在Nudm_SDM_Get中获取的Access and Mobility Subscription Data发生了变化。

可能的resourceId取值：

resourceId值	目标NF	数据含义

`am-data`	AMF	接入和移动性管理签约数据
`sm-data`	SMF	会话管理签约数据
`ue-context-in-smf-data`	AMF	SMF中的UE上下文数据
`nssai`	AMF	网络切片选择辅助信息

协议参考：根据3GPP TS 29.503 第5.2.2.3节，resourceId对应SDM服务的资源名称，UDM根据订阅时指定的resourceUri确定变更的数据资源类型。

2.2.2 changes中的op（变更操作类型）

字段	取值	含义

| op | "REPLACE" | 替换操作，用新值替换path指定位置的旧值 |

3GPP定义了三种变更操作类型，遵循JSON Patch（RFC 6902）规范：

操作类型	含义	典型场景

`REPLACE`	替换已有数据项的值	修改S-NSSAI列表、调整UE-AMBR值
`ADD`	新增一个数据项	为用户新增切片权限、新增区域限制
`REMOVE`	删除一个数据项	删除用户对某切片的使用权限

本例中使用REPLACE操作，表示对/nssai路径下的数据进行整体替换——用新的S-NSSAI列表完全替代旧的列表。

2.2.3 changes中的path（变更路径）

字段	取值	含义

| path | "/nssai" | JSON Pointer路径，指向nssai字段 |

path使用JSON Pointer语法（RFC 6901）指定变更发生的精确位置。以下是AM-Data中常见的变更路径示例：

path值	指向的数据	变更场景

`/nssai`	签约S-NSSAI列表	切片权限变更
`/subscribedUeAmbr`	签约UE-AMBR	套餐提速/降速
`/rfspIndex`	RFSP索引	频点策略调整
`/ratRestrictions`	RAT接入限制	接入技术控制
`/serviceAreaRestriction`	服务区域限制	活动区域变更
`/subsRegTimer`	签约注册周期定时器	注册周期调整

JSON Pointer的层级关系示例：


AM-Data (根对象 /)

├── /nssai

│   ├── /nssai/singleNssais

│   │   ├── /nssai/singleNssais/0

│   │   │   ├── /nssai/singleNssais/0/sst

│   │   │   └── /nssai/singleNssais/0/sd

│   │   └── /nssai/singleNssais/1

│   └── /nssai/defaultSingleNssais

├── /subscribedUeAmbr

│   ├── /subscribedUeAmbr/uplink

│   └── /subscribedUeAmbr/downlink

├── /rfspIndex

└── /subsRegTimer

协议参考：根据3GPP TS 29.503 第5.2.2.3节，path字段采用JSON Pointer（RFC 6901）语法，用于在AmData数据结构中精确定位变更位置。UDM在组装通知时，根据UDR返回的变更信息自动计算path值。

2.2.4 changes中的value（变更后的新值）

字段	取值	含义

| value | 新的nssai对象 | 包含更新后的S-NSSAI列表

本例中，变更后的nssai对象包含：

子字段	变更后内容	与变更前的对比

`singleNssais`	SST=1/SD=000001, SST=1/SD=000002, SST=4/SD=000003	新增了SST=1类型的两个eMBB切片
`defaultSingleNssais`	SST=1/SD=000001	默认切片更新为eMBB类型

变更前后的对比：

维度	变更前	变更后	业务含义
签约切片数量	2个（SST=4类型）	3个（2个eMBB + 1个自定义）	用户获得了eMBB切片的使用权限
默认切片	SST=4/SD=000001	SST=1/SD=000001	默认切片从自定义类型变为eMBB
切片类型分布	仅运营商自定义	eMBB + 运营商自定义	业务场景更加丰富

2.3 AMF对通知的处理逻辑

AMF收到Nudm_SDM_Notification后，并不是简单地确认了事——它会根据变更内容执行一系列策略更新动作。以下是AMF处理通知的完整逻辑：


flowchart TD

    A["AMF收到Nudm_SDM_Notification"] --> B["解析notifyItems"]

    B --> C["检查resourceId是否为am-data"]

    C -->|"是"| D["遍历changes数组"]

    C -->|"否"| LOG["记录日志: 非AM-Data变更, 忽略"]

    D --> E["解析每项change的path"]

    E --> F{path类型判断}

    F -->|"/nssai"| G["更新本地S-NSSAI缓存"]

    F -->|"/subscribedUeAmbr"| H["更新本地UE-AMBR缓存"]

    F -->|"/rfspIndex"| I["更新RFSP并向RAN下发新策略"]

    F -->|"/ratRestrictions"| J["更新RAT限制并可能触发注册拒绝"]

    F -->|"/serviceAreaRestriction"| K["更新区域限制并向UE下发新区域"]

    F -->|"/subsRegTimer"| L["更新注册周期定时器"]

    G --> M["重新计算Allowed NSSAI"]

    M --> N["向UE下发新的Allowed NSSAI"]

    H --> N2["在后续会话中使用新的UE-AMBR"]

    I --> N3["通过N2接口向RAN下发新RFSP"]

    J --> N4["检查UE当前RAT是否违反新限制"]

    K --> N5["通过Registration Accept下发新区域"]

    L --> N6["向UE下发新的周期性注册定时器"]

    N --> RESP["返回204 No Content给UDM"]

    N2 --> RESP

    N3 --> RESP

    N4 --> RESP

    N5 --> RESP

    N6 --> RESP

    RESP --> DONE["通知处理完成"]

    style DONE fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px

    style LOG fill:#fff9c4,stroke:#f57f17

AMF对各类变更的处理策略：

变更路径	AMF处理动作	是否需要通知UE

`/nssai`	重新计算Allowed NSSAI，可能与NSSF交互	是，通过Configuration Update Command
`/subscribedUeAmbr`	更新本地缓存，在后续PDU会话中生效	否，在下次会话建立时自动应用
`/rfspIndex`	更新并通过N2接口下发给RAN	否，通过N2直接通知RAN
`/ratRestrictions`	检查UE当前RAT，可能触发去注册	是，如果当前RAT被禁止
`/serviceAreaRestriction`	更新允许/禁止区域列表	是，通过Configuration Update Command
`/subsRegTimer`	更新注册周期，在下次周期注册时生效	是，在后续Registration Accept中携带

协议参考：根据3GPP TS 29.503 第5.2.2.3节，AMF收到通知后应更新本地存储的签约数据，并根据变更内容决定是否需要执行进一步的操作（如触发Configuration Update、N2通知等）。具体行为在TS 23.502 第4.2.2.2.2节（Configuration Update）中定义。

2.4 【硬核附加】用curl模拟UDM向AMF发送变更通知

在实际工程调试中，我们可能需要手动模拟UDM向AMF发送签约数据变更通知，以验证AMF的通知处理逻辑是否正确。以下是一个完整的curl模拟命令：

curl模拟通知请求（AM-Data中S-NSSAI变更）：


curl -i -X POST http://10.XX.XX.XX:31382/namf-callback/v1/sdm-notification/imsi-460XX00000XXXX \

  -H "Content-Type: application/json" \

  -d &#x27;{

    "notifyItems": [

      {

        "resourceId": "am-data",

        "changes": [

          {

            "op": "REPLACE",

            "path": "/nssai",

            "value": {

              "singleNssais": [

                {

                  "sst": 1,

                  "sd": "000001"

                },

                {

                  "sst": 1,

                  "sd": "000002"

                },

                {

                  "sst": 4,

                  "sd": "000003"

                }

              ],

              "defaultSingleNssais": [

                {

                  "sst": 1,

                  "sd": "000001"

                }

              ]

            }

          }

        ]

      }

    ]

  }&#x27;

curl命令参数解析：

参数	值	说明

`-i`	-	在输出中包含HTTP响应头
`-X POST`	POST	HTTP方法为POST
URL	http://10.XX.XX.XX:31382/namf-callback/...	AMF的callbackReference地址
`Content-Type`	application/json	请求体为JSON格式

notifyItems结构详解：

层级	字段	值	说明

1	`notifyItems`	数组	包含一个或多个变更通知项
2	`resourceId`	"am-data"	变更的数据资源类型
2	`changes`	数组	包含一个或多个变更操作
3	`op`	"REPLACE"	操作类型为替换
3	`path`	"/nssai"	变更的JSON Pointer路径
3	`value`	新的nssai对象	替换后的完整数据

另一个场景：curl模拟UE-AMBR变更通知：


curl -i -X POST http://10.XX.XX.XX:31382/namf-callback/v1/sdm-notification/imsi-460XX00000XXXX \

  -H "Content-Type: application/json" \

  -d &#x27;{

    "notifyItems": [

      {

        "resourceId": "am-data",

        "changes": [

          {

            "op": "REPLACE",

            "path": "/subscribedUeAmbr",

            "value": {

              "uplink": "200000000",

              "downlink": "5000000000"

            }

          }

        ]

      }

    ]

  }&#x27;

上述curl命令模拟了运营商将用户的上行速率从123.457 Mbps提升到200 Mbps、下行速率从1.235 Gbps提升到5 Gbps的场景。AMF收到此通知后，会更新本地缓存的UE-AMBR值，并在后续PDU会话建立时使用新的速率上限。

AMF预期响应：


HTTP/1.1 204 No Content

Date: Thu, 16 Apr 2026 10:30:00 GMT

AMF返回204 No Content，表示通知已成功接收和处理。如果AMF返回错误状态码（如4xx或5xx），UDM应根据重试策略进行重新通知。

协议参考：根据3GPP TS 29.503 第5.2.2.3节，Nudm_SDM_Notification的请求体结构定义在SdmNotification数据类型中。每个notifyItem包含resourceId（必选）和changes（可选，类型为PatchResult数组）。changes中的每个元素遵循JSON Patch（RFC 6902）的PatchItem结构，包含op、path和value三个字段。

2.5 订阅与通知的完整生命周期

将SDM订阅和通知放在完整的生命周期中来看，整个过程涉及四个阶段：


flowchart LR

    subgraph 阶段1: 订阅建立

        A1["AMF完成注册"] --> A2["Nudm_SDM_Subscribe"]

        A2 --> A3["UDM保存callbackReference"]

    end

    subgraph 阶段2: 数据变更

        B1["BOSS修改签约数据"] --> B2["UDR更新数据"]

        B2 --> B3["UDR触发变更通知"]

    end

    subgraph 阶段3: 通知推送

        C1["UDM查找订阅记录"] --> C2["POST到callbackReference"]

        C2 --> C3["AMF返回204确认"]

    end

    subgraph 阶段4: 策略执行

        D1["AMF更新本地缓存"] --> D2["执行相应策略动作"]

        D2 --> D3["必要时通知UE/RAN"]

    end

    A3 -.->|"等待数据变更"| B1

    B3 -.->|"触发通知"| C1

    C3 -.->|"确认后执行"| D1

    style A2 fill:#e3f2fd,stroke:#1565c0,stroke-width:2px

    style B1 fill:#fce4ec,stroke:#c62828,stroke-width:2px

    style C2 fill:#fff3e0,stroke:#e65100,stroke-width:2px

    style D2 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

生命周期关键节点说明：

阶段	触发条件	关键信令	协议参考
1-订阅建立	AMF完成注册流程	Nudm_SDM_Subscribe (POST)	TS 29.503 5.2.2.2
2-数据变更	运营人员操作BOSS	UDR内部数据更新	TS 29.505 5.2
3-通知推送	UDR检测到数据变更	Nudm_SDM_Notification (POST)	TS 29.503 5.2.2.3
4-策略执行	AMF收到通知	Configuration Update / N2通知	TS 23.502 4.2.2.2

重要说明：如果AMF未事先通过Nudm_SDM_Subscribe订阅AM-Data变更通知，则UDM在数据变更时不会主动通知AMF。AMF只会在下次UE执行注册更新（周期性注册或移动性注册）时，重新通过Nudm_SDM_Get获取最新的签约数据。因此，SDM订阅是实时通知机制的前提条件。

2.6 多AMF场景下的通知处理

在实际网络中，一个用户可能因为移动而发生AMF切换。此时需要考虑：UDM应该将通知发给哪个AMF？


flowchart TD

    UDM_NOTIFY["UDM检测到AM-Data变更"] --> CHECK["查看当前UECM注册记录"]

    CHECK -->|"AMF-1是当前服务AMF"| SEND1["向AMF-1的callbackReference发送通知"]

    CHECK -->|"AMF-2是当前服务AMF"| SEND2["向AMF-2的callbackReference发送通知"]

    SEND1 --> ACK1["AMF-1返回204确认"]

    SEND2 --> ACK2["AMF-2返回204确认"]

    subgraph UECM注册记录

        REG["当前服务AMF: AMF-1<br/>callbackReference: http://10.XX.XX.XX/...<br/>subscriptionId: sub-XXXX"]

    end

    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

关键机制：UDM在发送通知时，使用的是UECM注册记录中当前服务AMF的callbackReference。当AMF发生切换时：

新AMF在注册流程中发起Nudm_SDM_Subscribe，UDM保存新的callbackReference；
UDM更新UECM记录，将当前服务AMF指向新AMF；
后续数据变更通知将发送到新AMF的callbackReference；
旧AMF的订阅记录在去注册时被清除。

协议参考：根据3GPP TS 29.503 第5.2.3节，当AMF发生切换时，新AMF会通过Nudm_UECM_Registration更新UDM中的服务AMF记录，并通过Nudm_SDM_Subscribe建立新的订阅。旧AMF在执行去注册后，其订阅记录将被删除。

3 测试结论

验证项	结果	说明
UDM发送变更通知	OK	UDM在检测到AM-Data变更后，主动向AMF的callbackReference发送POST通知
resourceId正确性	OK	notifyItems中resourceId为"am-data"，正确指向接入管理签约数据
变更操作正确性	OK	changes中op=REPLACE，path="/nssai"，正确描述了S-NSSAI切片变更
变更数据正确性	OK	新的nssai包含3个singleNssais和1个defaultSingleNssai，与BOSS修改后的数据一致
AMF确认通知	OK	AMF返回204 No Content，确认成功接收并处理通知
AMF本地数据更新	OK	AMF根据通知内容更新了本地缓存的AM-Data

本测试用例完美通过！当运营人员通过BOSS系统修改用户的接入和移动性管理签约数据（AM-Data中的S-NSSAI信息）后，UDM成功通过Nudm_SDM_Notification服务向AMF推送了数据变更通知。通知消息中的notifyItems正确包含了resourceId（am-data）和changes（REPLACE操作、/nssai路径、新的S-NSSAI数据），AMF正确接收并返回204 No Content确认。整个通知流程与3GPP TS 29.503规范完全吻合。

关键收获总结：

SDM订阅是通知的前提：AMF必须在注册流程中通过Nudm_SDM_Subscribe向UDM注册callbackReference，否则UDM不会在数据变更时主动通知AMF；
通知使用callback模式：UDM不是直接调用AMF的SBI服务，而是POST到AMF在订阅时提供的回调地址，这是一种典型的"发布-订阅"模式；
通知遵循JSON Patch规范：变更操作（op）和变更路径（path）遵循RFC 6902和RFC 6901规范，支持REPLACE、ADD、REMOVE三种操作类型；
AMF的响应式更新：AMF收到通知后不仅更新本地缓存，还会根据变更类型执行相应的策略动作（如重新计算Allowed NSSAI、更新RFSP等），确保网络行为与最新签约数据保持一致。

爱卫生 | 18年通信教学 · 4本专业书籍作者 · 51学通信创始人

想系统学5G核心网？知识星球等你来：200+小时视频 · 3000+精华文章 · 1年答疑群

公众号/知识星球：51学通信 | 微信：gprshome201101

本文为《5G核心网原理与实践》实践篇之UDM系列。该系列持续更新，关注「51学通信」不错过每篇更新。

5GC实践篇之UDM篇第21篇：签约数据改变通知AMF

5GC实践篇之UDM篇第21篇：签约数据改变通知AMF

1 测试背景与用例简介

通知机制的前置条件：AMF的SDM订阅

通知机制的数据流全景图

测试目的

测试前置条件

测试步骤

测试结果验证（预期）

2 信令深度解析

2.1 通知消息的触发与发送（Nudm_SDM_Notification）

2.2 notifyItems字段深度解读

2.2.1 resourceId（变更资源标识）

2.2.2 changes中的op（变更操作类型）

2.2.3 changes中的path（变更路径）

2.2.4 changes中的value（变更后的新值）

2.3 AMF对通知的处理逻辑

2.4 【硬核附加】用curl模拟UDM向AMF发送变更通知

2.5 订阅与通知的完整生命周期

2.6 多AMF场景下的通知处理

3 测试结论

查看完整内容