首页 › ims › IMS紧急呼叫E-CSCF与LRF拆解

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 在架构中的位置

flowchart TD
    UE[UE / VoNR 终端]
    NR[(NG-RAN gNB)]
    AMF[AMF]
    SMF[SMF<br/>Emergency SMF]
    UPF[UPF<br/>Emergency Anchor]
    PCSCF[P-CSCF<br/>紧急检测]
    ECSCF[E-CSCF<br/>紧急会话控制]
    LRF[LRF<br/>= Routing Function<br/>+ GMLC]
    PSAP[PSAP<br/>公共安全应答点]
    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

几点关键设计意图：

三、完整信令时序：从紧急注册到 PSAP 接续

下面这张时序图把 5G 承载层（紧急注册 + 紧急 PDU 会话）与 IMS 会话层（E-CSCF/LRF 路由）串成一条链。它对应 TS 23.502 clause 4.13.4 与 TS 23.167 clause 7.2 的合并视图。

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,<br/>PEI=IMEI, 无SUCI或null-scheme)
    AMF-->>UE: Registration Accept<br/>(Emergency Number List)
    Note over UE,SMF: 阶段B：紧急 PDU 会话（TS 23.502 §4.13.4）
    UE->>AMF: PDU Session Establishment Request<br/>(DNN=emergency,S-NSSAI,Emergency ind)
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext (Emergency)
    SMF->>UPF: N4 Session Establishment
    SMF-->>UE: PDU Session Establish Accept<br/>(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<br/>(P-Access-Network-Info, SDP offer)
    PCSCF->>PCSCF: 紧急号码匹配/URN 检测
    PCSCF->>ECSCF: INVITE (设紧急标记,<br/>Route→本网E-CSCF)
    ECSCF->>LRF: Location Routing Request<br/>(查UE位置+PSAP路由号)
    LRF->>AMF: LCS 定位查询(NLg/NLs, 初始cell-id)
    AMF-->>LRF: UE 位置(经纬度/cell)
    LRF-->>ECSCF: Location Routing Response<br/>(ESRN, ESQK, 初始位置)
    ECSCF->>PSAP: INVITE (Request-URI=ESRN,<br/>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 承载层）

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）触发定位：

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 同步抓取：

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 的设计哲学非常清晰："用承载层旁路 + 会话层改路 + 位置层映射"三重机制，确保紧急呼叫在任何状态下都能落地到本地救援。

三者缺一，"无卡打 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 — clause 5 架构、clause 7 紧急会话建立过程、E-CSCF/LRF 信令流
  2. 3GPP TS 24.229 — IP multimedia call control protocol based on SIP and SDP — 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 — 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 — urn:service:sos 系列紧急业务 URN 语法
  5. ITU-T Q Suppl. 72 (11/2025) — Signalling requirements for IMS emergency call over multiple access — P-CSCF/E-CSCF/LRF 多接入紧急呼叫信令要求
  6. E-CSCF / LRF 概念解读 — 3GPP Explorer & TelecomTrainer — 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 等场景全覆盖。

51学通信知识星球海报-扫码加入

📎 本分类最新文章