51学通信

深度解析 3GPP TS 23.273：附录A & B & C - 5G定位的演进、智慧与融合

19分钟阅读

深度解析 3GPP TS 23.273：附录A & B & C - 5G定位的演进、智慧与融合

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，内容丰富的三个附录（Annex A, B, C）。本文旨在通过一个“温故而知新”的视角，将这些看似零散、实则蕴含深意的附录内容进行整合解读，为读者揭示5G定位服务在**演进兼容性（与4G的差异）、决策智能化（隐私选择）和架构融合化（PNI-NPN）**三个维度上的深刻思考与精妙设计。

1. 序章：站在巨人的肩膀上，眺望融合的未来

至此，我们已经完成了对3GPP TS 23.273核心流程和服务的系统性剖析。然而，任何一部伟大的法典，除了正文的条款，其附录部分往往隐藏着理解其立法精神、历史沿革和未来应用的“金钥匙”。本规范的附录A、B、C正是如此。

它们分别回答了三个深刻的问题：

  • 附录A (Differences with TS 23.271)：我们从哪里来？5G定位相比4G（EPS）到底在哪些核心参数和信息存储上做了“加减法”？这关乎网络的平滑演进与互通。
  • 附录B (LCS privacy selection rule in serving NF)：当规则变得复杂时，我们该如何决策？它为网络功能（NF）在面对多重隐私策略时，提供了一套清晰、可视化的决策流程图，是LCS智慧的体现。
  • 附录C (PNI-NPN architecture…)：我们如何与专网世界融合？它展示了5G定位服务是如何适配公专网一体化（PNI-NPN）这一前沿部署模式，实现信令优化的，是LCS融合能力的展现。

今天，我们将不再引入新的主角，而是邀请之前的所有角色——巡检员老王、智慧工厂的AGV、户外探险家小李——共同“返场”，从他们的故事中，提炼出这三个附录所蕴含的深刻洞见。

2. 温故：5G与4G的“代沟”与“传承” (附录A)

Annex A (informative): Differences with TS 23.271

附录A就像一部“LCS编年史”，它通过一系列对比表格，详细地罗列了5G LCS（本规范）与4G/EPS LCS（TS 23.271）之间的关键差异。理解这些差异，对于处理我们在6.13和6.19章节中探讨的5G/4G互通与连续性问题至关重要。

2.1 “语言”的进化：定位请求参数的差异 (Table A.1-1)

定位请求参数差异解读与影响
Target UE Identity5G使用GPSI/SUPI，4G使用MSISDN/IMSI这是最根本的身份标识差异。在互通时，GMLC和UDM/HSS必须能够在这两套身份体系间进行翻译和映射。
Called Party Number5G不支持4G中用于某些与呼叫相关的定位场景，在5G中被更通用的机制所取代。5G GMLC在收到4G传来的请求时，应忽略此参数。
Type of a deferred location request5G新增了对UE可用性、区域、移动等多种事件的支持5G的延迟定位能力远比4G强大和丰富。当5G的延迟任务需要切换到4G网络执行时（如6.19.2.1），5GC GMLC必须进行能力映射，将复杂的5G事件简化为4G能理解的模式（通常是退化为周期性定位）。

2.2 “思想”的变革：信息存储的差异 (Table A.2-1 & A.3-1)

这部分差异，深刻地体现了5G在隐私保护和架构设计上的理念变革。

信息存储项差异解读与影响
UE Privacy Universal Class5G不支持4G中的“万能钥匙”，一旦用户设置，允许任何LCS客户端定位。5G认为这种“一刀切”的授权风险太高，将其废除，强制要求所有定位都必须归入更精细的类别进行管理。
UE Location Privacy Indication (LPI)5G新增这是5G隐私保护的最大亮点。它赋予了用户通过信令动态修改全局隐私开关的能力（6.12.1），这是4G所不具备的。这也解释了为何在5G/4G互通时，对用户隐私状态的同步会成为一个挑战。
Call/session related Class5G不支持4G允许定位与一个正在进行的PS会话（如上网）相关联。5G简化了模型，将所有商业定位都归为“Unrelated”类别，通过更精细的“白名单”和“服务类型”进行管理，逻辑更清晰。

NOTE 1: A PLMN operator can avoid any difference in UE privacy support for EPS access versus 5GS access by only storing information for UE privacy … in a UDR (and UDM) and not in an HSS or GMLC.

这句NOTE给出了运营商实现平滑演进的最佳实践：将所有用户的LCS隐私策略，统一存储在5G的UDM/UDR中。即使是4G的GMLC，在进行隐私检查时，也应该去查询这个统一的数据源，而不是依赖HSS中可能存在的、过时的、不完整的4G隐私数据。这确保了用户无论在哪代网络下，其隐私意愿都能得到一致的、准确的尊重。

3. 知新（一）：当规则交叉时的“智慧”抉择 (附录B)

Annex B (informative): LCS privacy selection rule in serving NF

附录B为我们提供了一张极其珍贵的流程图（Figure B.1-1: Privacy selection flow diagram）。它不再是描述UE与网络间的信令交互，而是描绘了GMLC（或NEF）内部的决策逻辑。当一个MT-LR请求到来时，GMLC的“大脑”是如何运转的？

这张图，就是GMLC在执行我们在6.1.2商业定位流程中分析的“Step 2: Privacy Check”时的详细“思考过程”。

3.1 决策的起点：特权与全局开关

  1. 第一问：是否有“王牌”？ (POI requires to override privacy?)

    • 请求是否来自紧急服务或合法监听，并携带了POI（隐私覆盖指示符）？
    • 是 → 直接跳到终点，The location is allowed。这是最高特权，无视一切后续规则。
    • 否 → 进入常规商业流程。

  2. 第二问：“总开关”开了吗？ (LPI is valid?)

    • 查询UDM中用户的LPI（我们在7.1中分析的全局开关）。
    • LPI无效或不存在 → LPI指示“允许”，进入下一步精细规则检查。
    • LPI有效 → LPI指示“不允许”，直接跳到终点，The location is disallowed。

3.2 精细规则的“三堂会审”

如果全局开关是打开的，GMLC会开始一场“三堂会审”，优先级从高到低：

  1. 第一审：是否属于“内部人员”？ (PLMN Operator Class Criteria Met?)

    • 请求是否来自运营商内部的O&M、NWDAF等？
    • 是 → 检查PLMN Operator Class的设置。如果允许，则location allowed；否则disallowed。
    • 否 → 进入第二审。

  2. 第二审：是否属于“白名单”？ (Call/Session unrelated Class Criteria met?)

    • 请求的LCS客户端ID或服务类型，是否在用户的“白名单”或“服务类型列表”中？
    • 是 → 应用该条“白名单”规则（如“允许但需通知”），进入相应的隐私交互流程。
    • 否 → 进入第三审。

  3. 第三审：如何对待“陌生人”？ (Default Call/Session unrelated Class)

    • 对于这个“陌生”的客户端，应用用户设置的默认规则（如“默认禁止”）。

这张流程图，将GMLC复杂的隐私决策逻辑，以一种极其清晰、直观的方式呈现出来。它不仅是网络功能开发的“指导手册”，更是我们理解5G隐私保护体系严密性的“放大镜”。

4. 知新（二）：公专网一体化的“融合”之道 (附录C)

Annex C (informative): PNI-NPN architecture to support location service with signalling optimisation

附录C用一张架构图（Figure C-1 PNI-NPN architecture…），直观地展示了我们在6.13章节中详细分析过的PNI-NPN信令优化的“高速公路”是如何搭建的。

这张图的核心思想，就是信令的分流：

  • 蓝色线路（UE关联信令）：当智慧工厂的AGV（UE）接入本地的NG-RAN-1时，它的注册和移动性管理，依然由公共网络中的Serving AMF负责。所有与UE直接相关的信令（如LPP消息、NAS消息），都必须走这条“蓝色大动脉”。

    UE <-> NG-RAN 1 <-> Serving AMF (in Public network)

  • 红色线路（非UE关联信令）：当部署在本地的LMF，需要获取本地基站NG-RAN-2或NG-RAN-3的辅助信息时，它不再需要绕道遥远的公共网络。它将请求发送给部署在本地的Local AMF。

    LMF (in local) <-> Local AMF (in local) <-> NG-RAN 2/3 (in local)

    Local AMF在这里扮演了一个轻量级的、本地化的“信令路由器”。它与本地的RAN和LMF之间，通过N2和NLx接口，形成了一个低时延的本地信令闭环。

这张图的价值，在于它将抽象的“信令优化”概念，以一种可视化的拓扑结构呈现出来。它清晰地揭示了PNI-NPN架构如何通过引入Local AMF这个“旁路”，为本地的、非UE关联的定位信令，开辟了一条“红色快车道”，从而在不破坏公网统一管理的前提下，最大限度地满足了工业场景对低时延的极致追求。

5. 总结：演进、智慧、融合——5G定位的“三位一体”

附录A、B、C，这三个看似独立的章节，共同为我们揭示了5G定位服务设计的三个核心“元思想”：

  • 演进 (Evolution)：附录A告诉我们，5G定位并非空中楼阁，它是站在4G巨人肩膀上的演进。它在继承核心理念的同时，大胆地“做减法”（如废除Universal Class）和“做加法”（如引入LPI），使其架构更合理、隐私保护更完善。

  • 智慧 (Intelligence)：附录B告诉我们，5G定位的规则可以是复杂的，但其决策逻辑必须是清晰、严谨的。这张隐私选择流程图，就是网络功能（NF）内部嵌入式智能的体现。它确保了在多种策略交叉时，总能做出唯一、正确的裁决。

  • 融合 (Convergence)：附录C告诉我们，5G定位的边界是开放的。它能够通过PNI-NPN等创新架构，将自身的能力与垂直行业的专网需求深度融合，通过信令分流等优化手段，满足最严苛的工业级应用要求。

这“三位一体”的思想，贯穿了整个TS 23.273规范的设计。它确保了5G定位服务，不仅在技术上是先进的，在演进上是平滑的，在决策上是智能的，在应用上更是融合开放的。这，正是一个能够引领未来十年发展的技术标准，所应具备的宏大格局与深邃智慧。

FAQ - 常见问题解答

Q1：附录中的内容是强制性的（Normative）还是参考性的（Informative）？ A1：本规范中的附录A、B、C都是参考性的（Informative）。这意味着它们不包含强制性的协议要求，而是为了帮助读者更好地理解规范正文、提供实现示例或背景信息。例如，附录B的流程图，是GMLC隐私检查逻辑的一种“推荐实现”，厂商在开发产品时可以参考，但并非必须一模一样地实现，只要其最终行为符合正文中的规定即可。

Q2：5G废除了“Universal Class”，是否意味着用户无法再像过去一样，简单地“一键授权”所有定位了？ A2：是的。从纯粹的LCS隐私配置文件角度看，5G不再提供这种“无差别”的授权类别。这体现了5G对隐私保护的更高要求，鼓励用户进行更精细化的授权。但在实际使用中，手机的**操作系统（OS）**层面，通常依然会提供“始终允许所有App”这样的便捷开关。当用户选择它时，OS可能会在后台，为每一个新安装的、请求定位的App，都自动地、单独地在UDM中创建一条“允许”的规则，从而在用户体验上模拟出“一键授权”的效果。

Q3：PNI-NPN架构中的Local AMF，和我们之前谈到的服务于不同接入类型的多个AMF，是什么关系？ A3：它们是完全不同的概念。在6.9.2中，我们谈到的多个AMF（AMF-1, AMF-2），它们都是完整的、服务于UE的AMF，只是服务的接入类型不同。而PNI-NPN中的Local AMF，是一个功能简化的、不服务于UE的AMF。它的唯一职责，就是作为本地网络中、非UE关联信令的路由节点。当AGV（UE）注册时，它会注册到公共网络的Serving AMF，而绝不会注册到Local AMF。

Q4：为什么附录B的隐私选择流程图中，Call/Session related Class被完全忽略了？ A4：因为如附录A（Table A.2-1）所述，5G核心网（5GS）的LCS隐私模型中，已经不再支持Call/Session related Class。所有商业定位都被归为Call/Session unrelated Class。因此，在为5GS设计的隐私选择流程图中，自然就不再包含这个已经被“废弃”的类别了。

Q5：学习完这些附录，对我们理解整个5G定位服务有什么实质性的帮助？ A5：有巨大的帮助。它们能让你从“知其然”到“知其所以然”。

  • 附录A让你理解了5G/4G互通流程（6.13, 6.19）背后，那些“QoS映射”、“参数忽略”等操作的根本原因。
  • 附录B让你将抽象的“隐私检查”四个字，变成了一套可以编码实现的、清晰的逻辑树。
  • 附录C让你将抽象的“信令优化”四个字，变成了一幅具体的、可视化的网络拓扑。 这三个附录，是从历史、逻辑和架构三个维度，对整个规范核心思想的“升华”与“图解”，是通往真正精通5G定位服务的必经之路。

关系图谱