51学通信

深度解析 3GPP TS 23.273：6.20 测距侧行链路定位(Part 2 - 指挥官视角下的协同作战)

18分钟阅读

深度解析 3GPP TS 23.273：6.20 测距/侧行链路定位(Part 2 - 指挥官视角下的协同作战)

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.20.3 Procedures of SL-MT-LR involving LMF”和“6.20.4 Procedures of SL-MT-LR for periodic, triggered Location Events”的核心章节。本文将作为Sidelink定位系列的第二部分，通过一个未来感十足的自动化仓库场景，为您深度剖析由网络侧发起的（MT-LR）Sidelink定位流程，揭示当“指挥官”（外部应用）需要掌握“小队”（UE群组）的实时阵型时，5G网络是如何从“顶层”进行编排和指挥的。

1. 序章：自动化仓库的“协同危机”与“护航任务”

在上一篇文章中，我们见证了火场中的消防队长“伊娃”，如何通过SL-MO-LR流程，主动向网络求助，以获取她与队员们的相对位置。那是一个由“一线士兵”自下而上发起的请求。今天，我们将视角完全翻转，来到一个由“最高指挥官”自上而下发号施令的场景。

我们的故事发生在一个巨大的、宛如钢铁森林的5G全连接自动化仓库。数千台自主移动机器人（AMR）在这里穿梭不息。仓库的“大脑”——“仓储管理系统（WMS）”，一个强大的人工智能平台，扮演着LCS客户端/AF的角色。

现在，WMS面临着两个典型的“指挥官”难题：

  1. 协同危机（对应6.20.3 Immediate SL-MT-LR）：在B-07货架的狭窄通道，两台机器人“PackBot-01”和“PackBot-02”的路径规划发生冲突，存在碰撞风险。WMS需要立即获取它们之间精确的相对位置和距离，以做出最终的避让裁决。
  2. 护航任务（对应6.20.4 Deferred SL-MT-LR）：一件价值连城的精密仪器需要从入库区，由一个“护航编队”（由PackBot-01领头，PackBot-03和PackBot-04护卫两侧）运送到高价值存储区。WMS需要在这个长达15分钟的任务中，持续地、每2秒一次地监控这个编队的队形，确保它们始终保持着严格的安全间距。

在这两个场景中，请求的发起方不再是机器人自己，而是拥有上帝视角的WMS。这正是**SL-MT-LR（Sidelink Mobile Terminated Location Request）**的用武之地。

2. “指挥官”的指令：即时SL-MT-LR流程 (6.20.3)

当“协同危机”发生时，WMS立即向5G网络发出了一个“拉响红色警报”的定位请求。

“Figure 6.20.3-1: SL-MT-LR Procedure”为我们展示了这场由网络主导的“阵型快照”是如何被执行的。

2.1 第一步：WMS的“最高指令”

  1. The LCS Client or the AF (via NEF) sends an LCS service request by invoking the Ngmlc_Location_ProvideLocation service operation to the (H)GMLC for Ranging/Sidelink Positioning location results for the n UEs…

WMS向GMLC发起了ProvideLocation请求。这份“最高指令”的核心内容是：

  • 目标：一个群组，包含了PackBot-01和PackBot-02的身份标识（如应用层ID）。
  • 任务：获取它们之间的相对位置（relative locations）。
  • QoS：精度要求厘米级，时延要求亚秒级。

2.2 第二至第九步：指挥链的建立与“现场联络官”的指定

  1. The (H)GMLC … selects the UE (e.g. which is treated as UE1 in following steps) that initiates the Ranging/SL Positioning…
  2. The serving AMF selects an LMF serving UE1 … and sends an Nlmf_Location_DetermineLocation service operation towards the LMF…

这是一条标准的MT-LR指挥链，但有一个关键的“战术决策”：

  1. GMLC的隐私审查 (Step 2)：GMLC必须为群组中的每一个机器人，独立地向UDM查询其隐私设置。
  2. GMLC/LMF指定“联络官” (Step 3)：GMLC或后续的LMF，会从这个群组中，选择**一个UE（UE1）**作为本次任务的“现场联络官”或“队长”。这个选择可能基于谁的在线状态最稳定、谁的Sidelink能力最强、或者谁离网络最近。在我们的例子中，PackBot-01被选中。
  3. 任务下达 (Steps 4-9)：请求被一路转发到服务PackBot-01的AMF，再由AMF委派给一个支持Sidelink的LMF。

LMF，这位“现场总指挥”，正式接管了任务。

2.3 第十至十五步：LMF的“战术部署”

LMF现在需要通过“联络官”PackBot-01，来组织和协调这场定位。

  1. The LMF sends an SL-MT-LR request to the serving AMF as a supplementary services message…
  2. The serving AMF forwards the SL-MT-LR request … to UE1 using a DL NAS TRANSPORT message.
  3. UE1 attempts to discover the other UE 2 to n…

  1. LMF下达“作战计划” (Step 10-11)：LMF向PackBot-01发送了一条SL-MT-LR Request的NAS消息。这份“作战计划”详细说明了：

    • 作战目标：你需要找到并与PackBot-02进行定位。
    • 作战方式：进行RTT测距。

  2. “联络官”的组织工作 (Step 12-14)：PackBot-01收到指令后，立即开始执行：

    • 发现队友 (Step 12)：通过PC5 Sidelink信道，发现PackBot-02。
    • 交换能力 (Step 13)：与PackBot-02交换SLPP消息，确认双方都支持RTT测距。
    • 向LMF汇报准备情况 (Step 14-15)：将发现和能力交换的结果，通过AMF汇报给LMF。

2.4 第十六至二十步：执行与汇报

  1. Ranging/Sidelink Positioning of UE1 and the other discovered UEs occurs as for an SL-MO-LR as described for steps 12-20 of clause 6.20.1… 17-20. The LMF returns the Ranging/Sidelink positioning location results via AMF and GMLC to the LCS Client or AF…

这个阶段，完全复用了我们在上一篇SL-MO-LR中分析过的测量与计算流程：

  1. 执行测量 (Step 16)：在LMF的（可选）指令下，PackBot-01和PackBot-02之间进行高频的RTT信号交换。
  2. 数据汇总与上报：PackBot-01收集测量数据，并上报给LMF。
  3. LMF计算：LMF解算出两台机器人之间精确的相对距离和方向。
  4. 结果返回：LMF将计算结果，沿着LMF → AMF → GMLC → WMS的路径，返回给“最高指挥官”。

WMS的屏幕上，两台机器人的相对位置被精确地呈现出来。AI系统立即为PackBot-02重新规划了一条路径，一场潜在的碰撞被成功避免。

3. “护航编队”的守护：周期性SL-MT-LR流程 (6.20.4)

现在，让我们切换到“护航任务”的场景。WMS需要对PackBot-01、03、04组成的编队，进行长达15分钟、每2秒一次的持续监控。这触发了一次延迟的、周期性的SL-MT-LR。

The periodic and triggered SL-MT-LR procedure is based on SL-MT-LR procedure in clause 6.20.3, and used to estimate the relative locations or distances and/or directions between the UEs periodically or following certain trigger events.

“Figure 6.20.4-1: Periodic and Triggered SL-MT-LR Procedure”展示了这场“持久战”的运作方式。

3.1 建立“长期作战指令”

这个流程在启动阶段，与6.20.3非常相似，但WMS在Step 1发出的“最高指令”中，增加了周期性事件参数：

  1. The LCS service request further includes periodic or trigger event parameters. For periodic location, the LCS Service Request includes the time interval between successive location reports and the total number of reports.

WMS的请求是：“目标群组PackBot-01/03/04，任务是获取相对位置，时间间隔2秒，总时长900秒（450次报告）。”

3.2 下发“守护契约”

这个“长期作战指令”会一路被传递到LMF。LMF在向“联络官”PackBot-01下达SL-MT-LR Request时，这个请求就变成了一份“守护契约” (Periodic-Triggered SL-MT-LR Request)。

  1. The LMF sends a supplementary services Periodic-Triggered SL-MT-LR request to the serving AMF.

这份“契约”不仅告诉PackBot-01“和谁定位、如何定位”，更重要的是，它包含了触发条件：“每隔2秒，重复执行一次测量和上报。”

3.3 编队的“自主巡航”与事件上报

  1. The UEs 1 to n periodically perform Ranging/Sidelink positioning…
  2. UE1 monitors for occurrence of the trigger or periodic event requested in step 11.
  3. UE1 sends a supplementary services event report message to the serving AMF…
  1. 自主监控 (Step 22)：一旦“契约”被PackBot-01接受，整个编队就进入了一种“自主巡航”模式。PackBot-01内部的计时器，会成为整个编队行动的“节拍器”。
  2. 周期性触发 (Step 21)：每隔2秒，PackBot-01的计时器到时，它就会主动发起一次组内的Sidelink测距流程。
  3. 事件上报 (Step 24-31)：PackBot-01收集到测量数据后，会将其打包成一个“事件报告（Event Report）”，并通过AMF，上报给LMF。LMF计算后，再将结果推送给WMS。

这个“监控-触发-测量-上报”的循环，会一直持续下去，直到450次报告完成，或者WMS主动发起取消流程。WMS的屏幕上，护航编队的队形图，就像视频直播一样，被实时、平滑地刷新着。

4. 总结：Sidelink定位的“指挥官”模式

6.20.3和6.20.4共同构成了Sidelink定位的“指挥官模式”。与UE主动发起的MO-LR相比，它展现了截然不同的价值和应用场景：

  • 视角翻转，顶层设计：它将定位的发起权和控制权，完全交给了网络侧的LCS客户端。这使得Sidelink定位不再仅仅是UE的“个人行为”，而是能够被整合进企业级的、中心化的管理与调度平台（如WMS、车队管理、应急指挥系统）的“系统能力”。
  • 指定“联络官”，实现现场协同：通过在群组中动态指定一个UE作为“联络官（UE1）”，网络成功地将复杂的、分布式的多UE协同任务，简化为了一个“中心化指挥-分布式执行”的高效模型。
  • 融合延迟机制，赋能长期监控：通过将Sidelink定位与标准的延迟/周期性事件框架相结合，它为需要对群体进行长期、无人值守监控的应用场景（如车队护航、机器人编队、赛事追踪），提供了完美的解决方案。

对于“深蓝”矿井和“CyberClash”电竞赛事这样的高端工业和商业应用，SL-MT-LR流程意味着它们可以获得一种前所未有的、对“群体”进行精细化、实时化、上帝视角般的洞察与操控能力。这正是5G Sidelink定位，从一个“点对点”的工具，走向一个“平台级”服务的关键一步。

FAQ - 常见问题解答

Q1：在SL-MT-LR中，由谁来决定哪个UE扮演“联络官”（UE1）的角色？ A1：这个决策权主要在GMLC或LMF。当GMLC/LMF收到一个针对群组的请求后，它会评估群组中每个UE的状态。它的选择标准可能包括：1) 网络可达性：哪个UE当前处于CM-CONNECTED状态，并且信号质量最好？2) 能力：哪个UE的Sidelink和定位能力最强？3) 策略：运营商或企业客户是否预先指定了某个UE（如车队中的头车）作为默认的联络官？

Q2：SL-MT-LR和我们之前讲的“批量操作（Bulk Operation, 6.8）”有什么区别？它们不都是定位一个群组吗？ A2：这是一个非常好的问题，两者极易混淆。核心区别在于定位的目标：

  • 批量操作 (6.8)：目标是获取群组中每一个UE各自的、独立的、绝对位置。它返回的是N个坐标点。
  • SL-MT-LR (6.20.3)：目标是获取群组中UE彼此之间的、相对的位置关系（距离、方向）。它返回的是描述这个“阵型”的数据。 虽然SL-MT-LR也可以通过定位一个参考锚点来计算出整个阵型的绝对位置，但其核心依然是测量“相对关系”。

Q3：在周期性的SL-MT-LR（6.20.4）中，如果“联络官”UE1突然掉线或故障了，会怎么样？ A3：整个周期性定位任务将会中断。因为“联络官”是网络与小队之间唯一的通信桥梁，也是小队内部测量的发起者。当它掉线后，LMF会因为收不到事件报告而超时。此时，LMF会通知GMLC，GMLC再通知LCS客户端（WMS）：“任务失败，联络官失联”。一个鲁棒的WMS系统在收到这个通知后，应该重新发起一次SL-MT-LR请求，让网络从剩余的在线机器人中，重新选择一个新的“联络官”，重建守护任务。

Q4：为什么需要一个如此复杂的、由网络辅助的Sidelink定位流程？为什么不让机器人之间自己完成定位，然后各自上报给WMS？ A4：让机器人自己完成，就是纯粹的“Ad-hoc”网络模式，存在诸多问题：1) 缺乏协同与仲裁：谁来发起？谁来组织？测量冲突了怎么办？2) 缺乏可信度：WMS无法保证机器人上报的位置是真实的、未经篡改的。3) 能力孤岛：无法利用网络侧强大的计算能力、全局视野和高精度辅助数据。而网络辅助的模式，将LMF引入作为可信的“第三方裁判和指挥官”，完美地解决了上述所有问题，使得Sidelink定位成为一种电信级的、可管理、可信赖的服务。

Q5：这些Sidelink定位流程，在现实中部署了吗？ A5：Sidelink技术本身（最初为V2X设计）已经相对成熟，并在汽车行业有实际部署。而将其扩展到LCS框架下的通用定位（如本章所述），是3GPP Release 16及之后版本中引入的较新功能。目前，它们更多地出现在工业专网、车联网、公共安全等高端、前沿的试点和商用项目中。随着支持Sidelink的芯片和模组的普及，我们有望在未来几年看到更多基于这些流程的创新应用落地。

关系图谱