51学通信

深度解析 3GPP TS 23.273：6.20 测距侧行链路定位(Part 2 - 融合与新生)

19分钟阅读

深度解析 3GPP TS 23.273：6.20 测距/侧行链路定位(Part 2 - 融合与新生)

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.20.2 5GC-MO-LR Procedure using Ranging/SL positioning”和“6.20.5 5GC-MT-LR Procedure using Ranging/SL positioning”的核心章节。本文将这两节内容合并解读，旨在通过一个高难度的地下矿井作业场景，为读者揭示Sidelink定位能力是如何从一个独立的“新物种”，融合进5G最经典的MO-LR和MT-LR流程中，从而为解决极限环境下的绝对定位难题，提供了“新生”的解决方案。

1. 序章：地下迷宫的“坐标原点”危机

在上一篇文章中，我们见证了“阿尔法”消防小队如何在浓烟中，通过SL-MO-LR流程实现了队员间的相对位置感知。然而，在许多工业和勘探场景中，仅仅知道“我在你左边3米”是远远不够的，系统必须知道每一个体在地球坐标系中的绝对位置。

今天，我们的故事发生在地表之下800米的“深蓝”智能矿井。主角是“Geobot-M08”，一台负责矿脉勘探和钻孔作业的自主机器人。它的任务是前往一个新发现的、地质结构复杂的C-7号矿洞，执行一次厘米级精度的岩芯取样。

“Geobot-M08”面临着定位的“原点危机”：

  • GNSS失效：深达800米的地下，GNSS信号是绝对的禁区。
  • 蜂窝信号复杂：矿井内虽然部署了5G专网，但隧道狭长、岩壁反射多变，传统的基于蜂窝的TDOA或AOA定位，精度难以稳定达到厘米级。

幸运的是，“深蓝”矿井在设计之初，就在隧道壁上预先安装了多个位置绝对精确、不可移动的5G定位锚点。这些锚点，在LCS的语境下，就是**“Located UEs”**——身份为UE，但其精确位置早已被网络（LMF）所知。

现在，Geobot-M08需要利用这些“灯塔”来确定自身的绝对坐标。它将如何向网络求助？而当网络（矿井控制中心）主动查询它的位置时，又将如何智能地利用这些“灯塔”？6.20.2和6.20.5章节，正是为这种“利用已知点，定位未知点”的经典测量问题，提供了标准化的5G解决方案。

2. 理念的升华：从“新流程”到“新工具”

在深入具体流程前，我们必须厘清一个核心的理念转变。上一篇的6.20.1（SL-MO-LR）定义的是一个全新的流程，其主要目标是获取UE间的相对位置。

而我们今天探讨的6.20.2和6.20.5，则完全不同。它们复用了5G最经典的MO-LR（6.2）和MT-LR（6.1.2）流程，其目标依然是获取单个UE的绝对位置。Sidelink/Ranging在这里，不再是一种“新业务”，而是被“降维”成了一种可以被LMF在执行定位时自由调用的“新工具”或“新方法”。

这就像一个厨师，原本只会用“煎”和“炸”来做菜。现在，他学会了“蒸”这门新技术。他可以用“蒸”来做一道全新的菜（像SL-MO-LR），也可以在做传统红烧肉（像MO/MT-LR）的过程中，加入“蒸”的步骤来改善口感。6.20.2和6.20.5，正是讲述了LMF这位“大厨”，是如何将“Sidelink”这门新厨艺，完美地融入到它的传统“菜谱”中的。

3. 机器人的“自救”：MO-LR中使用Sidelink定位 (6.20.2)

Geobot-M08在C-7号矿洞的入口处停了下来。它的自主导航系统发现，仅靠惯性导航和激光雷达，累积误差已接近临界值，无法满足接下来厘米级钻孔的精度要求。它必须重新校准自己的绝对坐标。于是，它决定向网络“求救”。

This procedure is used to estimate the location of a UE based on the location of one or more Located UEs and the distance and/or direction between the UE and the Located UE(s). 5GC-MO-LR Procedure as defined in clause 6.2 applies with the following differences:

这场“自救”，本质上是一次标准的MO-LR，但增加了几个关键的“补丁”。

3.1 补丁一：AMF的“能力感知” (Differences in Step 3 & 4)

  • In step 3, the AMF may take the UE’s Ranging/Sidelink Positioning capability into account for LMF selection.
  • In step 4, the AMF provides the UE’s Ranging/Sidelink Positioning capability to LMF.

  1. UE发起请求：Geobot-M08向其服务的AMF发起了一次标准的MO-LR请求（6.2），要求获取自身的高精度绝对位置。

  2. AMF的智能选择 (Step 3)：AMF在为Geobot-M08选择LMF时，除了常规考量，还额外查看了它的“能力档案”。它发现，Geobot-M08的能力列表中，赫然写着“支持Sidelink定位”。AMF立刻意识到，这是一个具备“特种作战”能力的UE，于是，它专门为它挑选了一个同样支持Sidelink的“专家级”LMF。

  3. 能力信息的传递 (Step 4)：AMF在向LMF委派任务时，会附上一条重要信息：“注意，目标UE具备Sidelink能力。” 这就像给“大厨”LMF递上了一份特殊的食材清单。

3.2 补丁二：LMF的“菜谱融合” (Difference in Step 5)

  • Step 5 is replaced by step 10-16 of clause 6.20.3…

这是最核心的“补丁”。标准MO-LR流程中的Step 5，原本是LMF执行常规定位的地方。现在，它被替换成了一套更复杂的、源自6.20.3（SL-MT-LR流程）的“组合拳”。

这就像LMF这位大厨，在做到“红烧肉”的关键一步时，没有直接“煎炒”，而是拿出了一本关于“蒸”的秘籍，开始了一系列新的操作。这个“流程嵌套”的过程如下：

  1. LMF接收请求：LMF收到了来自Geobot-M08的MO-LR请求。

  2. LMF的“战术推演”：LMF分析后发现，在地下800米，常规的GNSS/TDOA方法无法满足厘米级精度。但它从AMF那里得知，Geobot-M08支持Sidelink，并且LMF自己的数据库里，记录着C-7号矿洞附近有三个定位锚点（Located UEs: Anchor-1, Anchor-2, Anchor-3）的精确坐标。

    • In step 10, the type of required location results is absolute location, and the other UEs 2 to n are the candidate Located UE(s) if included.

  3. LMF发起“协同作战”：LMF现在扮演了SL-MT-LR中GMLC的角色，它向Geobot-M08下达了一个“Sidelink多边测量”的指令。这个指令通过AMF → UE的SL-MT-LR Request消息（承载在NAS中）送达。

    After LMF determines that the assistance of Located UE is needed for Target UE Positioning, LMF decides that Target UE or LMF selects Located UE, and SL-MT-LR request also includes the indication of Target UE/LMF selecting Located UE.

  4. UE的执行：Geobot-M08收到指令后，开始执行Sidelink测距。它通过PC5接口，分别与Anchor-1, Anchor-2, Anchor-3进行RTT测距，得到了自己与这三个已知“灯塔”的精确距离。

  5. 结果的汇集与计算：Geobot-M08将测量到的三个距离值，通过NAS消息上报给LMF。LMF利用这三个距离，和它数据库中三个锚点的精确坐标，通过三边测量法（Trilateration），解算出了Geobot-M08的厘米级绝对坐标。

  6. 沿MO-LR路径返回：LMF将这个高精度结果，沿着LMF → AMF → Geobot-M08的标准MO-LR返回路径，送还给了发起者。

Geobot-M08的导航系统接收到这个精确的坐标后，完成了自我校准，随后精准地驶向了钻孔点。

4. 控制中心的“B计划”：MT-LR中使用Sidelink定位 (6.20.5)

现在，我们切换到另一个场景。矿井的地面“控制中心”（扮演LCS客户端），在屏幕上发现Geobot-M08已在C-7矿洞入口停滞了10分钟，远超预设的停留时间。控制中心担心机器人出现故障，于是主动发起了一次对Geobot-M08的MT-LR定位请求。

NOTE: The procedure can be triggered by GMLC, e.g. if the location result of Target UE determined by previous MT-LR procedure for the same request cannot fulfil the required QoS.

这句NOTE，点明了这个流程最典型的应用场景——作为“B计划”的失败重试（Fallback）。

4.1 “A计划”的失败

  1. 控制中心发起请求：控制中心向GMLC发起了标准的MT-LR请求，要求1米精度。
  2. GMLC → AMF → LMF：请求被一路转发到了LMF。
  3. LMF的首次尝试：LMF作为“大厨”，首先拿出了它的常规菜谱。它尝试了E-CID和UL-TDOA。然而，由于矿井下的多径效应，最终返回的定位结果，精度只有15米。
  4. LMF的内部“审判”：LMF将15米的结果与请求的1米QoS一比较，“A计划”失败！

4.2 “B计划”的智能启动

此时，一个“笨”的LMF可能会直接向GMLC报告失败。但一个“聪明”的、支持6.20.5的LMF，会立即启动它的“B计划”。

  • LMF的“灵光一现”：LMF在其内部的UE能力档案中，查到Geobot-M08是支持Sidelink的，并且矿洞内有可用的定位锚点。
  • 启动“内部循环”：LMF决定，在不告知GMLC的情况下，内部自动发起一次基于Sidelink的重试。

从这一刻起，LMF内部启动的流程，与我们上一节分析的“流程嵌套”完全一样：它向Geobot-M08下达Sidelink多边测量的指令，Geobot-M08与锚点进行RTT测距，将结果上报，LMF解算出厘米级精度坐标。

4.3 最终的胜利

这一次，LMF得到了一个精度为20厘米的结果。它再次与请求的1米QoS进行比较，“B计划”成功！

LMF将这份高精度的结果，沿着LMF → AMF → GMLC → 控制中心的标准MT-LR返回路径，上报上去。

控制中心的屏幕上，Geobot-M08的位置被精准地标记了出来，并附带了“设备正常，正在进行位置校准”的状态信息，一场虚惊得以解除。

5. 总结：Sidelink定位的“工具化”革命

6.20.2和6.20.5的流程，标志着Sidelink定位能力的一次深刻的“工具化”革命。它不再仅仅是一项用于UE间相对定位的“新业务”，而是被整合进了5G定位的“核心武器库”，成为LMF在面对极限环境时，可以随时拔出的“攻坚利器”。

  • MO-LR下的“主动求援”：UE可以利用自身的“边缘智能”，在发现常规定位手段可能失效时，主动向网络“建议”使用Sidelink这一高级工具，加速了问题的解决。
  • MT-LR下的“智能后手”：LMF被赋予了更高的智能，能够在常规方法失败后，自主地、无缝地切换到Sidelink定位模式进行重试。这种内置的Fallback机制，极大地提升了5G定位服务在各种挑战性环境下的可靠性和成功率。
  • 架构的融合：通过巧妙的“流程嵌套”，将复杂的Sidelink交互，无缝地嵌入到最经典的MO/MT-LR框架中。这既复用了成熟的信令流程，又引入了全新的定位维度，是3GPP标准“演进式创新”的典范。

对于Geobot-M08和无数即将在极限环境中工作的IoT设备而言，这套融合的流程意味着它们的“坐标原点”将拥有前所未有的可靠性保障。即使在最深的地下，最复杂的钢结构建筑内，只要有“灯塔”的存在，5G网络就能为它们点亮回家的路。

FAQ - 常见问题解答

Q1：MO-LR（6.20.2）和MT-LR（6.20.5）中使用Sidelink定位，对UE来说，体验有什么不同？ A1：从执行Sidelink测量的角度看，UE的行为是完全相同的（接收LMF指令，与锚点进行测距）。但从流程的触发和感知上，体验完全不同。在MO-LR中，UE是主动的、知情的，它知道自己发起了定位，并可能参与了方法的选择。在MT-LR中，UE是被动的、可能无感的，它只是响应LMF下发的指令，可能并不知道这是LMF在一次失败后的“重试”。

Q2：这些“定位锚点”（Located UEs）是特殊设备吗？它们如何维护？ A2：是的，它们通常是专用的、工业级的设备。它们被牢固地安装在已知位置，拥有稳定的供电和高质量的天线。它们也需要像PRU（6.17）一样，向网络（LMF）注册自己的精确位置和能力。它们的生命周期管理（安装、校准、维护、更换）是整个高精度定位解决方案部署的关键一环。

Q3：LMF是如何知道在特定区域有哪些可用的“定位锚点”的？ A3：LMF有一个专门的数据库，用于存储所有已注册的PRU和Located UEs的信息。当LMF收到一个定位请求，并从AMF得知UE的粗略位置（如Cell-ID）后，它会以这个粗略位置为索引，在数据库中搜索附近有哪些可用的锚点，从而启动协同定位。

Q4：在MT-LR的“B计划”中，如果LMF的第二次尝试（使用Sidelink）也失败了怎么办？ A4：如果所有可用的定位方法都已尝试，并且都无法满足请求的QoS，LMF将会向GMLC返回一个失败的响应，并附带一个明确的失败原因（Cause Code），例如“Positioning failed due to insufficient resources or measurements”。GMLC再将这个失败结果传递给最终的LCS客户端。

Q5：这些融合流程，是否意味着未来所有的手机都能通过测量与其他手机的距离来进行定位？ A5：技术上可行，但商业和隐私上很复杂。目前，6.20.2和6.20.5中描述的“Located UEs”主要是指位置固定的、专用的基础设施。将个人用户的手机用作“移动的、不可信的”锚点来进行“众包定位”，虽然是未来的一个研究方向，但涉及到极高的技术复杂性（如如何保证移动锚点的自身位置精度）和极其敏感的隐私问题（需要用户A授权，用TA的位置去定位用户B）。因此，在当前的标准化流程中，主要还是依赖于可信的、固定的锚点。

关系图谱