51学通信

深度解析 3GPP TS 23.273：6.13.2 MO-LR跨代共享：当4G终端呼叫5G服务

17分钟阅读

深度解析 3GPP TS 23.273：6.13.2 MO-LR跨代共享：当4G终端呼叫5G服务

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.13.2 MO-LR Transfer to a Third Party Procedure”的核心章节。本文将继续上一篇的跨代互通主题，但将视角完全翻转，通过一个常见的路边紧急救援场景，为您深度剖析当一个身处4G（EPS）网络下的终端，需要将自己的位置主动共享给一个5G世界的应用时，4G与5G这两代核心网是如何进行一场“逆向”的、精妙的协同工作的。

1. 序章：来自4G“老将”的求援

在上一篇文章中，我们见证了5G“大脑”如何指挥4G“四肢”，成功定位了一辆身处4G网络的5G汽车。今天，我们的故事主角是“老李”，他驾驶着一辆性能可靠但技术稍显“复古”的轿车，车上安装的是一个4G T-Box（车载通信终端）。

一个雨夜，老李的车在郊外抛锚。幸运的是，他的车配备了一键式“路边救援”功能。他按下了这个按钮，希望将自己的精确位置发送给他的汽车保险公司——“5G领航救援中心”。这个救援中心刚刚将其后台服务系统全面升级到了5G架构，并作为一个LCS客户端/AF，通过NEF接入了运营商的5G核心网（5GC）。

一个经典的、却又充满挑战的场景诞生了：

  • 请求的发起方：一个纯粹的4G终端（老李的T-Box），位于4G网络（EPS）覆盖下。
  • 请求的目标方：一个纯粹的5G应用（“5G领航救援中心”），存在于5G核心网（5GC）的世界里。

这是一个**移动始发（MO-LR）**的“位置共享”请求，但它需要跨越技术的代际。4G的EPC网络，该如何找到并“敲开”5G世界的大门，将这份来自“老将”的紧急求援信，准确无误地递送到5G“新贵”的手中？这正是6.13.2流程所要解答的核心命题。

2. 核心挑战：“逆向”的外交难题

与6.13.1的MT-LR互通流程（5GC找EPC）相比，MO-LR的互通（EPC找5GC）是一个“逆向”的过程。发起方位于旧世界，需要找到并与新世界对话。

这个“外交难题”的核心，依然在于两大网络体系的异构性。4G的EPC GMLC无法直接向5G的LCS客户端/AF推送位置。它必须找到一个能够理解并接纳4G请求，又能与5G应用世界对话的“双语外交官”。

这个外交官，再次由融合了5GC和EPC能力的GMLC来扮演。它必须能够：

  1. 聆听4G的语言：接收并处理来自4G MME的、基于Diameter协议的Provide Subscriber Location请求。
  2. 转述为5G的语言：将这个请求的意图，转换为5G世界中基于服务化的LocationUpdate或EventNotify操作。
  3. 传递回4G的确认：将来自5G世界的最终确认，再“翻译”回4G的Diameter消息，形成一个完整的闭环。

3. “跨代”求援之旅：流程详解 (Figure 6.13.2-1)

“Figure 6.13.2-1: MO-LR procedure with 5GC and EPC interaction”为我们描绘了这场“逆向外交”的完整路线图。

3.1 第一步：4G世界里的“呐喊”

  1. Steps 1-6 in clause 9.2.6 of TS 23.271 are performed.

当老李按下救援按钮时，一场完全在4G（EPS）世界内部的、标准的MO-LR“位置共享”流程首先被启动。这个流程在4G的LCS规范（TS 23.271）中有详细定义，其核心步骤包括：

  1. UE发起请求：老李的4G T-Box向其服务的MME发送一个包含MO-LR请求的NAS消息。这个请求中，除了QoS要求外，最关键的是包含了它想要将位置发送给的“第三方”的身份信息，以及用于路由的GMLC地址。

    • 关键信息：T-Box中预配置了“5G领航救援中心”在运营商网络中的入口——融合GMLC的地址。

  2. MME的初步处理：MME收到请求后，会验证老李的签约数据（从HSS获取），确认他有权使用MO-LR服务。

  3. MME → EPC GMLC：MME将这个定位共享请求，通过SLg接口（基于Diameter协议），发送给T-Box在请求中指定的EPC GMLC（即那个融合GMLC）。

  4. EPC GMLC的选择与执行：EPC GMLC收到请求后，会选择一个E-SMLC（4G的定位计算中心），并启动定位流程，获取T-Box的精确位置。

至此，EPC GMLC的手中已经拿到了老李的精确坐标。但它的任务只完成了一半。它现在必须想办法，将这个坐标送达5G世界的目标方。

3.2 第二步：穿越代际的“外交邮袋”

  1. For non-roaming case and if 5GC GMLC and EPC GMLC is combined, this step is skipped. Otherwise the EPC GMLC sends Location Update Notification Request towards to the 5GC GMLC including the information received in step 1.

这是跨代互通的关键一步。

  • 融合部署（主流场景）：如果GMLC是融合部署的，那么“4G部门”在拿到位置后，可以直接在内部将这个任务转交给“5G部门”。这一步在外部信令上是“透明的（skipped）”，但内部的逻辑转换是真实发生的。
  • 分离部署：如果两者分离，EPC GMLC需要通过Lr等接口，向5GC GMLC发送一个“位置更新通知请求”，将老李的位置、目标LCS客户端的ID等所有信息，打包成一个“外交邮袋”，发送过去。

场景模拟：融合GMLC的“4G部门”成功定位了老李的车辆。它立刻将位置结果，连同请求中指定的LCS客户端ID（“5G领航救援中心”），转交给了内部的“5G部门”。

3.3 第三步：5G世界里的“精准投递”

  1. Steps 9-10 in clause 6.2 are performed.

融合GMLC的“5G部门”接手后，它所面对的，就是一个标准的MO-LR结果投递任务（参照6.2流程）。

  • 寻找目标：GMLC根据请求中的LCS客户端ID，在其客户列表中查找“5G领航救援中心”的注册信息和联系地址（例如，一个通过NEF暴露的服务API端点）。
  • 投递结果：GMLC调用Ngmlc_Location_LocationUpdateNotify或类似的服务，将老李的精确位置，推送给“5G领航救援中心”的后台服务器。

救援中心的电子地图上，一个代表老李车辆的图标，被精准地标记在了郊外公路的某个坐标点上，并附带了“紧急救援请求”的标签。调度员立即派出了最近的拖车。

3.4 第四、五步：跨越代际的“回执”

一次可靠的服务，不仅要“送达”，还要有“确认”。

  1. For non-roaming case and if 5GC GMLC and EPC GMLC are combined, this step is skipped. Otherwise if the identified LCS Client is not accessible, the EPC GMLC sends a Location Update Notification response to AMF with an appropriate error cause. Otherwise, the response shall include an acknowledgement.
  2. Steps 13-14 in clause 9.2.6 of TS 23.271 are performed.

这是一条逆向的确认链，其重要性不亚于正向的请求链。

  1. 5G内的确认：“5G领航救援中心”收到位置后，会向5GC GMLC返回一个确认消息。
  2. “翻译”与跨代传递 (Step 4)：5GC GMLC（或融合GMLC的“5G部门”）收到确认后，将其“翻译”成4G的Diameter响应消息，传递给EPC GMLC（或“4G部门”）。
  3. 4G内的确认传递 (Step 5)：EPC GMLC再将这个确认，沿着**GMLC → MME → UE (T-Box)**的路径，原路返回。
  4. 最终的反馈：老李车上的T-Box最终会收到一个“传输成功”的确认。车载系统屏幕上可能会显示：“救援请求已发送，请原地等待！”

这个完整的确认闭环，确保了老李明确知道他的求救信号已经被成功接收，极大地缓解了他的焦虑。

4. 总结：兼容并包，服务至上

6.13.2流程，与6.13.1一起，构成了5G LCS互联互通能力的“一体两面”。它深刻地体现了3GPP在设计5G时，对向后兼容（Backward Compatibility）和业务连续性的高度重视。

  • 方向的反转，逻辑的对称：MO-LR的互通流程，在逻辑上与MT-LR形成了一种优美的对称。MT-LR是5G GMLC向EPC GMLC“下达指令”，MO-LR则是EPC GMLC向5GC GMLC“提交报告”。两者都以融合/互通的GMLC为核心枢纽，实现了异构网络间的无缝对话。
  • UE配置的关键性：在这个流程中，UE（T-Box）预先配置的正确GMLC地址是整个流程得以启动的“钥匙”。这凸显了在物联网应用中，终端侧预配置和管理的极端重要性。
  • 端到端的可靠性：通过设计一条完整的、跨越代际的确认回执链，规范确保了这种“位置共享”服务是可靠的、可信的，而不仅仅是“发后不理”的单向通知。

对于像老李这样的亿万存量4G用户，以及部署了海量4G物联网终端的企业而言，这套互通流程是他们能够享受到新兴5G应用服务的“桥梁”。它确保了5G的创新不会成为一个封闭的“孤岛”，而是能够赋能和盘活广阔的4G存量世界，真正实现了“一张网络，两代技术，统一服务”的宏大愿景。

FAQ - 常见问题解答

Q1：在这个MO-LR流程中，是谁完成的定位计算？5G的LMF还是4G的E-SMLC？ A1：是4G的E-SMLC。因为请求是由身处4G网络的UE发起的，整个定位的“执行”阶段都在EPC内部完成。EPC GMLC会委派一个E-SMLC去获取UE的位置。5G核心网在这个流程中，主要扮演的是“接收和投递”上游（EPC）送来的现成位置结果的角色，它不参与本次定位的计算。

Q2：为什么UE需要预先配置GMLC的地址？它不能直接告诉网络它想把位置发给哪个App吗？ A2：在4G/5G的LCS架构中，GMLC是外部LCS客户端接入运营商网络的唯一入口。UE和MME并不知道海量App后台（AF）的具体地址。它们只认识“GMLC”这个“总服务台”。因此，UE必须在请求中指明它要去哪个“服务台”办理业务。这个GMLC地址通常由App服务提供商（如“5G领航救援中心”）与运营商协商确定，并在T-Box出厂或App安装时预配置进去。

Q3：如果老李的T-Box没有配置GMLC地址，或者配置错了，会发生什么？ A3：MO-LR位置共享流程将失败。当MME收到T-Box的请求后，如果请求中没有GMLC地址，MME不知道该将这个请求转发给谁。MME可能会拒绝这个请求，并通过NAS消息向T-Box返回一个失败原因，例如“目标地址缺失”。车载屏幕上可能会显示“救援服务不可用”。

Q4：这个流程中的“融合GMLC”是一个强制要求吗？ A4：不是强制的，但它是强烈推荐且最主流的部署方式。如果5GC GMLC和EPC GMLC分离部署，它们之间就需要通过标准化的Lr等接口进行交互。这不仅增加了网络配置的复杂性，也引入了额外的信令跳数和时延。将两者功能融合在同一个网元上，通过内部接口进行高效交互，是实现平滑演进、降本增效的最佳实践。

Q5：这个流程可以用于非紧急的商业应用吗？比如，一个4G的物流追踪器，向一个5G的云平台汇报位置。 A5：完全可以。6.13.2的流程是通用的，它并不局限于紧急服务。任何一个身处4G网络的终端，只要它被正确配置了目标5G服务所对应的GMLC地址，并且其签约数据允许使用MO-LR位置共享服务，都可以利用这个流程，将其位置上报给一个5G世界的第三方应用。这为海量的存量4G物联网设备接入新兴的5G应用平台，提供了标准化的技术路径。

关系图谱