# 5G IMS 紧急呼叫 E-CSCF 与 LRF 定位路由信令全链拆解 > 聚焦 3GPP TS 23.167（IMS emergency sessions）与 TS 24.229 SIP 过程，结合 TS 23.502 第 4.13.4 条（Emergency Services Fallback/PDU 会话），拆解一次"拨 110/120"呼叫从无线到 PSAP 的完整信令链，重点解析 E-CSCF 的紧急会话路由判定、LRF 的位置检索（Location Retrieval）与路由号码（ESRN/ESQK）分配机制。 --- ## 一、为什么紧急呼叫需要一套独立的 IMS 机制 普通 VoNR 呼叫的呼叫模型建立在两个前提上：UE 已完成主认证与 IMS 注册，且路由完全由归属网络（HPLMN）的 S-CSCF/iFC 决定。但紧急呼叫（Emergency Call）打破了这两个前提—— 1. **必须允许未鉴权/受限服务状态的 UE 发起**：当 UE 没有有效 USIM、未签约、或处于 Limited Service 状态时，仍要能拨打 110/119/120。这意味着认证、签约校验、归属路由都要被"旁路"。 2. **必须按地理位置路由到本地 PSAP**：紧急呼叫绝不能绕回 HPLMN，而要落到 UE 当前所在地的公共安全应答点（PSAP）。这是"漫游用户在拜访地打急救"能打通的根本。 3. **必须携带并持续提供 UE 位置**：PSAP 需要主叫号码与位置才能调度救援，且通话过程中/通话后可能回调（Emergency Callback）。 正是这三点，催生了 IMS 中专门的两个功能实体——**E-CSCF（Emergency-CSCF）** 与 **LRF（Location Retrieval Function）**。E-CSCF 是 Rel-7 引入的网元，负责紧急会话的识别、路由与位置获取；LRF 负责检索 UE 地理位置并把位置映射为可路由的 PSAP 号码（ESRN）与可回调的临时号码（ESQK/ESRK）。 整个机制的规范主体是 **TS 23.167**（架构与信令流程，clause 5 架构、clause 7 过程），SIP 层细节在 **TS 24.229**（clause 5.1.2.2 紧急会话、5.1.6.3 P-CSCF 检测、5.1.6.4 E-CSCF 行为），紧急业务 URN 语法遵循 **RFC 5031**。 --- ## 二、E-CSCF 与 LRF 在架构中的位置 ```mermaid flowchart TD UE[UE / VoNR 终端] NR[(NG-RAN gNB)] AMF[AMF] SMF[SMF
Emergency SMF] UPF[UPF
Emergency Anchor] PCSCF[P-CSCF
紧急检测] ECSCF[E-CSCF
紧急会话控制] LRF[LRF
= Routing Function
+ GMLC] PSAP[PSAP
公共安全应答点] UDM[(UDM / UDR)] UE --> NR --> AMF --> SMF --> UPF --> PCSCF AMF -.Nudm.-> UDM PCSCF -->|INVITE 紧急| ECSCF ECSCF <-->|位置/路由查询| LRF LRF -.NLg/NLs LCS.-> AMF ECSCF -->|ESRN 路由| PSAP ``` 几点关键设计意图： - **E-CSCF 始终部署在 P-CSCF 所在网络**，即服务 UE 的网络（漫游场景下是 VPLMN）。这是 TS 23.167 clause 7 的硬性要求——紧急呼叫不回归属网。 - **LRF 内部含 GMLC（位置检索）+ 路由功能**：GMLC 部分通过 5G LCS（NLg/NLs）从 AMF 取位置；路由功能把位置映射到 ESRN。 - **P-CSCF 决定 E-CSCF**：P-CSCF 不走 DNS 查 S-CSCF，而是直接把 INVITE 转给本网 E-CSCF，这是"归属旁路"的物理体现。 --- ## 三、完整信令时序：从紧急注册到 PSAP 接续 下面这张时序图把 5G 承载层（紧急注册 + 紧急 PDU 会话）与 IMS 会话层（E-CSCF/LRF 路由）串成一条链。它对应 TS 23.502 clause 4.13.4 与 TS 23.167 clause 7.2 的合并视图。 ```text sequenceDiagram autonumber participant UE participant gNB as NG-RAN participant AMF participant SMF as SMF(E) participant UPF as UPF(E) participant PCSCF as P-CSCF participant ECSCF as E-CSCF participant LRF as LRF participant PSAP Note over UE,AMF: 阶段A：紧急注册（可无USIM/未鉴权） UE->>AMF: Registration Request (Emergency Registration,
PEI=IMEI, 无SUCI或null-scheme) AMF-->>UE: Registration Accept
(Emergency Number List) Note over UE,SMF: 阶段B：紧急 PDU 会话（TS 23.502 §4.13.4） UE->>AMF: PDU Session Establishment Request
(DNN=emergency,S-NSSAI,Emergency ind) AMF->>SMF: Nsmf_PDUSession_CreateSMContext (Emergency) SMF->>UPF: N4 Session Establishment SMF-->>UE: PDU Session Establish Accept
(UE IP, P-CSCF addr via PCO) Note over UE,PCSCF: 阶段C：IMS 紧急会话建立（TS 23.167 §7.2 / TS 24.229） UE->>PCSCF: INVITE urn:service:sos
(P-Access-Network-Info, SDP offer) PCSCF->>PCSCF: 紧急号码匹配/URN 检测 PCSCF->>ECSCF: INVITE (设紧急标记,
Route→本网E-CSCF) ECSCF->>LRF: Location Routing Request
(查UE位置+PSAP路由号) LRF->>AMF: LCS 定位查询(NLg/NLs, 初始cell-id) AMF-->>LRF: UE 位置(经纬度/cell) LRF-->>ECSCF: Location Routing Response
(ESRN, ESQK, 初始位置) ECSCF->>PSAP: INVITE (Request-URI=ESRN,
P-Asserted-Identity=ESQK/原号) PSAP-->>ECSCF: 183 Session Progress (SDP answer) ECSCF-->>PCSCF-->>UE: 183 / PRACK / 200 OK PSAP-->>UE: 200 OK (应答) Note over PSAP,LRF: 通话中：PSAP 可经 LRF 请求更精确位置 PSAP->>LRF: 位置更新请求(由ESQK反查) LRF-->>PSAP: 精确位置 UE->>PSAP: BYE Note over LRF: LRF 保留 ESQK↔UE 映射（回调窗口） ``` 下面对这条链上的每一类消息做 IE 级拆解。 --- ## 四、关键消息与 Information Element 拆解 ### 4.1 阶段A/B：紧急注册与紧急 PDU 会话（5G 承载层） - **Emergency Registration**：TS 23.501 clause 5.16 规定，受限服务 UE 可发起"紧急注册"。请求中携带的是 **PEI（IMEI）** 而非有效 SUPI；AMF 跳过 UDM 签约校验。Registration Accept 中下发 **Emergency Number List**（紧急号码列表），UE 据此本地判别后续拨号是否属于紧急。 - **PDU Session Establishment Request**：DNN 设为运营商配置的 **emergency DNN**（如 `sos`/`emergency`），并带紧急指示。AMF 选择支持紧急业务的 **Emergency SMF**；SMF 不做签约校验、不与 PCF 做计费策略，直接建 N4。P-CSCF 地址通过 **PCO（Protocol Configuration Options）** 下发，这是后续 SIP 流程的入口。 ### 4.2 阶段C-1：UE 发出的紧急 INVITE UE 收到紧急号码列表后，识别出被叫为紧急号码，按 TS 24.229 clause 5.1.6.3 构造 INVITE： | IE / Header | 取值与含义 | 规范出处 | |---|---|---| | Request-URI | `urn:service:sos`（或 `sos.ambulance`/`sos.police`/`sos.fire`） | RFC 5031 / TS 24.229 | | Request Method | INVITE | — | | `P-Access-Network-Info` | 携带 PLMN ID、Cell ID、接入类型 | TS 24.229 5.1.2.2 | | SDP offer | EVS/语音媒体描述 | — | | From/To | 与正常呼叫一致或临时标识 | — | 设计要点：用 **服务 URN（`urn:service:sos`）** 替代电话号码作为 Request-URI，是因为紧急号码各国不同（中国 110，美国 911，欧洲 112），而 URN 是全球统一的语义标识，便于跨网一致路由。 ### 4.3 阶段C-2：P-CSCF 的紧急检测与转发 P-CSCF 的核心动作是"判定紧急"并改路（TS 24.229 clause 5.1.6.3）： 1. **检测**：匹配 Request-URI 中的 `urn:service:sos`，或将被叫号码与本网紧急号码列表比对。 2. **改路**：不向归属 S-CSCF 转发，而是 **直接 Route 到本网 E-CSCF**。 3. **置紧急标记**：在 forwarded INVITE 中标注这是一个紧急会话，触发后续特殊处理（如媒体面专用承载、不释放）。 > 这里有一个常见误区：**P-CSCF 找 E-CSCF 不走 DNS**，因为归属 DNS 会把呼叫带回 HPLMN。E-CSCF 是 P-CSCF 本地配置/可达的同网网元，这一点是"漫游紧急呼叫本地化"的命门。 ### 4.4 阶段C-3：E-CSCF → LRF 位置检索（最核心的一步） E-CSCF 收到 INVITE 后，在转发给 PSAP **之前**必须先拿到 UE 位置与 PSAP 路由号（TS 23.167 clause 7.2）。它向 LRF 发起 **Location Routing Request**，携带 UE 标识与 P-Access-Network-Info 中的初始 cell-id。LRF 内部的 GMLC 通过 5G LCS（`NLg`：GMLC↔AMF）触发定位： ```mermaid flowchart LR ECSCF[E-CSCF] -->|位置路由请求| LRF LRF -->|NLg 提供位置| AMF AMF -->|NLs/NLpp| UE UE -->|测量/辅助数据| AMF AMF -->|位置报告| LRF LRF -->|位置→ESRN 映射| LRF2[路由功能] LRF2 -->|ESRN/ESQK| ECSCF ``` 定位先以 **cell-id（初始位置，Initial Location）** 快速返回，保证接续时延；通话中 PSAP 可请求 **更精确位置**（control plane 或 UE-assisted 定位）。LRF 返回 **Location Routing Response**，关键是两个号码： ### 4.5 ESRN 与 ESQK/ESRK：两个易混的路由号码 这是 IMS 紧急呼叫中最关键、也最容易在抓包中混淆的一对概念，必须分清。 | 号码 | 全称 | 作用 | 由谁使用 | 生命周期 | |---|---|---|---|---| | **ESRN** | Emergency Service Routing Number | 把呼叫路由到正确的本地 PSAP | E-CSCF 作 Request-URI | 单次呼叫 | | **ESQK / ESRK** | Emergency Service Query Key / Routing Key | PSAP 回调主叫、向 LRF 反查位置 | PSAP 回拨时拨打 | LRF 在回调窗口内保留映射 | 设计意图分离得很巧妙：**ESRN 解决"路由到哪个 PSAP"（基于位置），ESQK 解决"PSAP 如何回拨与查位置"（基于临时号码映射）**。E-CSCF 用 ESRN 当路由键把 INVITE 送到 PSAP；同时把 ESQK 放进 `P-Asserted-Identity`，使 PSAP 看到的是一个可回拨的号码。LRF 维护 `ESQK ↔ UE 真实身份` 的映射表，PSAP 回拨 ESQK 时，呼叫回到 LRF/GMSC，再映射回原 UE 完成回调。 ### 4.6 E-CSCF → PSAP：终接 E-CSCF 用 ESRN 作为 Request-URI 发出 INVITE。若 PSAP 是 IP/SIP 终接，则直达；若 PSAP 仍为电路域，E-CSCF 经 **BGCF → MGCF/MGW** 完成 IMS↔CS 互通。随后是标准的 183/PRACK/200 OK 媒体协商（EVS 编解码），与普通 VoNR 呼叫一致。 --- ## 五、与普通 VoNR 呼叫的对比 | 维度 | 普通 VoNR 呼叫 | IMS 紧急呼叫 | |---|---|---| | 鉴权要求 | 必须主认证 + IMS 注册 | 允许未鉴权/紧急注册（PEI/IMEI） | | 路由决策点 | 归属 S-CSCF + iFC | 本网 E-CSCF（拜访地） | | 位置 | 不强制 | 必须，经 LRF 检索并持续提供 | | 承载 | 普通 PDU 会话 | 紧急 PDU 会话（专用 DNN，旁路计费/签约） | | 被叫标识 | TEL URI / SIP URI | `urn:service:sos`（服务 URN） | | 回调 | 普通回拨 | ESQK 临时号码 + LRF 映射 | | 计费/策略 | PCF/CHF 正常 | 旁路，不可拒绝 | --- ## 六、抓包识别与排错实战 ### 6.1 抓包中如何认出这条流程 在 Wireshark 中对 NGAP/NAS/SIP/PFCP 同步抓取： - **NGAP/NAS 层**：看到 `Registration Request` 且 `5GS Registration type = Emergency`，紧接 `Emergency Number List` IE 下发，基本可判定进入紧急分支。 - **PDU 会话**：`DNN = emergency`（运营商具体字符串），SMF 不下发正常 QoS 计费规则。 - **SIP 层（最显著）**：INVITE 的 `Request-URI: `，且 `Route` 头指向 E-CSCF 而非 S-CSCF；后续 INVITE 到 PSAP 的 `Request-URI` 变成 ESRN（一个 TEL URI 号码）。 - **E-CSCF↔LRF**：若能看到 Diameter/HTTP 的 Location Routing Request/Response，其中携带 `ESRN`/`ESQK` 字段，即为定位检索交互。 ### 6.2 常见故障点 1. **UE 不识别紧急号码**：Emergency Number List 未下发或被终端过滤，导致 UE 按普通号码拨出，P-CSCF 兜底检测失败 → 呼叫被当普通呼叫路由，可能找不到归属而失败。排错：核对 Registration Accept 是否含紧急号码列表。 2. **P-CSCF 找不到 E-CSCF**：本地路由配置缺失，INVITE 无法转出。表现为 P-CSCF 上 408/404。排错：检查 P-CSCF 静态路由/DNS 到 E-CSCF 的可达性。 3. **LRF 位置检索失败/超时**：GMLC↔AMF LCS 链路不通，E-CSCF 拿不到 ESRN，呼叫无法接续到正确 PSAP。表现为 E-CSCF 侧 Location Routing Request 无响应。排错：核查 NLg/NLs 接口与 AMF LCS 订阅。 4. **ESQK 回调映射丢失**：LRF 提前清除 ESQK↔UE 映射，PSAP 回拨失败。注意 LRF 的回调窗口（callback timer）配置。 5. **CS PSAP 互通失败**：MGCF/MGW 配置或号码翻译表错误，导致 ESRN 无法落到 CS 域 PSAP。 ## 七、设计意图总结 把这条链串起来看，3GPP 的设计哲学非常清晰：**"用承载层旁路 + 会话层改路 + 位置层映射"三重机制，确保紧急呼叫在任何状态下都能落地到本地救援。** - 承载层（紧急注册/紧急 PDU 会话）解决"没身份也能上"； - 会话层（P-CSCF→E-CSCF）解决"不回归属、本地路由"； - 位置层（E-CSCF↔LRF，ESRN/ESQK）解决"路由到对的 PSAP、能回拨、能给位置"。 三者缺一，"无卡打 120"或"漫游打 911"都不可能成立。 --- ## 常见问题 **Q1：紧急呼叫为什么不能回 HPLMN 的 S-CSCF？** A：因为紧急呼叫必须按 UE 当前地理位置路由到本地 PSAP，且回归属网会引入不可接受的国际迂回时延，也无法保证救援属地化。TS 23.167 强制 E-CSCF 在服务（拜访）网络处理，这是"漫游打急救能通"的关键。 **Q2：ESRN 和 ESQK 到底怎么区分？** A：ESRN 是 E-CSCF 用来把呼叫"路由到 PSAP"的号码（一次性，基于位置）；ESQK/ESRK 是 LRF 分配给 PSAP 用来"回拨主叫"和"反查位置"的临时号码（LRF 维护其与 UE 的映射，回调窗口内有效）。一个管路由，一个管回调。 **Q3：未插 SIM 的 UE 真能打紧急呼叫吗？** A：在 IMS/VoNR 下需要先做紧急注册（用 PEI/IMEI）并建立紧急 PDU 会话；运营商网络须支持 Emergency Registration 与紧急承载。规范允许，但实际取决于运营商是否开通了 IMS 紧急业务，部分网络仍依赖 CSFB 回落到 2/3G 电路域紧急呼叫。 **Q4：LRF 取不到位置时紧急呼叫会断吗？** A：通常不会直接断。LRF 可先以 cell-id 等粗略位置/默认 ESRN 完成接续（保证首响），再在通话中通过 LCS 获取精确位置。只有当 LRF 完全无法给出任何路由号时，E-CSCF 才会因无 ESRN 而无法终接。 **Q5：5G 与 EPS 的 IMS 紧急呼叫机制有区别吗？** A：会话层（E-CSCF/LRF/URN/ESRN/ESQK）几乎一致，差别在承载层——5G 用紧急 PDU 会话（TS 23.502 §4.13.4）与 N4/5G LCS（NLg/NLs），EPS 用紧急 PDN 与 Gx/LCS（Slg/Sls）。高层复用，底层不同。 --- ## 参考来源 1. [3GPP TS 23.167 V19.x.x — IP Multimedia Subsystem (IMS) emergency calls](https://www.3gpp.org/dynareport/23167.htm) — clause 5 架构、clause 7 紧急会话建立过程、E-CSCF/LRF 信令流 2. [3GPP TS 24.229 — IP multimedia call control protocol based on SIP and SDP](https://www.3gpp.org/dynareport/24229.htm) — clause 5.1.2.2 紧急会话、5.1.6.3/5.1.6.4 P-CSCF/E-CSCF 检测与转发、P-Access-Network-Info 3. [3GPP TS 23.502 — Procedures for the 5G System](https://www.3gpp.org/dynareport/23502.htm) — clause 4.13.4 Emergency Services（紧急 PDU 会话）、TS 23.501 clause 5.16 Emergency services 4. [RFC 5031 — A Uniform Resource Name (URN) for Emergency Calls](https://datatracker.ietf.org/doc/html/rfc5031) — `urn:service:sos` 系列紧急业务 URN 语法 5. [ITU-T Q Suppl. 72 (11/2025) — Signalling requirements for IMS emergency call over multiple access](https://www.itu.int/epublications/publication/itu-t-q-suppl-72-2025-11) — P-CSCF/E-CSCF/LRF 多接入紧急呼叫信令要求 6. [E-CSCF / LRF 概念解读 — 3GPP Explorer & TelecomTrainer](https://3gpp-explorer.com/glossary/lrf/) — E-CSCF/LRF/ESRN/ESQK 工程化解读与回调映射 --- > 本文由「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 等场景全覆盖。