好的，我们继续对3GPP TS 29.515规范的第六章进行最后的攻坚。在前几篇文章中，我们已经彻底掌握了Ngmlc_Location API的架构、核心的请求/响应数据模型。然而，一个真正强大而完备的API，其魅力不仅在于核心功能，更在于它为处理复杂、边缘和高要求场景所提供的“高级工具集”。
本文作为第六章的收官之作，将聚焦于那些赋予GMLC服务深度和广度的高级数据模型。这些模型是实现用户隐私精细化控制、保障定位信息完整性、提升高频上报效率以及使能终端协同定位等前沿应用的关键。
深度解析 3GPP TS 29.515：第六章 (Part 4) - 高级数据模型之“精细化控制篇”
本文技术原理深度参考了3GPP TS 29.515 V18.8.0 (2025-03) Release 18规范中，关于**第六章“API定义”**的核心内容，重点剖析
6.1.5.2节中用于实现精细化控制的高级数据类型，包括UePrivacyRequirements,IntegrityRequirements,UpLocRepInfoAf,RelatedUe等。本文旨在帮助高级开发者和系统架构师理解并运用这些高级参数，构建出满足最严苛要求的5G定位应用。
故事新挑战：从“能用”到“好用”与“可靠”
应急调度员小李的指挥系统已经成功与GMLC对接，能够稳定地追踪“生命卫士-01”救护车。然而，随着应用的深入，新的、更复杂的需求开始涌现：
- 隐私关怀：救护车上的病人是一位公众人物，其家属通过法律途径要求，在每次对其位置进行紧急查询时，必须通知到病人的随身设备。小李的系统如何向网络传达这一临时的、精细化的隐私通知要求？
- 绝对可靠：前方事故现场有无人机进行空中勘察，并将空投一个救命的血浆包到救护车附近。“差之毫厘，谬以千里”，救护车上报的位置信息必须是绝对可信、未经篡改的。系统如何请求一次“带验真”的定位？
- 效率革命：救护车上集成了数十个生命体征传感器，每个传感器的数据都需要附带高频度的位置标签。如果所有数据都通过核心网信令面上报，将造成巨大的信令风暴。有没有办法将这些海量数据“分流”到普通的数据网络上传输？
- 协同作业：为了精准空投，无人机需要知道救护车相对于自己的精确位置和速度。系统如何发起一次“协同定位”，而不仅仅是定位一个孤立的目标？
这些需求，已经超出了简单ProvideLocation请求的范畴。它们需要调用InputData中那些我们尚未深入探讨的“高级选项”。现在，让我们逐一解锁这些强大的数据模型。
1. 6.1.5.2.7 Type: UePrivacyRequirements - 隐私策略的“运行时指令”
在之前的章节中我们知道，用户的隐私偏好通常是静态配置在UDM中的。但UePrivacyRequirements数据类型允许LCS客户端在每一次定位请求中，动态地附加额外的隐私处理指令。它就像一张“临时便签”，贴在了定位请求上，告诉网络这次要特殊处理。
原文引用 (Table 6.1.5.2.7-1: Definition of type UePrivacyRequirements):
（规范此处为UePrivacyRequirements的属性定义表格）
表 6.1.5.2.7-1: UePrivacyRequirements类型定义
| 属性名 (Attribute name) | 数据类型 (Data type) | P | Card. | 描述与深度解读 |
|---|---|---|---|---|
lcsServiceAuthInfo | LcsServiceAuth | O | 0..1 | LCS服务授权信息。这是一个枚举类型，是本结构体的核心。它指示网络在定位前，应如何与UE就隐私问题进行交互。其关键值包括：
|
codeWordCheck | boolean | O | 0..1 | 密码检查。如果为true，表示网络需要将请求中携带的CodeWord与用户预设的密码进行比对，验证通过后才能定位。这提供了一层额外的应用级安全。 |
场景重现与应用：
为了满足病人家属的合法要求，小李的技术团队修改了ProvideLocation请求的InputData对象，在其中加入了uePrivacyRequirements字段：
{
"gpsi": "msisdn-8613800100119",
"externalClientType": "EMERGENCY_SERVICES",
// ... 其他QoS和LDR参数
"uePrivacyRequirements": {
"lcsServiceAuthInfo": "LOCATION_ALLOWED_WITH_NOTIFICATION"
}
}当GMLC收到这个请求后，它会解析lcsServiceAuthInfo字段。即使病人的默认隐私设置是“无需通知”，GMLC也会根据这次请求的临时指令，在执行定位的同时，触发网络向病人的随身设备（通常与救护车的通信模块是不同的SIM卡）发送一条通知：“您的位置正在被紧急救援中心查询”。
UePrivacyRequirements为LCS应用提供了在运行时动态、精细地调整隐私交互策略的能力，是平衡业务需求与用户知情权、控制权的关键工具。
2. 6.1.5.2.15 Type: IntegrityRequirements - 定位情报的“验真戳”
对于自动驾驶、无人机物流、远程手术等生命攸关的应用，位置信息的完整性（Integrity）——即信息未经篡改、来源可靠——与精度同样重要。IntegrityRequirements允许应用请求一次带有完整性保障的定位。
原文引用 (Table 6.1.5.2.15-1: Definition of type IntegrityRequirements):
（规范此处为IntegrityRequirements的属性定义表格）
表 6.1.5.2.15-1: IntegrityRequirements类型定义
| 属性名 (Attribute name) | 数据类型 (Data type) | P | Card. | 描述与深度解读 |
|---|---|---|---|---|
targetIntegrityRisk (TIR) | TargetIntegrityRisk | O | 0..1 | 目标完整性风险。表示应用能容忍的位置信息出错的概率。例如，值为1E-7意味着要求定位信息出错的概率低于千万分之一。这是一个非常高的要求，网络需要启用额外的安全机制（如加密的定位信号、多源验证）来满足。 |
timeToAlert (TTA) | TimeToAlert | O | 0..1 | 告警时间。一个时间窗口（秒）。网络必须在这个时间窗口内，检测出定位信息的完整性是否达标。如果超出这个时间，即使后续检测出问题，也为时已晚。 |
alertLimit (AL) | AlertLimit | O | 0..1 | 告警限值。一个距离（米）。它与TTA配合使用，定义了一个“安全区域”。网络承诺，在TTA时间内，即使定位信息丢失完整性，UE的真实位置与最后一次可信位置之间的距离也不会超过AL。 |
这三个参数共同定义了一个严格的“完整性服务等级协议（SLA）”。
场景重现与应用：
为了确保无人机空投的绝对安全，小李的系统在为“生命卫士-01”发起定位时，加入了integrityRequirements：
{
// ... 其他目标和QoS参数
"integrityRequirements": {
"targetIntegrityRisk": "1E-5", // 风险等级: 十万分之一
"timeToAlert": 2, // 告警时间: 2秒内必须检测出问题
"alertLimit": 5 // 告警限值: 如果出问题，保证真实位置离最后可信点不超过5米
}
}这个请求等于在告诉GMLC和底层的LMF/NG-RAN：“我需要一份极其可靠的位置报告。如果这份报告的可靠性在2秒内得不到保障，或者你预估UE可能已经偏离了最后可靠位置超过5米，你必须立刻向我告警！”
GMLC在收到响应后，会在LocationData中返回一个integrityResult对象，告知应用本次请求的完整性要求是否被满足。IntegrityRequirements是5G定位服务从“信息服务”迈向“控制服务”的基石。
3. 6.1.5.2.17 Type: UpLocRepInfoAf - 海量上报的“高速公路”
我们曾提到，定位结果可以通过**控制面（Control Plane）或用户面（User Plane）**上报。UpLocRepInfoAf (User Plane Location Reporting Information for AF) 正是用于配置和启用用户面上报的专用数据结构。
原文引用 (Table 6.1.5.2.17-1: Definition of type UpLocRepInfoAf):
（规范此处为UpLocRepInfoAf的属性定义表格）
表 6.1.5.2.17-1: UpLocRepInfoAf类型定义
| 属性名 (Attribute name) | 数据类型 (Data type) | P | Card. | 描述与深度解读 |
|---|---|---|---|---|
upLocRepAfInd | boolean | C | 0..1 | 用户面上报指示 (AF)。这是一个开关，当值为true时，明确要求本次延迟定位的结果通过用户面上报。规范禁止此值为false，即一旦包含本结构体，就必须是请求用户面上报。 |
upLocRepAddrAf | UpLocRepAddrAfRm | O | 0..1 | 用户面上报地址 (AF)。这是最核心的字段，指定了UE应该将位置信息直接发送到哪个应用服务器（AF）的地址。通常是一个IP地址和端口号。 |
upCumEvtRptCriteria | UpCumEvtRptCriteria | O | 0..1 | 用户面累积事件报告标准。这是一个优化机制。它定义了在切换到用户面上报之前，UE可以在控制面积累多少（按时间或数量）报告再一次性发送。 |
场景重现与应用：
为了解决救护车上传感器数据的海量上报问题，小李的团队决定启用用户面上报。他们在ProvideLocation请求中加入了upLocRepInfoAf：
{
// ... 其他目标和LDR参数
"upLocRepInfoAf": {
"upLocRepAfInd": true,
"upLocRepAddrAf": {
"ipAddr": "203.0.113.10",
"port": 8888
}
}
}GMLC收到请求后，会将这个上报指令通过核心网一直传递到UE。之后，UE的通信模块就会将高频度的位置信息，封装在UDP或TCP包里，直接发送到IP地址为203.0.113.10的服务器的8888端口。
这样，核心网的信令面就被解放了出来，只负责处理关键的会话建立和管理信令，而海量的数据则通过高效的“数据高速公路”直达应用，实现了完美的流量分离。
4. 6.1.5.2.21 Type: RelatedUe - 协同定位的“关系说明”
在Sidelink等协同场景中，我们往往不关心一个UE的绝对位置，而是关心它相对于另一个UE的位置。RelatedUe数据类型就是用来在定位请求中定义这种“相对关系”的。
原文引用 (Table 6.1.5.2.21-1: Definition of type RelatedUe):
（规范此处为RelatedUe的属性定义表格。注意：原文表号为6.1.5.2.21-1）
表 6.1.5.2.21-1: RelatedUe类型定义
| 属性名 (Attribute name) | 数据类型 (Data type) | P | Card. | 描述与深度解读 |
|---|---|---|---|---|
appLayerId / gpsi / supi | Various | C | 0..1 | 相关UE的标识。至少提供一个，用于唯一确定这个“相关UE”是谁。 |
relatedUeType | RelatedUeType | M | 1 | 相关UE类型。强制必选，定义了这个相关UE在本次定位中的“角色”。枚举值包括：
|
场景重现与应用： 为了让无人机能精确地找到救护车，小李的系统需要请求“无人机相对于救护车的位置”。由于无人机才是运动的主体和需要精确引导的目标，所以无人机是“被定位UE”，而救护车是“参考UE”。
请求会这样构建（注意：这是对ProvideLocation请求的简化示意，实际流程更复杂）：
{
// 本次请求的主要目标是被定位的UE
"appLayerId": "DRONE-007",
// ... 其他QoS参数
// 请求Sidelink相对定位结果
"requestedRangingSlResult": ["RELATIVE_LOCATION"],
// 定义参与协同的UEs及其角色
"relatedUes": [
{
"appLayerId": "DRONE-007",
"relatedUeType": "LOCATED_UE" // 无人机是“被定位者”
},
{
"appLayerId": "LIFE-GUARDIAN-01",
"relatedUeType": "REFERENCE_UE" // 救护车是“参考点”
}
]
}GMLC和LMF收到这个请求后，就会明白这是一次协同定位任务，目标是计算出DRONE-007相对于LIFE-GUARDIAN-01的精确相对坐标，而不是它们的全球经纬度。
FAQ 环节
Q1：UePrivacyRequirements中定义的隐私交互（如弹窗确认），是由UE的操作系统（如Android/iOS）实现的，还是由网络实现的？
A1：这是由网络和UE紧密协同实现的。网络（具体是AMF/RAN）负责向UE发送指令，要求其进行用户交互。而UE的通信模组（Modem）在收到这些指令后，会通过标准的接口（AT命令等）通知上层的操作系统或应用，由操作系统来弹出那个“是/否”的对话框。用户点击的结果会再通过反向路径告知网络。所以，这是一个端到端的流程，3GPP定义了网络侧的信令和行为，而UE侧的实现则需要芯片和操作系统厂商的配合。
Q2：请求了IntegrityRequirements后，定位的响应会变慢吗？
A2：通常会的。实现定位信息的完整性，需要网络和终端执行额外的、更复杂的处理流程。例如，可能需要使用加密的辅助数据和定位信号（如NTRIP协议传输的RTK校正数据），终端和LMF之间可能需要进行多次信息交换和校验来确认位置的可靠性，这都会增加定位的时延。因此，完整性定位是一种“高质量、高成本”的服务，应用应仅在确实需要的场景下（如安全攸关的控制类应用）才去请求它。
Q3：启用用户面上报（User Plane Reporting）后，GMLC还参与后续的位置信息传递吗？
A3：不直接参与数据传递，但仍然参与会话管理。一旦用户面上报被激活，UE会将位置数据包直接发往应用服务器（AF），这个数据流不经过GMLC。但是，GMLC仍然是整个延迟定位会话的“管理者”。它负责会话的建立（通过ProvideLocation）、终止（通过CancelLocation或任务到期），以及处理可能发生的异常（如UE移动到新的AMF，需要更新上报策略）。GMLC的角色从“数据中转站”转变成了“交通警察”，负责指挥和管理数据流，但数据本身走了另一条高速公路。
Q4：在RelatedUe的例子中，为什么请求的主目标（appLayerId）是无人机，而不是救护车？
A4：这取决于定位的业务意图。在我们的场景中，需要引导无人机去找到救护车，所以业务的核心是“获取无人机的位置”。救护车虽然也是定位过程的重要参与者，但它的角色是作为一个静态或动态的“参考锚点”。因此，ProvideLocation请求的主体是被定位者（LOCATED_UE），而其他的参与方则作为“相关UE”（RelatedUe）在请求中列出。LMF会根据这个“角色”定义，来组织相应的Sidelink测量和计算流程。
Q5：这些高级数据模型是互斥的吗？我可以在一个InputData中同时包含UePrivacyRequirements和IntegrityRequirements吗？
A5：它们不是互斥的，完全可以组合使用，这正是InputData设计的强大之处。您可以构建一个极其复杂的请求，例如：“请对‘生命卫士-01’发起一次带有完整性保障（integrityRequirements）的周期性定位（ldrType: PERIODIC），定位前需要通知用户（uePrivacyRequirements），并将结果通过用户面（upLocRepInfoAf）直接上报给我的服务器”。这种组合能力使得开发者可以根据应用场景的精确需求，定制出最合适的定位服务模式。