# 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）**，它是整个定位流程的"大脑"，负责选择定位方法、调度测量、计算最终坐标。 ```mermaid flowchart TD UE["UE
(支持LPP)"] gNB["gNB / ng-eNB
(支持NRPPa)"] AMF["AMF
透明中继"] LMF["LMF
定位计算核心"] UDM["UDM
LCS签约+隐私"] GMLC["GMLC
VGMLC/HGMLC"] NEF["NEF / AF
能力开放"] UE -- "LPP (UE-NRPPa?)
经NAS透传" --> AMF AMF -- "Namf_N1N2MessageTransfer
(承载LPP PDU)" --> UE gNB -- "NGAP:
UE/Non-UE NRPPa Transport
LocationReport" --> AMF AMF -- "N2/NGAP透传NRPPa" --> gNB AMF -- "Nlmf_Location_
DetermineLocation" --> LMF LMF -- "Nlmf响应
位置结果+Correlation ID" --> AMF GMLC -- "Ngmlc_Location_
ProvideLocationInfo" --> AMF UDM -- "Nudm_SDM
LCS签约" --> GMLC NEF -- "Nnef_EventExposure
/ 定位API" --> GMLC ``` 这里有四个**极易混淆的接口**，正是协议初学者最容易踩坑的地方： | 接口/参考点 | 端到端实体 | 承载内容 | 设计要点 | |------------|-----------|---------|---------| | **LPP**（TS 37.355） | UE ↔ LMF | 定位能力、辅助数据、位置测量 | UE 和 LMF 直接对话，但**物理上不直连**，靠 NAS+AMF 中继 | | **NRPPa**（TS 38.455） | LMF ↔ gNB | SRS 配置、TRP 信息、RAN 侧测量 | 同样**不直连**，靠 AMF 经 N2/NGAP 透传 | | **N2/Namf**（TS 38.413） | AMF ↔ gNB / AMF ↔ LMF | 透明承载 NRPPa PDU、LPP PDU | AMF 不解析 PDU 内容，只搬运 | | **Nlmf / Ngmlc**（TS 29.572/29.515） | AMF↔LMF / AMF↔GMLC | 定位请求/响应、位置更新 | 纯 SBI，JSON over HTTP/2 | **最核心的设计哲学**：LPP 和 NRPPa 是"端到端"协议（UE-LMF、gNB-LMF），但 3GPP 故意不给他们分配独立传输承载，而是**复用 NAS 和 NGAP 做透传**。这样做的好处是 LMF 不必维护与每个 UE/gNB 的独立信令连接，定位能力可以"插件式"叠加到现有 5G 基础设施上，AMF 只当好"邮差"。 --- ## 三、三种定位请求：谁发起、为谁定位 TS 23.273 §6 定义了三大类定位请求，搞清楚"谁触发"是阅读所有信令图的前提。 | 维度 | **MO-LR**（§6.2） | **MT-LR**（§6.1） | **NI-LR**（§6.10） | |------|------------------|------------------|------------------| | **发起方** | UE 自己 | 外部 LCS Client / AF（经 GMLC） | 网络自己（紧急呼叫触发） | | **定位对象** | UE 自身 | 任意目标 UE | 发起紧急呼叫的 UE | | **是否经 GMLC** | 仅"转交他人"场景才经 VGMLC | **必经** GMLC（VGMLC→HGMLC） | 不经 GMLC，AMF 直接触发 | | **隐私校验** | 不需要（用户自己要的） | **严格校验**（Privacy Profile） | 跳过隐私（监管豁免） | | **典型 NAS 触发消息** | `UL NAS TRANSPORT`（含 MO-LR Request） | 无直接 NAS，靠 `Namf` 网络侧触发 | 紧急呼叫建立时 AMF 内部触发 | | **典型场景** | 天气查询、附近搜索、自救 | 物流追踪、好友定位、增值服务 | E911/E112 紧急救援 | 一个高频面试点：**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。 ```mermaid sequenceDiagram autonumber participant UE participant gNB participant AMF participant UDM participant LMF participant VGMLC Note over UE: CM-IDLE 时先做 Service Request
建立信令连接(TS 23.502 §4.2.3.2) UE->>AMF: UL NAS TRANSPORT
(MO-LR Request + 可选3条LPP PDU) Note right of AMF: 校验LCS签约(从UDM取)
决定是否允许
CM-IDLE→若last known满足QoS则跳过定位 AMF->>UDM: Nudm_SDM_Get (LCS Subscriber Data) UDM-->>AMF: MO-LR授权 + 辅助数据列表 AMF->>AMF: 选LMF(本地映射表/UDM)
分配LCS Correlation ID AMF->>LMF: Nlmf_Location_DetermineLocation Req
(Correlation ID, Serving Cell ID,
Client Type, QoS, UE定位能力,
LPP PDU, GAD shapes) rect rgb(230,245,255) Note over LMF,UE: 定位子过程(clause 6.11) — LPP/NRPPa 穿透 LMF->>AMF: Namf_Communication_N1N2MessageTransfer
(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
(请求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
(Correlation ID, 位置估计,
age, accuracy, 定位方法) opt UE要求转交位置给LCS Client AMF->>VGMLC: Ngmlc_Location_LocationUpdate
(UE ID, 事件=5GC-MO-LR, 位置) end AMF->>UE: DL NAS TRANSPORT (MO-LR Return Result
= 位置/辅助数据/失败原因) ``` ### 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 设计值得细看： | IE | 类型 | 作用 | |----|------|------| | `LCS Correlation Identifier` | 唯一标识 | AMF 分配，串起整个会话，便于跨网元追溯 | | `Serving Cell Identity` | NR CGI | LMF 据此判断初始位置、选择定位方法 | | `Client Type` | 枚举 | 影响隐私策略和计费标记 | | `UE Positioning Capability` | 结构体 | UE 支持哪些定位方法（GNSS/OTDOA/...），决定 LMF 策略 | | `Supported GAD Shapes` | TS 23.032 | UE 能接受哪种几何形状的位置结果（点/椭圆/多边形） | | `LocationQoS` | 结构体 | 精度、时延、QoS Class、是否要垂直坐标 | **关键优化点（§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 的"运输栈"： ```mermaid flowchart TB subgraph UE端["UE 协议栈"] LPPu["LPP PDU
(请求位置测量)"] NASu["NAS Message Container
(DL NAS TRANSPORT)"] end subgraph AMF["AMF 透传层"] N1d["N1 SM? = N1 NAS Container
Namf_N1N2MessageTransfer"] N2d["N2 / NGAP Container
Downlink UE Associated NRPPa Transport"] end subgraph gNB端["gNB 协议栈"] NRPPa["NRPPa PDU
(请求SRS配置)"] NGAP["NGAP 消息"] end LPPu -.封装.-> NASu N1d -.封装.-> N2d NRPPa -.封装.-> NGAP ``` | 层级 | 协议 | 端点 | 携带的 PDU | 承载它的"信封" | |------|------|------|-----------|---------------| | **UE 侧** | LPP | UE↔LMF | 能力/辅助数据/测量 | NAS TRANSPORT 的 `LPP Message Container` | | **RAN 侧** | NRPPa | gNB↔LMF | SRS/TRP/RAN 测量 | NGAP 的 `UE/Non-UE Associated NRPPa Transport` | | **核心网侧** | SBI | AMF↔LMF↔GMLC | 整个定位会话 | HTTP/2 JSON（Nlmf/Ngmlf/Namf） | **设计意图三问**： 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 从核心网侧反向"找"过去。 ```text sequenceDiagram autonumber participant AF as AF/LCS Client participant NEF participant HGMLC as H-GMLC
(归属) participant UDM participant VGMLC as V-GMLC
(拜访) participant AMF participant UE participant LMF AF->>NEF: 定位请求(target=GPSI/SUPI) NEF->>HGMLC: Nnef → Ngmlc Note over HGMLC: 1.隐私校验(Privacy Profile)
查询UDM签约 HGMLC->>UDM: Nudm_SDM (路由信息) UDM-->>HGMLC: SUPI + Serving AMF地址 HGMLC->>VGMLC: Ngmlc_Location_ProvideLocationInfo Req VGMLC->>AMF: Namf_Location_ProvidePositioningInfo Req
(含LCS Correlation ID) Note over AMF: 若UE CM-IDLE→触发网络发起的
Service Request(Paging);若支持末知位置则直接返回 AMF->>UE: (必要时)Paging → Service Request AMF->>LMF: Nlmf_Location_DetermineLocation
(网络侧发起定位) 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 侧工程师做抓包定位的核心抓手。 | NGAP 消息 | 方向 | 触发场景 | 关键 IE | |-----------|------|---------|---------| | **`LocationReportingControl`** | AMF→gNB | AMF 要求 gNB 上报 UE 的 cell/TA 级位置 | `Report Type`（cell/TA/both）、`Report Area`（TAI 列表/NCGI 列表）、`EventType`（change/transfer/stop） | | **`LocationReport`** | gNB→AMF | gNB 上报当前 UE 位置 | `UE Presence In Area List`、`Location Reporting Request Type` | | **`Downlink/Uplink UE Associated NRPPa Transport`** | 双向 | 透传绑定 UE 的 NRPPa PDU | `Routing ID`、`NRPPa PDU`（不透明传输） | | **`Downlink/Uplink Non UE Associated NRPPa Transport`** | 双向 | 透传不绑定 UE 的 NRPPa PDU | `NRPPa PDU`、`Routing ID` | NRPPa（TS 38.455）在这些 NGAP 信封里承载的"真实内容"： ```mermaid flowchart LR A["NRPPa Procedure"] --> A1["PositioningInformation
(Request/Response)"] A --> A2["Measurement
(Request/Response)"] A --> A3["PositioningActivation/
Deactivation(SRS激活)"] A --> A4["TRPInformation
(传输点静态信息)"] A --> A5["AssistanceInformation
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 的决策逻辑简化： ```mermaid flowchart TD Start["LMF收到DetermineLocation"] --> Q1{"UE能力含
GNSS?"} Q1 -- 是 --> Check1{"室外+精度
要求<10m?"} Q1 -- 否 --> RAT Check1 -- 是 --> GNSS["GNSS定位
(A-GNSS, RTK增强)"] Check1 -- 否 --> RAT{"RAN支持
NR定位?"} RAT -- 是 --> Cell{"精度要求高?"} RAT -- 否 --> ECID["ECID增强小区定位
(粗粒度,低时延)"] Cell -- 是 --> Multi["多小区协作:
DL-TDOA/UL-TDOA/Multi-RTT/AoA"] Cell -- 否 --> ECID GNSS --> Result["输出GAD Shape位置"] Multi --> Result ECID --> Result ``` | 定位方法 | 精度 | 依赖信令 | 典型场景 | |---------|------|---------|---------| | **A-GNSS / RTK** | 1-10m（RTK 可达 cm） | LPP 辅助数据 | 室外车联网 | | **DL-TDOA / Multi-RTT** | 1-3m | NRPPa（TRP+SRS） | 室内/城市峡谷 | | **UL-TDOA / UL-AoA** | 1-5m | NRPPa（SRS+PositioningActivation） | 高并发物联网 | | **ECID** | 50-200m | 仅 NGAP LocationReport | 监管粗定位、低功耗 | --- ## 九、抓包实战与故障排查 ### 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 常见故障点 | 现象 | 可能原因 | 排查方向 | |------|---------|---------| | MO-LR 返回 `UNAUTHORIZED` | UDM 无 LCS 签约或 `Mobile Originated` 未授权 | 查 UDM `LCS Subscriber Data` 的 `MO-Data` | | MT-LR 一直 `PENDING` 到超时 | UE CM-IDLE 且 Paging 失败 | 查 Paging 响应、UE 信号覆盖 | | 精度始终很差（>100m） | LMF 只回退到 ECID，高精度方法未协商 | 查 UE `Positioning Capability`、gNB 是否支持 NRPPa TRP | | LPP 超时 | LPP 往返过慢或 AMF 透传丢消息 | 查 Namf `N1N2MessageTransfer` 与 `N1MessageNotify` 配对 | | 漫游 MT-LR 无响应 | H-GMLC↔V-GMLC 互通失败 | 查 SEPP N32 链路、GMLC 地址（SLF 解析） | ## 十、Rel-18/Rel-19 演进方向 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](https://www.etsi.org/deliver/etsi_ts/123200_123299/123273/18.10.00_60/ts_123273v181000p.pdf) — §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 在线索引）](https://itecspec.com/3gpp/23.273/s/6.2) — MO-LR 12 步信令详解与 IE 说明 3. [3GPP TS 38.413 — NGAP](https://www.3gpp.org/dynareport/38413.htm) — §9.2 LocationReportingControl、UE/Non-UE Associated NRPPa Transport 等 NGAP 定位消息 4. [3GPP TS 38.455 — NRPPa](https://www.3gpp.org/dynareport/38455.htm) — PositioningInformation、Measurement、PositioningActivation 等过程 5. [Cisco Ultra Cloud Core 5G AMF — Troubleshoot MT-LR Call Flow](https://www.cisco.com/c/en/us/support/docs/wireless/ultra-cloud-core-access-mobility-management-function/225816-troubleshoot-mt-lr-call-flow-in-amf-and.html) — 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 等场景全覆盖。