聚焦 3GPP TS 23.167、TS 24.229、TS 23.502,拆解 VoNR 紧急呼叫从「紧急注册豁免 → P-CSCF 检测 → E-CSCF 路由 → LRF/RDF 定位获取 → ESQK 路由到 PSAP」的完整信令链路。
普通 IMS 呼叫的前提是:UE 完成 IMS 注册(携带 S-CSCF 指派)、签约有效、QoS 资源可用、媒体面打通。而紧急呼叫(Emergency Call,下称 E-Call)在监管层面有不可妥协的三条铁律——可达、定位、可回拨:
这三条铁律决定了 E-Call 在信令上完全绕开 home 网络(S-CSCF),由拜访地(visited)的 P-CSCF 直接把呼叫送到专用的 E-CSCF,再由 E-CSCF 联合 LRF 完成「定位 + 路由」。这一整套机制的核心规范是 TS 23.167(IMS emergency sessions),信令层面的 SIP 细节由 TS 24.229 定义,5G SA 下的承载与回退由 TS 23.502 clause 4.13.4 约束。
在 5G SA / VoNR 场景下,E-Call 还叠加了两层新东西:Emergency PDU Session(TS 23.502 clause 4.3.2.2,本地分流、绝不 home-routing)与 Emergency EPS Fallback(当 NR 覆盖不足以支撑 VoNR 时,把紧急呼叫回退到 EPS 做 VoLTE)。本文按信令流转顺序,把这条全链路拆透。
flowchart TD
UE[UE / UE without USIM]
gNB[(NG-RAN gNB / LMF)]
AMF[AMF]
PCF[PCF]
UPF[(UPF)]
PSCSCF[P-CSCF]
ECSCF[E-CSCF]
LRF["LRF<br/>(含 RDF 路由判决)"]
GMLC[GMLC]
PSAP[PSAP / ESRP / MGCF]
UE -- N1/N2/N3 --> gNB
gNB -- NGAP/N11 --> AMF
AMF -- Ng/Namf --> GMLC
AMF <--> PCF
gNB -- N3 --> UPF
UE -- SIP/Gm --> PSCSCF
PSCSCF -- "Mw (紧急 INVITE 直达,<br/>绕开 S-CSCF)" --> ECSCF
ECSCF -- "Mi/Ml" --> LRF
LRF -- "SLg / NLg" --> GMLC
LRF -- "RDF 路由判决" --> PSAP
PSAP -- "SIP/ISUP" --> ECSCF
各实体职责(依据 TS 23.167 clause 6):
| 实体 | 核心职责 | 关键规范 |
|---|---|---|
| P-CSCF | 第一跳,检测紧急呼叫;为未注册 UE 触发紧急注册;把紧急 INVITE 直接路由到 E-CSCF | TS 24.229 §5.4 |
| E-CSCF | 紧急会话专用 CSCF,不要求 UE 注册/鉴权;选择 LRF;把呼叫路由到正确 PSAP;支持 PSAP 回拨 | TS 23.167 §6.2 |
| LRF | Location Retrieval Function:获取 UE 初始/重定位位置;分配 ESQK;内含 RDF | TS 23.167 §6.3 |
| RDF | Routing Determination Function:根据位置+ESQK 判决目标 PSAP(可与 LRF 合设) | TS 23.167 §6.4 |
| GMLC | Gateway Mobile Location Centre:在 5G 下经 SLg/Ng 接口从 AMF/LMF 取位置;可与 LRF 合设 | TS 29.172 / TS 23.271 |
| EATF | Emergency Access Transfer Function:支持紧急呼叫的 SRVCC/DRVCC 接续,保障切换不中断 | TS 23.237 |
| PSAP | Public Safety Answering Point:紧急中心,可经 ESRP/MGCF 适配 SIP 或 ISUP | — |
当 UE 拨打紧急号码时,P-CSCF 首先判断 UE 是否已正常注册:
Service-Route 头域(普通注册的 200 OK 必带 Service-Route,用于后续请求找到 S-CSCF)。设计意图非常明确——切断 UE 后续请求通往 S-CSCF 的路径,确保紧急 INVITE 不会被错误地路由回 home S-CSCF。
2. P-CSCF 本地维护一个「紧急注册状态」,使得后续紧急 INVITE 直接发给 E-CSCF。设计哲学:紧急注册只服务于「把呼叫送出去」这一件事,不分配任何归属域的会话服务能力,最大限度保证「无签约也能打通」。
P-CSCF 如何判断一个 INVITE 是紧急呼叫?依据 TS 24.229 §5.1.6 与 RFC 5031,检测条件为满足其一:
urn:service:sos、urn:service:sos.ambulance、urn:service:sos.fire、urn:service:sos.police(北美还可能用 urn:service:sos 子类型或本地紧急号码)。检测命中后,P-CSCF 执行三件事:
urn:service:sos(或更细的子类型);P-Access-Network-Info(RFC 7315),可能携带 CGI/ECGI/TAI,供 E-CSCF/LRF 初步定位。E-CSCF 收到紧急 INVITE 后,第一步是选择并查询 LRF(依据 TS 23.167 clause 7.2)。LRF 完成两件事:取位置、给路由号。
(1) 取位置——两种语义
| 位置类型 | 触发时机 | 获取方式 | 精度 |
|---|---|---|---|
| Initial Location(初始位置) | 呼叫建立期间,E-CSCF/LRF 主动发起 | 优先用 IP-CAN 已知的小区级信息(ECGI+TAI),可接受时直接用;不满足则触发定位 | 小区级(数百米~公里) |
| Retrieved/Requery Location(重定位) | 通话进行中或 PSAP 显式请求 | 经 GMLC→AMF→LMF 触发 NG-RAN 定位(A-GNSS/OTDOA 等) | 米级(10~50m) |
在 5G SA 下,定位获取的内部链路是:LRF(合设 GMLC)→(SLg/NLg 接口)→ AMF →(Namf_Location)→ LMF/gNB,由 LMF 执行 NG-RAN 侧定位计算(TS 38.305)。AMF 本身可即时返回当前服务小区的 ECGI+TAI 作为「快速初始位置」,避免呼叫建立被定位流程阻塞。
(2) 给路由号——ESQK / ESRK / ESRD
LRF/RDF 为本次呼叫分配一个全局唯一的路由键,三者概念相近、有部署差异:
RDF 拿到位置(经纬度/小区)后,结合本地 PSAP 服务区映射表,判决出唯一目标 PSAP,并把 ESQK 作为新的 Request-URI/被叫号塞回 INVITE,交 E-CSCF 路由出去。
下图涵盖「未注册 UE → 紧急注册 → Emergency PDU Session → 紧急 INVITE → LRF 取位置 → ESQK 路由 → PSAP 接听 → PSAP 回拨」全链。
sequenceDiagram
autonumber
participant UE
participant gNB as NG-RAN(gNB)
participant AMF
participant SMF
participant PCSCF as P-CSCF
participant ECSCF as E-CSCF
participant LRF as LRF/RDF
participant GMLC
participant LMF
participant PSAP
Note over UE,AMF: ① 紧急注册 + Emergency PDU Session(TS 23.502 §4.13.4)
UE->>gNB: RegRequest(Emergency Reg, Request Type=Emergency)
gNB->>AMF: N2 + NAS(Emergency Reg)
AMF-->>UE: Emergency Registration(受限服务,无 Home S-CSCF)
UE->>AMF: PDU Session Est(Emergency DNN, LBO 本地分流)
AMF->>SMF: 选本地 SMF/UPF(Emergency Session)
SMF-->>UE: Emergency PDU Session 建立(Gm 链路打通)
Note over UE,LRF: ② 紧急 INVITE 与定位获取
UE->>PCSCF: INVITE urn:service:sos + P-Access-Network-Info
PCSCF->>PCSCF: 检测命中(URN/本地号码),改写 R-URI,跳过 S-CSCF
PCSCF->>ECSCF: INVITE(紧急,直达 E-CSCF)
ECSCF->>LRF: INVITE(请求位置+ESQK)
LRF->>GMLC: 取 Initial Location(SLg/NLg)
GMLC->>AMF: Namf_Location_ProvidePositionInfo
alt 需精确位置
AMF->>LMF: 触发 NG-RAN 定位(A-GNSS/OTDOA)
LMF-->>AMF: 精确位置
else 快速初始位置
AMF-->>GMLC: ECGI+TAI(小区级)
end
GMLC-->>LRF: Location + 分配 ESQK
LRF->>LRF: RDF 判决目标 PSAP
LRF-->>ECSCF: 200/INVITE(R-URI=ESQK,路由信息)
ECSCF->>PSAP: INVITE(ESQK + 位置)
PSAP-->>ECSCF: 183 Session Progress(SDP)
ECSCF-->>UE: 183(SDP + QoS 协商)
UE-->>PSAP: PRACK/UPDATE(可靠临时响应)
PSAP-->>UE: 200 OK(应答)
UE-->>PSAP: ACK(媒体面建立,紧急通话开始)
Note over PSAP,UE: ③ 通话中断后 PSAP 回拨(RFC 7090)
PSAP->>ECSCF: INVITE(R-URI=ESQK,回拨)
ECSCF->>LRF: 按 ESQK 反查 UE
LRF-->>ECSCF: UE 当前联系信息
ECSCF-->>UE: INVITE(回拨接入)
紧急 INVITE 携带的位置与标识类头域是排查的核心抓手。下表列出最关键的 Information Element:
| IE / SIP 头域 | 所在消息 | 作用 | 取值示例 |
|---|---|---|---|
Request-URI |
INVITE | 紧急标识,P-CSCF 改写后用于路由 | urn:service:sos.ambulance |
P-Access-Network-Info |
INVITE/REGISTER | 接入网信息(RFC 7315),含 ECGI/TAI/ARFCN | IEEE-802.11 或 3GPP-NR-TDD; cgi-ecgi=0xABCDEF |
P-Asserted-Identity |
INVITE | 主叫身份(紧急呼叫可为受限/临时号) | sip:[email protected] |
Geolocation(RFC 6442) |
INVITE | 位置 conveyance,可带 PIDF-LO(经纬度/civic) | application/pidf+xml |
| ESQK | LRF 返回/路由 URI | LRF 分配的全局唯一路由键,关联位置与回拨 | esqk:[email protected] |
| ESRD/ESRK | INVITE(CS/混合部署) | 选 PSAP 群 / 路由键 | — |
Service-Route(缺席) |
紧急 REGISTER 200 OK | 故意不携带,阻断回 home S-CSCF | (不出现) |
P-Emergency-Service-Local-Function |
200 OK | E-CSCF 返回,告知 UE 紧急服务已识别 | — |
下图是「紧急 INVITE 关键头域」的组装视图,帮助理解各实体填入的字段:
flowchart TB
subgraph UE
A1["From/To/Call-ID<br/>Via, CSeq"]
end
subgraph P-CSCF["P-CSCF(改写层)"]
B1["Request-URI<br/>→ urn:service:sos.ambulance"]
B2["+ P-Access-Network-Info<br/>(ECGI/TAI,来自 5GC)"]
B3["+ Route: E-CSCF"]
end
subgraph LRF["LRF/RDF(定位层)"]
C1["+ ESQK(分配)<br/>→ 新 Request-URI"]
C2["+ Geolocation(PIDF-LO)<br/>经纬度/civic"]
C3["+ 目标 PSAP 路由信息"]
end
A1 --> B1 --> B2 --> B3
B3 --> C1 --> C2 --> C3
C3 --> OUT["送达 PSAP 的最终 INVITE"]
紧急呼叫在 5G SA 下有两条不可忽视的「承载侧」机制:
1. Emergency PDU Session(TS 23.502 §4.3.2.2) - UE 用 Emergency DNN 建立 PDU 会话,强制 LBO(本地分流),SMF/UPF 必选在拜访地,绝不 home-routing——否则位置与媒体都会绕回 home,违背紧急呼叫「visited 处置」原则。 - 该会话不依赖用户签约,AMF 仅根据 Request Type=Emergency 受理,PCF 可下发受限 QoS(保证 SIP 信令 5QI 与媒体 5QI=1)。
2. Emergency EPS Fallback(TS 23.502 §4.13.4.2) - 当 AMF 判定当前 NG-RAN 不支持 IMS voice over NR(或覆盖不足以保证紧急通话质量)时,紧急呼叫触发 EPS Fallback:N2 触发 handover 或 RRC Release 重定向到 E-UTRAN,UE 在 EPS 内重做 VoLTE 紧急呼叫。 - AMF 在 Registration Accept 中通过 EPS Fallback Indicator 与能力协商告知 UE 是否会回退;gNB 则依据 NR 覆盖质量决定走 handover 还是 redirection。 - 这一步对监管极其敏感:紧急呼叫的 Fallback 时延也计入紧急服务可用性指标,因此部分国家要求优先 handover(而非重定向)以缩短中断。
stateDiagram-v2
[*] --> 检测NR覆盖: UE 拨打紧急号码
检测NR覆盖 --> VoNR紧急呼叫: NR 覆盖 + IMS voice over NR 支持
检测NR覆盖 --> EPS_Fallback: NR 覆盖不足 / 不支持 VoNR
VoNR紧急呼叫 --> 通话建立: LRF 取位 + ESQK 路由
EPS_Fallback --> 切换方式: N2 Handover(时延优)
EPS_Fallback --> 重定向方式: RRC Release + Redirection
切换方式 --> VoLTE紧急呼叫: 在 EPS 内重建
重定向方式 --> VoLTE紧急呼叫: 在 EPS 内重建
VoLTE紧急呼叫 --> 通话建立
通话建立 --> SRVCC接续: 通话中无线恶化
SRVCC接续 --> 通话保持: 经 EATF 转接 CS 域
抓包如何识别一条紧急呼叫
- 在 Gm(UE↔P-CSCF)抓 SIP:找 Request-URI 含 urn:service:sos*,或被叫为本地紧急号码但被 P-CSCF 改写为 URN 的 INVITE。
- 在 Mw(P-CSCF↔E-CSCF)抓包:紧急 INVITE 的 Route 头应指向 E-CSCF,不应出现 S-CSCF 的 service-route 痕迹。
- 在 LRF 侧:找分配 ESQK 的交互,以及 GMLC 与 AMF 之间的 Namf_Communication_N1N2MessageTransfer / Namf_Location 调用。
- 5GC 侧:Emergency PDU Session 的请求中 Request type = Initial Emergency Request,DNN 为 emergency DNN。
常见故障点与排错思路
| 现象 | 可能根因 | 排查方向 |
|---|---|---|
| 未注册 UE 拨不通紧急号 | P-CSCF 未支持紧急注册 / 无 Emergency SCC | 检查 P-CSCF 紧急注册配置、AMF Emergency Reg 受理 |
| 紧急 INVITE 被误送到 S-CSCF | 紧急 REGISTER 200 OK 误带 Service-Route,或 P-CSCF 检测规则缺失 |
核对 200 OK 是否省略 Service-Route;核对号码→URN 改写表 |
| 位置为空/不准 | LRF↔GMLC↔AMF 链路断;Initial Location 用了过期 ECGI | 查 SLg/NLg 接口;检查 LMF 定位触发与 A-GNSS 配置 |
| PSAP 收不到 / 路由错 PSAP | RDF PSAP 服务区映射过期;ESQK 分配冲突 | 核对小区→PSAP 映射表;检查 ESQK 池分配 |
| 回拨失败 | ESQK 在 LRF 侧已释放/超时;UE 已移出原区 | 检查 LRF ESQK 保持时长(TS 23.167 要求保留足够时间支持回拨) |
| ## 常见问题 |
Q1: 紧急 INVITE 为什么不能走 S-CSCF?
A: 紧急呼叫的可达性要求与归属域无关——UE 可能无签约、无 USIM,home S-CSCF 根本不存在。走 S-CSCF 会引入鉴权、iFC 触发、漫游回 home 等不可控环节,且会绕远路、增加时延。因此标准规定 P-CSCF 直接路由到 visited 的 E-CSCF,紧急注册的 200 OK 也刻意不带 Service-Route 以从机制上阻断回 home 的路径。
Q2: ESQK 到底有什么用?为什么不能直接用 UE 号码路由? A: 紧急场景下 UE 经常没有有效的、可被 PSAP 识别的号码(受限服务)。ESQK 由 LRF 动态分配,全网唯一,且在 LRF 侧绑定本次呼叫的 UE 位置与当前联系信息。它既是路由键(RDF 据此选 PSAP),也是 PSAP 回拨的索引——PSAP 回拨 ESQK,E-CSCF 反查 LRF 即可定位 UE,实现「可回拨」铁律。
Q3: Initial Location 和 Retrieved Location 有何区别?是否都必需? A: Initial Location 在呼叫建立期间获得,优先用 IP-CAN 已知的小区级信息(ECGI+TAI),追求快速,用于先把呼叫路由到大致正确的 PSAP;Retrieved/Requery Location 在通话中或 PSAP 请求时,经 NG-RAN 定位(A-GNSS/OTDOA)获得米级精度,用于精准派遣救援。监管通常要求至少提供初始位置保证呼叫路由,重定位则按需触发。
Q4: 5G 紧急呼叫为什么必须用 Emergency PDU Session 且本地分流? A: 紧急会话要求在 visited 网络就地处置(路由到本地 PSAP、用本地 LRF/定位资源)。若 PDU 会话 home-routing,媒体与信令会回到 home UPF/IMS,不仅位置获取复杂化、时延增大,还可能在跨地/跨国漫游时把呼叫路由到错误的 PSAP。Emergency DNN + 强制 LBO 是从承载层就保证「visited 就地处理」的关键。
Q5: VoNR 覆盖不足时紧急呼叫怎么办? A: 触发 Emergency EPS Fallback(TS 23.502 §4.13.4.2)。AMF 依据 NG-RAN 上报的 IMS voice 支持能力与覆盖质量判定,通过 N2 Handover 或 RRC Release+Redirection 把 UE 转到 E-UTRAN,UE 在 EPS 内建立 VoLTE 紧急呼叫。优先用 Handover 以缩短中断时延;通话中无线恶化还可经 EATF 做 SRVCC/DRVCC 接续到 CS 域,保证不中断。
本文由「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 等场景全覆盖。
