5G IMS紧急呼叫建立信令全链拆解：E-CSCF路由与LRF定位机制深度解析

一、紧急呼叫为什么需要一套完全不同的信令机制

在普通VoNR/VoLTE通话中，一次呼叫要经过"鉴权→PDU会话建立→IMS注册→INVITE→资源预留→振铃→接通"这条标准链路，整个过程对 UE 是否有有效订阅、是否有签约数据强依赖。但紧急呼叫（Emergency Call，如110/119/120、911/112）存在三个本质性约束，这决定了它必须走一套旁路正常业务逻辑的专用信令通道：

1. 无SIM、未鉴权、无签约的UE也必须能打通（R-UIM卡损坏、欠费停机、甚至无卡状态下都要能拨打）；
2. 必须获取UE的物理位置并路由到地理上对应的接警中心（PSAP）——这是普通SIP路由完全没有的概念，普通呼叫是按"号码"路由，紧急呼叫是按"位置"路由；
3. 抢占式高优先级——紧急承载必须能在网络拥塞时强行抢占其他会话的资源。

为了满足这三点，3GPP在5G体系中设计了一条贯穿5GC（AMF/SMF/UPF）+ IMS（P-CSCF/E-CSCF）+ LCS（LRF/RDF/GMLC）三大子系统的专用信令链路。本文聚焦这条链路中最具IMS域特色的两个核心机制：E-CSCF如何识别并路由紧急呼叫，以及LRF如何完成"位置→PSAP"的映射。相关规范锚点为 TS 23.502 clause 4.13、TS 23.167（IMS emergency sessions）、TS 24.501（NAS层紧急PDU会话）、TS 24.229（SIP层紧急INVITE）。

二、整体信令链路全景图

紧急呼叫完整建立可拆为五个阶段。下图给出从UE摘机拨号到PSAP接通的端到端全景：

flowchart TD
    A[UE摘机拨打紧急号码<br/>受限服务/无SIM] --> B{是否已注册?}
    B -- 否 --> S1[阶段1: 紧急注册<br/>Initial Emergency Registration]
    S1 --> S2[阶段2: 紧急PDU会话建立<br/>Request Type=initial emergency request]
    B -- 是 --> S2
    S2 --> S3[阶段3: P-CSCF地址获取<br/>SMF经PCF下发紧急P-CSCF]
    S3 --> S4[阶段4: 紧急INVITE路由<br/>P-CSCF → E-CSCF 而非 S-CSCF]
    S4 --> S5[阶段5: LRF定位与PSAP选路<br/>LRF/RDF → ESRN → PSAP]
    S5 --> M[紧急媒体会话建立<br/>抢占式QoS ARP]
    style S1 fill:#fff3cd
    style S2 fill:#fff3cd
    style S4 fill:#f8d7da
    style S5 fill:#d1ecf1
    style M fill:#d4edda

理解这张图的关键是：普通呼叫与紧急呼叫在阶段4彻底分叉。普通INVITE被P-CSCF按正常注册关系路由给S-CSCF，而紧急INVITE被P-CSCF强制改道发往E-CSCF。这个"改道"动作，是整个紧急呼叫机制在IMS域的灵魂。

三、阶段1-2：紧急注册与紧急PDU会话（5GC侧）

3.1 紧急注册（Emergency Registration）

当一个受限服务UE（无有效USIM、或鉴权失败、或无签约）需要发起紧急呼叫时，它会在Registration Request中把 5GS Registration Type 置为 emergency registration（TS 24.501 §5.5.1.2）。AMF收到后执行一套特殊逻辑（TS 23.502 §4.13.3 / TS 23.501 §5.16.3）：

• 跳过主鉴权或仅做尽力而为的鉴权；当UE无法鉴权时，AMF使用本地配置的"emergency subscriber profile"；
• 不查询UDM的签约数据（或使用UDM中专用的emergency profile）；
• 在Registration Accept中将 5GS registration result 的 "emergency registration" 比特置1，并可在S1 Mode参数中指示"emergency registered only"。

这一步的设计意图是：把"UE合法性"与"紧急服务接入权"解耦。监管法规（如美国FCC、欧盟112指令）要求运营商不得因鉴权失败拒绝紧急呼叫，所以3GPP必须在协议层面预留一个"不依赖USIM的注册通道"。

3.2 紧急PDU会话建立（核心机制）

紧急PDU会话（Emergency PDU Session）是整条链路的承载体。其NAS层信令与普通PDU会话高度相似，但有几个决定性差异（TS 23.502 §4.3.2.2、TS 24.501 §6.4.1.2）：

sequenceDiagram
    autonumber
    participant UE
    participant RAN as gNB
    participant AMF
    participant SMF
    participant PCF
    participant UPF

    UE->>AMF: UL NAS Transport<br/>(PDU Session Est. Request)<br/>Request Type = "initial emergency request"
    Note over UE,AMF: 关键IE: DNN可为空/紧急DNN<br/>SNSSAI=紧急切片; 不带5GSM cause鉴权
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext<br/>Emergency Indicator = TRUE
    SMF->>SMF: 选择紧急专用SMF/UPF池<br/>跳过Secondary Auth/NSSAA
    SMF->>PCF: Npcf_SMPolicyControl_Create<br/>(Emergency session)
    PCF-->>SMF: Policy + 紧急QoS规则<br/>ARP pl(抢占)=1, pv(防被抢占)=1
    SMF->>UPF: N4 Session Establishment<br/>紧急专用UPF(免计费/免合法监听特殊处理)
    SMF-->>AMF: N1 SM Container<br/>(PDU Session Est. Accept)<br/>含紧急P-CSCF地址
    AMF->>UE: DL NAS Transport<br/>PDU Session Est. Accept
    Note over SMF,PCF: 紧急P-CSCF地址通过PCF/DNN配置下发

关键差异点详解（对照普通PDU会话）：

设计意图：紧急PDU会话用一套独立的资源域（独立DNN、独立UPF、最高ARP），把紧急业务"隔离"在普通业务之外。当网络严重拥塞时，紧急承载的ARP抢占标志位使其能强行拆掉低优先级会话的无线/N3资源，保证SOS信令通道畅通——这是普通会话绝不可能做到的。

四、阶段3-4：P-CSCF发现与紧急INVITE的"改道"

4.1 P-CSCF地址如何下发

紧急PDU会话建立成功后，UE需要一个P-CSCF来收发SIP信令。在5G中，P-CSCF地址的下发路径是：SMF → PCF → （PDU Session Establishment Accept中的PCO Protocol Configuration Options）→ UE（TS 23.501 §5.8.2.6、Cisco UCC SMF配置文档印证：SMF从DNN配置中取P-CSCF地址）。

对紧急会话，下发的P-CSCF必须是与紧急E-CSCF可达的紧急专用P-CSCF（部分运营商为紧急业务部署独立P-CSCF池，避免普通IMS信令风暴影响紧急呼叫）。

4.2 紧急INVITE的"改道"机制（本文最关键环节）

UE通过紧急PDU会话拿到P-CSCF后，构造并发送SIP INVITE。这个INVITE的Request-URI使用的是URN格式而非电话号码（TS 24.229 §5.1.2.2.1、IETF RFC 5031）：

INVITE sip:urn:service:sos SIP/2.0          // 通用SOS
INVITE sip:urn:service:sos.fire SIP/2.0     // 消防
INVITE sip:urn:service:sos.police SIP/2.0   // 警察

UE也可能用本地紧急号码（如tel:110）。P-CSCF的识别逻辑是：将收到的号码与本网紧急号码列表做匹配，匹配成功即判定为紧急呼叫，随后执行改道（TS 23.167 §7.1、TS 24.229 §5.4.1.2.2）。

改道的核心规则： - 普通呼叫：P-CSCF → S-CSCF（按UE的IMS注册关系） - 紧急呼叫：P-CSCF → E-CSCF（Emergency-CSCF），绕过S-CSCF

sequenceDiagram
    autonumber
    participant UE
    participant PCSCF as P-CSCF
    participant SCSCF as S-CSCF
    participant ECSCF as E-CSCF
    participant LRF
    participant PSAP

    Note over UE: Request-URI = urn:service:sos
    UE->>PCSCF: INVITE (urn:service:sos)<br/>P-Preferred-Service-ID(ecscf)
    PCSCF->>PCSCF: 号码匹配紧急号码表<br/>判定为Emergency Call
    Note over PCSCF: 改道: 不发S-CSCF, 强制发E-CSCF<br/>插入P-Asserted-Service-ID
    PCSCF->>ECSCF: INVITE (转发, 标记紧急)
    Note over ECSCF: 解析位置信息缺失 → 向LRF请求
    ECSCF->>LRF: 请求UE位置 + PSAP选路<br/>(含correlation id)
    LRF->>LRF: 调RDF, 查询/获取UE位置
    LRF-->>ECSCF: 返回ESRN(路由号) + ESQK + PSAP地址
    Note over ECSCF: 用ESRN作为Request-URI重写INVITE
    ECSCF->>PSAP: INVITE (Route by ESRN)
    PSAP-->>ECSCF: 183 Session Progress
    ECSCF-->>PCSCF: 183 Session Progress
    PCSCF-->>UE: 183 Session Progress

设计意图：为什么不让S-CSCF来转？因为紧急呼叫的UE可能根本没有IMS注册（受限服务UE走完紧急PDU会话就直接拨号，S-CSCF里没有它的注册记录，无法路由）。E-CSCF作为一个"无状态、不依赖用户注册"的入口网元，专门为紧急INVITE提供确定性的下一步路由——查LRF要PSAP。这就是E-CSCF在R7版本被引入的根本原因：把"找接警中心"这个逻辑从依赖用户签约的路由体系里彻底剥离出来。

五、阶段5：LRF定位与PSAP选路（紧急呼叫的核心差异）

5.1 LRF与RDF的角色拆分

E-CSCF本身不知道UE的物理位置，也不知道哪个PSAP该接这通电话。这件事交给LRF（Location Retrieval Function）完成（TS 23.167 §6、§7.3）。LRF内部通常包含两个子功能：

flowchart LR
    ECSCF[E-CSCF] --> LRF
    subgraph LRF [LRF: Location Retrieval Function]
        RRF[RF<br/>Retrieval Function<br/>负责获取UE位置]
        RDF[RDF<br/>Routing Determination Function<br/>负责位置→PSAP映射]
        RRF --> RDF
    end
    RRF -.经SLg/MLPP.-> GMLC[GMLC/AMF<br/>TS 23.271 LCS]
    RDF -- 查询 --> DB[紧急服务辖区<br/>路由数据库]
    LRF --> R3[输出: ESRN + ESQK<br/>+ PSAP路由地址]
    style RDF fill:#d1ecf1
    style RRF fill:#fff3cd

• RF（Retrieval Function）：通过GMLC向5GC的AMF发起Namf_Communication_EBIAssignment / UE Location Request（或经SLg接口），获取UE当前的位置（cell-level、TA-level或更精确的定位结果，TS 23.271 LCS体系）。紧急场景支持"先给初始位置快速路由、再补充更新位置"的两段式定位。
• RDF（Routing Determination Function）：把RF拿到的地理位置（经纬度或cell ID）映射到有管辖权的PSAP。这是真正的"按位置路由"——同一座城市的不同街区，紧急呼叫会被RDF路由到不同的接警中心。

5.2 ESRN与ESQK：两个决定路由的关键号码

RDF选定PSAP后，LRF返回两个关键标识（TS 23.167 §6.4、3gpp-explorer ESRN词条）：

E-CSCF收到LRF返回的ESRN后，重写INVITE的Request-URI为ESRN，然后按正常SIP路由把INVITE送到PSAP。这一步之后，剩下的183/PRACK/200 OK/资源预留流程就和普通VoNR呼叫一致了，只是底层承载用的是阶段2建立的紧急QoS。

5.3 为什么需要ESQK的correlation机制

PSAP接警员经常需要回拨报警人。但紧急呼叫的UE可能是无SIM/受限服务UE，没有稳定的可回拨号码。ESQK解决了这个问题：PSAP用ESQK向LRF查询，LRF用ESQK关联到该UE的紧急会话上下文，返回一个可用于回呼的路由信息。这种"用临时密钥关联会话"的设计，与普通呼叫"用MSISDN标识用户"的思路完全不同。

六、抓包实战：如何在Wireshark里识别这条链路

6.1 关键识别特征

6.2 用tshark快速过滤紧急会话

# 过滤NAS层紧急注册
tshark -r emergency.pcap -Y "nas-5gs.reg_type == 2"

# 过滤SIP紧急INVITE (URN方式)
tshark -r emergency.pcap -Y 'sip.Request-URI contains "urn:service"'

# 查看ESRN路由改写后到PSAP的INVITE
tshark -r emergency.pcap -Y 'sip.Method == "INVITE"' \
  -T fields -e frame.number -e sip.Request-URI -e sip.from

6.3 常见故障点与排错思路

1. 故障：受限服务UE拨紧急号不通 排查重点：AMF是否接受emergency registration、是否为该UE分配了紧急subscriber profile。若AMF拒绝emergency registration，检查AMF配置的 emergencyServiceAllowed 标志（TS 23.501 §5.16.3.2）。

2. 故障：紧急PDU会话建立失败（SMF返回smcause） 排查：SMF本地是否配置了紧急DNN和紧急UPF；Request Type是否正确携带 initial emergency request。常见错误是UE用了普通Request Type，导致SMF按普通流程走二次认证失败。

3. 故障：INVITE被路由到了S-CSCF而非E-CSCF 这是最典型的IMS侧配置错误。排查P-CSCF的紧急号码表（Emergency Number List）是否完整、是否覆盖了UE拨打的号码格式（URN vs tel号码）。P-CSCF未识别为紧急→走S-CSCF→S-CSCF发现无注册→403 Forbidden。

4. 故障：LRF返回位置不准导致路由到错误PSAP 排查RF的位置获取：是否走了SLg向AMF/GMLC查询、cell粒度是否够、是否触发了定位增强（A-GNSS）。位置陈旧会导致RDF误判辖区。

5. 故障：ESQK回呼失败 排查ESQK的correlation是否在会话结束前有效；部分实现ESQK有效期过短，导致接警员稍后回呼时LRF已清除关联上下文。

七、状态机视角：紧急会话的特殊生命周期

stateDiagram-v2
    [*] --> 未注册受限: 无有效USIM/欠费
    未注册受限 --> 紧急注册中: 摘机拨紧急号
    紧急注册中 --> 紧急已注册: AMF接受<br/>(bypass鉴权)
    紧急已注册 --> 紧急PDU会话建立: initial emergency request
    紧急PDU会话建立 --> INVITE已发: P-CSCF地址下发
    INVITE已发 --> E_CSCF路由中: P-CSCF改道
    E_CSCF路由中 --> LRF定位中: 缺位置→查LRF
    LRF定位中 --> PSAP振铃: ESRN路由+183
    PSAP振铃 --> 通话中: 200 OK + 资源预留
    通话中 --> 会话释放: BYE (含ESQK销毁)
    会话释放 --> [*]
    note right of 紧急PDU会话建立
        任意阶段失败都
        不影响重新发起
    end note

紧急会话状态机与普通IMS会话状态机最大的区别是：每个阶段都有"尽力而为、可重试"的弹性，且整体不允许被低优先级业务抢占。这也是为什么运营商把紧急呼叫可用率列为最高级别的KPI。

八、设计哲学总结：三个"解耦"贯穿始终

回看整条信令链路，3GPP用三个解耦实现了紧急呼叫的特殊性：

1. 接入权与签约解耦（阶段1-2）：emergency registration/紧急PDU会话不依赖USIM与UDM签约，监管要求入网即可呼。
2. 路由权与注册解耦（阶段4）：E-CSCF不依赖S-CSCF注册关系，紧急INVITE有确定的入口。
3. 选路目标与号码解耦（阶段5）：LRF/RDF按地理位置选PSAP，而非按被叫号码——这是普通电话网与紧急电话网最根本的分野。

理解了这三个解耦，就理解了为什么紧急呼叫在5G架构里需要一套"看似冗余、实则不可或缺"的专用机制。

常见问题

Q1：紧急呼叫为什么可以绕过S-CSCF直接发E-CSCF？S-CSCF不负责所有SIP会话控制吗？ A：S-CSCF的路由依赖UE的IMS注册记录（用户归属、iFC触发规则）。受限服务UE可能根本没有IMS注册，S-CSCF查不到路由上下文。E-CSCF作为无状态紧急入口，不依赖用户注册，只做"识别紧急→查LRF→路由PSAP"这一确定性动作（TS 23.167 §7.1）。

Q2：ESRN和ESQK到底有什么区别？ A：ESRN（路由号）是给网络侧用的——E-CSCF用它作Request-URI把INVITE路由到正确PSAP，本质是一个可路由号码。ESQK（查询密钥）是给PSAP侧用的——接警员回呼或查询报警人位置时，用ESQK向LRF反查会话关联。一个管"路由过去"，一个管"关联回来"。

Q3：紧急PDU会话为什么必须跳过二次认证（DN-AA/NSSAA）？ A：二次认证需要数据网（如企业DN）和切片做身份校验，依赖UE的有效凭证与订阅。受限服务UE拿不出这些凭证，若强制二次认证会直接失败导致紧急会话建不起来。监管要求紧急业务零阻塞，故规范在TS 23.502 §4.3.2.2.1明确对紧急PDU会话豁免。

Q4：如果UE已经正常注册并签了VoNR，还需要走紧急注册和紧急PDU会话吗？ A：仍建议走紧急PDU会话。原因是普通PDU会话的QoS ARP优先级不够、且承载在普通UPF上，无法保证拥塞时被抢占保护。已注册UE发起紧急呼叫时，网络会额外建立一条紧急PDU会话（或复用并升级QoS），确保SOS承载具备最高抢占优先级。这是运营商保障紧急呼叫可靠性的标准做法。

Q5：LRF怎么知道UE的精确位置？用的是GPS还是基站定位？ A：两者都用。LRF的RF经GMLC→AMF→(RAN)走LCS体系（TS 23.271）。紧急场景常用"两段式"：先用cell/TA级别的初始位置快速选路PSAP（满足时延要求），再通过A-GNSS等增强定位补充精确坐标更新给PSAP。法规（如美国E911 Phase II）对定位精度和时延有强制指标。

参考来源

1. 3GPP TS 23.502 V19.x — Procedures for the 5G System, Clause 4.13 (Emergency Services) — 紧急服务在5G核心网的总体流程定义
2. 3GPP TS 23.167 V19.1.1 — IMS emergency sessions — E-CSCF/LRF/RDF、ESRN/ESQK、PSAP选路核心规范（ETSI官方PDF）
3. 3GPP TS 24.501 — NAS protocol for 5GS, §6.4.1.2 Emergency PDU Session — 紧急PDU会话NAS层Request Type、IE定义
4. 3GPP TS 23.167 Section 7 — Procedures for establishment of IMS emergency sessions — 紧急会话建立高层流程在线解读
5. ShareTechnote — 5G NAS Emergency PDU Session — 紧急PDU会话信令抓包级解读
6. 3glteinfo — VoNR Emergency Call Procedure — VoNR紧急呼叫端到端call flow
7. Cisco UCC 5G SMF — Emergency Services Support — 厂商SMF紧急业务实现细节
8. 3gpp-explorer — ESRN / LRF / E-CSCF Glossary — 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 等场景全覆盖。