51学通信

深度解析 3GPP TS 23.273：5G定位服务(LCS) Stage 2 全景概览

27分钟阅读

深度解析 3GPP TS 23.273：5G定位服务(LCS) Stage 2 全景概览

本文将对3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范进行一次全面的总结性介绍。本文旨在通过一个贯穿始终的应用场景，为读者描绘出5G系统定位服务（LCS）的宏伟蓝图，让通信行业的工程师和高校学生对整个规范的核心架构、关键特性及主要流程有一个清晰的、全局性的初步了解。

前言：开启万物互联的“眼睛”

欢迎来到5G的世界，一个不仅仅关乎速度，更关乎万物智能互联的时代。从自动驾驶汽车到智慧物流，从工业物联网到个人紧急救援，精确、可靠的位置信息正成为无数创新应用的基石。而为这一切提供标准化技术支撑的，正是我们今天要深入探讨的核心规范——3GPP TS 23.273，它定义了5G系统（5GS）中的定位服务（Location Services, LCS）。

想象一下，这篇规范就像是为整个5G网络装上了一双无处不在的“眼睛”，使其具备了感知终端（UE）地理位置的能力。它不仅告诉我们“终端在哪里”，还详细规定了“谁可以问”、“在什么条件下可以问”、“如何问”以及“如何保护用户隐私”等一系列复杂而关键的问题。

为了让这次技术之旅不再枯燥，我们引入一位特殊的“主角”——“探路者-01”号物流无人机。它是一家大型物流公司的明星员工，负责在繁忙的都市中执行高精度的配送任务。“探路者-01”的一天，将完美映射出TS 23.273规范中几乎所有核心概念和流程。

跟随“探路者-01”的航迹，我们将一同揭开5G定位服务的神秘面纱，鸟瞰TS 23.273规范的全貌。

1. 规范概述与核心范畴 (Scope & References)

在深入技术细节之前，我们首先需要明确TS 23.273的定位和范畴。

The present document specifies the stage 2 of the service-based architecture used for location services in the 5G system, and corresponding Network Functions (NFs), NF services and procedures, to meet the service requirements defined in TS 22.261 and TS 22.071.

这段原文精确地定义了本文档的性质。它是一份**“Stage 2”**规范，这意味着它聚焦于系统架构和功能流程层面，描述网络功能（NF）之间如何交互以实现定位服务，但并不过度深入到具体接口协议的比特层面（那是Stage 3规范的任务）。它旨在满足TS 22.261（5G系统业务需求）和TS 22.071（LCS业务需求）中提出的高层要求。

简单来说，TS 23.273就是5G定位服务的**“系统设计说明书”**。它涵盖了两大类服务：

  • 监管类定位服务 (Regulatory Location Services): 例如，紧急呼叫（E911）时的用户定位，这是法律强制要求的服务，具有最高的优先级和隐私覆盖权限。
  • 商业类定位服务 (Commercial Location Services): 例如，地图导航、车队管理、社交打卡、精准广告推送等。这类服务的多样性和对隐私的敏感性，对架构的灵活性和安全性提出了极高要求。

现在，让我们回到主角“探路者-01”。它的日常工作中，就同时涉及了这两类服务。物流公司的**“无人机调度中心”**需要实时跟踪它的位置，这属于商业LCS；而一旦“探路者-01”遇到紧急故障需要迫降，它自动触发的求救信号就需要网络为其提供监管级的定位服务，以便救援队快速响应。

2. 核心架构与关键角色 (Chapter 4: Architecture Model and Concepts)

第四章是整个规范的基石，它定义了5G定位服务的“舞台”和“演员”。

Location information for one or multiple target UEs may be requested by and reported to an LCS client or an AF within or external to a PLMN or SNPN, or a control plane NF within a PLMN or SNPN.

这里点明了定位服务的发起者——LCS客户端 (LCS Client) 或 应用功能 (AF)。在我们的故事里，物流公司的“无人机调度中心”就是一个外部LCS客户端。它通过网络提供的标准接口，来请求“探路者-01”的位置。

为了实现这个请求，5G核心网内部有几个关键的网络功能（NF）协同工作，它们是LCS架构的核心。规范中的“Figure 4.2.1-1: Non-roaming reference architecture for Location Services in reference point representation”清晰地展示了这些角色及其关系。

我们来认识一下这些核心演员：

2.1 网关移动定位中心 (GMLC - Gateway Mobile Location Centre)

GMLC是LCS服务的“总前台”和“安全门卫”。所有来自外部LCS客户端的定位请求，第一站就是GMLC。

它的职责包括：

  • 授权认证： 验证“无人机调度中心”是否有权限查询“探路者-01”的位置。
  • 隐私检查： 查询用户（即无人机的所有者）的隐私设置，决定是否允许此次定位。
  • 路由寻址： 找到管理“探路者-01”当前接入和移动性的AMF。
  • 计费记录： 为商业定位服务生成计费信息。

2.2 接入与移动性管理功能 (AMF - Access and Mobility Management Function)

AMF是终端的“移动管家”。它负责终端的注册、连接、移动性管理，因此它始终知道终端当前的大致位置（例如，在哪一个跟踪区TA）。在LCS流程中，AMF扮演着“承上启下”的角色。

当GMLC发来定位请求后，AMF负责：

  • 找到UE： 如果“探路者-01”处于空闲状态，AMF会发起寻呼，唤醒它。
  • 选择LMF： AMF会根据UE的能力、当前位置、QoS要求等信息，选择一个最合适的LMF来执行具体的定位计算。
  • 消息中转： 作为UE和LMF之间定位信令（例如LPP协议消息）的透明传输通道。

2.3 定位管理功能 (LMF - Location Management Function)

LMF是LCS的“技术大脑”和“计算核心”。它负责管理和执行所有与定位测量和计算相关的复杂技术工作。

LMF的主要工作是：

  • 定位方法决策： 根据AMF传递来的QoS要求（如精度、时延），以及UE和网络的能力，决定采用哪种或哪几种定位技术（如GNSS、小区ID、往返时间RTT、到达时间差TDOA等）。
  • 协同定位过程： 与UE（“探路者-01”）和RAN（基站）进行交互，分发辅助数据（如GNSS星历），收集测量报告。
  • 位置计算： 最终根据收集到的测量数据，计算出UE的精确地理坐标。

2.4 统一数据管理 (UDM - Unified Data Management)

UDM是“用户数据中心”。它存储着与用户相关的所有签约数据，其中就包括LCS隐私设置。当GMLC需要进行隐私检查时，就会向UDM发起查询。

场景串联： 清晨，“探路者-01”准备从仓库出发。调度中心（LCS Client）通过互联网向运营商的GMLC发起了一个针对“探路者-01”的周期性定位请求（例如，每5秒报告一次位置）。

  1. GMLC接到请求，首先认证了调度中心的合法性，然后向UDM查询，确认该无人机的隐私档案允许被其所有者（物流公司）跟踪。
  2. GMLC随后向UDM查询“探路者-01”当前归属的AMF地址。
  3. GMLC将定位请求转发给这个AMF。
  4. AMF收到请求，发现“探路者-01”正准备起飞，处于连接状态。AMF根据调度中心要求的高精度（例如5米），为它选择了一个支持高精度定位的LMF。
  5. AMF将请求传递给LMF，并告知“探路者-01”的连接信息。
  6. LMF正式接管，开始与“探路者-01”和基站进行交互，准备执行具体的定位任务。

这个简单的启动过程，就将LCS的核心架构串联了起来。

3. 丰富多样的定位请求类型 (Chapter 4.1a: Types of Location Request)

TS 23.273定义了多种灵活的定位请求模式，以适应不同的业务需求。

  • 移动终端终结的定位请求 (MT-LR - Mobile Terminated Location Request): 这是最常见的类型，由网络侧的LCS客户端发起，请求获取某个UE的位置。我们上面“调度中心”的例子就是典型的MT-LR。

  • 移动终端发起的定位请求 (MO-LR - Mobile Originated Location Request): 由UE自己发起，请求网络计算自己的位置，或者请求网络将自己的位置发送给某个第三方LCS客户端。例如，“探路者-01”在配送完成后，可以主动上报自己的精确降落位置给调度中心。

  • 网络诱发的定位请求 (NI-LR - Network Induced Location Request): 由网络内部功能（通常是AMF）为特定目的发起。最典型的场景就是紧急呼叫，当UE发起紧急呼叫时，AMF会立即为这个UE触发一个NI-LR，以获取其位置提供给紧急服务中心。

此外，根据请求的实时性，又可分为：

  • 立即定位请求 (Immediate Location Request): 请求立即返回UE的当前位置。
  • 延迟定位请求 (Deferred Location Request): 为未来某个事件或条件设置一个“定位触发器”。这非常强大，规范定义了多种事件类型：
    • UE可用性 (UE availability): 当UE从不可达状态（如关机、无信号）恢复在线时，报告其位置。
    • 区域事件 (Area): 当UE进入、离开或停留在某个预设的地理围栏时报告位置。例如，调度中心可以为“探路者-01”设置一个“客户收货区”的地理围栏，当无人机进入该区域时自动通知客户准备收货。
    • 周期性定位 (Periodic Location): 按固定的时间间隔持续报告位置。
    • 移动事件 (Motion): 当UE移动超过预设的距离时报告位置。

4. 高阶特性：让定位服务更智能、更安全 (Chapter 5: High Level Features)

第五章是规范的精华所在，它定义了众多高级功能，使得5G定位服务远比前几代通信系统更加强大和完善。

4.1 UE LCS隐私 (UE LCS privacy)

这是商业LCS服务的生命线。TS 23.273构建了一套精细化的隐私控制框架。

The UE LCS privacy profile shall include information related to classes of LCS client, referred to as “privacy classes”, which are permitted, or conditionally permitted, to obtain location information for the UE.

用户的隐私配置文件（存储在UDM中）可以针对不同类别的LCS客户端设置不同的策略，例如：

  • 无条件允许定位。
  • 定位前需要通知用户。
  • 定位前需要用户明确授权（弹窗确认）。
  • 完全禁止定位。

更进一步，这些策略还可以绑定时间窗口（如只在工作时间允许公司定位）和地理区域（只在厂区内允许定位）。

同时，规范还定义了隐私覆盖指示符 (POI - Privacy Override Indicator)，专门用于紧急服务等监管类应用，可以无视用户的隐私设置，强制执行定位。

4.2 并发定位请求支持 (Support of Concurrent Location Requests)

在5G多业务场景下，一个UE可能同时被多个应用请求定位。比如，“探路者-01”在飞行时，调度中心在以5秒一次的频率跟踪它（请求A），同时，城市空中交通管理局为了空域管理，也在以10秒一次的频率查询它的位置（请求B）。

In either case, if allowed by the QoS requirements and privacy settings, the entity may combine the concurrent location requests by fully executing one of the requests and using the ensuing location estimate result(s) to satisfy the other request(s) without fully executing the latter.

规范允许网络实体（如AMF或LMF）智能地**“合并”**这些并发请求。例如，当请求A触发了一次高精度定位后，如果其结果也满足请求B的QoS要求，网络就可以直接用这次结果去响应请求B，而无需再重复执行一次定位流程，从而极大地节省了信令开销和UE的电量。

4.3 其他关键特性速览

  • LMF/GMLC发现与选择： 在复杂的网络环境中，AMF/GMLC如何智能地发现并选择最合适的LMF/GMLC来提供服务。
  • 与IMS互通： 当定位请求使用SIP-URI或TEL-URL（IMS体系中的身份标识）时，GMLC如何将其转换成核心网可识别的SUPI。
  • 用户面定位支持： 对于非监管类服务，定位信令可以通过用户面（User Plane）传输，为某些应用（如低时延游戏）提供更灵活的定位交互。
  • GNSS辅助数据采集： LMF如何从外部AF（例如GNSS数据提供商）获取辅助数据，并通过广播或专用信道下发给UE，以加速GNSS定位。
  • UE无感知定位 (UE Unaware Positioning): 在特定监管场景下（如追踪嫌疑人），即使UE处于空闲态，网络也可以在不寻呼UE的情况下，利用上行探测信号（SRS）等方式进行定位，实现对UE的“静默”定位。

5. 核心流程：一次定位请求的生命周期 (Chapter 6: Location Service Procedures)

第六章是规范的“操作手册”，用详细的信令流程图和步骤描述，展示了各种定位场景下的网络行为。这里我们以最经典的**“5GC-MT-LR商业服务流程”**（Figure 6.1.2-1）为例，看看“调度中心”获取“探路者-01”位置的全过程。

这个过程就像一场精心编排的戏剧：

  1. 【舞台幕后】 调度中心(LCS Client/AF) → GMLC: 发起ProvideLocation请求。
  2. 【GMLC的后台调查】 GMLC → UDM: SDM_Get，查询UE的隐私设置。UDM返回隐私档案。GMLC进行隐私检查，如果用户禁止，流程终止。
  3. 【寻找UE的管家】 GMLC → UDM: UECM_Get，查询UE当前的AMF地址。UDM返回AMF地址。
  4. 【GMLC的跨域委托】 如果UE在漫游，HGMLC → VGMLC: ProvideLocation请求。
  5. 【总委托下达】 (H/V)GMLC → AMF: ProvidePositioningInfo请求，将定位任务和QoS要求传递给AMF。
  6. 【AMF的准备工作】 如果UE空闲，AMF发起网络触发的服务请求（寻呼），激活UE。
  7. 【用户隐私交互】 如果隐私策略要求，AMF通过NAS消息通知UE，或请求UE用户授权。
  8. 【AMF选择专家】 AMF根据QoS和UE能力，选择一个LMF。
  9. 【任务交接给专家】 AMF → LMF: DetermineLocation请求，将所有定位相关信息交给LMF。
  10. 【LMF的专业操作】 LMF与UE/RAN进行信令交互（如LPP/NRPPa协议），下发辅助数据，收集测量报告。
  11. 【计算与出结果】 LMF完成位置计算，得到经纬度坐标。
  12. 【结果层层上报】 LMF → AMF → GMLC → LCS Client: 定位结果沿着请求路径原路返回。
  13. 【剧终】 调度中心的地图上，“探路者-01”的图标刷新到了最新的位置。

这只是众多流程中的一个。规范还详细定义了MO-LR、NI-LR、延迟定位的事件上报、跨5GS/EPS的移动性切换等各种复杂场景的流程。

6. 数据存储与服务接口 (Chapter 7 & 8)

最后，规范的第七章和第八章是对整个体系的“数据字典”和“API文档”进行定义。

  • 第七章 (Information storage): 详细定义了UDM和GMLC中需要存储的数据模型。例如，Table 7.1-1定义了UDM中LCS隐私配置文件的详细字段，如Location Privacy Indication、Call/session Unrelated Class等，这为运营商配置和开发用户隐私管理功能提供了依据。
  • 第八章 (Network Function Services): 以服务化接口（SBI）的视角，定义了LMF和GMLC对外提供的服务及其操作。例如，定义了Nlmf_Location服务，其中包含了DetermineLocation、EventNotify等操作。这使得5G核心网的各个NF可以像调用微服务一样，灵活地相互调用，实现解耦和可扩展性。

总结：TS 23.273的里程碑意义

通过对3GPP TS 23.273的全景概览，我们可以看到，它不仅仅是对前代定位技术的简单演进，更是一次面向5G服务化架构的全面重构和能力升级。

  • 架构更灵活： 基于SBA架构，GMLC, AMF, LMF等功能实体高度解耦，职责清晰，易于扩展和独立演进。
  • 功能更强大： 引入了精细化的隐私管理、丰富的延迟定位事件、对并发请求的智能处理等，满足了从垂直行业到个人应用的多元化需求。
  • 服务更融合： 统一了对3GPP接入和非3GPP接入（如Wi-Fi）的定位支持，并定义了与4G EPS网络的互通和移动性连续性，保证了服务的无缝体验。

“探路者-01”顺利完成了今天的配送任务，安全返航。在它的每一次起飞、每一次转向、每一次精准降落背后，都有TS 23.273所定义的这套精密、高效、安全的定位服务体系在默默守护。

这篇概览文章只是一个开始。在接下来的系列中，我们将逐一章节、逐一特性地深入到规范的每一个角落，真正掌握5G定位服务的精髓。

FAQ - 常见问题解答

Q1：GMLC 和 LMF 在5G定位架构中的核心区别是什么？ A1：可以形象地理解为：GMLC是“产品经理+法务”，LMF是“首席技术官+算法工程师”。GMLC面向外部客户，负责接收需求（是什么业务）、做权限和隐私的合规性审查，并找到处理该请求的内部团队。而LMF是技术实现的核心，它不直接与外部客户打交道，专注于研究如何最高效、最精确地完成定位计算（怎么实现），并管理与终端和基站的技术交互。

Q2：5G的定位隐私保护相比4G有哪些显著的增强？ A2：5G的隐私保护更加精细化和动态化。TS 23.273不仅支持传统的“允许/拒绝”模式，还引入了与地理位置、时间相关的动态隐私策略。更重要的是，引入了Location Privacy Indication (LPI)机制，允许UE随时通过NAS信令主动更新自己的隐私偏好（比如，暂时开启“请勿打扰”模式，禁止所有商业定位），这给了用户前所未有的自主控制权。

Q3：什么是延迟定位请求（Deferred Location Request），它有什么典型的应用场景？ A3：延迟定位请求不是立即要位置，而是设置一个未来的触发条件，当条件满足时网络才去定位并上报。这是一种非常高效的机制。典型场景包括：1）电子围栏：物流公司设置一个“仓库”区域，当货车进入该区域时，系统自动收到通知并记录到达时间。2）资产跟踪：在一个昂贵的设备上设置“移动即上报”的触发器，平时设备静止不动不耗电，一旦被非法移动超过50米，立即定位并告警。

Q4：为什么AMF在定位流程中扮演了如此重要的角色？ A4：AMF是UE在核心网的“第一联系人”，负责其移动性和连接状态管理。因此，它天然地成为定位流程中的关键枢纽。首先，只有AMF知道UE当前是否可达、在哪一片区域，是GMLC找到UE的必经之路。其次，AMF掌握了UE的接入网络类型、能力等信息，是选择最合适LMF的重要决策点。最后，UE与核心网之间的NAS信令都必须经过AMF，使其成为LMF与UE之间传输定位协议消息的天然通道。

Q5：TS 23.273是一份Stage 2规范，学习它之后，我还需要关注哪些相关的Stage 3规范？ A5：学习Stage 2规范可以让你理解系统架构和流程，但要进行具体开发，就必须深入Stage 3规范。与TS 23.273密切相关的Stage 3规范主要包括：TS 29.518 (AMF服务)、TS 29.572 (LMF服务)、TS 29.571 (GMLC服务) 定义了NF之间的服务化接口API；TS 24.501定义了UE与AMF之间的NAS消息，用于承载定位相关信令；TS 38.305 (NG-RAN) 和 TS 37.355 (LPP协议) 则定义了空口的定位能力和具体的定位信令协议。

关系图谱