我们已经抵达了3GPP TS 29.673规范深度解读之旅的最终章。在前几篇文章中，我们已经完整地探索了UCMF的功能逻辑、API资源模型和交互流程。我们学会了如何指挥UCMF“查字典”、“造新词”、“办订阅”、“退订阅”以及接收“通知”。现在，我们将深入到API的“细胞”层面，对构成这一切交互的基石——数据模型（Data Model）——进行一次彻底的、精细的解剖。
深度解析 3GPP TS 29.673：6.1.6 Data Model (API数据模型)
本文技术原理深度参考了3GPP TS 29.673 V18.4.0 (2024-06) Release 18规范中，第六章“API Definitions”的6.1.6节“Data Model”。本文旨在为读者提供一份关于
Nucmf_UECapabilityManagementAPI所有核心JSON对象的“精装修”施工图，我们将逐一剖析每个数据结构的每一个字段，揭示其在UCMF信息交互中的精确含义和作用。
引言：从“蓝图”到“建材”——API的DNA解密
如果说API的资源和方法是建筑的“蓝图”，那么数据模型就是建造这座大厦所用的每一块“砖石”、每一根“钢筋”的详细规格说明书。没有对数据模型的精确理解，API的交互就如同鸡同鸭讲，无法实现。
第六章的6.1.6节，正是Nucmf_UECapabilityManagement API的“DNA图谱”。它定义了我们在之前所有流程中看到的那些JSON对象（如DicEntryData, CreateSubscription）的内部结构。对于软件工程师来说，这一节的内容将直接转化为他们代码中的类（Class）或结构体（Struct）。
我们将继续跟随主角小明和他功能不断进化的“智联-V1”手机的故事线，将这些看似抽象的数据结构，与真实的网络事件一一对应。我们将看到，当AMF为小明的手机分配ID时，它所构造的DicEntryCreateData对象里到底装了什么；当UCMF向AMF-B发送通知时，那个UcmfNotification对象的每一个字段又代表了什么。让我们开始这场对API“微观世界”的终极探索。
1. 解读第6.1.6.1章 General (数据模型总览)
本节为我们提供了数据模型的整体视图，将所有用到的数据类型分为两大类：本规范特有的和从其他规范复用的。
3GPP TS 29.673 - 6.1.6.1 General
This clause specifies the application data model supported by the API.
1.1 Nucmf_UECapabilityManagement 特有数据类型
Table 6.1.6.1-1: Nucmf_UECapabilityManagement specific Data Types 是本节的核心，它列出了所有由TS 29.673首次定义的数据类型。这些是我们本次解读的重点。
| Data type | Clause defined | Description |
|---|---|---|
| DicEntryData | 6.1.6.2.2 | A dictionary entry for a UE radio capability ID in the UCMF |
| DicEntryCreateData | 6.1.6.2.3 | Data for a creating a dictionary entry request |
| DicEntryCreatedData | 6.1.6.2.4 | Data for a creating a dictionary entry response |
| UeRadioCapId | 6.1.6.2.5 | UE Radio Capability ID |
| CreateSubscription | 6.1.6.2.6 | Data for a creating a subscription request |
| CreatedSubscription | 6.1.6.2.7 | Data for a creating a subscription response |
| UcmfNotification | 6.1.6.2.8 | Data for a notification request from a UCMF |
| ManAssOpRequestlist | 6.1.6.2.9 | Manufacturer Assigned operation requested list |
| EventType | 6.1.6.3.3 | |
| RacFormat | 6.1.6.3.4 | The encoding type of the UE’s Radio Access Capability Information |
这张表就像一本书的目录，清晰地指引我们去探索每一个核心数据对象的定义。
1.2 复用的通用数据类型
Table 6.1.6.1-2: Nucmf_UECapabilityManagement re-used Data Types 列出了从其他规范（主要是定义通用数据类型的TS 29.571）“借用”过来的数据类型。这体现了3GPP SBA设计的高度模块化和复用性。例如NfInstanceId, ProblemDetails等都是所有SBA接口通用的。
2. 解读第6.1.6.2章 Structured data types (结构化数据类型)
本节开始逐一详细定义Table 6.1.6.1-1中列出的每一个复杂JSON对象。
2.1 Type: DicEntryData - “字典词条”的完整形态
这是UCMF“字典”中一个完整“词条”的最终形态，是GET操作成功后返回的核心数据。
Table 6.1.6.2.2-1: Definition of type DicEntryData
| Attribute name | Data type | P | Cardinality | Description |
|---|---|---|---|---|
| dicEntryId | DicEntryId | C | 0..1 | Identifier of the Dictionary Entry. |
| plmnAssiUeRadioCapId | PlmnAssiUeRadioCapId | C | 0..1 | This IE shall include a PLMN Assigned UE Radio Capability ID if allocated… |
| manAssiUeRadioCapId | ManAssiUeRadioCapId | C | 0..1 | This IE shall include a Manufacturer Assigned UE Radio Capability ID if available… |
| typeAllocationCode | TypeAllocationCode | M | 1 | This IE shall contain the Type Allocation Code corresponding to the UE Radio Access Capability… |
| ueRadioCapability5GS | RefToBinaryData | C | 0..1 | …UE Radio Access Capability Information encoded as OCTET STRING… for 5G. |
| ueRadioCapabilityEPS | RefToBinaryData | C | 0..1 | …UE Radio Access Capability Information encoded as OCTET STRING… for EPS (4G). |
| ueRadioCap5GSForPag | RefToBinaryData | O | 0..1 | …UE Radio Access Capability Information for paging encoded… for 5G. |
| ueRadioCapEPSForPag | RefToBinaryData | O | 0..1 | …UE Radio Access Capability Information for paging encoded… for EPS (4G). |
字段深度剖析:
dicEntryId: 字典条目ID，即UCMF数据库的主键。这是一个条件性（Conditional）字段，因为在某些场景下（例如按ue-radio-capa-id查询时），这个内部ID可能不是关注的重点。plmnAssiUeRadioCapId/manAssiUeRadioCapId: PLMN分配的ID和制造商分配的ID。一个字典条目可以同时关联这两种ID。typeAllocationCode: TAC码，必须存在（Mandatory）。它将这份能力信息与具体的终端型号绑定。ueRadioCapability5GS/ueRadioCapabilityEPS: 这是最重要的能力信息载体。其数据类型是RefToBinaryData，这在JSON中通常是一个字符串，其值是multipart消息中二进制部分的Content-ID。这再次印证了我们之前对multipart机制的分析。ueRadioCap5GSForPag/ueRadioCapEPSForPag: 这是可选的（Optional）寻呼专用能力信息。这是一份简化版的能力信息，只包含网络在寻呼（Paging）UE时所必需知道的最少信息。通过使用这份更小的能力信息，可以进一步优化寻呼信令的开销。
场景链接：当AMF-B通过GET .../dic-entries?ue-radio-capa-id=PLMN-ID-XYZ成功查询到小明手机的能力后，它收到的HTTP响应体中，JSON部分就是一个完整的DicEntryData对象，而二进制部分则包含了ueRadioCapability5GS字段所引用的真实能力数据。
2.2 Type: DicEntryCreateData - “新词条”的申请表
这是Assign操作（POST /dic-entries）的请求体，是AMF向UCMF提交的“建档申请”。
Table 6.1.6.2.3-1: Definition of type DicEntryCreateData
| Attribute name | Data type | P | Cardinality | Description |
|---|---|---|---|---|
| typeAllocationCode | TypeAllocationCode | M | 1 | … |
| ueRadioCapability5GS | RefToBinaryData | C | 0..1 | … |
| ueRadioCapabilityEPS | RefToBinaryData | C | 0..1 | … |
| supportedFeatures | SupportedFeatu res | C | 0..1 | … |
| ueRadioCap5GSForPag | RefToBinaryData | O | 0..1 | … |
| ueRadioCapEPSForPag | RefToBinaryData | O | 0..1 | … |
与DicEntryData的对比分析:
- 少了什么？
DicEntryCreateData中没有dicEntryId和plmnAssiUeRadioCapId。这非常合理，因为dicEntryId是UCMF内部生成的，而plmnAssiUeRadioCapId正是这次请求想要获取的目标，它们都不应由客户端提供。 - 多了什么？
supportedFeatures字段，用于特性协商。 - NOTE: 表格的注释强调，
ueRadioCapability5GS和ueRadioCapabilityEPS至少要存在一个。AMF不能提交一个空的能力信息去申请ID。
场景链接：小明手机固件升级后，AMF-A构造的正是一个DicEntryCreateData对象。它将手机的TAC码填入typeAllocationCode字段，并将手机上报的5G和4G完整能力信息分别打包成二进制部分，再将它们的Content-ID填入ueRadioCapability5GS和ueRadioCapabilityEPS字段。
2.3 Type: DicEntryCreatedData - “新词条”的回执
这是Assign操作成功后（201 Created）的响应体，是UCMF给AMF的“受理回执”。
Table 6.1.6.2.4-1: Definition of type DicEntryCreatedData
| Attribute name | Data type | P | Cardinality | Description |
|---|---|---|---|---|
| plmnAssiUeRadioCapId | PlmnAssiUeRadioCapId | M | 1 | This IE shall include a PLMN Assigned UE Radio Capability ID if allocated. |
这个数据结构非常简洁，只包含一个必须存在的字段：plmnAssiUeRadioCapId。它的使命就是把新分配的（或已存在的）PLMN ID准确无误地返回给请求者。
2.4 Type: CreateSubscription & CreatedSubscription - “订阅”的申请与回执
-
CreateSubscription(POST /subscriptions的请求体):nfId(C): 订阅者的NF实例ID。ucmfNotificationUri(M): 回调地址，必须提供。suggestedExpires(O): 建议的过期时间。
-
CreatedSubscription(201 Created的响应体):dicEntryId(M): 当前最高的字典条目ID。UCMF在确认订阅时，会告诉订阅者当前字典的最新“水位线”，便于其进行初始同步。confirmedExpires(O): 最终确认的过期时间。
2.5 Type: UcmfNotification - “快递”包裹的内容
这是Notify操作（POST {ucmfNotificationUri}）的请求体，是UCMF派送的“信息简报”。
Table 6.1.6.2.8-1: Definition of type UcmfNotification
| Attribute name | Data type | P | Cardinality | Description |
|---|---|---|---|---|
| dicEntryId | DicEntryId | M | 1 | Highest DicEntryId that has been allocated OR the value 1… |
| eventType | EventType | M | 1 | Different events type included in the notification. |
| manAssOpRequestlist | ManAssOpRequestlist | C | 0..1 | …list of PLMN Assigned UE Radio Capability IDs or a list of TACs if the event type indicates the deletion… |
| versionId | Uinteger | O | 0..1 | …to notify a new version id of PLMN Assigned UE Radio Capability Id(s). |
| newDicEntries | array(DicEntryDa ta) | O | 1..N | List of dictionary entries that have newly been created… |
字段深度剖析:
dicEntryId/newDicEntries: 这两个字段互斥，实现了我们之前讨论的高效模式（只给ID）和豪华模式（给完整数据）两种通知策略。eventType: 必须提供，明确告知是创建、删除还是版本更新事件。manAssOpRequestlist: 当事件是“删除”时，这个结构体里会包含被删除的ID列表或TAC列表。versionId: 一个非常精巧的设计。运营商可能会对某些ID代表的能力信息进行微调或修正，此时，能力信息本身不变，但其“版本号”会增加。UCMF可以通过Notify消息，只通知版本号的变化，而无需重新传输整个能力信息，进一步优化了信令。
3. 解读第6.1.6.3章 Simple data types and enumerations (简单类型与枚举)
本节定义了一些基础的数据类型和枚举值。
EventType(枚举):"CREATION_OF_DICTIONARY_ENTRY""DELETION_OF_PLMN_ASSIGNED_IDS""NEW_VERSION_ID_OF_PLMN_ASSIGNED_IDs"
RacFormat(枚举):"5GS""EPS"
这些枚举值为JSON对象中的eventType和rac-format字段提供了标准的、受约束的取值，保证了协议的严谨性。
总结
通过对TS 29.673第六章6.1.6节数据模型的终极解剖，我们已经将Nucmf_UECapabilityManagement API的每一个“细胞”都观察得一清二楚。我们不再仅仅是理解API的宏观流程，而是精确掌握了其每一次交互中信息载体的具体构造。
-
结构化的信息设计: 每一个JSON对象都经过精心设计，其字段的增减、必选与可选，都精确地反映了其在特定操作（请求或响应）中的业务逻辑。例如，
DicEntryCreateData与DicEntryData的差异，就完美体现了“创建”与“呈现”两种意图的不同。 -
高度的模块化与复用: 通过复用通用数据类型（如
ProblemDetails），并定义清晰的本地数据类型，整个数据模型显得既统一又高效。 -
灵活的策略支持:
UcmfNotification的设计尤为出色，通过dicEntryId和newDicEntries的互斥使用，为UCMF的通知推送策略提供了极大的灵活性，允许运营商在效率和信息完整性之间进行权衡。
至此，我们对3GPP TS 29.673的深度解读系列已覆盖了其全部核心内容。从高层的功能愿景，到中层的API资源交互，再到底层的数据模型定义，我们已经构建了一个完整而立体的UCMF知识体系。希望这个系列的文章，能为您在理解和实践5G核心网技术的道路上，提供一份有价值的导航图。
FAQ
Q1：DicEntryData和DicEntryCreateData这两个数据结构非常相似，为什么不合并成一个？
A1：将它们分开是遵循了“接口隔离原则”和“最小化暴露”的设计思想。DicEntryCreateData是客户端（AMF）的输入，它只应包含客户端必须且能够提供的信息。而DicEntryData是服务器（UCMF）的输出，它代表了一个资源的完整状态，包含了服务器端生成的信息（如dicEntryId, plmnAssiUeRadioCapId）。将两者分开，使得API的契约更加清晰，避免了客户端填写不该填的字段，也避免了服务器暴露不必要的内部状态。
Q2：ueRadioCapability5GS等字段的数据类型为什么是RefToBinaryData，而不是直接就是一个包含二进制数据的字符串（例如Base64编码）？
A2：这是为了实现最高效的数据传输。RefToBinaryData本质上是一个引用或指针（在实现中是Content-ID字符串），它将JSON元数据与multipart消息中的二进制载荷分离开来。这样做的好处是：1）避免了Base64编码带来的约33%的性能开销。2）二进制数据可以保持其原始格式，并由其独立的Content-Type头来描述，处理更直接。3）保持了JSON部分的可读性和简洁性。
Q3：typeAllocationCode (TAC) 在DicEntryData中为什么是强制的（Mandatory）？
A3：将能力信息与TAC强制绑定，极大地提升了UCMF数据库的价值。它确保了每一份能力信息都能追溯到具体的设备型号。这对于运营商进行网络规划、故障排查和业务分析至关重要。例如，如果发现某个特定的能力组合导致了网络问题，运营商可以通过TAC快速定位到所有可能受影响的终端型号，并采取相应措施。
Q4：UcmfNotification中的versionId字段具体在什么场景下使用？
A4：versionId用于处理对已有能力信息的非结构性更新。想象一下，制造商发布了一个补丁，修复了其RRC协议实现中的一个小bug，这个修复可能不会改变UE支持的频段、MIMO等宏观能力，但能力信息的二进制内容确实发生了微小的变化。此时，UCMF可以不分配新的ID，而是在原有ID的基础上，将其versionId加一。然后，UCMF可以发送一个eventType为NEW_VERSION_ID_OF_PLMN_ASSIGNED_IDs的通知，只告诉AMF：“ID为XYZ的能力信息现在有新版本了”。AMF收到后，就会在下次遇到使用该ID的UE时，重新向UCMF Resolve一次，获取最新版本的二进制数据。这比删除旧ID、创建新ID的开销要小得多。
Q5：UcmfNotification中的newDicEntries数组可以包含多个DicEntryData对象吗？
A5：是的，它的基数（Cardinality）是1..N，意味着可以包含一个或多个。这允许UCMF将短时间内发生的多个字典创建事件进行“批处理”，合并到一次Notify消息中发送出去。例如，在网络高峰期，瞬间有10个新能力被Assign，UCMF可以选择将这10个新条目的完整数据打包在一个newDicEntries数组里，通过一次POST请求就通知给订阅者，这比连续发送10次Notify请求要高效得多。