# IMS紧急呼叫信令全链拆解：从5G紧急注册到E-CSCF/LRF路由PSAP ## 一、为什么紧急呼叫值得单独拆一条信令链 普通IMS主被叫建立在一条简单假设之上——**用户已完成正常注册、持有有效凭证、网络已为其建立了正常PDU会话**。但紧急呼叫（Emergency Call，如110/119/120、北美911、欧盟112）恰恰要打破这三条假设中的每一条： - 用户可能处于**受限服务状态（Limited Service）**，USIM无效、被拒网、漫游受限，照样要打通救命电话； - 网络对紧急呼叫**不强制鉴权与订阅校验**，甚至在无USIM场景（部分国家法规）也要放行； - 路由不再依据被叫号码，而是依据**UE当前地理/小区位置**，把它送到最近的公共安全应答点（PSAP，Public Safety Answering Point）。 这条"打破三条假设"的特殊性，催生了一整套独立的网元与信令：紧急注册（Emergency Registration）、紧急PDU会话、P-CSCF旁路S-CSCF直达**E-CSCF（Emergency-CSCF）**、**LRF（Location Retrieval Function）**完成定位与路由键生成、**ESRK/ESRN**锚定PSAP回呼。整套机制的舞台规范是 **3GPP TS 23.167《IMS emergency sessions》**，5G侧的承载建立落在 **TS 23.502 clause 4.13（Emergency Services）**，SIP具体编码则由 **TS 24.229** 约束。 本文以 VoNR（5G IMS）场景为骨架，把这条从UE拨号到PSAP应答的完整信令链逐段拆开，重点剖析 **E-CSCF ↔ LRF 的路由决策** 这一核心机制。 ## 二、关键网元与接口拓扑 ```mermaid graph TD UE([UE]) -->|N1NAS/无RRC| RAN[(gNB/NG-eNB)] RAN --> AMF AMF -->|N11| SMF SMF -->|N4| UPF SMF -.PCO下发P-CSCF.-> UE UPF --- PC[P-CSCF] subgraph IMS核心 PC -->|紧急直达| EC[E-CSCF] EC <-->|定位/路由键| LRF[LRF/RDF] LRF <-->|位置查询| GMLC[GMLC] end EC -->|SIP/IP| PSAP1[PSAP-IP] EC -->|经BGCF/MGCF| PSAP2[PSAP-CS/电路域] GMLC <--> RAN ``` 值得强调的三个设计取舍： 1. **P-CSCF 旁路 S-CSCF**：普通呼叫 `P-CSCF → S-CSCF`，而紧急呼叫 `P-CSCF → E-CSCF`。原因在于 S-CSCF 依赖用户签约（iFC触发、业务链），但紧急呼叫必须**对未签约/未注册用户也可达**，因此绕开依赖HSS签约的S-CSCF，由专用 E-CSCF 终结。 2. **LRF 内含 RDF**：TS 23.167 明确 LRF 可内嵌 **RDF（Routing Determination Function）**，RDF 负责把"位置"翻译成"PSAP路由地址"。二者逻辑分离、物理合一，是工程上的常见实现。 3. **E-CSCF 是行政锚点**：E-CSCF 服务于一个**地理服务区（serving area）**，是该区域内所有紧急会话的唯一锚点，便于法规落地与录音录像。 ## 三、完整信令时序：四阶段全链 ```mermaid sequenceDiagram autonumber participant UE participant RAN as (g)NB participant AMF participant SMF participant UPF participant PC as P-CSCF participant EC as E-CSCF participant LRF as LRF/RDF participant PSAP Note over UE,AMF: 阶段A 5G紧急注册（TS 23.502 4.13 Emergency Registration） UE->>AMF: Registration Request(Emergency指示) AMF-->>UE: Registration Accept(Emergency Services) Note over UE,UPF: 阶段B 紧急PDU会话建立（TS 23.502 4.13 Emergency PDU Session Establishment） UE->>AMF: PDU Session Est. Request(DDN=Emergency DNN) AMF->>SMF: NsmPDU_Session CreateSMContext(Emergency Indication) SMF->>UPF: N4 Session Establishment(Emergency) SMF-->>UE: PDU Session Est. Accept(P-CSCF addr via PCO) Note over UE,PC: 阶段C IMS紧急注册（TS 24.229） UE->>PC: SIP REGISTER(Emergency) PC->>EC: REGISTER(Emergency,转发E-CSCF) EC-->>PC: 200 OK PC-->>UE: 200 OK Note over UE,PSAP: 阶段D 紧急会话建立与路由（TS 23.167 clause 7.3/7.4） UE->>PC: INVITE Request-URI=urn:service:sos PC->>EC: INVITE(+Route E-CSCF, +P-Access-Network-Info) EC->>LRF: 位置获取与路由键请求(NPLI/ESRK) LRF-->>EC: PSAP Route(ESRK/ESRN + PSAP URI) EC->>PSAP: INVITE(按ESRK路由) PSAP-->>EC: 100 Trying / 183 Session Progress EC-->>UE: 183 Session Progress(早媒体/回铃) PSAP-->>EC: 200 OK(INVITE) EC-->>UE: 200 OK(INVITE) UE-->>PSAP: ACK Note over UE,PSAP: 会话激活：双向媒体流（含定位上报持续） ``` ### 阶段A：5G紧急注册 当 UE 处于受限服务状态（例如USIM鉴权失败、被网络拒绝），用户拨打紧急号码时，UE 触发 **5G紧急注册**（TS 23.502 clause 4.13 中 Emergency Registration 流程）。AMF 收到携带 Emergency 指示的 Registration Request 后： - **不执行签约校验**：即便 UDM 查不到该 SUPI 的正常签约，AMF 仍接受注册，并分配一个临时标识用于本次紧急服务； - **不执行网络切片选择/NSSAA**：紧急注册跳过切片二次认证，确保最短路径放行； - 返回的 Registration Accept 中携带 Emergency Services 指示，UE 据此进入"紧急注册"状态。 设计意图很明确：**法规优先于商业逻辑**。救命电话不能因为欠费、被拒网而中断。 ### 阶段B：紧急PDU会话建立 UE 完成5G紧急注册后，发起 **Emergency PDU Session Establishment**（TS 23.502 clause 4.13）。这条流程与普通PDU会话建立有几处关键差异： 1. **DNN 固定为 Emergency DNN**（运营商标配的紧急专用DNN，典型如 `sos`），AMF 据此选择支持紧急能力的 SMF； 2. SMF **跳过 UDM 订阅校验、跳过 PCF 计费策略绑定**（部分国家要求保留呼叫记录但不向用户计费）； 3. SMF 通过 **PCO（Protocol Configuration Options）** 把 P-CSCF 地址下发给 UE——这是UE进入IMS域的"门牌号"； 4. UPF 建立紧急专用的用户面隧道，且这条承载通常被标记为**高优先级/不可抢占**。 抓包时，普通PDU会话 `DNN=internet`，紧急PDU会话 `DNN=sos`（或运营商定义值），且 NAS 消息中 `Emergency` 指示位被置位——这是 Wireshark 里最快的一眼区分法。 ### 阶段C：IMS紧急注册 UE 拿到 P-CSCF 地址后，发起 SIP REGISTER。这里有一个 **TS 24.229 规定的关键行为**：紧急注册时，P-CSCF **不把 REGISTER 转给 I-CSCF/S-CSCF**（因为用户可能根本无HSS签约），而是直接转给本服务区的 **E-CSCF**。E-CSCF 完成一个"宽松"的注册接纳：不要求完整的鉴权五元组，仅记录 UE 的联系地址与紧急注册状态，用于后续会话的合法性背书。 ### 阶段D：紧急会话建立——本文核心 这是整条链的"硬核"。逐步拆解每个信令消息的关键IE： #### 步骤8：UE → P-CSCF，INVITE UE 检测到用户拨打的是紧急号码（号码识别规则见 TS 22.101 与本地法规配置表），把 Request-URI 设为统一资源名： ``` INVITE sip:urn:service:sos SIP/2.0 ``` `urn:service:sos` 是 TS 24.229 定义的紧急服务 URN。若是细化子服务，可出现 `urn:service:sos.fire`、`urn:service:sos.police` 等，供E-CSCF/PSAP做业务分流。 #### 步骤9：P-CSCF → E-CSCF，INVITE（重路由） P-CSCF 识别到这是一次紧急呼叫后做两件事： - **插入 Route 头**指向本地 E-CSCF（旁路S-CSCF）； - **强制写入 `P-Access-Network-Info`** 头，携带 UE 当前接入的小区标识（cgi-3gpp / 全球小区标识 CGI），这是 LRF 进行定位的初始依据。 #### 步骤10/11：E-CSCF ↔ LRF，位置获取与路由键生成 E-CSCF 不直接知道该把呼叫送到哪个 PSAP，于是向 LRF 发起查询。LRF 的工作分两步： - **定位（Location Retrieval）**：以 `P-Access-Network-Info` 中的小区标识为起点，必要时通过 GMLC 触发更精确的定位流程（A-GNSS / OTDOA / E-CID），得到 UE 的 **NPLI（Network Provided Location Information）**； - **路由决策（Routing Determination，由 RDF 完成）**：依据"位置 → 行政服务区 → PSAP"映射表，输出 **ESRK（Emergency Service Routing Key）/ ESRN（Emergency Service Routing Number）** 和目标 PSAP 的 tel URI 或 SIP URI。 > **设计要点**：ESRK 同时承担"路由"与"回呼锚定"双重角色。PSAP 回呼时拨打 ESRK，网络据此把回呼路由回 LRF/E-CSCF，再锚定到原 UE。因此 ESRK 必须在 LRF 中与原始会话绑定保存一段时间（TS 23.167 要求 LRF 保存紧急会话记录）。 #### 步骤12～16：路由与媒体协商 E-CSCF 拿到 PSAP 路由地址后： - 若 PSAP 支持 SIP/IP 互联，直接前转 INVITE； - 若 PSAP 为电路域（传统），则经 **BGCF → MGCF** 完成到 CS 域的桥接，由 MGW 做媒体编解码转换（如 EVS↔G.711）。 随后的 `100 Trying`、`183 Session Progress`（可携带早媒体，让UE听到排队/语音提示）、`200 OK`、`ACK` 完成标准SIP三次握手，会话激活。 ### 阶段E：位置连续性与切换 紧急呼叫激活后，UE 可能在通话中移动并发生切换。TS 23.167 要求 LRF 持续更新位置；当从5G回落到LTE（紧急SRVCC）时，IMS侧锚点不变，**LRF 维持 ESRK 绑定**，保证 PSAP 始终能回呼到同一个用户。这一锚定逻辑是 eSRVCC 在紧急场景下的延伸，也是它与普通 eSRVCC 的关键区别。 ## 四、紧急INVITE的IE结构剖析 ```mermaid graph TB INV[紧急INVITE消息] --> RL[Request-Line] RL --> RL1["Request-URI:
sip:urn:service:sos"] INV --> HDR[SIP消息头域] HDR --> H1["P-Preferred-Service / P-Asserted-Service
urn:service:sos"] HDR --> H2["P-Access-Network-Info
IEEE-802.11/cg-3gpp 小区标识"] HDR --> H3["P-Asserted-Identity
tel:+ESRK(回呼锚定号)"] HDR --> H4["Route: sip:ecscf.home.net
(P-CSCF强制插入)"] HDR --> H5["Require/Supported: precondition
(可选,资源预留)"] INV --> SDP[SDP消息体] SDP --> S1["m=audio RTP/AVP(EVS/G.711)"] SDP --> S2["a=rtpmap / a=fmtp 编解码参数"] SDP --> S3["a=sendrecv 双向媒体"] ``` ## 五、关键IE与标识参数表 | 标识 / IE | 所在消息 | 作用 | 来源规范 | |---|---|---|---| | `urn:service:sos` | Request-URI | 紧急服务URN，触发E-CSCF路由 | TS 24.229 | | Emergency指示（5GMM） | NAS Registration Request | 5G紧急注册标志，免鉴权放行 | TS 23.502 / TS 24.501 | | Emergency DNN | PDU Session Req | 紧急专用DNN，免订阅校验 | TS 23.501 | | P-CSCF地址 | PCO容器 | SMF经PCO下发P-CSCF给UE | TS 24.501 | | `P-Access-Network-Info` | INVITE头域 | UE接入小区标识，定位起点 | TS 24.229 | | ESRK / ESRN | LRF→E-CSCF | 紧急路由键+PSAP回呼锚定号 | TS 23.167 | | NPLI | E-CSCF↔LRF | 网络提供的位置信息 | TS 23.167 | | RDF映射表 | LRF内部 | 位置→行政服务区→PSAP | TS 23.167 | | `P-Asserted-Identity` | E-CSCF→PSAP | 携带ESRK供PSAP显示/回呼 | TS 24.229 | ## 六、普通IMS呼叫 vs 紧急IMS呼叫对比 | 维度 | 普通IMS呼叫 | 紧急IMS呼叫 | |---|---|---| | 注册前提 | 必须完成正常IMS注册 | 可无USIM/受限服务下紧急注册 | | 鉴权 | 5G AKA/EAP-AKA'必须成功 | 紧急注册免/简化鉴权 | | PDU会话 | 正常DNN，需订阅与计费 | Emergency DNN，免订阅、多数地区免计费 | | CSCF路径 | P-CSCF→I-CSCF→S-CSCF | P-CSCF→E-CSCF（旁路S-CSCF） | | 路由依据 | 被叫号码 + ENUM/DNS解析 | UE位置 + ESRK → 就近PSAP | | 定位 | 不强制 | LRF/GMLC强制获取NPLI | | 切换连续性 | 普通SRVCC/切换 | 紧急SRVCC，LRF锚定保PSAP回呼可达 | | 业务触发 | iFC（依赖HSS签约） | 无iFC，E-CSCF直连 | | 计费 | 正常计费 | 法规豁免计费，但强制保留记录 | ## 七、状态机：UE紧急服务生命周期 ```text stateDiagram-v2 [*] --> 未注册_受限服务 未注册_受限服务 --> 紧急注册中: 拨打紧急号码/UE检测 紧急注册中 --> 紧急注册成功: 5G+IMS双注册完成 紧急注册成功 --> 紧急会话建立中: 发送INVITE(urn:service:sos) 紧急会话建立中 --> 紧急会话活跃: 收到200 OK+ACK 紧急会话活跃 --> 紧急会话活跃: 切换/位置更新(ESRK锚定不变) 紧急会话建立中 --> 注册失败释放: 路由失败/超时 紧急会话活跃 --> 会话释放: BYE(PSAP或UE释放) 会话释放 --> [*] 注册失败释放 --> [*] ``` 注意 **"紧急注册成功 → 紧急会话活跃"** 是单向递进：紧急注册态本身有时限，若长时间无会话，网络可回收该临时上下文；而会话一旦激活，即使UE短暂回到受限服务态，**会话仍被E-CSCF/LRF锚定维持**，这是法规"通话不可中断"的工程体现。 ## 八、抓包识别与故障排查 ### 8.1 抓包如何一眼识别这是紧急呼叫 在 Wireshark（NGAP/5G-NAS + SIP 联合过滤）中按以下特征定位： 1. **NAS层**：`Registration Type = Emergency` 或 PDU Session Request 中 `DNN = sos` 且消息含 Emergency Indication IE； 2. **PCO**：PDU Session Establishment Accept 中 P-CSCF IPv4/IPv6 地址出现在 Protocol Container Options； 3. **SIP层**：`Request-URI` 含 `urn:service:sos`；`Route` 头指向 `ecscf`；`P-Access-Network-Info` 存在； 4. **媒体面**：RTP流的目的端口对端为 PSAP/MGCF 网段。 ### 8.2 常见故障点与排错思路 | 现象 | 可能根因 | 排错切入 | |---|---|---| | 拨打紧急号码直接挂断 | UE未识别为紧急号，按普通呼叫处理 | 查UE紧急号码表配置（TS 22.101） | | 紧急注册被拒 | AMF未配置紧急注册能力 / NSSAI切片冲突 | 查AMF紧急注册开关与切片配置 | | PDU会话建立失败 | SMF不支持Emergency DNN / PCO未下发P-CSCF | 抓SMF N11，确认DNN与PCO | | INVITE到E-CSCF后被丢弃 | P-CSCF未正确插入Route到E-CSCF | 查P-CSCF路由策略 | | LRF返回错误PSAP | 定位NPLI不准 / RDF映射表过期 | 查GMLC定位精度与RDF服务区映射 | | PSAP无法回呼UE | ESRK绑定已过期或未锚定 | 查LRF的ESRK保留时长配置 | | 紧急SRVCC后掉话 | 切换未维持ESRK锚定 | 查ATCF/LRF锚定是否迁移 | ## 九、R18/R19演进：NG-eCall与多接入紧急呼叫 值得关注的是 **TS 23.167 在 Rel-18/Rel-19 引入的 NG-eCall（Next Generation eCall）**。eCall 是车载自动紧急呼叫（车辆碰撞后自动触发），NG-eCall 将其承载从2G/3G电路域迁移到5G IMS。Rel-19（TS 23.167 V19.1.1）明确： - 当车载UE发起NG-eCall时，INVITE携带车辆标识与 **MSD（Minimum Set of Data，最小数据集）**； - **若 LRF/RDF 未部署**，E-CSCF 可依据"自动发起（automatic initiation）"指示，使用带内信息（in-band modem / SIP body）把MSD送达PSAP，而不强依赖LRF做路由决策； - 多接入场景（固定宽带/Wi-Fi/4G/5G）下，P-CSCF需统一处理不同接入来的紧急呼叫，这一需求也已被 **ITU-T Q系列Suppl.72（2025-11）** 纳入信令要求。 这意味着 R19 之后，E-CSCF 不再是"必须有LRF才能工作"——这是对车联网、卫星接入、固移融合等异构网络的重要弹性。 ## 常见问题 **Q1：紧急呼叫为什么能打通，而普通呼叫被网络拒绝？** A：因为紧急呼叫走的是一套**旁路机制**——5G紧急注册免鉴权、紧急PDU会话免订阅、P-CSCF旁路S-CSCF直达E-CSCF。三条旁路共同确保即便用户处于受限服务态（欠费、被拒网、漫游受限），救命电话依然可达。这是法规要求强加于商业逻辑之上的设计。 **Q2：E-CSCF 和 S-CSCF 到底什么关系？为什么不能复用？** A：S-CSCF 依赖 HSS 签约数据执行 iFC 业务触发，**对未签约用户无法服务**；E-CSCF 是为紧急呼叫专门设计的"无条件接纳"锚点，不查签约、直接处理。二者职责正交，物理上 E-CSCF 通常与 S-CSCF 合设但逻辑实体独立。 **Q3：ESRK 和被叫号码有什么区别？** A：被叫号码是用户拨的"真实号码"（如110），而 ESRK 是 LRF 生成的**临时路由锚定号**。它的作用是双重的：①作为路由键把呼叫送到就近PSAP；②作为PSAP回呼时的锚定点，让回呼能路由回原始UE。普通呼叫没有这层抽象。 **Q4：UE 怎么知道一个号码是紧急号码？** A：UE 维护一张紧急号码识别表，来源有三：①USIM/USAT中预置（EF_ECC）；②网络在注册接受消息中下发（TS 22.101规定的Emergency Number List）；③UE本地法规配置（出厂烧录）。三者取并集。识别为紧急号后，UE才会用 `urn:service:sos` 触发紧急流程。 **Q5：紧急呼叫在切换后会不会掉？** A：标准要求**不掉**。通过紧急SRVCC + LRF的ESRK锚定，IMS侧会话锚点与PSAP的关联在切换前后保持不变。但工程上，锚定迁移依赖 ATCF/LRF 的正确配置，这是排错时的高发故障点（见8.2表）。 ## 参考来源 1. [3GPP TS 23.167 V19.1.1 — IMS emergency sessions](https://www.etsi.org/deliver/etsi_ts/123100_123199/123167/19.01.01_60/ts_123167v190101p.pdf) — clause 7 紧急会话建立流程，含NG-eCall与LRF/RDF机制 2. [3GPP TS 23.502 — Procedures for the 5G System](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3145) — clause 4.13 Emergency Services（含Emergency Registration与Emergency PDU Session Establishment） 3. [3GPP TS 24.229 — IP multimedia call control protocol based on SIP and SDP](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1498) — 紧急注册、`urn:service:sos`、P-Access-Network-Info等SIP编码 4. [TS 23.167 Section 7 — Procedures related to establishment of IMS emergency sessions](https://itecspec.com/3gpp/23.167/s/7) — 章节导航与子条款（7.3/7.4 含无注册场景） 5. [ITU-T Q Suppl.72 (11/2025) — Signalling requirements for IMS emergency call in support of multiple access](https://www.itu.int/epublications/publication/itu-t-q-suppl-72-2025-11-signalling-requirements-for-ip-multimedia-subsystem-ims-emergency-call-in-support-of-multiple-access) — 多接入（固网/Wi-Fi/4G/5G）统一紧急呼叫信令要求 --- > 本文由「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 等场景全覆盖。