5G定位LCS三请求信令全链拆解：从MO-LR/MT-LR到LPP/NRPPa穿透

5G定位（Location Services，LCS）是3GPP规范体系中少数横跨核心网、接入网、终端、安全、计费五大领域的协议族。一条"帮我定位这台UE"的指令，背后要跨越 UE ↔ gNB ↔ AMF ↔ LMF ↔ GMLC ↔ UDM ↔ NEF/AF 多达六七个网元，并复用 NAS、NGAP、NRPPa、LPP、SBI 五套协议栈协同完成。本文聚焦 3GPP TS 23.273 V18.10（5GS LCS Stage 2） 的核心信令机制，以 MO-LR（UE自定位）/ MT-LR（网络侧发起）/ NI-LR（监管发起） 三种定位请求为主线，逐条拆解每一条消息的关键 IE，讲清楚"LPP 和 NRPPa 为什么非要被 NAS 和 NGAP『打包』传输"这个最容易被一线工程师忽略的设计意图。

一、LCS 的本质：监管刚需驱动 + 商业能力开放

5G 必须支持 LCS，首先是监管刚需——TS 23.273 §6.10 与 TS 22.261 强制要求运营商在紧急呼叫（Emergency）场景下提供 UE 位置（类似北美的 E911、欧盟的 E112）。这部分是不可协商的，运营商拿牌照就必须支持。其次是商业能力开放——高精度定位（Rel-17 引入的高精度 RTK、Rel-16 的 DL-TDOA/AoA）让 5G 可以服务车联网（V2X）、工业 AGV、室内导航、资产追踪等垂直行业，LCS 通过 NEF 以 API 形式开放给 AF。

这种"监管 + 商业"双驱动，直接决定了 LCS 协议设计的两个底层约束：

1. 精度优先级可变：监管要求粗粒度（小区级即可）但时延低；商业要求亚米级但时延可放宽。这催生了 QoS 协商中的 LCS QoS Class（indicator/must）+ accuracy（精度，米）+ response time（响应时间）+ Vertical coordinate（垂直坐标） 四元组。
2. 隐私优先：定位是强隐私信息，必须支持 LCS Privacy Profile（用户/家庭/通用三层隐私策略），任何定位请求都要先过隐私校验。

二、LCS 架构与接口全景

理解信令前，必须先建立"谁和谁说话"的拓扑。5G 定位引入了一个全新网元 LMF（Location Management Function），它是整个定位流程的"大脑"，负责选择定位方法、调度测量、计算最终坐标。

flowchart TD
    UE["UE<br/>(支持LPP)"]
    gNB["gNB / ng-eNB<br/>(支持NRPPa)"]
    AMF["AMF<br/>透明中继"]
    LMF["LMF<br/>定位计算核心"]
    UDM["UDM<br/>LCS签约+隐私"]
    GMLC["GMLC<br/>VGMLC/HGMLC"]
    NEF["NEF / AF<br/>能力开放"]

    UE -- "LPP (UE-NRPPa?)<br/>经NAS透传" --> AMF
    AMF -- "Namf_N1N2MessageTransfer<br/>(承载LPP PDU)" --> UE
    gNB -- "NGAP:<br/>UE/Non-UE NRPPa Transport<br/>LocationReport" --> AMF
    AMF -- "N2/NGAP透传NRPPa" --> gNB
    AMF -- "Nlmf_Location_<br/>DetermineLocation" --> LMF
    LMF -- "Nlmf响应<br/>位置结果+Correlation ID" --> AMF
    GMLC -- "Ngmlc_Location_<br/>ProvideLocationInfo" --> AMF
    UDM -- "Nudm_SDM<br/>LCS签约" --> GMLC
    NEF -- "Nnef_EventExposure<br/>/ 定位API" --> GMLC

这里有四个极易混淆的接口，正是协议初学者最容易踩坑的地方：

最核心的设计哲学：LPP 和 NRPPa 是"端到端"协议（UE-LMF、gNB-LMF），但 3GPP 故意不给他们分配独立传输承载，而是复用 NAS 和 NGAP 做透传。这样做的好处是 LMF 不必维护与每个 UE/gNB 的独立信令连接，定位能力可以"插件式"叠加到现有 5G 基础设施上，AMF 只当好"邮差"。

三、三种定位请求：谁发起、为谁定位

TS 23.273 §6 定义了三大类定位请求，搞清楚"谁触发"是阅读所有信令图的前提。

一个高频面试点：MO-LR 不一定经 GMLC。只有当 UE 要求"把我的位置发给某个 LCS Client/AF"时，AMF 才会分配一个 VGMLC 地址（§6.2 step 2）；如果 UE 只是想知道自己在哪里，GMLC 完全不参与。

四、MO-LR 完整信令时序图（TS 23.273 §6.2）

这是 UE 主动发起定位的完整链路。下图严格对应 §6.2 的 12 个步骤，标注了每条消息的承载协议和关键 IE。

sequenceDiagram
    autonumber
    participant UE
    participant gNB
    participant AMF
    participant UDM
    participant LMF
    participant VGMLC

    Note over UE: CM-IDLE 时先做 Service Request<br/>建立信令连接(TS 23.502 §4.2.3.2)
    UE->>AMF: UL NAS TRANSPORT<br/>(MO-LR Request + 可选3条LPP PDU)
    Note right of AMF: 校验LCS签约(从UDM取)<br/>决定是否允许<br/>CM-IDLE→若last known满足QoS则跳过定位
    AMF->>UDM: Nudm_SDM_Get (LCS Subscriber Data)
    UDM-->>AMF: MO-LR授权 + 辅助数据列表
    AMF->>AMF: 选LMF(本地映射表/UDM)<br/>分配LCS Correlation ID
    AMF->>LMF: Nlmf_Location_DetermineLocation Req<br/>(Correlation ID, Serving Cell ID,<br/>Client Type, QoS, UE定位能力,<br/>LPP PDU, GAD shapes)
    rect rgb(230,245,255)
    Note over LMF,UE: 定位子过程(clause 6.11) — LPP/NRPPa 穿透
    LMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(DL NAS TRANSPORT: LPP 请求辅助数据/测量)
    AMF->>UE: DL NAS TRANSPORT (LPP PDU)
    UE-->>AMF: UL NAS TRANSPORT (LPP PDU: 测量结果)
    AMF-->>LMF: Namf_Communication_N1MessageNotify (LPP)
    LMF->>AMF: Namf(...): Downlink UE Associated NRPPa Transport
    AMF->>gNB: NGAP: Downlink UE Associated NRPPa Transport<br/>(请求SRS配置/TRP测量)
    gNB-->>AMF: NGAP: Uplink UE Associated NRPPa Transport
    AMF-->>LMF: Namf(...): Uplink UE Associated NRPPa Transport
    Note over LMF: 计算位置坐标(GAD Shape)
    end
    LMF-->>AMF: Nlmf_Location_DetermineLocation Rsp<br/>(Correlation ID, 位置估计,<br/>age, accuracy, 定位方法)
    opt UE要求转交位置给LCS Client
        AMF->>VGMLC: Ngmlc_Location_LocationUpdate<br/>(UE ID, 事件=5GC-MO-LR, 位置)
    end
    AMF->>UE: DL NAS TRANSPORT (MO-LR Return Result<br/>= 位置/辅助数据/失败原因)

4.1 逐条 IE 解析

第 1 步 UL NAS TRANSPORT（TS 24.501） 中封装的 MO-LR Request（TS 24.501 §8.2.x）核心 IE：

• LCS Service Type：区分"自定位 / 转交给 Client / 仅取辅助数据"三种意图。
• LCS requested QoS：accuracy（精度，0=不限）、response time、LCS QoS Class（BASIC 还是 ASSURED——后者不可降级）。
• LPP message(s)：最多 3 条预封装 LPP PDU。这是 Rel-16 的优化——UE 一次性把"我要哪些辅助数据"塞进请求，省一轮 LPP 往返（§6.2 step 2 NOTE）。
• Integrity requirements（Rel-17+）：Time-to-Alert (TTA)、Target Integrity Risk (TIR)、Alert Limit (AL)，来自 TS 38.305，用于 GNSS/RAT-dependent 完整性保护（如车联网安全相关定位）。
• Scheduled location time：预约在未来某时刻定位（延迟定位）。

第 4 步 Nlmf_Location_DetermineLocation（TS 29.572） 是整个流程的"指挥棒"，IE 设计值得细看：

关键优化点（§6.2 step 2）：若 UE 请求 current or last known location，且 AMF 本地缓存的旧位置满足 requested maximum age of location 精度要求，AMF 直接跳过 step 3-6，不触发任何定位测量——这就是为什么很多"附近搜索"类应用秒回结果，根本没走真实定位。

五、协议穿透：LPP/NRPPa 如何被 NAS 与 NGAP "打包"

这是 LCS 协议族最精妙、也最容易被忽视的一层。下图展示了一个 LPP PDU 从 LMF 到 UE 的"运输栈"：

flowchart TB
    subgraph UE端["UE 协议栈"]
        LPPu["LPP PDU<br/>(请求位置测量)"]
        NASu["NAS Message Container<br/>(DL NAS TRANSPORT)"]
    end
    subgraph AMF["AMF 透传层"]
        N1d["N1 SM? = N1 NAS Container<br/>Namf_N1N2MessageTransfer"]
        N2d["N2 / NGAP Container<br/>Downlink UE Associated NRPPa Transport"]
    end
    subgraph gNB端["gNB 协议栈"]
        NRPPa["NRPPa PDU<br/>(请求SRS配置)"]
        NGAP["NGAP 消息"]
    end
    LPPu -.封装.-> NASu
    N1d -.封装.-> N2d
    NRPPa -.封装.-> NGAP

设计意图三问：

1. 为什么 LPP 不走用户面？ 走控制面（NAS 透传）可以复用 UE 已有的信令连接，UE 在 CM-IDLE 也能被唤醒做定位；且控制面更安全（受 NAS 安全保护）。用户面定位（LCS-UPP，Rel-17 §6.18）是补充方案，用于高频高精度场景。
2. 为什么 AMF 要做透传而不让 LMF 直连 gNB/UE？ 避免新增 N_UE 和 N_gNB 接口，保持核心网网元职责单一。AMF 既是 NAS 终结点，又是 N2 终结点，天然是"中继最佳人选"。
3. UE Associated vs Non-UE Associated NRPPa 有何区别？ 前者绑定特定 UE（定位某台 UE），后者不绑定 UE（如 LMF 向 gNB 请求所有 TRP 的静态信息或下发广播辅助数据）。

六、MT-LR 信令流程：GMLC 主导的"找 UE"

当外部 AF/Client 要定位某台 UE 时，走 MT-LR（§6.1）。与 MO-LR 的根本区别是：UE 不知道自己要被定位，整个流程由 GMLC 从核心网侧反向"找"过去。

sequenceDiagram
    autonumber
    participant AF as AF/LCS Client
    participant NEF
    participant HGMLC as H-GMLC<br/>(归属)
    participant UDM
    participant VGMLC as V-GMLC<br/>(拜访)
    participant AMF
    participant UE
    participant LMF

    AF->>NEF: 定位请求(target=GPSI/SUPI)
    NEF->>HGMLC: Nnef → Ngmlc
    Note over HGMLC: 1.隐私校验(Privacy Profile)<br/>查询UDM签约
    HGMLC->>UDM: Nudm_SDM (路由信息)
    UDM-->>HGMLC: SUPI + Serving AMF地址
    HGMLC->>VGMLC: Ngmlc_Location_ProvideLocationInfo Req
    VGMLC->>AMF: Namf_Location_ProvidePositioningInfo Req<br/>(含LCS Correlation ID)
    Note over AMF: 若UE CM-IDLE→触发网络发起的<br/>Service Request(Paging);若支持末知位置则直接返回
    AMF->>UE: (必要时)Paging → Service Request
    AMF->>LMF: Nlmf_Location_DetermineLocation<br/>(网络侧发起定位)
    rect rgb(255,245,230)
    Note over LMF,UE: 同MO-LR的定位子过程(LPP/NRPPa)
    LMF->>UE: (经NAS)LPP测量
    UE-->>LMF: LPP测量结果
    end
    LMF-->>AMF: 位置估计
    AMF-->>VGMLC: Namf_Location_ProvidePositioningInfo Rsp(位置)
    VGMLC-->>HGMLC: Ngmlc Rsp(位置)
    HGMLC-->>NEF: 位置结果
    NEF-->>AF: 位置结果

MT-LR 的两个经典故障点：

• H-GMLC ↔ V-GMLC 的拆分：漫游场景下，归属地的 H-GMLC 负责隐私校验和签约，拜访地的 V-GMLC 负责实际定位。两者通过 Ngmlc_Location_LocationUpdate 互联。抓包时若只看到 H-GMLC 有请求、V-GMLC 无响应，往往是跨 PLMN 的 N32/SEPP 互通问题或 GMLC 地址解析失败。
• CM-IDLE 的 Paging 失败：MT-LR 要求定位一台空闲态 UE 时，AMF 必须 Paging 唤醒它。若 UE 处于覆盖盲区或不响应 Paging，定位会等到 response time 超时后返回 last known location 或失败。

七、NGAP 定位相关消息详解（TS 38.413 §9）

AMF 与 gNB 之间（N2 接口）有一组专门为定位设计的 NGAP 消息。这是 RAN 侧工程师做抓包定位的核心抓手。

NRPPa（TS 38.455）在这些 NGAP 信封里承载的"真实内容"：

flowchart LR
    A["NRPPa Procedure"] --> A1["PositioningInformation<br/>(Request/Response)"]
    A --> A2["Measurement<br/>(Request/Response)"]
    A --> A3["PositioningActivation/<br/>Deactivation(SRS激活)"]
    A --> A4["TRPInformation<br/>(传输点静态信息)"]
    A --> A5["AssistanceInformation<br/>Control/Failure"]
    A --> A6["ErrorIndication"]

其中 PositioningActivation（SRS 激活） 是高精度定位的关键：LMF 通过它让 gNB 为 UE 分配/激活 SRS（Sounding Reference Signal） 资源，这样多个 TRP 才能同时测量 UE 上行信号实现 UL-TDOA/UL-AoA。抓包时看到 PositioningActivation，基本可判定网络在做厘米/亚米级高精度定位。

八、定位方法决策：LMF 如何选算法

LMF 拿到定位请求后，要综合 QoS、UE 能力、RAN 能力选择定位方法。下图是 TS 38.305 §7 的决策逻辑简化：

flowchart TD
    Start["LMF收到DetermineLocation"] --> Q1{"UE能力含<br/>GNSS?"}
    Q1 -- 是 --> Check1{"室外+精度<br/>要求<10m?"}
    Q1 -- 否 --> RAT
    Check1 -- 是 --> GNSS["GNSS定位<br/>(A-GNSS, RTK增强)"]
    Check1 -- 否 --> RAT{"RAN支持<br/>NR定位?"}
    RAT -- 是 --> Cell{"精度要求高?"}
    RAT -- 否 --> ECID["ECID增强小区定位<br/>(粗粒度,低时延)"]
    Cell -- 是 --> Multi["多小区协作:<br/>DL-TDOA/UL-TDOA/Multi-RTT/AoA"]
    Cell -- 否 --> ECID
    GNSS --> Result["输出GAD Shape位置"]
    Multi --> Result
    ECID --> Result

九、抓包实战与故障排查

9.1 如何在 Wireshark 里识别 LCS 流程

• SBI 侧：过滤 http2.headers.path contains "nlmf" 或 "ngmlc"，看到 Nlmf_Location_DetermineLocation 即定位会话起点。用 Correlation ID 串联同一会话的多条消息。
• NGAP 侧：过滤 ngap.procedureCode == 45（LocationReportingControl）或匹配 NRPPa Transport，观察 SRS 激活和测量交互。
• NAS 侧：过滤 nas_5gs.message_type == 0x67（UL NAS TRANSPORT）且 nas_eps.nas_msg_container 内含 LPP（0x00 开头的 LPP PDU）。

9.2 常见故障点

LCS 在 R18/R19 持续演进，几个值得关注的机制（TS 23.273 §6.20/6.21/6.22/6.23）：

• Ranging/Sidelink Positioning（§6.20）：UE 间直接测距定位（如车与车），无需网络参与计算，LPP 扩展支持 sidelink。
• NWDAF 辅助定位（§6.21）：用 AI/ML 预测 UE 移动轨迹，提前缓存位置。
• LMF-based AI/ML 定位（§6.22）/ NG-RAN 侧 AI 模型（§6.23）：用训练好的模型替代部分测量，降低空口开销——这是 6G 定位的前奏。
• MBSR/MWAB 支持（§6.1.4/6.1.5/6.2）：移动基站中继（如车载中继）场景，LMF 需先定位中继再推算 UE 位置。

常见问题

Q1：MO-LR 和 MT-LR 在 NAS 层的根本区别是什么？ A：MO-LR 由 UE 用 UL NAS TRANSPORT 主动发起，UE "知道自己被定位"；MT-LR 由 GMLC 经 Namf 从网络侧发起，UE 可能全程不知情（除非隐私策略要求通知）。这也意味着 MO-LR 不需要 Privacy 校验，MT-LR 必须先查 UDM Privacy Profile。

Q2：LPP 消息为什么有时一条 NAS 里能带，有时又要单独往返？ A：Rel-16 允许 MO-LR Request 里预封装最多 3 条 LPP PDU（如直接附上"我要的辅助数据类型"），省一轮往返。但定位测量结果因依赖辅助数据下发的回执，仍需独立 LPP 往返。

Q3：NI-LR 和 MT-LR 监管版（§6.1.1）有何区别？ A：NI-LR（Network Induced）是 AMF 在紧急呼叫建立时内部自动触发，不走 GMLC；MT-LR 监管版（§6.1.1）是 GMLC 应监管要求发起，仍经 GMLC 链路。两者都跳过用户隐私校验，但触发链路不同。

Q4：为什么高精度定位一定要 PositioningActivation 激活 SRS？ A：上行定位（UL-TDOA/UL-AoA）需要多个 TRP 同时测量 UE 上行信号。SRS 是 UE 专门发的探测信号，平时不常发；LMF 通过 NRPPa PositioningActivation 通知 gNB 为 UE 激活专属 SRS 资源，多个 TRP 才能实现时间同步测量。

Q5：LCS 走控制面（Control Plane）和用户面（User Plane）怎么选？ A：控制面定位（默认，LPP over NAS）复用信令连接、安全性高、CM-IDLE 可用，适合低频和监管场景；用户面定位（LCS-UPP，§6.18，Rel-17）走 SUPL-like 通道，适合高精度高频（如持续 RTK）场景，避免占用 NAS 信令资源。

参考来源

1. 3GPP TS 23.273 V18.10.0 — 5GS Location Services (LCS) Stage 2 — §6.1 5GC-MT-LR、§6.2 5GC-MO-LR、§6.10 监管服务、§6.11 公共子过程
2. TS 23.273 Section 6.2 — 5GC-MO-LR Procedure（iTecSpec 在线索引） — MO-LR 12 步信令详解与 IE 说明
3. 3GPP TS 38.413 — NGAP — §9.2 LocationReportingControl、UE/Non-UE Associated NRPPa Transport 等 NGAP 定位消息
4. 3GPP TS 38.455 — NRPPa — PositioningInformation、Measurement、PositioningActivation 等过程
5. Cisco Ultra Cloud Core 5G AMF — Troubleshoot MT-LR Call Flow — MT-LR 工程实现与常见故障案例

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。