51学通信

深度解析 3GPP TS 29.515：5.1 & 5.2 Ngmlc_Location服务 - GMLC的核心能力集

28分钟阅读

好的，我们无缝衔接上一篇的内容，继续深入探索3GPP TS 29.515规范的核心。现在，我们将进入这部规范的心脏地带——第五章，这里详细定义了GMLC究竟能为5G网络提供哪些具体的定位服务。

深度解析 3GPP TS 29.515：5.1 & 5.2 Ngmlc_Location服务 - GMLC的核心能力集

本文技术原理深度参考了3GPP TS 29.515 V18.8.0 (2025-03) Release 18规范中，关于**第五章“GMLC提供的服务”（Services offered by the GMLC）**的核心章节，特别是5.1节的引言和5.2节对Ngmlc_Location服务的宏观描述，并对其中最关键的服务操作ProvideLocation进行深度剖析，旨在为读者清晰地展示GMLC定位能力的全貌。

故事续篇：应急响应中的组合拳

在之前的章节中，我们陪伴应急调度员小李初步了解了GMLC的定位和角色。他知道GMLC是5G定位服务的总调度，也清楚了要通过阅读TS 29.515这份“API施工图纸”来与GMLC进行交互。现在，小李和他的技术团队面临着更具体的问题：这个GMLC到底能做些什么？我们能向它提出哪些类型的定位请求？是只能问“车在哪？”，还是可以下达更复杂的指令，比如“车到这个路口了告诉我”或者“把现场这个小队所有人的位置都给我”？

第五章的内容，将完美解答小李的所有疑问。它就像一份GMLC的能力清单和使用说明书，详细列出了GMLC所提供的每一项服务及其具体操作。让我们一起深入其中，看看小李在指挥“生命卫士-01”时，究竟能打出怎样一套眼花缭乱的定位服务“组合拳”。

1. 5.1 Introduction (引言)：GMLC的服务菜单

第五章的开篇，5.1节“Introduction”，通过两张高度概括的表格，为我们揭示了GMLC服务的全貌。这可以被视为GMLC的“主菜单”。

第一张表格，Table 5.1-1，从宏观上定义了GMLC提供了哪些服务（Service）以及每个服务下有哪些具体的操作（Service Operation）。

原文引用 (Chapter 5.1 Introduction):

The table 5.1-1 shows the GMLC Services and GMLC Service Operations:

现在，我们1:1重绘这张表格，并深入解读其内涵。

表 5.1-1: GMLC服务列表 (Table 5.1-1: List of GMLC Services)

Service NameService OperationsOperation SemanticsExample Consumer(s)
Ngmlc_LocationProvideLocationRequest/ResponseV-GMLC, H-GMLC, NEF, NWDAF, LMF, AMF
LocationUpdateRequest/ResponseAMF, V-GMLC
LocationUpdateNotifyNotifyNEF
CancelLocationRequest/ResponseH-GMLC, NEF, NWDAF
EventNotifyNotifyH-GMLC, NEF, NWDAF
PrivacyCheckIdMappingRequest/ResponseH-GMLC

这张表格是理解GMLC服务化能力的关键。

  • Service Name (服务名称)：GMLC目前只定义了一个核心服务，名为Ngmlc_Location。这体现了服务化架构“高内聚”的设计原则，所有与定位相关的能力都被聚合在这一个服务之下。
  • Service Operations (服务操作)：这是服务的具体“动作”。Ngmlc_Location服务包含了ProvideLocation、LocationUpdate等多个操作。这些操作构成了GMLC的“工具箱”，每个工具都有其独特的用途。
  • Operation Semantics (操作语义)：定义了操作的交互模式。
    • Request/Response：这是一次性的“请求-响应”模式。消费者发起一个请求，提供者处理后返回一个结果。例如，小李问“车现在在哪？”，GMLC回答“在XX路”，这就是一次典型的请求-响应。
    • Notify：这是“通知”模式，通常用于订阅场景。消费者预先订阅某个事件，当事件发生时，提供者会主动向消费者推送一个通知。例如，小李订阅了“救护车到达现场”事件，当GMLC检测到这一情况时，会主动“通知”小李的系统。
  • Example Consumer(s) (消费者示例)：列出了哪些网络功能（NF）可能会调用这些服务操作。这与我们在第四章分析的架构图完美对应。值得注意的是，NEF（网络开放功能）是ProvideLocation、CancelLocation和EventNotify等关键操作的消费者，这再次印证了它是外部应用（如小李的应急中心）访问GMLC服务的门户。

紧接着，规范通过Table 5.1-2将这些概念性的服务与具体的API实现关联起来。

表 5.1-2: API描述 (Table 5.1-2: API Descriptions)

Service NameClauseDescriptionOpenAPI Specification FileapiNameAnnex
Ngmlc_Location6.1Ngmlc Location ServiceTS29515_Ngmlc_Location.yamlngmlc-locA.2

这张表告诉开发者：关于Ngmlc_Location服务的所有技术细节（API的URI、参数、数据结构等），都在本规范的6.1章节中定义，并且其标准化的机器可读描述文件是TS29515_Ngmlc_Location.yaml，其API的简称是ngmlc-loc。这为后续的开发工作提供了清晰的指引。

2. 5.2 Ngmlc_Location Service (Ngmlc_Location服务)

从5.2节开始，规范对Ngmlc_Location这个核心服务进行了详细的阐述。

2.1 5.2.1 Service Description (服务描述)

本节用一段精炼的文字描述了Ngmlc_Location服务的核心价值。

原文引用 (Chapter 5.2.1 Service Description):

The Ngmlc_Location service enables an NF to request location determination (current geodetic and optionally local and/or civic location) for a target UE or to request relative locations, distance, or direction between UEs. The following are the key functionalities of this NF service:

  • Allow the consumer NF to request the current geodetic and optionally local and/or civic location of a target UE.
  • Allow the consumer NF to subscribe/unsubscribe the geodetic and optionally local and/or civic location of a target UE for some certain events.
  • Allow the consumer NF to cancel an on-going periodic or triggered location request of a target UE.
  • Allow the consumer NF to get notified about the geodetic and optionally local and/or civic location of a target UE when some certain events are detected.
  • Allow the consumer NF to perform privacy check and ID mapping of a UE for Ranging SL Positioning service.
  • Allow the consumer NF to request the relative locations, distance, or direction between UEs.

这段描述可以被看作是Ngmlc_Location服务的“电梯演讲”，它清晰地罗列了服务的六大核心能力。我们可以将其与小李的应急响应场景进行映射：

Ngmlc_Location 核心能力解读应急场景映射
请求当前位置提供最基础的按需定位能力，可以获取经纬度、地方坐标系或街道地址。小李需要立即知道事故报警人的位置，或“生命卫士-01”的当前快照位置。
订阅/退订事件提供基于事件的“延迟定位”（Deferred Location），允许用户订阅特定事件，如周期性上报、进入区域等。小李需要持续追踪“生命卫士-01”的行进路线，于是订阅了周期性位置上报事件。
取消定位请求允许用户终止一个正在进行的延迟定位任务，以释放网络资源。“生命卫士-01”任务完成返航，小李取消了对它的高频度位置追踪。
接收事件通知GMLC主动将触发的事件通知给订阅者。这是订阅/退订能力的另一面。当“生命卫士-01”抵达小李划定的事故区域时，GMLC主动通知应急指挥中心。
隐私检查与ID映射主要用于Sidelink（直通链路）定位场景，确保定位请求符合用户隐私策略。现场消防员A想通过Sidelink定位B，网络需要通过此能力检查B是否同意被A定位。
请求相对位置支持获取终端间的相对位置、距离、方向，同样是Sidelink/V2X场景的关键能力。在GPS信号不佳的地下车库，小李需要为救援机器人提供相对于“生命卫士-01”的精确方向和距离指引。

2.2 5.2.2 Service Operations (服务操作) & 5.2.2.1 Introduction (引言)

在宏观描述之后，规范开始逐一介绍实现上述能力的具体服务操作。5.2.2.1节列出了Ngmlc_Location服务下的所有操作，这与我们在Table 5.1-1中看到的列表是一致的。这标志着我们正式从“是什么”的讨论，进入了“怎么实现”的细节。接下来，我们将对其中最重要、最复杂的ProvideLocation操作进行一次彻底的、深入到每个参数的剖析。

3. 5.2.2.2 ProvideLocation：定位请求的核心引擎

ProvideLocation是整个Ngmlc_Location服务中最核心、最基本的操作。几乎所有的定位请求场景，都是通过调用这个操作来发起的。

3.1 单个UE定位 (5.2.2.2.2 Provide Location of a single UE)

这是最常见的场景，即定位一个特定的目标。规范首先指出了这个操作在Stage 2流程中的应用场景，例如5GC-MT-LR（网络侧发起的定位）、事件触发的定位等。这再次强调了Stage 3是对Stage 2的实现。

紧接着，规范给出了该操作的交互流程图。

原文引用 (Figure 5.2.2.2.2-1: Provide Location Request/Response for a target UE)

规范中的 “Figure 5.2.2.2.2-1: Provide Location Request/Response for a target UE” 描绘了一个简洁而强大的交互模型。它展示了：

  1. NF Service Consumer（例如，NEF）向GMLC发送一个 HTTP POST 请求到 .../provide-location URI，请求体中包含了详细的定位参数（InputData）。
  2. GMLC 在处理请求后：
    • 2a. 成功时：返回 200 OK 响应，响应体中包含了定位结果（LocationDataExt）。
    • 2b. 失败或重定向时：返回 4xx/5xx 的错误码（响应体中可能包含ProblemDetails来描述错误原因）或 3xx 的重定向码。

这个流程看似简单，但魔鬼隐藏在细节之中，尤其是第一步请求中的InputData对象，它承载了定位请求的所有精确要求。

3.1.1 剖析定位请求（Step 1: The HTTP POST Request）

规范用一个很长的段落描述了请求中可以包含的参数。这是本章最核心的知识点，我们必须将其彻底分解。

原文引用 (Chapter 5.2.2.2.2, Step 1):

The NF Service Consumer shall send an HTTP POST request to the URI associated with the “provide-location” custom operation. The input parameters for the request (the target UE identification (SUPI, GPSI or Application Layer ID), required QoS, supported GAD shapes, LCS client type, external Service Identity, Codeword, service coverage, LDR type, serving AMF address, … an indication of the request of location reporting via user plane … H-GMLC Callback URI … NEF or NWDAF Callback URI…) may be included in the HTTP POST request body.

这段文字提及的参数极其丰富，我们将它们整理成表格，并结合小李的场景进行逐一解析，这足以体现出ProvideLocation操作的强大灵活性。

参数类别关键参数解读与分析应急场景应用
目标标识SUPI, GPSI, Application Layer ID定义了要定位的目标是谁。可以是内部的SUPI(IMSI)，公开的GPSI(手机号)，或是应用层的ID（如车牌号，需应用服务器解析）。小李的系统通过NEF发起请求时，通常使用“生命卫士-01”的公共号码（GPSI）。
服务质量required QoS定义了对定位结果的质量要求，包括水平精度(hAccuracy)、垂直精度(vAccuracy)、**响应时间(responseTime)**等。这是向网络提出的SLA（服务等级协议）。救护车在城市高架上，小李需要高精度定位以区分是在桥上还是桥下，他会请求一个较高的垂直精度（如3米）。同时，他需要实时追踪，会要求低时延响应。
延迟定位LDR type, scheduled location timeLDR (Location Deferred Request) 定义了延迟定位的类型，如：周期性事件(PERIODIC)、进入/离开区域事件(ENTERING_INTO_AREA)等。scheduled location time则用于一次性的未来某个时刻的定位。小李为“生命卫士-01”设置了每10秒上报一次位置的周期性事件（LDR type = PERIODIC）。
回调通知NEF or NWDAF Callback URI对于延迟定位，消费者需要提供一个回调URI。当触发事件发生时，GMLC会向这个URI发送一个EventNotify通知，将定位结果推送过来。小李的应急中心系统提供了一个API端点https://emergency.city.gov/api/updates作为回调URI。GMLC会每10秒向这个地址POST一次救护车的最新位置。
用户面/控制面indication of the request of location reporting via user plane定义了定位结果的上报方式。控制面（默认）：通过核心网信令上报，可靠但可能占用信令资源。用户面：通过数据网络直接上报给应用服务器，适合高频度、大批量的定位数据。对于每10秒一次的追踪，控制面信令完全足够。但如果小李需要追踪上千个移动传感器，他可能会选择用户面上报，以避免信令风暴。
漫游相关H-GMLC Callback URI在漫游场景下，V-GMLC需要知道如何将定位事件通知回H-GMLC。如果“生命卫士-01”开到了邻市，邻市的V-GMLC在收到定位结果后，会通过这个URI将结果通知回救护车归属地的H-GMLC。
隐私与安全LCS client type, CodewordLCS client type声明了请求者的身份（如紧急服务、商业服务等），这关系到隐私策略的执行。Codeword则是一种简单的验证机制，GMLC可要求UE输入此密码才允许定位。小李的系统声明自己是EMERGENCY_SERVICES，这使得GMLC在处理隐私规则时拥有更高的优先级。

这张表格清晰地展示了，一个简单的ProvideLocation POST请求，其背后蕴含着对定位场景的精细化控制。小李的团队可以通过组合这些参数，实现从“查一下位置”到“未来一小时，每5秒给我一次这辆车的位置，要求水平精度5米，垂直精度3米，结果请推送到我的服务器”这样复杂而精确的指令。

3.1.2 理解定位响应（Step 2: The Response）

  • 成功响应 (Step 2a)：

    原文引用 (Chapter 5.2.2.2.2, Step 2a):

    On success, “200 OK” shall be returned. The response body shall contain the parameters related to the determined position of the UE if any (geodetic position, local position, civic location, positioning methods, integrity result,…).

    成功的响应不仅仅是一个200 OK状态码，其响应体LocationDataExt中包含了丰富的定位结果信息，例如：地理坐标、民用地址、所使用的定位技术（是GPS还是基站定位）、定位结果的可信度等等。这使得小李的系统不仅能在地图上画一个点，还能显示出“地址：XX路，定位方式：GPS，精度：5米”这样详细的信息。

  • 失败与重定向 (Step 2b)：

    原文引用 (Chapter 5.2.2.2.2, Step 2b):

    On failure or redirection, one of the HTTP status code listed in Table 6.1.3.2.2-2 may be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the “cause” attribute…

    当定位失败时，GMLC会返回详细的错误信息。例如，如果因为用户隐私设置而拒绝定位，可能会返回403 Forbidden，并在ProblemDetails中注明cause为POSITIONING_DENIED。如果目标UE关机或不在服务区，可能会返回504 Gateway Timeout，cause为UNREACHABLE_USER。这种精细化的错误处理机制，让小李的系统能够清晰地了解定位失败的原因，并做出相应的处理（例如提示“目标失联”或“用户拒绝定位”）。

3.2 群体UE定位 (5.2.2.2.3 Provide Locations of a group of UEs)

除了定位单个目标，ProvideLocation操作还支持强大的群体定位能力，这在应急指挥、车队管理、物联网等场景中至关重要。

原文引用 (Chapter 5.2.2.2.3, Figure 5.2.2.2.3-1)

规范中的 “Figure 5.2.2.2.3-1: ProvideLocation Request/Response for a target group” 展示了与单个UE定位类似的流程，核心区别在于请求和响应的内容。

场景代入：事故现场情况复杂，小李不仅要指挥救护车，还要协调第一时间赶到的5名消防员组成的“尖刀小队”。他需要在地图上看到整个小队的实时位置分布。

此时，他的系统会发起一次群体ProvideLocation请求：

  • 请求的关键区别：请求体InputData中不再使用SUPI或GPSI，而是使用External Group ID或Internal Group ID来标识整个“尖刀小队”。

  • GMLC的处理：GMLC收到请求后，会向UDM查询该群组包含哪些成员，然后为每个成员并行地发起内部的单用户定位流程。

  • 响应的关键区别：

    原文引用 (Chapter 5.2.2.2.3, Step 2a):

    On success, “200 OK” shall be returned. The response body shall contain the success type.

    对于立即的群体定位请求，GMLC的200 OK响应体中，通常只包含一个成功指示（success type），比如SUCCESS_COMPLETELY或SUCCESS_PARTIALLY。它并不会在这次响应中返回所有人的位置。因为获取多个人的位置需要时间，一次性返回会造成很大的时延。

    那么位置信息如何获取呢？通常群体定位会与延迟定位结合。小李的请求会同时包含群组ID和一个回调URI。GMLC在分别获取到每个消防员的位置后，会通过多次EventNotify通知，将每个人的位置信息逐个或分批推送到应急中心的服务器上。

这种设计体现了API设计的智慧：通过异步通知的方式，解耦了群体定位请求的提交和定位结果的接收，避免了同步等待带来的性能瓶颈，极大地提升了系统的响应速度和处理能力。

FAQ 环节

Q1：ProvideLocation操作和EventNotify操作是什么关系？为什么ProvideLocation的请求里要包含一个用于EventNotify的回调URI？

A1：它们是“订阅”和“通知”的关系，共同构成了延迟定位（Deferred Location）的完整闭环。ProvideLocation不仅可以用于一次性的立即定位，还可以用于“订阅”一个未来的定位事件（如周期性上报、进入区域等）。当您通过ProvideLocation发起这类订阅请求时，您必须同时提供一个eventNotificationUri（回调URI）。这个URI告诉GMLC：“当你订阅的事件发生时，请把结果送到这个地址来”。随后，当事件真的触发时（例如，到了下一次上报时间点），GMLC就会调用EventNotify操作，向您提供的URI主动推送一个包含位置信息的通知。所以，ProvideLocation是“下单”，EventNotify是“送货上门”。

Q2：什么是延迟定位请求（LDR - Location Deferred Request）？它和立即定位有什么区别？

A2：立即定位（Immediate Location Request）就像问路：“请问现在A点在哪里？”你期待立刻得到一个答案。而延迟定位（LDR）则是下一个“预约”或“监控”指令，例如：“请在接下来一小时内，每分钟告诉我一次A点的位置”或“当A点进入B区域时，请通知我”。LDR的请求被GMLC接收后会立即返回一个受理成功的响应，但真正的定位结果不会在这次响应中返回，而是在未来某个时间点或某个事件触发后，通过EventNotify操作异步推送给请求者。

Q3：用户面（User Plane）上报和控制面（Control Plane）上报定位信息有什么不同？应该如何选择？

A3：这是定位结果传递路径的选择。**控制面（Control Plane）**是通过核心网的信令通道来传递位置信息，路径是 UE → RAN → AMF → GMLC。这条路径可靠性高，有服务质量保证，但设计初衷是传递信令，不适合传输大量、高频的数据。**用户面（User Plane）**则是让UE通过普通的数据连接（就像我们手机上网一样），将位置信息直接发送给指定的应用服务器（AF）。这条路径带宽大，更灵活，适合物联网等需要海量终端高频上报位置的场景。选择哪种方式取决于应用需求：对于少数关键目标（如救护车）的低频追踪，控制面更可靠；对于成千上万个传感器的高频数据采集，用户面更高效。

Q4：在群体定位中，为什么GMLC不一次性返回所有成员的位置，而是采用异步通知的方式？

A4：主要出于性能和实时性的考虑。定位一个UE需要一个完整的信令流程，耗时可能从几百毫秒到几秒不等。如果一个群组有50个成员，GMLC需要等待所有50个成员的定位都完成后再打包返回，那么客户端收到的第一个位置信息的时延将是所有定位中最慢的那一个的时延，这会让用户体验变得很差。采用异步通知，GMLC每成功定位一个成员，就可以立刻通过EventNotify将该成员的位置推送出去，这样客户端就可以实时地、渐进地在地图上更新成员位置，大大提升了系统的实时性和响应能力。

Q5：ProvideLocation的参数那么多，是不是每次请求都必须全部填上？

A5：不是的。这些参数大多是可选的。ProvideLocation API的设计非常灵活。最简单的请求可能只需要一个目标ID（如GPSI）。此时，GMLC会使用一套默认的QoS参数和定位策略来执行一次立即定位。只有当您有特定的需求时，才需要填写相应的可选参数。例如，只有需要持续追踪时，才需要填写LDR type和eventNotificationUri；只有对精度有特殊要求时，才需要填写locationQoS。这种设计使得API既能简单易用，又能满足复杂场景的精细化控制需求。

关系图谱