普通IMS主被叫建立在一条简单假设之上——用户已完成正常注册、持有有效凭证、网络已为其建立了正常PDU会话。但紧急呼叫（Emergency Call，如110/119/120、北美911、欧盟112）恰恰要打破这三条假设中的每一条：
这条"打破三条假设"的特殊性，催生了一整套独立的网元与信令：紧急注册（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 的路由决策 这一核心机制。
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
值得强调的三个设计取舍：
P-CSCF → S-CSCF，而紧急呼叫 P-CSCF → E-CSCF。原因在于 S-CSCF 依赖用户签约（iFC触发、业务链），但紧急呼叫必须对未签约/未注册用户也可达，因此绕开依赖HSS签约的S-CSCF，由专用 E-CSCF 终结。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: 会话激活：双向媒体流（含定位上报持续）
当 UE 处于受限服务状态（例如USIM鉴权失败、被网络拒绝），用户拨打紧急号码时，UE 触发 5G紧急注册（TS 23.502 clause 4.13 中 Emergency Registration 流程）。AMF 收到携带 Emergency 指示的 Registration Request 后：
设计意图很明确：法规优先于商业逻辑。救命电话不能因为欠费、被拒网而中断。
UE 完成5G紧急注册后，发起 Emergency PDU Session Establishment（TS 23.502 clause 4.13）。这条流程与普通PDU会话建立有几处关键差异：
sos），AMF 据此选择支持紧急能力的 SMF；抓包时，普通PDU会话 DNN=internet，紧急PDU会话 DNN=sos（或运营商定义值），且 NAS 消息中 Emergency 指示位被置位——这是 Wireshark 里最快的一眼区分法。
UE 拿到 P-CSCF 地址后，发起 SIP REGISTER。这里有一个 TS 24.229 规定的关键行为：紧急注册时，P-CSCF 不把 REGISTER 转给 I-CSCF/S-CSCF（因为用户可能根本无HSS签约），而是直接转给本服务区的 E-CSCF。E-CSCF 完成一个"宽松"的注册接纳：不要求完整的鉴权五元组，仅记录 UE 的联系地址与紧急注册状态，用于后续会话的合法性背书。
这是整条链的"硬核"。逐步拆解每个信令消息的关键IE：
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做业务分流。
P-CSCF 识别到这是一次紧急呼叫后做两件事：
- 插入 Route 头指向本地 E-CSCF（旁路S-CSCF）；
- 强制写入 P-Access-Network-Info 头，携带 UE 当前接入的小区标识（cgi-3gpp / 全球小区标识 CGI），这是 LRF 进行定位的初始依据。
E-CSCF 不直接知道该把呼叫送到哪个 PSAP，于是向 LRF 发起查询。LRF 的工作分两步：
P-Access-Network-Info 中的小区标识为起点，必要时通过 GMLC 触发更精确的定位流程（A-GNSS / OTDOA / E-CID），得到 UE 的 NPLI（Network Provided Location Information）；设计要点：ESRK 同时承担"路由"与"回呼锚定"双重角色。PSAP 回呼时拨打 ESRK，网络据此把回呼路由回 LRF/E-CSCF，再锚定到原 UE。因此 ESRK 必须在 LRF 中与原始会话绑定保存一段时间（TS 23.167 要求 LRF 保存紧急会话记录）。
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三次握手，会话激活。
紧急呼叫激活后，UE 可能在通话中移动并发生切换。TS 23.167 要求 LRF 持续更新位置；当从5G回落到LTE（紧急SRVCC）时，IMS侧锚点不变，LRF 维持 ESRK 绑定，保证 PSAP 始终能回呼到同一个用户。这一锚定逻辑是 eSRVCC 在紧急场景下的延伸，也是它与普通 eSRVCC 的关键区别。
graph TB
INV[紧急INVITE消息] --> RL[Request-Line]
RL --> RL1["Request-URI:<br/>sip:urn:service:sos"]
INV --> HDR[SIP消息头域]
HDR --> H1["P-Preferred-Service / P-Asserted-Service<br/>urn:service:sos"]
HDR --> H2["P-Access-Network-Info<br/>IEEE-802.11/cg-3gpp 小区标识"]
HDR --> H3["P-Asserted-Identity<br/>tel:+ESRK(回呼锚定号)"]
HDR --> H4["Route: sip:ecscf.home.net<br/>(P-CSCF强制插入)"]
HDR --> H5["Require/Supported: precondition<br/>(可选,资源预留)"]
INV --> SDP[SDP消息体]
SDP --> S1["m=audio RTP/AVP(EVS/G.711)"]
SDP --> S2["a=rtpmap / a=fmtp 编解码参数"]
SDP --> S3["a=sendrecv 双向媒体"]
| 标识 / 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呼叫 | 紧急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直连 |
| 计费 | 正常计费 | 法规豁免计费，但强制保留记录 |
stateDiagram-v2
[*] --> 未注册_受限服务
未注册_受限服务 --> 紧急注册中: 拨打紧急号码/UE检测
紧急注册中 --> 紧急注册成功: 5G+IMS双注册完成
紧急注册成功 --> 紧急会话建立中: 发送INVITE(urn:service:sos)
紧急会话建立中 --> 紧急会话活跃: 收到200 OK+ACK
紧急会话活跃 --> 紧急会话活跃: 切换/位置更新(ESRK锚定不变)
紧急会话建立中 --> 注册失败释放: 路由失败/超时
紧急会话活跃 --> 会话释放: BYE(PSAP或UE释放)
会话释放 --> [*]
注册失败释放 --> [*]
注意 "紧急注册成功 → 紧急会话活跃" 是单向递进：紧急注册态本身有时限，若长时间无会话，网络可回收该临时上下文；而会话一旦激活，即使UE短暂回到受限服务态，会话仍被E-CSCF/LRF锚定维持，这是法规"通话不可中断"的工程体现。
在 Wireshark（NGAP/5G-NAS + SIP 联合过滤）中按以下特征定位：
Registration Type = Emergency 或 PDU Session Request 中 DNN = sos 且消息含 Emergency Indication IE；Request-URI 含 urn:service:sos；Route 头指向 ecscf；P-Access-Network-Info 存在；| 现象 | 可能根因 | 排错切入 |
|---|---|---|
| 拨打紧急号码直接挂断 | 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）明确：
这意味着 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表）。
urn:service:sos、P-Access-Network-Info等SIP编码本文由「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 等场景全覆盖。