51学通信

深度解析 3GPP TS 23.273：6.2 5GC-MO-LR 终端始发定位流程

20分钟阅读

深度解析 3GPP TS 23.273：6.2 5GC-MO-LR 终端始发定位流程

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.2 5GC-MO-LR Procedure”的核心章节。本文将通过一名5G网络优化工程师的日常工作，抽丝剥茧地解析终端始发定位请求（MO-LR）的完整信令流程，揭示当“我”想知道“我”在哪，或“我”想告诉“你”我在哪时，5G网络内部发生了怎样一番精密的协作。

1. 序章：来自现场的“定位信标”

在之前的篇章中，我们跟随了紧急救援、外卖配送等由网络侧发起的定位场景（MT-LR）。今天，我们将视角翻转，聚焦于一个由终端（UE）主动发起的定位模式——移动始发定位请求（MO-LR, Mobile Originated Location Request）。这是我们日常使用地图、打车、社交打卡等应用时，背后最常触发的定位流程。

为了深入理解这一核心流程，让我们认识今天的主角——5G网络优化工程师“王工”。他的任务是在一座新建成的、结构复杂的中央商务区（CBD）进行网络信号质量普查。当他发现一处信号异常的干扰点时，他需要使用一款名为“信优-5G”的专业App，将自己当前所处的精确位置连同测量数据，一起上报给公司的“网络监控中心”（扮演LCS客户端/AF的角色）。

王工的每一次“打点上报”，都将触发一次教科书般的5GC-MO-LR流程。这不仅是简单的“我在哪？”的查询，更可能是一次将“我”的位置安全、可靠地传送给“第三方”的复杂交互。跟随王工的脚步，我们将拆解这个由UE作为“火车头”的定位旅程。

2. 流程启动：UE的主动请缨 (Steps 1-2)

与MT-LR的被动响应不同，MO-LR的序幕完全由UE拉开。规范中的“Figure 6.2-1: 5GC-MO-LR Procedure”为我们展示了这趟旅程的完整路线图。

2.1 第一步：唤醒沉睡的终端 (Step 1: UE Triggered Service Request)

  1. If the UE is in CM-IDLE state, UE instigates the UE triggered Service Request as defined in clause 4.2.3.2 of TS 23.502 in order to establish a signalling connection with the AMF.

王工抵达CBD的一处地下停车场，发现这里的5G信号覆盖存在盲点。他立刻掏出他的工程手机，准备记录这个干扰点。此时，手机为了省电，正处于CM-IDLE（连接管理-空闲）状态。

当王工点亮屏幕并打开“信优-5G”App时，这个动作本身就触发了手机向网络发起一次“UE触发的服务请求”。这就像在沉寂的房间里打开了对讲机，手机主动向网络“报到”，从“沉睡”中被唤醒，与AMF（接入与移动性管理功能）建立起一条稳固的信令连接。这是所有后续通信的前提。

2.2 第二步：发出定位的“英雄帖” (Step 2: MO-LR Request message)

连接建立后，UE便可以正式发出它的定位请求。这是整个流程中最关键的起始步骤。

  1. The UE sends an MO-LR Request message included in a UL NAS TRANSPORT message. … Different types of location services can be requested: location estimate of the UE, location estimate of the UE to be sent to an LCS client or AF, or location assistance data.

王工在App上点击“记录当前点位”按钮。App立刻构建了一个MO-LR请求，并将其封装在一条上行NAS传输消息中，发送给了AMF。这个请求的内容，决定了本次定位的目标和形式。规范定义了三种主要的MO-LR服务类型：

2.2.1 三种MO-LR服务类型

  1. 自身位置估算 (Location estimate of the UE)：这是最基础的“我是谁，我在哪”模式。UE向网络请求：“请计算我的位置，然后把结果告诉我”。比如，地图App刚打开时，需要获取当前位置并在屏幕上显示蓝点。

  2. 向第三方传送位置估算 (Location estimate … to be sent to an LCS client or AF)：这是王工当前正在使用的模式，即“请告诉‘他’我在哪”。UE向网络请求：“请计算我的位置，并将其发送给我指定的第三方（网络监控中心）”。请求中必须包含第三方的身份标识（LCS Client identity or AF ID）以及用于路由的GMLC地址。

  3. 位置辅助数据 (Location assistance data)：这是一种“请帮我一把，我自己算”的模式。UE向网络请求：“我的GNSS定位太慢，请给我一些辅助数据（如星历、差分修正信息等）”。网络（LMF）在收到后，会返回相应的辅助数据，而最终的位置计算由UE自己完成。这被称为“自主自定位”（Autonomous Self Location）。

2.2.2 请求中携带的“详细说明”

除了服务类型，王工的App在请求中还附带了详细的“任务说明书”：

  • LCS QoS：王工需要米级精度，因此QoS被设置为高精度、低时延。
  • 最大位置年龄 (maximum age of location)：App可能允许网络使用10秒内的缓存位置，以提高响应速度。
  • GMLC地址：“信优-5G”App被预配置了公司网络监控中心所对接的运营商GMLC地址。
  • 服务类型 (Service Type)：可能被定义为“网络质量普查”。
  • 假名指示符 (pseudonym indicator)：如果出于隐私考虑，王工不希望上报其真实的SUPI，App可以请求网络为其分配一个临时的假名。

AMF在收到这份内容详尽的“英雄帖”后，便开始扮演“武林盟主”的角色，着手寻找能够完成此任务的“武林高手”。

3. 网络侧的响应与执行 (Steps 3-6)

AMF作为UE在核心网的直接管理者，负责承接MO-LR请求并调度核心网资源来完成它。

3.1 第三步：寻找定位专家LMF (Step 3: LMF Selection)

  1. The AMF selects an LMF as described in clause 5.1. AMF may be configured locally a mapping table of UE identity e.g. MSISDN and LMF address. … If the AMF is aware that the UE is served by a MBSR, it would select the LMF that can support the MBSR handling.

AMF需要根据王工的请求，选择一个最合适的LMF（定位管理功能）。这个选择过程非常智能，AMF会综合考虑：

  • 请求的QoS：高精度请求自然要派给能力更强的LMF。
  • UE当前位置：王工身处地下停车场，AMF会倾向于选择一个擅长室内定位或混合定位的LMF。
  • UE接入类型：如果王工连接的是移动基站（MBSR），AMF会专门选择支持MBSR流程的LMF。
  • 本地配置或NRF查询：AMF可以通过本地配置的策略，或动态查询NRF（网络功能仓库）来发现符合条件的LMF。

最终，AMF为王工选择了LMF-C，一个在处理复杂城市场景下高精度定位方面享有盛誉的“专家”。

3.2 第四步：任务的正式委派 (Step 4: Nlmf_Location_DetermineLocation)

  1. The AMF invokes the Nlmf_Location_DetermineLocation service operation towards the LMF. The service operation includes an LCS Correlation identifier, the serving cell identity, the client type, …

AMF通过调用Nlmf_Location_DetermineLocation服务，将任务正式委派给LMF-C。这份委派书中包含了AMF从UE请求中解析出的所有信息，并增加了一个由AMF分配的“LCS Correlation identifier”，作为本次任务的唯一“工单号”。

3.3 第五步：LMF的十八般武艺 (Step 5: UE Positioning)

  1. If the UE is requesting its own location, the actions described in clause 6.11 are performed… If the UE is instead requesting location assistance data, the LMF transfers this data to the UE as described in clause 6.11.1.

这是真正的技术核心环节。LMF-C接过任务，开始施展它的定位“十八般武艺”（定义在6.11章节）。

  • 决策：LMF-C分析发现王工在地下，GNSS信号极弱。它决定采用混合定位策略。
  • 交互：LMF-C通过AMF，向王工的手机发送LPP（定位协议）消息，指令其：
    1. 尝试接收并测量周围泄露进来的微弱GNSS信号。
    2. 扫描并上报周围的Wi-Fi热点（SSID, BSSID, RSSI）。
    3. 扫描并上报周围的蓝牙信标（BLE beacons）。
  • 协同：同时，LMF-C指令AMF，让AMF请求基站网络（NG-RAN）对王工手机的上行信号进行测量，执行UL-TDOA。
  • 计算：LMF-C汇集了来自UE的GNSS/Wi-Fi/BLE测量报告，以及来自RAN的UL-TDOA测量报告。它强大的算法引擎将这些多源信息进行融合加权，最终计算出了一个高精度的、带有楼层信息的位置坐标。

3.4 第六步：专家向“盟主”复命 (Step 6: Nlmf_Location_DetermineLocation Response)

  1. When a location estimate best satisfying the requested QoS has been obtained … the LMF returns the Nlmf_Location_DetermineLocation Response towards the AMF.

LMF-C将计算出的精确位置、精度评估、时间戳以及本次定位所使用的混合方法等信息，打包成DetermineLocation Response，返回给了AMF。至此，核心的定位计算环节完成。

4. “最后一公里”：结果的交付与确认 (Steps 7-13)

对于“告诉‘他’我在哪”这种最复杂的MO-LR场景，定位结果的交付是一段漫长而严谨的旅程。AMF在收到LMF的结果后，需要启动一个子流程，确保位置信息被安全、可靠地送达“网络监控中心”。

4.1 第七、八步：AMF向GMLC系统发起上报

  1. If the location estimate was successfully obtained, the AMF invokes the Ngmlc_Location_LocationUpdate service operation towards to the VGMLC assigned in the step 2.
  2. If the VGMLC is same NF instance as HGMLC this step is skipped. Otherwise VGMLC invokes the Ngmlc_Location_LocationUpdate service operation towards to the HGMLC…

AMF此时的角色从“调度者”转变为“客户端”。

  • 它调用GMLC提供的Ngmlc_Location_LocationUpdate服务，将王工的位置信息主动“更新”给GMLC系统。请求中会包含UE标识、位置结果、事件原因（5GC-MO-LR）以及“信优-5G”App指定的LCS Client ID等。
  • 如果王工处于漫游状态，他所接入的VPLMN中的GMLC（VGMLC）在收到更新后，还需要将其转发给归属网络的GMLC（HGMLC）。

4.2 第九至十二步：穿越网络的确认回执

这是一条“确认之链”，确保了信息的端到端可靠交付。

  • Step 9：HGMLC将位置信息推送给最终的“网络监控中心”（LCS Client/AF）。
  • Step 10：“网络监控中心”接收数据，存入数据库，然后向HGMLC返回一个确认回执。
  • Step 11 & 12：这个确认回执沿着HGMLC → VGMLC → AMF的路径被逐级传回。

这个看似繁琐的确认流程，对于需要高可靠性的商业应用至关重要。它确保了王工的每一次“打点”，都被监控中心“已读”，而不是石沉大海。

4.3 第十三步：给UE的最终答复 (Step 13: MO-LR Response)

13)The AMF sends an MO-LR Response message included in a DL NAS TRANSPORT message. … or an indicator whether a location estimate was successfully transferred to the identified LCS client or AF.

AMF在收到了来自GMLC系统的最终确认后，向王工的手机发送最后一条MO-LR Response消息。

  • 对于“告诉‘他’我在哪”的场景：这个消息的内容是一个成功指示符。王工的“信优-5G”App收到后，会在屏幕上显示一个“√”，并提示“点位已成功上报！”。
  • 对于“告诉我我在哪”的场景：这个消息则会直接包含LMF计算出的位置估算结果。

至此，一次完整的5GC-MO-LR流程宣告结束。

5. 总结：UE赋能的“主动式”定位服务

6.2章节定义的MO-LR流程，与MT-LR流程形成了完美的互补。它赋予了UE和应用前所未有的主动性和灵活性。

  • 用户驱动：整个流程的“扳机”掌握在用户手中，体现了“我的位置我做主”的原则。
  • 功能丰富：提供了“自定位”、“辅助定位”、“位置共享”三种核心模式，满足了从个人导航到行业应用的广泛需求。
  • 架构严谨：即便是UE主动发起的请求，其处理过程依然遵循了5G核心网“调度-执行-交付”的严谨架构。特别是“位置共享”流程，通过GMLC系统的介入，确保了第三方接入的可管理、可计费、可追溯，保障了商业模式的闭环。

对于王工而言，这套流程意味着他手中的工程手机，不仅仅是一个通信工具，更是一个高精度的、与后台系统实时联动的“空间信标”，让他的每一次外勤工作都变得更加高效和精准。

FAQ - 常见问题解答

Q1：MO-LR和MT-LR最直观的区别是什么？ A1：最直观的区别是流程的发起方和方向。MT-LR是“网络找你”，由网络侧的LCS客户端发起，信令从核心网流向UE，UE是被动响应者。MO-LR是“你找网络”，由UE上的App发起，信令从UE流向核心网，UE是主动请求者。

Q2：MO-LR请求的三种类型（自身位置、共享位置、辅助数据）在实际应用中如何选择？ A2：这完全取决于App的业务逻辑。

  • 地图App显示“我在哪”，会用“自身位置”请求。
  • 跑步App需要持续记录轨迹，为了省电可能会选择“辅助数据”请求，利用手机自身的计算能力。
  • 打车App中，乘客查看司机位置是MT-LR，而司机端App持续上报自己的位置，则是一个周期性的“共享位置”MO-LR。

Q3：为什么MO-LR的“共享位置”流程需要经过GMLC，AMF不能直接把位置发给第三方AF吗？ A3：不能。GMLC在这里扮演了不可或缺的**“网关”和“策略执行点”**角色。1) 安全与认证：GMLC负责认证第三方AF的合法性，防止任何未经授权的应用获取用户位置。2) 计费与结算：GMLC是商业定位服务的计费点，记录每次成功的定位服务以进行结算。3) 隐私与合规：即便是UE主动共享，GMLC也可能需要根据更高级的策略（如法律法规）进行二次检查。4) 解耦：将AMF与成千上万的外部AF解耦，所有外部请求都统一收敛到GMLC，简化了网络架构。

Q4：如果我的手机App发起了MO-LR，但网络无法满足我要求的精度（比如我在隧道里），会发生什么？ A4：LMF在执行定位（Step 5）后，会将实际达到的精度与请求的QoS进行比较。如果无法满足，LMF在返回给AMF的响应（Step 6）中，会包含一个失败原因或一个带有较低精度评估的结果。最终，AMF在给UE的响应（Step 13）中，会告知App此次定位失败，或者返回一个带有“精度不足”标记的位置。App可以根据这个结果，在界面上给用户相应的提示，如“当前位置精度较低”。

Q5：MO-LR流程中，UE需要知道LMF的地址吗？ A5：不需要。UE始终只与它的“管家”AMF进行直接的NAS信令交互。选择哪个LMF、LMF的地址是什么，这些都是核心网内部的决策和路由，对UE是完全透明的。这种架构设计极大地简化了终端的实现，终端只需信任并与AMF对话即可。

关系图谱