5G IMS紧急呼叫E-CSCF与LRF路由信令全链拆解

紧急呼叫（Emergency Call）是整个移动通信体系里要求最高、容错空间最小的业务：它必须在用户欠费停机、没有USIM卡、漫游在陌生网络、甚至正常鉴权刚刚失败的极端条件下，依然能在几秒内接通到最近的公共安全应答点（PSAP）。这就决定了IMS紧急呼叫不能复用普通VoNR主叫那套"先注册鉴权→建立QoS流→按用户签约路由"的逻辑，而必须设计一条绕过用户归属域、本地化锚定、强制携带定位信息的旁路信令链。本文依据3GPP TS 23.167（IMS emergency sessions，Stage 2）、TS 23.502（5GS Procedures）和TS 24.229（SIP procedures），从5GC紧急承载建立到E-CSCF/LRF路由判定再到PSAP落地，逐消息拆解这条旁路信令。

一、为什么紧急呼叫必须"另起炉灶"

普通IMS呼叫的路由依赖S-CSCF从用户归属域（HSS/UDM）查询iFC（initial Filter Criteria），再根据签约触发AS、按Tel URI做ENUM/DNS解析。这一套对紧急呼叫有四个致命缺陷：

1. 依赖用户签约与正常鉴权——欠费、无卡、鉴权失败的UE根本到不了S-CSCF；
2. 归属域路由会绕远路——一个漫游到外地的用户，紧急呼叫若回归属域再转出来，定位和接续时延不可接受，且跨运营商边界后PSAP选择会错乱；
3. 不强制携带定位——普通INVITE里没有强制性的位置信息，而法规要求PSAP必须知道呼叫者位置；
4. 回调困难——紧急呼叫结束后PSAP可能需要回拨，但用户号码可能根本不存在。

为此3GPP定义了E-CSCF（Emergency-CSCF）作为专门网元，固定部署在UE当前接入的拜访网络（Visited Network），所有紧急INVITE无论用户是否注册、是否漫游，都强制路由到这个本地的E-CSCF，再由它配合LRF（Location Retrieval Function）完成定位与PSAP选择。这就是整个机制的核心理念：紧急呼叫的处置权交给接入地，而非归属地。

二、关键功能实体与职责

三、紧急呼叫的三阶段全链视图

完整的紧急呼叫在5G体系下分三个阶段：5GC紧急承载阶段（让一个无法正常接入的UE拿到IP连通性）→IMS紧急会话建立阶段（INVITE经P-CSCF到E-CSCF到PSAP）→会话维持与释放阶段（媒体建立、定位更新、回调窗口）。

下面这张总览状态图刻画了UE侧在三个阶段的状态迁移：

stateDiagram-v2
    [*] --> 正常注册态: 普通用户
    [*] --> 有限服务态: 无卡/欠费/鉴权失败
    正常注册态 --> 紧急承载就绪: 紧急PDU会话建立
    有限服务态 --> 紧急注册态: TS23.502 §4.12.2
    紧急注册态 --> 紧急承载就绪: 紧急PDU会话建立
    紧急承载就绪 --> 紧急会话进行中: INVITE→PSAP应答
    紧急会话进行中 --> 回调保护窗口: BYE后ESRK保留T_guard
    回调保护窗口 --> [*]: 超时/PSAP回拨完成后释放
    紧急会话进行中 --> 紧急会话进行中: EATF锚定下跨域切换
    note right of 紧急承载就绪
        拜访网络本地锚定
        不经归属域路由
    end note

3.1 阶段一：5GC紧急承载（无卡/无鉴权也能上网）

当UE处于有限服务状态（Limited Service State），它无法发起正常注册，但可以发起紧急注册（TS 23.502 §4.12.2）。UE在Registration Request中把Registration type置为"emergency registration"，AMF识别后跳过完整的用户鉴权（或仅做IMEI检查），建立一条仅限紧急业务的受限注册上下文。

紧接着UE发起紧急PDU会话建立（TS 23.502 §4.3.5.2），关键区别于普通PDU会话：

• Request type = "emergency request"；
• 使用网络侧配置的紧急专用DNN（每个PLMN本地配置，UE不需要也不允许自己指定）；
• 不需要SMF做二次用户鉴权，不查UDM签约；
• 只支持IPv4/IPv6类型（不支持Ethernet/Unstructured）；
• 紧急PDU会话始终锚定在拜访网络，不做Home-Routed，确保本地落地；
• SMF在PDU Session Establishment Accept中通过PCO（Protocol Configuration Options）把P-CSCF地址下发给UE。

下面是5GC侧紧急承载建立的信令时序（覆盖无鉴权UE的完整路径）：

sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    participant SMF
    participant UPF
    participant PCF
    UE->>AMF: Registration Request(type=Emergency Registration)
    Note over AMF: 跳过用户鉴权, 仅查IMEI, 接受紧急注册
    AMF-->>UE: Registration Accept(含Emergency Number List)
    UE->>AMF: PDU Session Establishment Request(request type=emergency request)
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext(emergency indication)
    Note over SMF: 不查UDM, 选本地支持紧急业务的SMF/UPF
    SMF->>PCF: Npcf_SMPolicyControl(紧急策略)
    PCF-->>SMF: 紧急QoS规则(高ARP, pre-emption)
    SMF->>UPF: N4 会话建立
    SMF->>AMF: Namf_Communication_N1N2Msg(PDU Session Est. Accept+PCO)
    Note over AMF: PCO内含P-CSCF地址
    AMF->>gNB: N2 PDU Session Resource Setup
    AMF->>UE: PDU Session Establishment Accept
    UE->>UE: 解析PCO获得P-CSCF IP, 准备发起IMS紧急INVITE

设计意图：把"获得IP连通性"与"用户合法身份"彻底解耦。监管要求任何UE都必须能打通紧急电话，所以5GC在协议层面专门留出一条不依赖USIM鉴权的承载通道，并通过Emergency Number List（NAS IE，TS 24.501）把当地紧急号码下发给UE，避免漫游UE用错号码。

3.2 阶段二：IMS紧急会话建立（核心信令）

UE拿到P-CSCF地址后，识别到用户拨的是紧急号码（或自身判定为紧急），构造一条紧急INVITE。这是整条链的灵魂，关键SIP头部如下表：

紧急INVITE抵达P-CSCF后，P-CSCF做三件关键动作：①识别为紧急（按URN或号码表）；②插入定位（若UE未带PIDF-LO，P-CSCF可据P-Access-Network-Info补，或标记由E-CSCF/LRF获取）；③强制本地路由——无论用户归属域在哪，P-CSCF都把INVITE转发到拜访网络本地的E-CSCF，绕过S-CSCF的iFC触发逻辑。

下面是IMS紧急会话建立的完整时序（含定位查询与PSAP落地）：

sequenceDiagram
    participant UE
    participant PCSCF as P-CSCF
    participant ECSCF as E-CSCF
    participant LRF as LRF/RDF
    participant GMLC as GMLC
    participant MGCF as MGCF
    participant PSAP as PSAP
    UE->>PCSCF: INVITE(urn:service:sos, P-Access-Network-Info, SDP)
    Note over PCSCF: 识别紧急, 插入定位, 申请紧急QoS(高ARP)
    PCSCF->>ECSCF: 转发INVITE(本地E-CSCF, 绕过S-CSCF)
    ECSCF->>LRF: Location/Routing查询(携带小区/坐标)
    alt 仅有粗定位
        LRF->>GMLC: 触发高精度定位
        GMLC->>GMLC: AMF→LMF→gNB→UE定位
        GMLC-->>LRF: 精确位置(PIDF-LO)
    end
    Note over LRF: RDF用位置映射PSAP服务区
    LRF-->>ECSCF: 返回PSAP地址 + ESRK/ESQK + PIDF-LO
    alt PSAP支持IP(SIP)
        ECSCF->>PSAP: INVITE(Request-URI=ESRK, PAI=ESRK, body=PIDF-LO)
    else PSAP为CS域(PSTN)
        ECSCF->>MGCF: INVITE(经BGCF选路)
        MGCF->>PSAP: IAM(ISUP, 主叫=ESRK)
    end
    PSAP-->>ECSCF: 183 Session Progress(SDP)
    ECSCF-->>PCSCF: 183
    PCSCF-->>UE: 183(Session Progress)
    UE->>PCSCF: PRACK
    PCSCF->>ECSCF: PRACK
    E_CSCF = ECSCF
    PSAP-->>ECSCF: 200 OK(应答)
    ECSCF-->>PCSCF: 200 OK
    PCSCF-->>UE: 200 OK
    UE->>PCSCF: ACK...(双向RTP媒体建立)
    Note over LRF: 保留ESRK↔UE映射, 进入回调保护窗口(T_guard)

3.3 阶段三：定位更新、跨域切换与回调窗口

紧急会话建立后还有两个普通呼叫没有的特殊机制：

• 定位更新（Location Update）：UE若在通话中移动，E-CSCF可周期性或事件触发地向LRF更新位置，LRF再通过PSAP支持的接口（如HELD）把新位置推给PSAP，确保救援队伍知道最新坐标。
• EATF锚定的紧急SRVCC：若紧急通话期间UE从5G覆盖区移出（例如进入只有3G/2G CS覆盖的区域），E-CSCF此前已将会话锚定在EATF，配合MSC Server增强完成PS→CS域切换，保证通话不掉线。这一点比普通eSRVCC更严格——紧急呼叫在任何情况下都不允许因切换失败而中断。
• 回调保护：通话BYE后，LRF不会立即释放ESRK与UE的映射，而是保留一个T_guard保护时间（典型数分钟）。期间PSAP回拨ESRK，LRF能把它路由回原UE。

四、E-CSCF路由决策：一棵判定树

E-CSCF收到INVITE后并不是无脑转发，而是要依次回答几个问题：定位够不够？PSAP是IP还是CS？需不需要触发高精度定位？这张决策流程图刻画了E-CSCF的路由判定逻辑：

flowchart TD
    A[E-CSCF收到紧急INVITE] --> B{Request-URI为URN?}
    B -- 否 --> B1[据Emergency Number List改写并打标记]
    B -- 是 --> C
    B1 --> C{是否带有效定位 PIDF-LO?}
    C -- 否 --> D[向LRF请求定位/触发GMLC高精度定位]
    C -- 是 --> E
    D --> E[LRF/RDF用位置映射PSAP服务区]
    E --> F{LRF返回PSAP类型?}
    F -- IP/SIP可达 --> G[E-CSCF直发INVITE至PSAP SIP URI]
    F -- 仅CS/PSTN可达 --> H[经BGCF选MGCF, SIP转ISUP/IAM]
    G --> I[分配/记录ESRK+PIDF-LO, 进入T_guard保护]
    H --> I
    I --> J{通话中UE移动/跨域?}
    J -- 是 --> K[EATF锚定, 触发紧急SRVCC或位置更新]
    J -- 否 --> L[正常媒体维持]
    K --> L
    L --> M[BYE后保留ESRK映射支持PSAP回拨]

五、普通IMS呼叫 vs 紧急呼叫：一张表看清差异

六、抓包识别与排错实战

6.1 抓包如何认出这是紧急呼叫

在5GC侧（NGAP/NAS抓包）：关注REGISTRATION REQUEST中的Registration type=Emergency registration，以及PDU SESSION ESTABLISHMENT REQUEST中的Request type=Emergency request。这是两条最硬的标志位。

在IMS侧（SIP抓包，通常在P-CSCF/E-CSCF上抓）：第一时间看Request-URI是否为urn:service:sos*。如果URI仍是tel:110，则需要进一步确认P-CSCF是否完成了紧急识别并改写——若INVITE被错误地按普通号码路由到S-CSCF而非E-CSCF，就是典型的识别失败。

6.2 常见故障点

1. UE未识别紧急号码：漫游UE拿到了错误的Emergency Number List，或USIM未配置当地号码，导致UE按普通呼叫处理。排错：核对NAS Registration Accept里的Emergency Number List IE（TS 24.501）。
2. 紧急PDU会话建立失败：拜访网络未配置紧急DNN，或SMF未开启紧急业务支持。表现为PDU Session Establishment Reject。排错：检查SMF/UPF的紧急业务配置与本地DNN。
3. P-CSCF未下发：UE拿到了紧急承载但收不到P-CSCF地址，无法发起INVITE。排错：核对PCO里P-CSCF地址是否下发。
4. E-CSCF路由错误：INVITE被错误地经S-CSCF走了归属域路由（绕远了），通常因P-CSCF的紧急识别规则未命中。排错：检查P-CSCF的紧急号码表/URN识别规则。
5. 定位缺失导致PSAP拒收：E-CSCF未从LRF拿到有效PIDF-LO，PSAP按法规拒绝接续。排错：检查LRF↔GMLC↔AMF↔LMF定位链是否打通，小区→PSAP映射表（RDF数据库）是否完整。
6. ESRK回拨失败：T_guard超时设置过短或ESRK映射丢失，PSAP回拨接不通。排错：核对LRF的ESRK保留时长与映射表。

七、常见问题

Q1: 紧急呼叫为什么一定要走E-CSCF，能不能直接从P-CSCF送到PSAP？ A: 不能。P-CSCF不具备定位查询和PSAP服务区映射能力，也无法分配ESRK/ESQK。E-CSCF是唯一与LRF对接、负责把"位置→PSAP→路由号码"三者绑定的网元。直接送PSAP会丢失定位与回调能力，违反法规。

Q2: 一个完全没插卡的UE能打紧急电话吗？ A: 在支持5G紧急业务的网络中可以。UE发起紧急注册（跳过用户鉴权），建立紧急PDU会话，再发紧急INVITE，P-CSCF/E-CSCF用IMEI衍生临时标识处理，LRF基于小区定位。最终PSAP看到的主叫通常是ESRK临时号码而非真实用户号码。

Q3: ESRK、ESQK、ESRN三个号码到底有什么区别？ A: 三者都是LRF分配的紧急路由号码，但用途不同。ESRN用于把呼叫路由到正确的紧急服务网/选择性路由器（北美概念）；ESRK是按呼叫唯一分配的临时号码，既用于路由到PSAP也支持回拨，呼叫期间携带定位；ESQK则用于"PSAP反向查LRF取定位"的模型。一个网络部署通常选其中一种体系。

Q4: 漫游用户的紧急呼叫会绕回国吗？ A: 不会。紧急PDU会话和E-CSCF都强制锚定在拜访网络（VPLMN），定位、PSAP选择全部本地完成，不经过归属域。这是为了保证就近接续和准确属地化PSAP路由，也是与普通呼叫最大的架构差异之一。

Q5: 紧急通话中UE跨域移动会断吗？ A: 设计上不应断。E-CSCF在建立阶段就会话锚定在EATF，跨域（如5G→3G CS覆盖）时由EATF配合MSC Server增强完成紧急SRVCC，并在新域更新定位。紧急呼叫对连续性的要求高于普通业务，标准对此有专门保障机制。

参考来源

1. 3GPP TS 23.167 — IP Multimedia Subsystem (IMS) emergency sessions — §6功能实体（E-CSCF/LRF/RDF/EATF）、§7紧急会话建立流程
2. 3GPP TS 23.502 — Procedures for the 5G System — §4.3.5.2紧急PDU会话建立、§4.12.2紧急注册
3. 3GPP TS 24.229 — IP multimedia call control protocol based on SIP — §5.1.2A紧急会话SIP流程、紧急号码识别与改写
4. ShareTechnote — IMS Emergency FAQ — E-CSCF/LRF在拜访网络路由紧急呼叫的机制解读
5. RFC 5031 / RFC 6443 — 紧急业务URN方案与紧急业务架构框架（urn:service:sos）

本文由「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 等场景全覆盖。