51学通信

深度解析 3GPP TR 23.700-28：6.22 信息的管道 (5GS与EPS中的覆盖数据传输)

24分钟阅读

深度解析 3GPP TR 23.700-28：6.22 信息的管道 (5GS与EPS中的覆盖数据传输)

本文技术原理深度参考了3GPP TR 23.700-28 V18.1.0 (2023-03) Release 18规范中, 关于“第六章 Solutions”的 6.22 节 “Solution #22: Coverage data transfer in 5GS and EPS” 的核心章节, 旨在为读者深度剖析一种借鉴现有成熟框架（UUAA）、为“覆盖数据”这一关键情报, 搭建一条贯穿UE、核心网与外部服务器的安全、高效“信息管道”的架构性解决方案。

在上一篇文章中, 我们见证了Solution 21如何将NWDAF这个“AI大脑”引入NTN决策闭环, 实现了基于“置信度”的智能功耗协商, 将系统的“智慧”提升到了新高度。然而, 无论是UE的自主计算、AMF的策略制定, 还是NWDAF的深度分析, 所有这些上层“智慧”的施展, 都离不开一个最根本的“食粮”——覆盖数据。

我们已经探讨过多种“使用”和“分析”数据的方法, Solution 15也为我们描绘了“提供”数据服务的三条路径。但这些探讨, 或多或少都还停留在“逻辑”层面。当我们需要将一份结构复杂、数据量可能不小的“覆盖地图”, 从一个远端的商业服务器, 安全、可靠地传输到一个野外的UE手中时, 我们需要面对的是一个更具体、更工程化的问题：这条“信息管道”本身, 该如何设计和构建？

这, 正是Solution #22——“5GS和EPS中的覆盖数据传输”——所要解决的核心问题。它不再聚焦于“数据的内容”是什么, 而是专注于“数据该如何流转”。它没有从零开始发明轮子, 而是巧妙地借鉴了3GPP为无人机（UAV）通信设计的、一套已经非常成熟的“身份认证与授权”框架, 为“覆盖数据”的端到端传输, 铺设了一条坚固的“管道”。

为了演绎这条“管道”的构建过程, 我们的主角将切换为一家名为“全球测绘”（GeoMapping Inc.）的商业公司。这家公司运营着一个庞大的“覆盖地图服务器”（CMS, Coverage Map Server）, 里面存储着全球最高精度的卫星覆盖预测数据。伊芙琳博士所在的科研机构, 向这家公司购买了服务, 希望能将这些数据, 安全地推送到她部署在雨林中的所有固定传感器上, 以便它们能够自主规划最优的休眠与唤醒策略。

1. 核心哲学：他山之石, 可以攻玉 (解读 6.22.1 Description)

Solution 22的哲学根基, 再次体现了3GPP标准化工作中的一种高效智慧——“借鉴与重塑”。

6.22.1 Description

This solution addresses several objectives in KI#1 and KI#2 which need provision of coverage data of NR/E-UTRAN satellite access with discontinuous coverage to UE and CN. The logical system architecture and coverage data transfer procedure in this solution is designed by re-using architecture and procedures for UUAA (USS UAV Authentication & Authorization) described in TS 23.256, and no new EPC interface needs to be defined.

这段描述是整个方案的“设计说明书”, 它清晰地阐明了其核心思想：

  • 灵感来源：UUAA框架（TS 23.256）。 UUAA是3GPP为无人机（UAV）接入移动网络而设计的一套专用认证与授权框架。它的核心, 是解决一个类似的问题：一个无人机, 如何向一个外部的、第三方的“无人机交通管理系统”（USS/UTM）证明自己的身份, 并获得在该空域飞行的授权？
  • 借鉴的精髓： Solution 22的专家们敏锐地发现, “UE向外部CMS请求覆盖数据” 和 “无人机向外部USS请求飞行授权”, 这两个场景在逻辑架构和信任模型上, 具有惊人的相似性：
    • 都有一个“终端”（UE/UAV）。
    • 都有一个“移动核心网”（5GC/EPC）。
    • 都有一个“外部第三方权威服务器”（CMS/USS）。
    • 核心需求都是：在核心网的“见证”和“协助”下, 实现终端与外部服务器之间一次安全、可信的认证与数据交换。
  • 最大的优点： 通过重用UUAA, 方案得以继承一套已经非常成熟、经过充分安全论证的架构和流程, 从而避免了重新发明一套复杂的认证和传输机制。特别是对于EPS（4G核心网）, 它明确指出“无需定义新的接口”, 这极大地降低了对现网改造的要求。

Figure 6.22.1-1: 5GS and EPS architecture for coverage data transfer 为我们展示了这套借鉴而来的“信息管道”架构图。

  • 核心角色：
    • CMS (Coverage Map Server): 扮演着UUAA中USS的角色, 是数据的最终源头。它部署在DN（数据网络）中, 是一个外部服务器。
    • CM NF (Coverage Map transfer NF): 扮演着UUAA中CAA-NF的角色, 是核心网与外部服务器之间的“安全网关”和“翻译官”。它通常与NEF（网络曝露功能）部署在一起。
    • UE & CN (AMF/SMF): 扮演着请求的发起方和流程的驱动方。

2. 操作流程：一场需要“双重认证”的数据之旅

Solution 22为我们展示了“覆盖数据”在UE注册和PDU会话建立这两个最关键的流程中, 是如何完成其“端到端”之旅的。其核心, 是一场严谨的、需要“双重认证”的流程。

2.1 流程一：在注册时获取“全局地图” (Coverage data transfer at 5GS Registration)

Figure 6.22.2-1: Coverage data transfer at 5GS Registration procedure 详细描绘了UE在“入网”时, 如何顺便获取一份“覆盖地图”的全过程。

场景复现：“全球测绘”公司的数据服务

  1. 步骤 1: UE的“带参请求”

    1. The UE sends a Registration request message including CMT ID, CMT Data Container (coverage data request), and optionally CMS address. 伊芙琳的一个雨林传感器开机, 发起初始注册。在Registration Request中, 它附带了三个特殊的新“参数”：

    • CMT ID (Coverage Map Transfer ID): 这是UE用于获取覆盖数据的“专属ID”, 由“全球测绘”公司分配, 类似于一个“服务账号”。
    • CMT Data Container: 这是一个数据容器, 里面封装了UE本次的“数据请求”, 例如：“我需要以‘生态站阿尔法’为中心、半径50公里范围、未来48小时的覆盖地图, 精度要求为1公里。”
    • CMS address (可选): “全球测绘”服务器的地址（如FQDN）。

  2. 步骤 2 & 3: 核心网的“常规体检” AMF首先执行标准的网络侧认证（Primary Authentication）, 确认这个传感器是合法的移动网络用户。然后从UDM获取其签约数据。

  3. 步骤 4 & 6: 触发“增值服务认证”

    4. AMF determines whether additional authentication is required for the UE with CMT ID. 6. If AMF determined additional authentication… is required…, the AMF invokes Nnef_Authentication_AuthenticateAuthorize Request message… AMF在UE的签约数据中, 发现它订阅了“第三方覆盖数据服务”。于是, AMF决定, 需要为这项“增值服务”, 启动一次额外的、专门的认证。AMF扮演“中间人”, 通过CM NF（NEF）, 向外部的CMS, 发起了一次“认证与授权”请求。

  4. 步骤 7 & 8: CMS的“客户身份核实”

    7. CM NF /NEF invokes Naf_Authentication_AuthenticateAuthorize Request message… 8. Authentication for Coverage Map Transfer is performed by the CMS. 请求最终到达“全球测绘”的CMS。CMS收到了UE的CMT ID后, 开始在自己的“客户数据库”中进行核实：“这个CMT ID是否是我司的有效客户？它是否有权请求这个区域的地图？” 这是一个应用层的、独立于移动网络认证的第二次认证。

  5. 步骤 9-11: 数据的“安全回传”

    9. CMS sends Naf_Authentication_AuthenticateAuthorize Response message, include: … and CMT Data (coverage data) which is requested. CMS确认客户身份无误后, 便生成UE所请求的“覆盖地图”数据。这份数据沿着一条安全的响应路径, 逐级返回：CMS → CM NF → AMF。

  6. 步骤 12-15: 地图的“最终交付”

    12. AMF stores the CMT Data (coverage data), and utilizes it in corresponding procedures (e.g. paging, de-registration). 14. AMF triggers a UE Configuration Update procedure to deliver to the UE the CMT Data Container (coverage data).

    • AMF的“双重利用”： AMF收到地图后, 做了两件事。首先, 它自己**“备份”**了一份, 存在UE的上下文中。这份“备份”将来可以被AMF自己用来优化寻呼（例如, 在地图显示的无覆盖时段, 主动抑制寻呼）。
    • UE的“最终签收”： AMF通过UE Configuration Update流程, 将这份“覆盖地图”, 正式交付给了雨林传感器。传感器收到后, 便可以据此规划自己的“人生”了。

2.2 流程二：在会话建立时获取“业务地图”

Figure 6.22.2-2: Coverage data transfer at 5GS PDU Session Establishment procedure 展示了类似的流程。其核心区别在于, 请求的发起方和驱动方, 从AMF（负责移动性）变为了SMF（负责会话管理）。

  • 触发场景： UE可能需要为某项特定的业务（例如, 一次高清视频回传）, 获取一份专属的、高精度的“业务覆盖地图”。这个请求, 就会在建立该业务的PDU会话时被发起。
  • 流程驱动者： SMF。因为它才是管理PDU会话的“总管”。整个认证和数据获取的流程, 将由SMF来驱动, AMF在其中只扮演一个“信使”的角色。
  • 最终结果： “覆盖地图”同样会被交付给UE, 并由SMF进行“备份”, 以便未来根据这份地图, 对该PDU会话的QoS策略等进行优化（例如, 在预测到信号即将变差时, 主动降低视频流的码率）。

3. 系统影响分析：一次职责清晰的架构演进 (解读 6.22.3 Impacts)

UE:

  • The UE includes GPSI, CMT ID, CMT Data Container … in Registration request…
  • The UE stores and process the reived coverage data…

UE的影响： 成为**“服务的申请与消费者”**。它需要能够在NAS信令中, 封装和发起覆盖数据的请求, 并能够解析和使用网络返回的数据。

AMF:

  • The AMF determines whether the addition authentication for coverage map transfer to the UE with CMT ID, and triggers the coverage map transfer procedure.
  • The AMF receives coverage data from CM NF… and takes utilizes coverage data in corresponding procedures…

AMF的影响： 扮演**“移动性服务的认证网关与数据使用者”**。它负责在注册流程中, 触发对覆盖数据服务的认证, 并将获取到的数据, 用于优化其自身的移动性管理功能（如寻呼）。

SMF (and SMF+PGW-C):

  • The SMF determines whether the addition authentication for coverage map transfer to the UE with CMT ID, and triggers the coverage map transfer procedure.
  • The SMF receives coverage data from CM NF… and takes utilizes coverage data in corresponding procedures…

SMF的影响： 扮演**“会话服务的认证网关与数据使用者”**。它在PDU会话流程中, 扮演着与AMF在注册流程中类似的角色, 并将数据用于优化会话管理。

CM NF/NEF:

  • The CM NF selects CMS based on CMS address provided by the UE, or CMT ID.
  • The CM NF translate and modify the coverage data request from UE to obtain precise coverage data from CMS.

CM NF/NEF的影响： 成为**“智能翻译与安全代理”**。它不仅是安全网关, 还可能需要扮演“翻译官”的角色, 将UE上报的Cell ID或TAI, 转换为CMS能够理解的地理坐标, 从而实现“跨界对话”。

4. 方案评估：成熟框架下的可靠传承 (解读 6.22.4 Solution evaluation)

6.22.4 Solution evaluation

This solution provides the logical architecture and several procedures for transfer coverage data to the UE and the Core Network. The procedures in clause 6.22.2 have the following benefits:

  • Both UE using NR satellite access and E-UTRAN satellite access can receive the coverage data in consistent way.
  • AMF, MME, SMF are not required to process the coverage data. Any type or format of coverage data can be provided to the UE.
  • CM NF as NEF handles the coverage data request and coverage data, so the existing service operations… can be re-used.

评估部分高度肯定了本方案的一致性、透明性和可重用性。

  • 优点：
    1. 一致的体验： 无论UE是5G NR还是4G E-UTRAN, 都能通过同样一套逻辑来获取数据。
    2. 核心网“透明”： AMF/MME/SMF只负责驱动流程和透传数据容器, 它们无需理解“覆盖地图”的具体格式。这份地图可以是网格、多边形、甚至是一种私有格式, 这为未来的技术演进, 提供了极大的灵活性。
    3. 重用服务： 方案完美地重用了5GC/EPC中现有的认证服务框架, 降低了标准化的复杂度和实现成本。

总结：为“信息”修建的“高速公路”

Solution 22以其“借鉴与重塑”的工程智慧, 为我们展示了在复杂的5G生态系统中, 如何为一种全新的“货物”（覆盖数据）, 快速、安全、经济地修建一条贯穿各方的“物流高速公路”。它没有去重新设计复杂的收费站（认证）和运输车队（协议）, 而是巧妙地将为“无人机”修建的那条成熟的高速公路, 稍加改造, 便成功地服务于“覆盖数据”的运输。

“全球测绘”公司的故事告诉我们, 5G NTN的生态系统, 是一个开放的、鼓励专业分工的平台。它为像CMS这样的第三方“增值服务提供商”, 提供了标准化的、安全的“入场券”。

至此, 我们已经检阅了TR 23.700-28中几乎所有关键的、具有里程碑意义的解决方案。我们已经拥有了管理功耗的“休眠术”, 应对拥塞的“疏导术”, 精准寻呼的“制导术”, 以及获取信息的“情报术”。

然而, 在我们结束这场波澜壮阔的技术巡礼之前, 还有一个看似微小、却不容忽视的问题。在所有这些复杂的流程背后, UE发起通信的“第一步”——随机接入——在非连续覆盖的严酷环境下, 它自身是否也需要一些特殊的“行为准则”？如果一个UE明知没有信号, 它是否应该从根本上就抑制自己去“敲门”的冲动？

这, 正是我们将要在下一篇、也是本系列对TR 23.700-28解决方案的最后一篇分析中, 探讨的Solution #23——“对UE尝试连接模式的处理”。一场关于“源头治理”的最终思考, 即将上演。

FAQ

Q1：UUAA框架到底是做什么的？为什么它和覆盖数据传输有共通之处？ A1：UUAA (USS UAV Authentication & Authorization) 是为无人机（UAV）设计的。它的核心是让一个UAV, 通过移动核心网, 向一个外部的无人机交通管理系统（USS）进行认证和授权, 以获取飞行许可。它与覆盖数据传输的共通之处在于信任模型：终端（UAV/UE）自己无法直接与权威的外部服务器（USS/CMS）建立信任关系。移动核心网（CN）在其中扮演了**“信任中介”**的角色。CN首先认证终端是其合法用户, 然后再“背书”终端的身份, 协助它与外部服务器完成第二次的应用层认证。正是这个“CN作为信任中介”的核心架构, 使得UUAA框架可以被完美地“移植”过来。

Q2：这个方案中的“双重认证”是否会让流程变得很慢？ A2：认证流程确实会增加初始接入的时延, 但这是为了安全而付出的必要代价。覆盖地图是具有高商业价值的敏感数据, 必须确保只有经过授权的用户才能获取。好消息是, 这种“双重认证”通常只需要在UE首次注册或会话建立时执行一次。一旦认证成功, 核心网和UE可能会缓存相应的安全上下文或“令牌”, 在后续的短期交互中, 可以免除或简化认证流程, 从而加快数据获取的速度。

Q3：为什么AMF/SMF无需理解“覆盖地图”的格式, 这一点很重要？ A3：这一点至关重要, 它体现了**“分层与解耦”的架构设计思想。覆盖地图的格式, 未来可能会随着技术的发展而不断演进（例如, 从二维地图变为三维地图, 增加信号质量预测等）。如果要求AMF/SMF去解析每一种格式, 那么核心网的软件将变得异常臃肿, 且每次地图格式更新, 都需要对核心网进行一次大规模的升级。而通过将地图数据封装在一个“不透明”的CMT Data Container中, AMF/SMF只负责“搬运”这个“集装箱”, 而无需关心里面装的是什么。真正的解析工作, 只发生在“发货方”（CMS）和“收货方”（UE）这两端。这使得核心网的协议保持了极大的稳定性和前向兼容性**。

Q4：这个方案和Solution 15中提出的三种路径是什么关系？ A4：Solution 22可以被看作是对Solution 15中“路径A（授权查询）”和“路径B（官方渠道）”的一次深度、工程化的实现方案。Solution 15在逻辑上提出了“可以向外部服务器查”或“可以向AMF要”的思路, 但没有详细说明“如何安全地查”和“如何可靠地要”。Solution 22则通过借鉴UUAA框架, 为这两个逻辑路径, 提供了具体、标准、安全的流程实现。它明确了CM NF的角色, 定义了双重认证的步骤, 使得Solution 15的构想, 真正具备了可落地、可标准化的能力。

Q5：这个方案对EPS（4G核心网）的支持有多好？ A5：非常好, 这是该方案的一大亮点。评估部分明确指出“no new EPC interface needs to be defined”。这是因为UUAA框架本身在设计时, 就同时考虑了5GS和EPS的架构。它在EPS中的实现, 主要是通过扩展现有的S6a（MME-HSS）、SGi（PGW-DN）等接口上的信令参数, 以及利用PCO（Protocol Configuration Options）在UE和PGW之间透传应用层数据来完成的。这意味着, 运营商可以通过对现有EPC网元进行软件升级的方式, 来支持这套流程, 而无需进行颠覆性的硬件替换或接口改造, 保护了现有投资。

关系图谱