51学通信

深度解析 3GPP TS 23.273：6.14 广播辅助数据流程：为海量终端秒级定位赋能

20分钟阅读

深度解析 3GPP TS 23.273：6.14 广播辅助数据流程：为海量终端秒级定位赋能

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.14 Procedures for Broadcast of Assistance Data”的核心章节，包括其两个紧密耦合的子章节6.14.1和6.14.2。本文旨在通过一场大型城市马拉松的真实应用场景，为读者揭示5G网络如何从“一对一”的单播辅助，进化到“一对多”的广播辅助，并如何通过加密机制，将其打造为一种安全、可运营的增值服务。

1. 序章：马拉松起跑线上的“搜星之战”

在之前的篇章中，我们探讨的定位服务大多是“按需响应”式的：一个UE需要定位，网络便为其启动一次服务。然而，当场景切换到成千上万个UE在同一时间、同一地点、有着完全相同需求的“并发请求风暴”时，传统的“一对一”模式便显得力不从心。

今天，我们的故事，就发生在一场国际顶级城市马拉松的起跑线上。数万名跑者聚集在狭长的起跑区，蓄势待发。我们的主角是业余精英跑者“小驰”，他的手腕上佩戴着一款专业的5G运动手表——“Speedster-5G”。这款手表的核心卖点之一，就是能在比赛开始的瞬间，实现亚米级的实时精准定位，为小驰提供最精确的配速和路线导航。

赛事官方的“智慧马拉松”App后台（扮演LCS客户端/AF）也面临着巨大的挑战：它需要在发令枪响的瞬间，同时获取数万名选手的初始位置，以便在直播画面上实时渲染出每个人的动态位置。

问题来了：数万块手表同时开机，同时请求GNSS辅助数据以加速定位。如果网络对每一块手表都进行一次“一对一”的单播（Unicast）辅助数据下发，一场灾难性的信令风暴将不可避免。这会堵塞控制面信道，导致大多数手表无法及时获取辅助数据，在起跑后的关键几分钟内都处于“搜星”状态，无法定位。

为了化解这场“搜星之战”，3GPP在6.14章节中，设计了一套极其高效的解决方案——广播辅助数据（Broadcast of Assistance Data）。它将网络的服务模式，从“挨个打电话”，升级为了“打开全城广播”。

2. 网络的“全城广播”：LMF发起的数据广播流程 (6.14.1)

6.14.1章节的核心，是定义了由谁（LMF）、广播什么（辅助数据）、以及如何通过网络将广播内容送达“发射塔”（基站）的流程。

The following procedure is used by the LMF to support broadcasting of network assistance data to target UEs. This procedure is not associated with a UE location session.

规范开篇点明，这个流程与任何特定的UE会话无关。它是一种“对空广播”，服务的是一个地理区域，而非单个用户。

“Figure 6.14.1-1: Broadcasting Network Assistance Data”为我们描绘了这场“广播”的幕后准备工作。

2.1 第一步：LMF的“节目”制作与排期

  1. The LMF invokes the Namf_Communication_NonUeN2MessageTransfer service operation towards the AMF to request the transfer of a Network Assistance Data message to an NG-RAN node… The service operation includes the Network Assistance Data message and the target NG-RAN node identity.

在马拉松比赛开始前，赛事组织方（通过“智慧马拉松”App后台）已经与运营商协商，决定在起跑区启动GNSS辅助数据广播。

  1. LMF收集“节目素材”：LMF（定位管理功能）作为“节目制作人”，首先需要获取最新的GNSS辅助数据。这些数据可能来自其自建的GNSS参考网络，或从专业的第三方数据提供商（AF）那里获取（如6.15章节所定义）。这些“素材”主要包括：

    • 卫星星历和时钟修正：告知手表每颗卫星的精确轨道和时间偏差。
    • 差分修正数据（DGNSS/RTK）：对于需要亚米级精度的“Speedster-5G”，这是最关键的数据，用于消除大气层等因素造成的定位误差。
    • 电离层模型：帮助手表更好地估算信号延迟。

  2. LMF制作“广播节目”：LMF将这些素材打包成一个“网络辅助数据（Network Assistance Data）”消息。

  3. LMF制定“播放列表”：LMF确定这个“节目”需要在哪些“发射塔”（基站）播出。它会根据马拉松起跑区的地理范围，将其映射为一个目标基站列表（target NG-RAN node identity list）。

2.2 第二至第五步：从“制作中心”到“发射塔”

  1. The AMF forwards the Network Assistance Data message to the target NG-RAN node…
  2. The NG-RAN node broadcasts the assistance data…
  3. The target NG-RAN node may return feedback…
  4. The AMF invokes the Namf_Communication_NonUeN2InfoNotify service operation towards the LMF…

  1. LMF → AMF (Step 1)：LMF将打包好的“广播节目”和“播放列表”，通过NonUeN2MessageTransfer服务，交给AMF。这是一个非UE关联的请求，因为它的目标是基站，而非UE。

  2. AMF → NG-RAN (Step 2)：AMF扮演了“发行总监”的角色。它根据“播放列表”，将“广播节目”通过N2接口，精准地分发给每一个被指定的基站。

  3. NG-RAN的“开播” (Step 3)：覆盖起跑区的基站们，在收到“节目”后，便通过特定的系统广播信道（如 SIBs - System Information Blocks），将这些辅助数据源源不断地向其覆盖范围内的所有UE进行广播。

  4. 闭环反馈 (Steps 4 & 5)：基站可能会向AMF报告广播的执行情况（例如，“数据已成功播出”）。AMF再将这些反馈信息汇总，通知给LMF。这确保了LMF作为“节目制作人”，对整个播出流程是可知、可控的。

至此，起跑区上空的电波中，已经充满了能让GNSS设备“耳聪目明”的辅助信息。小驰的“Speedster-5G”手表只要开机，就能“收听”到这个广播。但故事还有一个关键环节。

3. “VIP通行证”：加密广播与密钥分发 (6.14.2)

赛事组织方与运营商合作，将最高精度的RTK差分修正数据，作为一项增值服务，只提供给购买了“精英选手包”的跑者。这意味着，这部分最关键的辅助数据，在广播时必须是加密的（ciphered）。小驰购买了该服务包，他的“Speedster-5G”如何获取解密的“钥匙”？

6.14.2章节正是为这种安全、可运营的广播模式，设计了一套精妙的密钥分发流程。

The following procedure is used by the LMF and the AMF to distribute ciphering keys to UEs to enable UEs to decipher broadcast assistance data that was ciphered by the LMF.

“Figure 6.14.2-1: Delivery of Ciphering Keys to UEs for Broadcast Assistance Data”为我们揭示了这场“秘密握手”的全过程。

3.1 第一、二步：LMF“制钥”，AMF“掌钥”

  1. The LMF invokes the Nlmf_Broadcast_CipheringKeyData Notify service operation towards the AMF carrying one or more ciphering keys…
  2. The AMF stores the ciphering keys…

  1. LMF生成密钥 (Step 1)：LMF作为加密方，首先会生成用于加密广播数据的密钥。一个密钥不仅有密钥值，还有一系列“说明书”：

    • 密钥ID：用于区分不同的密钥。
    • 有效周期：例如，此密钥仅在比赛日的6:00至14:00有效。
    • 适用区域：此密钥仅适用于马拉松赛道沿线的跟踪区（TA list）。
    • 适用数据类型：此密钥仅用于解密“RTK差分修正数据”。

    LMF将这些密钥及其“说明书”，通过Nlmf_Broadcast_CipheringKeyData Notify服务，提前发送给AMF。

  2. AMF存储密钥 (Step 2)：AMF收到密钥后，并不立即分发，而是将它们安全地存储起来，成为了“密钥的保管者”。它会等待一个合适的时机——等待有合法资格的UE前来“领取”。

3.2 第三至第七步：“注册”即“领钥”

  1. A UE sends a Registration Request to a RAN node. … The UE includes in the Registration Request an indication that ciphering keys are requested.
  2. The AMF returns a Registration Accept to the RAN node… If the UE is subscribed to receive ciphered broadcast data, the AMF includes in the Registration Accept one or more ciphering keys…

这是整个流程的点睛之笔。密钥的分发，被巧妙地嵌入到了UE最基础、最常规的网络操作——**注册（Registration）**流程中。

  1. 小驰开机，手表“报到” (Step 3)：比赛前，小驰到达起跑区，打开了他的“Speedster-5G”手表。手表开机后，第一件事就是向网络发起注册请求。

    • 关键的“申请”：由于“Speedster-5G”被设计为支持高级定位服务，它会在Registration Request消息中，主动包含一个指示：“我需要解密广播数据的密钥！”

  2. AMF的“审查与批准” (Step 6)：AMF收到了来自小驰手表的注册请求。它开始了一系列严格的审查：

    • 审查地点：AMF发现手表当前的跟踪区（TA），在LMF之前下发的密钥“适用区域”列表内。
    • 审查需求：AMF看到了手表请求中“需要密钥”的标志。
    • 审查资格：最关键的一步，AMF会查询UDM，检查小驰的签约数据。它发现，小驰的“精英选手包”签约中，包含了“允许接收广播定位密钥”的授权。
    • 批准下发：三项审查全部通过！AMF在即将发送给手表的Registration Accept（注册接受）消息中，将那把有效期内、适用于当前区域的RTK数据解密密钥，**“顺便”**放了进去。

  3. 手表“领钥” (Step 7)：手表收到Registration Accept消息，成功在网络中注册。同时，它从中提取出密钥，并安全地存储起来。

3.3 珠联璧合：解密与定位

现在，所有的拼图都已到位：

  • 小驰的“Speedster-5G”正在通过广播信道，接收着被加密的、最高精度的RTK差分修正数据（来自6.14.1流程）。
  • 同时，它的“口袋”里，已经有了一把刚刚通过注册流程领取的、合法有效的解密密钥（来自6.14.2流程）。

手表立即使用密钥解密了广播数据，并将其送入GNSS定位引擎。几乎在发令枪响的瞬间，屏幕上便显示出了一个带有“亚米级精度”标记的、极其稳定的定位点。

4. 总结：可运营的、可扩展的定位赋能平台

6.14章节所定义的广播辅助数据流程，其意义远不止于解决信令风暴。它为5G定位服务，构建了一个可运营、可扩展、安全可靠的“广域赋能平台”。

  • 极致的可扩展性：通过将“一对一”的单播，升级为“一对多”的广播，从根本上解决了大规模并发定位请求带来的信令瓶颈。一个区域内，无论是一个UE还是一百万个UE，网络的广播信令开销都是恒定的。
  • 安全可运营的商业模式：通过引入加密广播和基于签约的密钥分发机制，运营商可以将高精度的辅助数据（如RTK），打包成一种可销售的增值服务。这为运营商开辟了新的商业模式，也为需要高精度定位的垂直行业（如自动驾驶、测绘、精准农业）提供了标准化的解决方案。
  • 与核心流程的无缝集成：将密钥的分发，巧妙地融入到最基础的UE注册流程中，最大限度地减少了额外的信令交互，实现了“润物细无声”般的用户体验。

对于小驰和数万名跑者，这套流程意味着更专业、更精准的赛事体验。而对于5G网络本身，这标志着它已不再仅仅是一个通信管道，更是一个能够向广阔世界“广播”其核心能力（如高精度定位）的、真正的赋能平台。

FAQ - 常见问题解答

Q1：广播辅助数据是不是意味着所有UE都能免费收到？ A1：不一定。这取决于运营商的策略。运营商可以：1) 广播未加密的基础辅助数据（如卫星星历），所有UE都可以接收和使用，以提升普遍的定位体验。2) 同时广播加密的高级辅助数据（如RTK差分修正），只有付费订阅、并成功获取到密钥的UE才能解密和使用。6.14章节的设计，为这种差异化、分层级的服务提供了完美的框架。

Q2：除了注册流程，UE还有其他方式获取密钥吗？ A2：是的。规范在6.14.2的NOTE 2中提到，UE的注册请求可能是由多种原因触发的。例如：

  • 周期性注册：UE为了向网络“报平安”，会定期发起注册。如果它发现自己存储的密钥即将过期，就可以利用这次机会，重新请求新的密钥。
  • 移动性注册：当UE移动到一个新的跟踪区（TA），并发起TA更新时，如果旧的密钥不适用于新区域，它也会在Registration Request中请求适用于新区域的密钥。 这确保了UE总能拥有与其当前位置和时间相匹配的有效密钥。

Q3：UE是如何知道该去哪个广播信道“收听”辅助数据的？ A3：这个信息是由**RAN（基站）**来管理的。基站会在其常规的系统信息（System Information Blocks, SIBs）中，广播关于“LCS辅助数据广播”的调度信息。这些信息会告诉UE：“在某某信道、某某时间，我会广播定位辅助数据，请有需要的同学准时收听。” UE的协议栈在解析了这些SIB后，便知道去哪里接收数据了。

Q4：为什么密钥的分发是由AMF而不是LMF来完成？ A4：这是一个职责划分清晰的架构设计。LMF是“定位专家”和“数据生产者”，它负责生成定位数据和用于加密的密钥，但它不直接管理UE的身份、签约和会话。AMF是“UE管家”和“策略执行点”，它负责处理UE的注册、鉴权，并能够访问UDM获取UE的签约信息。因此，由AMF来“掌管”密钥，并在注册时根据UE的“资格”进行分发，是最高效、最安全的选择。

Q5：这个广播流程，对于UE的功耗有何影响？ A5：极大地降低了功耗。相比单播，UE无需为了获取辅助数据而发起一次完整的“请求-响应”信令交互。它只需要在大部分时间里，像收听FM广播一样，被动地接收广播信道的数据即可。接收（listening）的功耗，远低于发射（transmitting）的功耗。对于需要长期、周期性获取辅助数据的物联网设备，这种模式的节能效果极为显著。

关系图谱