51学通信

深度解析 3GPP TS 23.273：6.1.2 5GC-MT-LR Procedure for the commercial location service (商业定位服务流程)

20分钟阅读

深度解析 3GPP TS 23.273：6.1.2 5GC-MT-LR Procedure for the commercial location service (商业定位服务流程)

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.1.2 5GC-MT-LR Procedure for the commercial location service”的核心章节。本文将通过一个我们日常生活中最熟悉的外卖场景，详细拆解商业定位服务请求的完整生命周期，揭示它与监管类定位在流程上的根本差异，特别是其精巧而严密的多级隐私保护机制。

1. 序章：一份外卖背后的“隐私协商”

在上一篇文章中，我们见证了5G监管类定位服务如何在万分危急的时刻，以最高权限和效率拯救了探险家“小李”。现在，让我们回归到和平而充满烟火气的都市生活。

晚上8点，白领“小美”结束了一天的辛勤工作，饥肠辘辘的她打开了手机上的“美味速达”App，点了一份心心念念的麻辣烫。付款后，App界面跳转，一个动态地图出现，上面有一个小摩托图标，代表着外卖骑手“小张”的实时位置。小美可以清晰地看到小张从商家取餐，然后穿过几条街道，正朝自己的方向驶来。

这个我们习以为常的功能，正是**商业类定位服务（Commercial Location Service）**最典型的应用。然而，这看似简单的位置更新背后，却隐藏着一场由5G网络主导的、远比紧急救援复杂得多的“隐私协商”。网络必须在满足小美（通过App）的位置查询需求和保护小张（外卖骑手）的个人隐私之间，找到完美的平衡点。

今天，我们将跟随小美这份麻-辣烫的配送之旅，深入剖析TS 23.273规范中商业MT-LR流程的每一个环节，看看5G网络是如何在提供便捷服务的同时，坚定地扮演着用户隐私“守门人”的角色。

2. 商业请求的“第一道关”：GMLC的隐私预审 (Steps 1-3)

与监管类请求的“畅通无阻”截然不同，商业请求从一开始就要面临严格的审查。流程图“Figure 6.1.2-1: 5GC-MT-LR Procedure for the commercial location services”详细描绘了这场“协商”的每一步。

2.1 第一步：来自App的商业请求 (Step 1: LCS Service Request)

小美在App中点击“查看骑手位置”的瞬间，“美味速达”的后台服务器（扮演LCS客户端或AF）便向运营商的GMLC（网关移动定位中心）发起了对骑手小张的MT-LR请求。

  1. The LCS Client, the NF or the AF (via NEF) sends a request to the (H)GMLC for a location… The request may include the required QoS, supported GAD shapes and other attributes. (H)GMLC … authorizes the LCS Client…

这个请求与监管类请求在内容上相似（包含QoS、目标UE标识等），但其Client Type被明确标记为“增值服务”（Value Added Services）。GMLC看到这个标记，便知道必须启动商业流程的“重重关卡”。

第一重授权：GMLC首先要验证“美味速达”App本身是否是合法的、已签约的LCS客户，是否有权使用运营商的定位能力。这是对服务请求方（App）的授权。

2.2 第二、三步：UDM的“隐私档案”调阅 (Step 2 & 3: Privacy Check & AMF Query)

对App的授权只是开始，真正的核心在于对被定位者——骑手小张——的隐私保护。

  1. The (H)GMLC invokes a Nudm_SDM_Get service operation towards the UDM of the target UE to get the privacy settings of the UE identified by its GPSI or SUPI. The UDM returns the target UE Privacy setting of the UE. The (H)GMLC checks the UE LCS privacy profile.

这是商业流程的第一个、也是最关键的“隐私门禁”。GMLC必须向UDM（统一数据管理）查询小张的“LCS隐私配置文件”。这份档案里详细记录了小张（或其所属的公司为其统一配置的）关于定位的个人意愿。

这份隐私档案可能包含以下几种设置：

  • 允许定位：允许“美味速达”App在特定条件下（如配送期间）定位。
  • 需要通知：定位前，需要在小张手机上弹窗告知。
  • 需要验证：定位前，不仅要通知，还必须得到小张的明确授权（点击“同意”）。
  • 不允许定位：完全禁止此App的定位请求。

GMLC的决策：

  • 如果隐私档案显示“不允许定位”，GMLC会立即拒绝“美味速达”的请求，整个流程到此结束。小美的App上可能会显示“无法获取骑手位置”。
  • 如果隐私档案显示“允许”或“需要通知/验证”，GMLC才会继续下一步，向UDM查询小张当前的服务AMF地址（Step 3）。

这一步确保了任何商业定位都必须首先尊重用户在UDM中预设的隐私主权。

场景模拟 - 第一阶段： GMLC收到请求，首先确认“美味速达”是签约客户。然后，它向UDM查询骑手小张的隐私档案。档案显示：对于“美味速达”这个LCS客户端，隐私策略是“需要通知和验证（positioning requires notification and verification）”。GMLC记录下这一重要指令，并从UDM获取了小张当前所在区域的AMF地址，准备将任务和“隐私指令”一并下发。

3. 第二道关：UE侧的“当面确认” (Steps 6-9)

GMLC的预审通过后，请求被转发给了AMF。现在，AMF将扮演“执行者”的角色，严格按照GMLC传递来的“隐私指令”，与小张的手机进行直接交互。

3.1 第六步：寻呼UE（如果需要）

  1. If the UE is in CM IDLE state, the AMF initiates a network triggered Service Request procedure … to establish a signalling connection with the UE.

如果小张此时正在等红灯，手机处于CM_IDLE（空闲省电）状态，AMF会首先发起寻呼，将他的手机唤醒并建立信令连接。

3.2 第七、八步：隐私通知与验证的执行

这是商业流程的第二个核心“隐私门禁”，也是用户能直接感知的环节。

  1. If the indicator of privacy check related action indicates that the UE must either be notified or notified with privacy verification…, a notification invoke message is sent to the target UE…
  2. The target UE notifies the UE user of the location request and, if privacy verification was requested, waits for the user to grant or withhold permission.

根据GMLC在第一阶段获取的指令，AMF知道必须进行“通知和验证”。于是：

  1. AMF 发送通知：AMF通过N1接口，向小张的手机发送一条NAS（非接入层）消息，其中包含了“位置通知请求”。
  2. UE 弹出交互界面：手机的操作系统或通信模组收到该消息后，会在屏幕上弹出一个系统级的对话框，内容可能是：“‘美味速达’App正在请求获取您的位置信息”，下方有两个按钮：[允许] 和 [拒绝]。
  3. 用户决策与响应：小张作为外卖骑手，知道这是工作流程的一部分，于是点击了**[允许]**。手机将这个“允许”的响应通过NAS消息回传给AMF。

这个过程确保了即使用户在UDM中预设了允许，在每一次具体的定位事件发生时，用户依然拥有临时的、最终的否决权。

3.3 第九步：隐私偏好的动态更新

  1. The AMF invokes the Nudm_ParameterProvision_Update (LCS privacy) service operation to store in the UDM the Location Privacy Indication information received from the UE.

规范还设计了一个非常人性化的功能。在小张点击“允许”的同时，手机弹窗上可能还有一个“记住我的选择，30天内不再询问”的复选框。如果小张勾选了它，这个“允许”的响应中就会包含一个新的LPI（位置隐私指示）。AMF在收到后，会通过Nudm_ParameterProvision_Update服务，将小张的这个新偏好更新回UDM的隐私档案中。这样，在接下来的30天里，GMLC在第一道关（Step 2）就能直接判断为“允许”，从而跳过UE侧的弹窗打扰，提升了用户体验。

4. 核心定位执行与“第三道关”：地理隐私 (Steps 10-23)

在UE侧的隐私“绿灯”亮起后，接下来的核心定位执行流程（Steps 10-15）在技术上与我们上一篇分析的监管类流程非常相似：AMF选择LMF → AMF委派任务给LMF → LMF与UE/RAN交互进行定位计算 → LMF将结果返回给AMF → AMF将结果返回给GMLC。

然而，商业流程在结果上报前，还可能存在第三个“隐私门禁”——地理位置隐私检查。

  1. If the privacy check in step 2 indicates that further privacy checks are needed, the (H)GMLC shall perform an additional privacy check… One example when this additional privacy check is needed is when the target UE user has defined different privacy settings for different geographical locations.

场景设定：假设骑手小张在他的隐私档案中，除了对App的授权规则外，还设定了一条高级规则：“我家方圆500米内，为我的‘个人隐私区’，禁止任何商业定位”。

在这种情况下，GMLC在Step 2检查隐私档案时，就会发现存在这条高级地理规则。于是，整个定位流程会变成一个巧妙的“两步走”策略：

  1. 第一步：粗略定位与地理围栏判断。GMLC会先发起一次“静默的”、低精度的定位（例如，仅获取小区ID），其唯一目的就是判断小张当前是否在他的“个人隐私区”内。
  2. 第二步：决策与精确定位。
    • 如果在区域内：GMLC会直接拒绝定位请求，保护小张的隐私。小美的App上可能会显示“骑手正在休息区，暂不更新位置”。
    • 如果不在区域内：GMLC才会继续启动我们前面描述的、包含用户通知和验证的完整高精度定位流程（Steps 17-23）。

这个精巧的设计，在不牺牲核心区域隐私的前提下，保证了正常工作区域的定位服务可用性，体现了5G隐私保护的高度灵活性和人性化。

5. 流程终点：结果交付 (Step 24)

历经重重关卡，GMLC终于拿到了一个合规、精确的位置结果。

  1. The (H)GMLC sends the location service response to the LCS Client, the NF or the AF (via the NEF) if the target UE is allowed to be located…

GMLC将小张的地理坐标发送给“美味速达”的后台服务器。服务器再通过互联网将这个位置信息推送到小美的手机App上。

故事结局：小美看着地图上平滑移动的摩托车图标，安心地等待着她的麻辣烫。而骑手小张的隐私权利，在5G网络这套严谨、周密的商业定位流程的守护下，也得到了充分的尊重和保障。

6. 总结：商业定位的“平衡艺术”

与监管类定位的“雷厉风行”相比，5G商业MT-LR流程展现的是一种**“平衡的艺术”。它在服务提供商、用户和网络之间建立了一套基于信任和协商**的规则体系：

  • 多级隐私门禁：从GMLC对UDM档案的预审，到AMF在UE侧的实时验证，再到可能的地理位置隐私检查，构成了纵深防御体系，确保了用户隐私的“层层加锁”。
  • 用户最终决定权：即使在预设了“允许”的情况下，UE侧的实时验证机制也赋予了用户在关键时刻的“一票否决权”。
  • 动态与便利的平衡：通过LPI的动态更新机制，在保证安全的前提下，又避免了频繁弹窗对用户的过度打扰，在安全与便利之间取得了良好平衡。

这套流程的设计哲学，深刻地反映了5G时代对个人数据权利的尊重。它向我们证明，技术的发展不仅能带来更便捷的服务，也能构建起更强大的隐私保护壁垒。

FAQ - 常见问题解答

Q1：监管类和商业类MT-LR流程最核心的区别是什么？ A1：最核心的区别在于对用户隐私的处理方式。监管类流程拥有最高权限，可以无条件覆盖（override）用户的所有隐私设置，流程追求的是极致的速度和必达性。而商业类流程的核心是协商与授权，它设置了多重隐私检查关卡（UDM预审、UE实时验证、地理围栏检查），每一步都必须在尊重用户隐私设置的前提下进行，用户拥有最终决定权。

Q2：在我手机上弹出的“App请求位置”的弹窗，是App自己弹出的还是网络弹出的？ A2：根据6.1.2流程，这个弹窗是由网络侧（AMF）通过系统级的NAS信令触发，由手机的操作系统或通信模组来响应并呈现的。它不是App自己能够随意弹出的应用层弹窗。这确保了该验证过程的权威性和安全性，App无法绕过这个由网络控制的隐私验证环节。

Q3：如果骑手小张一直不理会手机上的定位授权请求，会发生什么？ A3：规范定义了“no response”的场景。AMF在发送通知后会启动一个计时器。如果在预设的时间内（例如30秒）没有收到用户的响应（允许或拒绝），AMF会将其判定为“无响应”。根据隐私策略的配置，这通常等同于“拒绝”。AMF会向GMLC上报一个失败的结果，小美的App上将无法看到骑手的位置更新，并可能提示“获取骑手位置超时”。

Q4：地理位置隐私检查（如“家庭隐私区”）这个功能，需要用户如何设置？ A4：这通常需要运营商或设备制造商提供相应的用户界面。用户可能可以在手机的“设置”菜单中，或通过运营商的官方App，来定义自己的隐私区域。用户在地图上画一个圈，并将其标记为“家”或“公司”，然后设定“在此区域内禁止商业定位”的规则。这些设置最终会被转换为策略数据，存储在运营商核心网的UDM中。

Q5：整个商业定位流程这么复杂，会不会导致我看到的外卖骑手位置有很大延迟？ A5：不会。尽管流程步骤繁多，但5G核心网的信令交互速度极快，整个流程（尤其是在用户已预授权、无需实时弹窗的情况下）通常能在几秒钟内完成。对于需要持续追踪的场景（如外卖），App通常会发起一个周期性定位请求。首次请求可能需要完整的隐私协商，但一旦授权，后续的周期性更新流程会大大简化，从而确保您在地图上看到的是平滑、准实时的移动轨迹。

关系图谱