好的，我们继续对3GPP TS 29.515规范的第六章进行庖丁解牛。在“请求篇”中，我们已经精通了如何向GMLC下达一份清晰、详尽的“作战指令”。现在，我们将转换视角，站在接收端，学习如何解读GMLC返回的“战报情报”。这些情报以JSON数据模型的形式传来，蕴含着关于目标位置、定位质量和上下文的全部秘密。
深度解析 3GPP TS 29.515：第六章 (Part 3) - 核心数据模型之“响应与通知篇” (LocationData & EventNotifyData)
本文技术原理深度参考了3GPP TS 29.515 V18.8.0 (2025-03) Release 18规范中，关于**第六章“API定义”**的核心内容，重点剖析
6.1.5.2节中用于承载ProvideLocation操作响应和EventNotify通知的核心数据类型：LocationData、EventNotifyData及其扩展形式。本文旨在让开发者彻底掌握如何解析和利用GMLC返回的每一比特信息，将原始的网络数据转化为富有价值的应用洞察。
故事新篇章：解读来自网络的情报
在应急指挥中心，小李的技术团队成功地向GMLC发送了追踪“生命卫士-01”的ProvideLocation请求。几乎在瞬间，他们的服务器就收到了GMLC返回的200 OK响应。紧接着，他们提供的回调URL（eventNotificationUri）开始每10秒就收到一次来自GMLC的主动推送。
屏幕前，首席架构师再次发问：“我们收到了两类数据包。第一类是调用ProvideLocation后立刻返回的那个，第二类是后续源源不断推送来的。它们里面都包含了什么？我们如何从这些看似复杂的JSON中，提取出地图上那个精确的坐标点、那个清晰的街道地址，以及那个代表精度的光圈？我们又如何知道网络是用GPS还是基站定位的？这份情报的可信度有多高？”
这就是我们今天要完成的任务：成为一名顶级的“情报分析师”，破译GMLC发来的LocationData和EventNotifyData，将冰冷的JSON数据转化为小李屏幕上生动、准确的战场态势。
1. 6.1.5.2.3 Type: LocationData - ProvideLocation的直接回报
LocationData是GMLC对ProvideLocation请求的同步响应体。无论你发起的是一次性的立即定位，还是一个长期的延迟定位订阅，GMLC都会在第一时间返回一个包含LocationData（或其扩展LocationDataExt）的200 OK响应。
- 对于立即定位，
LocationData中直接包含了最终的定位结果。 - 对于延迟定位订阅，
LocationData的主要作用是确认订阅成功，并返回管理这个长期任务的关键凭证——ldrReference。它也可能包含目标的初始位置。
原文引用 (Table 6.1.5.2.3-1: Definition of type LocationData):
（规范此处为一个巨大的表格，定义了LocationData的所有属性）
我们将这个至关重要的表格进行逻辑分组和深度解读，揭示每一份“战报”的全部内涵。
表 6.1.5.2.3-1: LocationData类型定义 (Definition of type LocationData)
| 属性名 (Attribute name) | 数据类型 (Data type) | P | Card. | 描述与深度解读 |
|---|---|---|---|---|
| --- Group 1: 目标是谁 & 在哪？ (Identity & Core Location) --- | ||||
gpsi / supi | Gpsi / Supi | O | 0..1 | 目标标识。明确告知本次响应是关于哪个UE的。 |
locationEstimate | GeographicArea | O | 0..1 | 地理位置估算。这是最核心的字段，一个描述地理位置和不确定性的结构体。其内部包含：
uncertaintyEllipse画出一个表示精度范围的椭圆光圈。 |
civicAddress | CivicAddress | O | 0..1 | 民用地址。一个结构体，包含国家、城市、街道、门牌号等信息。由GMLC通过地理编码服务（Geocoding）将经纬度反向解析得出。场景：小李的界面上除了地图，还会显示文字地址：“北京市朝阳区XX路123号”。 |
localLocationEstimate | LocalArea | O | 0..1 | 本地坐标估算。用于室内定位等场景，提供相对于某个本地坐标系的位置。 |
| --- Group 2: 何时 & 多久以前的位置？ (Timestamp & Age) --- | ||||
timestampOfLocationEstimate | DateTime | O | 0..1 | 位置估算的时间戳。ISO 8601格式的UTC时间，精确记录了UE处于该位置的时刻。极其重要，用于判断信息的时效性。 |
ageOfLocationEstimate | Integer | O | 0..1 | 位置估算的时效。从另一个维度表示信息的新鲜度，单位是分钟。 |
| --- Group 3: 这份情报有多好？ (Quality & Fulfillment) --- | ||||
accuracyFulfilmentIndicator | AccuracyFulfilmentIndicator | O | 0..1 | 精度满足指示。枚举值，FULFILLED或NOT_FULFILLED。它告诉消费者，本次定位结果是否满足了你在InputData的locationQos中提出的精度要求。 |
achievedQos | MinorLocationQoS | O | 0..1 | 达成的QoS。如果支持MUTIQOS特性，这里会返回本次定位实际达到的精度等QoS参数。 |
integrityResult | IntegrityResult | C | 0..1 | 完整性结果。用于UAS（无人机）等高安全场景，返回对定位信息完整性校验的结果。 |
| --- Group 4: 情报是怎么来的？ (Positioning Methodology) --- | ||||
positioningDataList | array(PositioningMethodAndUsage) | O | 1..N | 定位方法列表（非GNSS）。这是一个数组，列出了本次定位尝试过的非GNSS定位方法及其使用情况。每个元素包含method（如OTDOA, E-CID）和usage（如SUCCESSFUL, ATTEMPTED_BUT_UNSUCCESSFUL）。 |
gnssPositioningDataList | array(GnssPositioningMethodAndUsage) | O | 1..N | 定位方法列表（GNSS）。同上，但专门针对GNSS类定位方法（如A-GNSS, A-GPS）。场景：小李的系统可以从这两个列表中得知，本次定位成功使用了A-GNSS，同时尝试了OTDOA但失败了。这为判断定位可靠性提供了极好的参考。 |
| --- Group 5: 会话与网络上下文 (Session & Network Context) --- | ||||
ldrReference | LdrReference | C | 0..1 | 延迟定位请求参考号。对于延迟定位订阅请求，GMLC的首次200 OK响应中必须包含此字段。它是管理该订阅任务的唯一ID。场景：小李的系统收到首次响应后，必须立即保存这个ldrReference，以便后续发送CancelLocation。 |
servingLMFIdentification | LmfIdentification | C | 0..1 | 服务LMF的标识。 |
ueVelocity | VelocityEstimate | O | 0..1 | UE速度估算。如果请求了，且网络能够提供，这里会返回UE的水平速度、垂直速度和方向。 |
场景重现与情报分析：
小李的系统收到ProvideLocation的首次响应，解析出的LocationData JSON如下：
{
"gpsi": "msisdn-8613800100119",
"locationEstimate": {
"shape": "ELLIPSOID_ARC",
"point": { "lat": 39.9042, "lon": 116.4074 },
"uncertaintyEllipse": { "semiMajor": 8, "semiMinor": 6, "orientationMajor": 30 },
"confidence": 95
},
"civicAddress": { "country": "CN", "city": "Beijing", "street": "Chang'an Avenue" },
"timestampOfLocationEstimate": "2025-11-13T14:20:05Z",
"accuracyFulfilmentIndicator": "FULFILLED",
"positioningDataList": [
{ "method": "OTDOA", "usage": "ATTEMPTED_BUT_UNSUCCESSFUL" }
],
"gnssPositioningDataList": [
{ "method": "A-GNSS", "usage": "SUCCESSFUL" }
],
"ldrReference": "LDR-REF-ABC-789"
}情报分析结论：
- 目标：“生命卫士-01”（
gpsi）。 - 位置：北京长安街某处（
civicAddress），经纬度为39.9042, 116.4074（locationEstimate）。 - 精度：95%的概率在一个长半轴8米、短半轴6米的椭圆区域内。
- 时间：这是UTC时间14:20:05时的位置（
timestampOfLocationEstimate）。 - 质量：满足了我们在请求中提出的QoS要求（
accuracyFulfilmentIndicator）。 - 来源：主要通过A-GNSS成功定位，网络还尝试了OTDOA但失败了（
positioningDataList等）。 - 后续行动：这是一个长期任务，任务ID是
LDR-REF-ABC-789，务必保存！（ldrReference）。
2. 6.1.5.2.6 Type: EventNotifyData - 延迟定位的持续情报流
EventNotifyData是GMLC发起的异步通知的载体。当延迟定位订阅的事件被触发时（例如，10秒钟过去了，到了下一次上报的时间点），GMLC就会构造一个EventNotifyData对象，并将其POST到消费者指定的回调URI。
原文引用 (Table 6.1.5.2.6-1: Definition of type EventNotifyData):
（规范此处为EventNotifyData的属性定义表格）
EventNotifyData与LocationData共享了许多相同的字段（如locationEstimate、civicAddress等），因为它们的核心目的都是传递位置信息。但EventNotifyData额外包含了一些关键的“事件上下文”字段，以说明这次通知的“来龙去脉”。
表 6.1.5.2.6-1: EventNotifyData类型定义 (新增及核心上下文)
| 属性名 (Attribute name) | 数据类型 (Data type) | P | Card. | 描述与深度解读 |
|---|---|---|---|---|
ldrReference | LdrReference | M | 1 | 延迟定位请求参考号。强制必选。它清晰地告诉消费者，本次通知是隶属于哪个长期定位任务的。场景：小李的平台同时追踪10辆车，通过ldrReference就能准确地将收到的位置更新到正确的车辆上。 |
eventNotifyDataType | EventNotifyDataType | M | 1 | 事件通知数据类型。强制必选，极其重要。它告诉消费者为什么会收到这次通知。枚举值包括：
PERIODIC，就刷新地图位置；如果是ENTERING_INTO_AREA，就触发告警。 |
terminationCause | TerminationCause | C | 0..1 | 终止原因。当定位任务结束时，GMLC会发送最后一次通知，并附上此字段，告知结束原因，如NORMAL（上报次数用完）、UE_UNREACHABLE（UE失联）、OPERATOR_DETERMINED（运营商终止）等。 |
targetNode | NfInstanceId | C | 0..1 | 目标节点。在UE_MOBILITY_FOR_DEFERRED_LOCATION事件中，此字段会包含UE迁入的新AMF的实例ID。 |
| (…其他共享自LocationData的字段…) | 如gpsi, supi, locationEstimate, civicAddress等。 |
EventNotifyDataExt & 群体定位通知
Table 6.1.5.2.12-1定义的EventNotifyDataExt是对EventNotifyData的扩展。它允许在一次通知中包含多个UE的事件报告（通过addEventDataList数组），这对于群体定位的通知场景非常高效。
场景重现与情报流分析：
10秒后，小李的服务器收到了GMLC推送来的EventNotifyData：
// POST https://emergency.city.gov/api/updates
{
"ldrReference": "LDR-REF-ABC-789",
"eventNotifyDataType": "PERIODIC",
"gpsi": "msisdn-8613800100119",
"locationEstimate": {
"point": { "lat": 39.9045, "lon": 116.4080 },
...
},
"timestampOfLocationEstimate": "2025-11-13T14:20:15Z"
}情报分析：
- 上下文：这是
LDR-REF-ABC-789任务（追踪“生命卫士-01”）的通知。 - 原因：这是一次常规的周期性上报（
PERIODIC）。 - 情报：目标在UTC 14:20:15时，移动到了新的位置(39.9045, 116.4080)。
一小时后，任务即将结束，最后一次通知可能是这样的：
{
"ldrReference": "LDR-REF-ABC-789",
"eventNotifyDataType": "LOCATION_CANCELLATION_EVENT",
"gpsi": "msisdn-8613800100119",
"terminationCause": "NORMAL"
}情报分析：任务LDR-REF-ABC-789因为正常完成（上报次数用尽）而终止。小李的系统可以据此将该任务归档。
3. 6.1.5.2.9 Type: LocUpdateNotification - MO-LR情报的传递
最后，我们快速回顾一下LocUpdateNotification，它是MO-LR流程中，GMLC向应用推送通知的载体。其数据结构（Table 6.1.5.2.9-1）与EventNotifyData非常相似，但有本质区别：
- 没有
ldrReference：因为MO-LR通常不与一个长期的、网络侧发起的任务ID关联。 - 包含
locationRequestType: 字段值固定为MO-LR，明确告知这是UE主动上报的数据。 - 数据来源：其核心位置信息直接来自于UE上报给AMF，再由AMF通过
LocationUpdate传递给GMLC的数据，GMLC在此主要扮演“转发者”的角色。
FAQ 环节
Q1：LocationData和EventNotifyData都包含位置信息，它们最核心的区别是什么？
A1：最核心的区别在于交互模式和上下文。LocationData是同步响应，是对ProvideLocation请求的直接、即时的回复。它的主要作用是提供立即定位的结果，或在订阅延迟定位时返回确认和任务ID（ldrReference）。而EventNotifyData是异步通知，是GMLC在未来某个时间点主动推送给消费者的。它必须包含ldrReference和eventNotifyDataType来解释“这是哪个任务的通知”以及“为什么通知”，它是延迟定位服务产生持续价值的载体。
Q2：locationEstimate中的shape为什么可以是ELLIPSOID_ARC（椭圆弧）而不是一个简单的圆形？这有什么用？
A2：这反映了定位技术本身的物理特性。很多定位方法（如基于信号到达时间差的OTDOA）产生的不确定性区域并不是一个完美的圆形，而更接近于一个椭圆形，甚至双曲线的一部分。ELLIPSOID_ARC（包含不确定性椭圆的定义）能更真实、更精确地描述这种不确定性。对于需要高精度路径规划的应用（如自动驾驶、无人机），知道不确定性在哪个方向上更大（椭圆的长轴方向），对于风险评估和决策制定至关重要。
Q3：如果我收到的LocationData中accuracyFulfilmentIndicator是NOT_FULFILLED，我应该怎么办？
A3：这意味着网络尽力了，但没能达到您在locationQos中提出的高要求。您不应该直接丢弃这个结果，而是应该进行降级处理。首先，解析返回的实际位置信息（locationEstimate）和可能有的achievedQos，判断这个“没那么准”的位置是否对您的应用仍然有价值。例如，如果您要求5米精度用于导航，但网络返回了20米精度的结果，这个结果虽然不满足导航要求，但对于在城市地图上大致显示车辆位置来说，仍然是可用的。您的应用可以据此在界面上给用户一个提示，比如“当前位置精度较低”。
Q4：我如何知道一个延迟定位任务（LDR）已经结束了？
A4：您会收到一个特殊的EventNotify通知。在这个通知中，eventNotifyDataType字段会被设为LOCATION_CANCELLATION_EVENT，并且会包含一个terminationCause字段来说明结束的原因（例如，NORMAL表示预设的上报次数已完成，UE_UNREACHABLE表示目标失联超过了预设时长等）。收到这个通知，就标志着GMLC侧的这个定位任务已经正式终结，您的应用可以进行相应的清理和归档工作。
Q5：positioningDataList和gnssPositioningDataList这两个列表有什么实际应用价值？
A5：它们提供了宝贵的“定位过程元数据”，价值巨大。首先，它们增强了位置的可信度。一个仅由A-GNSS成功定位的结果，通常比一个仅由E-CID（增强型小区ID）成功定位的结果更可信。其次，它们有助于问题排查。如果定位精度一直很差，通过查看这两个列表，可能会发现GNSS方法总是失败（ATTEMPTED_BUT_UNSUCCESSFUL），这可能暗示UE处于室内或有遮挡的环境。最后，它们可以用于智能决策。例如，一个应用可以设定规则：只有当gnssPositioningDataList中存在成功记录时，才执行需要高精度的自动操作；否则，只进行大致位置的展示。