51学通信

深度解析 3GPP TS 23.273：6.20 测距侧行链路定位 (Part 1 - MO-LR流程)

20分钟阅读

深度解析 3GPP TS 23.273：6.20 测距/侧行链路定位 (Part 1 - MO-LR流程)

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.20 Ranging/Sidelink Positioning procedures”及其子章节“6.20.1 Procedures of SL-MO-LR involving LMF”的核心内容。本文将通过一场惊心动魄的火场救援行动，为您深度剖析5G时代最具革命性的定位能力之一——网络辅助的侧行链路定位（Sidelink Positioning），揭示UE之间如何“面对面”地确定彼此的相对位置。

1. 序章：火场迷雾中的“生命罗盘”

在之前的篇章中，我们探讨的所有定位技术，都依赖于一个共同的“锚点”——位置固定的基站。UE通过与这些“灯塔”的交互来确定自身坐标。然而，当这些“灯塔”全部失效时——例如，在GPS信号无法穿透、蜂窝网络因灾难而瘫痪的摩天大楼火场内部——我们该如何为身陷其中的人们提供“生命罗盘”？

侧行链路定位（Sidelink Positioning）正是为这种极限场景而生的终极解决方案。它彻底颠覆了“UE-网络”的传统定位模式，开创了“UE-UE”的全新范式。设备之间不再依赖基站，而是通过直接通信（PC5接口），互相测量距离和方向，从而确定彼此的相对位置。

今天，我们的主角是“阿尔法”消防小队。队长“伊娃”和她的两名队员“迈克”、“克洛伊”，正准备进入一座充满浓烟、结构复杂的商业综合体，搜救被困人员。他们每个人都配备了集成了5G Sidelink模组的“火场视觉系统”头盔。

伊娃队长的核心需求是：在头盔的AR面罩上，必须实时、精确地显示出她与迈克、克洛伊的相对位置和距离，以便在能见度几乎为零的环境中，保持战斗队形，确保队员之间永不失联。这个需求，将触发一次教科书般的、由网络辅助的**SL-MO-LR（Sidelink Mobile Originated Location Request）**流程。

章节拆分说明：6.20章节内容极其丰富，涵盖了MO-LR、MT-LR及其多种变体。为保证解读的深度和清晰度，本文将作为该系列的第一部分，专注于最核心、最复杂的6.20.1 网络辅助的SL-MO-LR流程。

2. 战前准备：建立“心灵感应”的通道 (Precondition & Steps 1-6)

在阿尔法小队冲入火场之前，一系列的“战前准备”工作必须完成。这确保了他们的设备之间能够建立起安全、可靠的直接通信链路。

Precondition: UE1 is in coverage and registered with a serving PLMN that supports Ranging/Sidelink Positioning. UEs 2 to n may or may not be in coverage…

前提条件：队长伊娃（UE1）的设备必须处于网络覆盖下，因为她将是本次定位的发起者和与后方指挥部（网络）的联络官。而队员迈克和克洛伊（UEs 2-n）的设备则不要求必须在网，这正是Sidelink的强大之处——即使在信号盲区，他们依然可以成为定位网络的一部分。

“Figure 6.20.1-1: SL-MO-LR Procedure”为我们描绘了从准备到执行的完整作战图。

  1. The procedures and signalling specified in clause 6.2 of TS 23.586 are used to provision the Ranging/Sidelink positioning service authorization and policy/parameter provisioning to UEs 1 to n.
  2. Secure groupcast and/or unicast links are established between UEs 1 to n…
  1. 授权 (Step 1)：在出勤前，消防指挥中心（扮演AF/LCS Client）已经通过网络，为阿尔法小队的所有设备，下发了Sidelink定位的授权和策略。这就像是颁发“持枪证”，明确了他们有权在任务中使用这项高级功能。
  2. 发现与建链 (Steps 2-3)：小队在集结时，他们的头盔会自动进行设备发现（Discovery），并建立起安全的PC5接口链路。这就像队员之间互相确认了对讲机频道，并约定了加密口令。他们之间现在可以进行直接、加密的通信了。

2.2 能力的“互探”与决策的诞生 (Steps 4-6: Verification & Capability Exchange)

  1. The Ranging/Sidelink positioning capabilities exchange between UE-1 and UEs 2 to n is performed using SLPP message(s) as specified in TS 38.355…
  2. Based on the Ranging/Sidelink positioning capabilities of UE1/…/UEn, the target UE determines SL-MO-LR is to be performed.
  1. 能力互探 (Step 5)：伊娃、迈克、克洛伊的头盔之间，通过PC5链路，交换**SLPP（Sidelink Positioning Protocol）**消息。这就像队员之间在互相检查装备：“我的头盔支持RTT测距，精度可达10厘米，你呢？”“我的支持AOA角度测量”。
  2. 伊娃的决策 (Step 6)：作为任务发起者，伊娃的头盔（UE1）汇集了所有队员的能力信息。它发现，仅靠设备之间的能力，或许可以完成简单的测距，但要实现AR面罩上“你前我后，他左我右”的精确队形图，需要复杂的计算，最好有“后方炮火支援”。于是，它做出了一个关键决策：“我需要向网络发起一次‘网络辅助’的SL-MO-LR请求！”

3. 呼叫“后方炮火”：MO-LR请求的发出 (Steps 7-9)

决策既定，伊娃的头盔立即开始呼叫“后方指挥部”——LMF。

  1. UE1 sends a supplementary services SL-MO-LR request message to the serving AMF in an UL NAS TRANSPORT message. The SL-MO-LR request indicates the other UEs 2 to n (using Application Layer ID)… and indicates whether location calculation assistance is needed…

  1. 建立与网络的连接 (Step 7)：如果伊娃的头盔处于IDLE状态，它会首先发起服务请求，连接上AMF。

  2. 发出“求援信” (Step 8)：头盔向AMF发送了一条SL-MO-LR request消息。这份“求援信”的内容极其丰富：

    • 目标：明确指出需要定位的队友是迈克和克洛伊。注意，这里使用的不是他们的SUPI，而是应用层ID（Application Layer ID），例如“Fireman-Mike”、“Fireman-Chloe”。这既保护了队员的底层网络身份隐私，也便于上层应用（AR显示）进行识别。
    • 需求：明确要求“需要位置计算辅助（location calculation assistance）”，并说明了需要的定位结果类型，如“相对距离和方向”。
    • 最终客户：包含了后方指挥中心（LCS Client）的身份信息，以便网络知道该将最终的“战果”汇报给谁。

  3. AMF的精准委派 (Step 9)：AMF收到这份特殊的求援信后，会立即为伊娃选择一个支持Sidelink定位的“专家级”LMF，并将请求完整地转发过去。

LMF，这位“总指挥”，正式登场。

4. 指挥官的“战前部署”：LMF的辅助与编排 (Steps 10-15)

LMF接手后，它并不急于下令开火，而是进行了一系列精密的“战前部署”，确保一线“士兵”（UEs）能够以最高效率完成测量。

4.1 详细的情报核查 (Steps 10-11)

  1. The LMF may send a request to UE1 for the required capabilities of UEs 2 to n…
  2. UE 1 returns its capabilities to the LMF…

LMF可能会向伊娃的头盔再次确认迈克和克洛伊的详细定位能力，以确保信息无误。伊娃的头盔会将之前通过SLPP“互探”到的情报，完整地汇报给LMF。

4.2 支线任务：获取绝对坐标 (Step 12)

  1. If Target UE’s absolute location information is required at step 8, LMF can … triggers 5GC-MT-LR procedure to the (V)GMLC to acquire the absolute location of the Located UE(s)…

这是一个极其重要的增强功能。如果指挥中心不仅想看到小队的相对队形，还想在城市地图上看到这个队形整体位于大楼的哪个位置，那么就需要获取至少一个队员的绝对坐标。

  • LMF此时会“一心二用”，并行地发起一个标准的5GC-MT-LR流程，去定位迈克或克洛伊（他们被称为Located UEs，即位置已知的参考UE）。
  • LMF会利用一切可能的手段（GNSS, TDOA, Wi-Fi…）来获取这个绝对位置“锚点”。

4.3 分发“秘密武器”：下发辅助数据 (Steps 13-14)

  1. LMF sends the requested assistance data to UE1 … The assistance data may assist UEs 1 to n … to obtain Sidelink location measurements at step 16…

LMF现在要为小队分发“秘密武器”——辅助数据（Assistance Data）。这份数据可能包括：

  • 精确的时间同步信息：确保所有头盔的“秒表”都是一致的，这对于RTT测距至关重要。
  • 参考UE的绝对位置：将在Step 12中获取到的迈克的绝对坐标，下发给伊娃。
  • 测量配置：详细的测量频率、信号格式等参数。

伊娃的头盔收到后，会通过PC5链路，将这份“作战计划”分发给所有队员。

4.4 下达“开火”指令 (Step 15)

  1. …LMF sends a request for location information of UE1 by SLPP message and location information of UE2-UEn by supplementary service message.

LMF向伊娃的头盔发送最终的“开火”指令。至此，所有准备工作完成，真正的测量即将开始。

5. 炮火齐鸣：Sidelink测距的执行 (Steps 16-23)

  1. UE1 performs a Ranging/Sidelink positioning procedure among UEs 1 to n… in which UEs obtain Sidelink location measurements and UEs 2 to n … transfer their Sidelink location measurements to UE1.

在LMF的统一号令下，阿尔法小队的所有头盔，开始了一场在PC5链路上进行的、高频的“无线电捉迷藏”：

  1. 信号交换：伊娃的头盔向迈克的头盔发送一个测距信号，迈克的头盔立即返回一个响应。伊娃的头盔精确地记录下信号的往返时间（RTT）。这个过程在小队所有成员之间两两进行。

  2. 数据汇总 (Step 16)：迈克和克洛伊的头盔，将它们自己测量的、或者它们与其他队员之间的测量结果，全部通过PC5链路，汇总到“联络官”伊娃的头盔中。

  3. 伊娃的“战地报告” (Steps 17, 19)：伊娃的头盔将收集到的所有原始测量数据（RTT值、AOA值等），打包成一份详尽的“战地报告”，通过NAS信令，上报给LMF。

  4. LMF的“超级计算” (Step 20)：LMF的后台，此刻就是一台“超级计算机”。它接收了这份包含多点、多维度的测量数据报告。

    20. If the LMF will calculate location results, the LMF calculates Ranging/Sidelink positioning location results…

    LMF的算法引擎开始运转。它利用这些原始数据，结合之前获取的迈克的绝对位置“锚点”，解算出了整个小队的精确队形图和他们在火场中的绝对位置。

  5. 结果的下发与呈现 (Steps 21-23)：

    • LMF将最终的计算结果，沿着**LMF → AMF → UE1（伊娃）**的路径返回。
    • 伊娃头盔的AR面罩上，迈克和克洛伊的虚拟轮廓和距离信息被清晰地、稳定地叠加在了浓烟之中。
    • 同时，AMF还会将这份结果，通过GMLC，上报给后方的消防指挥中心。

指挥中心的大屏幕上，阿尔法小队的实时动态阵型图被点亮。伊娃和她的队员们，在“生命罗盘”的指引下，成功地在迷雾中找到了被困人员。

6. 总结：为极限而生的协同智能

6.20.1的SL-MO-LR流程，是5G定位能力从“广域覆盖”向“近场精控”的一次革命性跃迁。它并非简单地让UE之间互联，而是构建了一套网络与终端深度协同的智能定位框架。

  • 双层通信架构：完美地融合了PC5 Sidelink链路（用于UE间的实时、低时延数据交换）和Uu控制面链路（用于UE与网络间的可靠、高层级指令交互）。
  • 网络的核心价值：在这个看似“去中心化”的定位模式中，网络（LMF）的核心价值反而更加凸显。它不再是“运动员”，而是成为了“总教练”和“超级大脑”，负责授权、编排、辅助、计算和仲裁，确保了整个复杂系统的有序、高效和精确。
  • 相对与绝对的统一：通过并行的MT-LR流程，巧妙地将设备间的“相对位置”与地球坐标系中的“绝对位置”结合起来，满足了从单兵战术到战区指挥的多层次需求。

这套流程，为消防救援、V2X协同驾驶、机器人编队、AR游戏等一系列前沿应用，提供了坚实的技术基石。它让5G网络，真正拥有了深入到“最后一米”、赋能“万物交互”的终极能力。

FAQ - 常见问题解答

Q1：SL-MO-LR和我们之前讲的MO-LR（6.2）有什么根本区别？ A1：根本区别在于定位的目标和方式。常规的MO-LR，目标是定位UE自身，方式是利用UE与网络（基站）之间的信号。而SL-MO-LR，目标是定位UE与另一个或多个UE之间的相对关系，核心方式是利用UE与UE之间的Sidelink信号。

Q2：为什么在SL-MO-LR请求中，UE使用“应用层ID”而不是SUPI？ A2：主要出于隐私和应用解耦的考虑。SUPI是用户的核心网络身份，暴露给应用或其他UE会带来安全风险。而应用层ID（如消防员编号、游戏昵称）是特定于应用的，即使泄露，也不会影响用户的网络安全。这使得Sidelनेल一定位可以在不牺牲用户基础隐私的前提下进行。

Q3：是UE自己计算位置，还是LMF计算位置？ A3：两者皆可，取决于UE在Step 8的请求。

  • UE计算：如果UE（如伊娃的头盔）计算能力强大，且LMF下发了足够的辅助数据（如参考UE的绝对位置），它可以自行完成最终计算，然后直接将结果上报。
  • LMF计算（网络辅助）：这是本章分析的模式，也是更常见、更强大的模式。UE只负责测量，并将原始数据上报给LMF。由LMF这个“超级大脑”来完成复杂的融合计算。这种模式对UE的算力要求更低，且LMF能融合更多网络侧信息，结果通常更可靠。

Q4：Sidelink定位是否意味着完全脱离网络也能工作？ A4：不完全是。Sidelink的数据传输（PC5接口）可以完全脱离网络覆盖。但是，3GPP定义的这套SL-MO-LR流程，其大部分能力（如授权、编排、计算辅助）都依赖于网络辅助。可以理解为，纯“野外模式”下的Sidelink定位能力有限（例如，只能简单测距），而在有网络辅助的情况下，它的能力才能被完全释放，实现高精度的、可管理的、与上层应用联动的协同定位。

Q5：SLPP和RSPP是什么协议？它们有什么关系？ A5：SLPP (Sidelink Positioning Protocol)，定义在TS 38.355中，是LCS层面的协议，运行在UE之间或UE与LMF之间。它专门用于传输定位相关的能力、配置、测量数据和辅助数据。而RSPP (Ranging and Sidelink Positioning Protocol)，定义在TS 23.586中，更偏向V2X应用层面，它也运行在PC5上，但更多是用于承载和协商与V2X相关的定位服务。两者在功能上有重叠，但SLPP更专注于LCS体系下的定位信息交换。在6.20的流程中，主要是通过SLPP进行交互。

关系图谱