5G SA网络部署初期,IMS语音无法直接在NR上提供(VoNR未就绪),UE发起语音呼叫时必须回落到EPS(4G LTE)网络,由VoLTE承载语音业务。3GPP TS 23.502 Section 4.13.6.1定义了EPS Fallback for IMS Voice的完整流程框架。
EPS Fallback的本质是一个跨系统语音承载能力缺失的补偿机制:5GC通过SMF感知到IMS语音PDU Session无法在NR上建立专用QoS Flow,触发AMF协调gNB将UE迁移到LTE,在EPC侧完成VoLTE语音承载建立。
flowchart TB
subgraph 触发条件
A[UE发起IMS语音呼叫<br/>SIP INVITE]
B[SMF收到Voice QoS Flow<br/>建立请求]
C{NR是否支持VoNR?}
end
subgraph 决策路径
D[N26接口是否存在?]
E{gNB能力评估}
end
subgraph 三径回降
F[路径1: HO-based<br/>with N26]
G[路径2: Redirection-based<br/>with N26]
H[路径3: Redirection-based<br/>without N26]
end
A --> B --> C
C -->|不支持VoNR| D
C -->|支持VoNR| Z[直接VoNR]
D -->|存在| E
D -->|不存在| H
E -->|HO能力| F
E -->|仅重定向| G
style Z fill:#4CAF50,color:#fff
style F fill:#2196F3,color:#fff
style G fill:#FF9800,color:#fff
style H fill:#F44336,color:#fff
当UE发起IMS语音呼叫时,SIP INVITE通过已建立的IMS PDU Session发送到IMS网络。IMS侧通过Rx接口向PCF触发AAR(AA-Request),PCF通过SMF下发QoS规则,要求建立专用QoS Flow承载语音媒体。
关键信令链(TS 23.502 Section 4.13.6.1 Step 1-3):
| 步骤 | 消息 | 方向 | 关键IE |
|---|---|---|---|
| 1 | SIP INVITE | UE → P-CSCF | SDP含语音编解码 |
| 2 | AAR (Diameter) | P-CSCF → PCF | Media-Component-Description, Flow-Status |
| 3 | SM Policy Association Modification | PCF → SMF | QoS Flow参数(5QI=1, ARP) |
| 4 | PDU Session Modification Command | SMF → AMF → gNB | QoS Flow建立请求, 5QI=1 |
gNB收到QoS Flow建立请求后,根据本地配置(是否支持VoNR)做出决策:
imsVoiceEPSFallbackOrIndication信元NGAP关键IE结构(TS 38.413 Section 9.3.1.2):
PDU Session Resource Setup Response Transfer
├── PDU Session Resource Setup Response Item
│ ├── PDU Session ID
│ ├── PDU Session Resource Setup Response Transfer
│ │ ├── QoS Flow Per TNL Information ← 成功的QoS Flow列表(可能为空)
│ │ └── Cause ← 取值 "Multiple DSCP QoS Flows Not Supported" 或其他
└──
同时gNB在INITIAL CONTEXT SETUP RESPONSE或PDU SESSION RESOURCE SETUP RESPONSE中携带VoiceFallbackIndicator,指示AMF需要触发EPS Fallback。
这是时延最优的EPS Fallback路径,核心特征是N26接口(AMF↔MME)提供无缝的UE上下文迁移。
sequenceDiagram
participant UE
participant gNB
participant AMF
participant SMF
participant PCF
participant MME
participant SGW
participant PGW as PGW/C-UPF
participant CSCF as P-CSCF
Note over UE,CSCF: Phase 1: IMS语音触发
UE->>CSCF: SIP INVITE (含SDP)
CSCF->>PCF: AAR (Rx)
PCF->>SMF: SM Policy Modification (5QI=1)
SMF->>AMF: N1N2MessageTransfer<br/>(PDU Session Mod, QoS Flow)
AMF->>gNB: PDU Session Resource Setup<br/>(含5QI=1 QoS Flow)
Note over UE,CSCF: Phase 2: gNB拒绝 & HO准备
gNB-->>AMF: PDU Session Resource Setup Response<br/>(REJECT + VoiceFallbackIndicator)
AMF->>gNB: HANDOVER REQUIRED<br/>(Target=eNB ID)
Note over UE,CSCF: Phase 3: N26上下文迁移
gNB-->>AMF: HANDOVER REQUIRED
AMF->>SMF: Nsmf_PDUSession_StatusNotify<br/>(Trigger=EPS Fallback HO)
SMF->>PGW: SMF PGW-C隧道信息更新
AMF->>MME: Forward Relocation Request (N26)
Note right of MME: 包含: MM Context,<br/>PDN Connections,<br/>UE Security Capabilities
MME->>SGW: Create Session Request
SGW-->>MME: Create Session Response
MME-->>AMF: Forward Relocation Response
Note over UE,CSCF: Phase 4: HO执行
AMF->>gNB: HANDOVER COMMAND
gNB->>UE: RRC Reconfiguration<br/>(HO to eNB, mobilityControlInfo)
UE->>UE: 切换到LTE
UE->>MME: Tracking Area Update
Note over UE,CSCF: Phase 5: VoLTE语音建立
MME->>SGW: Modify Bearer Request
SGW->>PGW: Modify Bearer Request
PGW-->>CSCF: 通过IMS承载继续SIP信令
Note over UE,CSCF: SIP 183 Session Progress<br/>→ VoLTE通话建立
这是整个流程中最核心的消息,承载了UE从5GC到EPC的完整上下文(TS 23.502 Section 4.11.1.2.1):
| IE名称 | 来源 | 说明 |
|---|---|---|
| MM Context | AMF | UE安全上下文、5G-GUTI、SUCI、安全能力 |
| PDN Connection | SMF | 每个PDU Session对应的EPS承载信息 |
| EPS Bearer ID | SMF映射 | 5G QoS Flow到EPS Bearer的映射 |
| PGW-C/SMF FQDN | SMF | PGW控制面地址(SMF充当PGW-C) |
| PGW-U/UPF TEID | UPF | 用户面隧道端点 |
| UE Security Capabilities | UE | NR/LTE加密和完整性算法支持列表 |
| MME UE S1AP ID | MME分配 | 目标侧标识 |
| Target eNB ID | gNB | 目标LTE小区标识 |
SMF在收到EPS Fallback触发后,执行PDU Session → PDN Connection和QoS Flow → EPS Bearer的映射(TS 23.501 Section 5.7.1):
flowchart LR
subgraph "5GC侧"
PS[PDU Session<br/>DNN=internet]
QF1[QoS Flow 1<br/>5QI=9 Default]
QF2[QoS Flow 2<br/>5QI=1 Voice]
PS --> QF1
PS --> QF2
end
subgraph "映射规则"
MR1[Default QoS Flow →<br/>Default EPS Bearer<br/>EBI=5]
MR2[Voice QoS Flow →<br/>Dedicated EPS Bearer<br/>EBI=6]
end
subgraph "EPC侧"
PDN[PDN Connection<br/>APN=internet]
EB1[EPS Bearer 5<br/>QCI=9 Default]
EB2[EPS Bearer 6<br/>QCI=1 Voice]
PDN --> EB1
PDN --> EB2
end
QF1 --> MR1 --> EB1
QF2 --> MR2 --> EB2
style QF2 fill:#FF5722,color:#fff
style EB2 fill:#FF5722,color:#fff
当gNB判断无法执行切换(如目标eNB资源未知),选择RRC Release with Redirection方式将UE引导到LTE。N26接口仍然存在,用于AMF向MME传递UE上下文。
sequenceDiagram
participant UE
participant gNB
participant AMF
participant SMF
participant MME
participant SGW
participant PGW as PGW/C-UPF
Note over UE,PGW: Phase 1: 触发 & 重定向
gNB->>AMF: PDU Session Resource Setup Response<br/>(REJECT + VoiceFallbackIndicator)
AMF->>gNB: UE Context Modification Request<br/>(Redirection指示)
gNB->>UE: RRC Release<br/>(redirectedCarrierInfo=LTE EARFCN)
Note right of UE: UE搜索LTE频点<br/>驻留目标eNB
Note over UE,PGW: Phase 2: N26上下文传递
AMF->>MME: Forward Relocation Request (N26)
MME->>SGW: Create Session Request
SGW-->>MME: Create Session Response
MME-->>AMF: Forward Relocation Response
Note over UE,PGW: Phase 3: TAU & 语音建立
UE->>MME: Tracking Area Update Request<br/>(含N26分配的GUTI)
MME->>MME: 验证UE上下文<br/>(已通过N26获得)
MME->>SGW: Modify Bearer Request
SGW->>PGW: Modify Bearer Request
Note over UE,PGW: VoLTE语音承载建立完成
| 对比维度 | HO-based with N26 | Redirection-based with N26 |
|---|---|---|
| RAN侧动作 | RRC Reconfiguration (HO) | RRC Release + Redirection |
| 中断时间 | ~50-100ms(HO切换) | ~200-500ms(重选+TAU) |
| UE状态转换 | Connected → Connected | Connected → Idle → Connected |
| 上下文传递 | HO前通过N26完成 | RRC Release后通过N26完成 |
| 成功率 | 依赖邻区配置 | 较高(仅频点信息) |
| SIP连续性 | 高(中断短) | 中(可能丢SIP消息) |
这是最复杂、时延最长的路径。当AMF和MME之间没有部署N26接口时,UE需要完全通过EPC流程重新建立连接。
sequenceDiagram
participant UE
participant gNB
participant AMF
participant MME
participant SGW
participant PGW as PGW/SMF
participant HSS as UDM/HSS
Note over UE,HSS: Phase 1: 重定向
gNB->>UE: RRC Release<br/>(redirectedCarrierInfo=LTE EARFCN)
Note right of UE: UE搜索LTE频点<br/>驻留目标eNB
Note over UE,HSS: Phase 2: EPS Attach(无N26辅助)
UE->>MME: Attach Request<br/>(PDN Connectivity Req<br/>Request Type=handover)
Note right of MME: Request Type=handover<br/>指示这是EPS FB场景
MME->>HSS: Update Location Request (diameter)
HSS-->>MME: Update Location Answer<br/>(含订阅数据)
Note over UE,HSS: Phase 3: PGW-C/SMF发现与会话恢复
MME->>PGW: Create Session Request<br/>(PGW FQDN从HSS或DNS获取)
Note right of PGW: SMF(PGW-C)查找<br/>已有PDU Session上下文
PGW-->>MME: Create Session Response
MME->>SGW: Create Session Request
SGW-->>MME: Create Session Response
Note over UE,HSS: Phase 4: 默认承载建立
MME->>UE: Attach Accept + Activate Default EPS Bearer
UE->>MME: Attach Complete
Note over UE,HSS: Phase 5: 专用语音承载建立
MME->>SGW: Create Bearer Request (QCI=1)
SGW->>PGW: Create Bearer Request
PGW-->>SGW: Create Bearer Response
SGW-->>MME: Create Bearer Response
MME->>UE: Activate Dedicated EPS Bearer Context Request
UE-->>MME: Activate Dedicated EPS Bearer Context Accept
Note over UE,HSS: VoLTE语音承载建立完成
TS 24.301 Section 8.2.9定义了PDN Connectivity Request中的Request Type取值:
| Request Type | 含义 | 适用场景 |
|---|---|---|
| initial | 初始PDN连接 | 普通Attach |
| handover | 切换中的PDN连接 | EPS Fallback无N26 |
| emergency | 紧急呼叫PDN | 紧急号码拨号 |
当MME收到Request Type=handover时,不会立即删除5G侧PDU Session(通过PGW-C/SMF协调),实现数据面连续性。
AMF是EPS Fallback三径选择的核心决策节点。以下是其状态转换逻辑:
stateDiagram-v2
[*] --> IMS_Voice_Triggered: 收到gNB REJECT<br/>+VoiceFallbackIndicator
IMS_Voice_Triggered --> Check_N26: 检查N26接口配置
state Check_N26 {
[*] --> N26_Supported: AMF配置支持N26
[*] --> N26_Not_Supported: AMF未配置N26
}
N26_Supported --> HO_Preparation: gNB发送<br/>HANDOVER REQUIRED
N26_Supported --> Redirection_N26: gNB发送<br/>RRC Release + Redirection
N26_Not_Supported --> Redirection_NoN26: 仅重定向路径
HO_Preparation --> N26_Forward_Relocation: N26消息交互
state N26_Forward_Relocation {
[*] --> Send_FWD_RELOC_REQ: AMF→MME
Send_FWD_RELOC_REQ --> Wait_FWD_RELOC_RSP: 等待MME响应
Wait_FWD_RELOC_RSP --> FWD_RELOC_CPLT: 收到Response
}
Redirection_N26 --> N26_Context_Transfer: UE RRC Release后
Redirection_NoN26 --> UE_Attach_LTE: UE自主Attach
N26_Forward_Relocation --> HO_Command: 发送HO COMMAND
Redirection_N26 --> TAU_LTE: UE发起TAU
Redirection_NoN26 --> Attach_Complete: MME完成Attach
HO_Command --> VoLTE_Established: 语音承载建立
TAU_LTE --> VoLTE_Established
Attach_Complete --> VoLTE_Established
VoLTE_Established --> [*]
EPS Fallback的核心架构基础是SMF与PGW-C的融合部署(TS 23.501 Section 4.3)。这种设计确保UE从5GC迁移到EPC时,用户面隧道可以平滑切换,而不需要PGW-U/UPF做锚点迁移。
flowchart TD
subgraph "EPS Fallback前(5G)"
UE1[UE] -->|NR Uu| gNB1[gNB]
gNB1 -->|N3 GTP| UPF1[UPF/PGW-U]
UPF1 -->|N6| DN1[IMS/Internet]
end
subgraph "EPS Fallback后(4G)"
UE2[UE] -->|LTE Uu| eNB1[eNB]
eNB1 -->|S1-U GTP| SGW1[S-GW]
SGW1 -->|S5 GTP| PGW1[PGW-U/UPF]
PGW1 -->|SGi| DN2[IMS/Internet]
end
UE1 -.->|回降| UE2
UPF1 -.->|同一物理实体| PGW1
style UPF1 fill:#E91E63,color:#fff
style PGW1 fill:#E91E63,color:#fff
关键机制:SMF在收到EPS Fallback触发后,向UPF/PGW-U下发N4 Session Modification,将下行数据隧道的TEID从N3(gNB侧)切换到S5(S-GW侧),实现下行数据不中断。
| 场景 | HO-based with N26 | Redirection with N26 | Without N26 |
|---|---|---|---|
| SIP INVITE状态 | 已发到P-CSCF | 已发到P-CSCF | 已发到P-CSCF |
| 183/180响应时序 | 中断~50ms | 中断~300ms | 中断~3-5s |
| SIP消息丢失风险 | 极低 | 中等(UDP可能超时重传) | 高(需IMS重注册) |
| P-CSCF可达性 | 通过PGW-U锚点保证 | 通过PGW-U锚点保证 | 依赖新P-CSCF发现 |
Cisco AMF配置文档揭示了运营商可配置的EPS Fallback策略参数:
| 参数 | 取值 | 说明 |
|---|---|---|
| eps-fallback-indication | enable/disable | 是否允许gNB触发EPS FB |
| redirection-eps-fallback | enable/disable | 是否允许重定向方式 |
| ho-eps-fallback | enable/disable | 是否允许切换方式 |
| voice-service-support | vonr/eps-fallback | 语音承载策略 |
| n26-interface | supported/unsupported | N26接口能力 |
AMF在Registration Accept中通过5GS Network Feature Support信元向UE指示网络侧的语音能力支持情况(TS 24.501 Section 9.11.3.7):
5GS Network Feature Support (部分)
├── IMS VoPS (1 bit): 5GC是否支持IMS语音 over PS
├── EMC (2 bits): 紧急呼叫支持指示
├── EMF (2 bits): 紧急呼叫回退指示
├── IWK_N26 (1 bit): N26互通是否支持
├── MCSI (1 bit): MCS指示
└── ...
其中IWK_N26字段直接告知UE网络是否部署了N26接口,UE据此决定在EPS Attach时是否携带Request Type=handover。
| 接口 | 过滤器 | 关注点 |
|---|---|---|
| N2 (NGAP) | ngap.procedureCode == 35 (PDU Session Resource Setup) |
查看gNB Response中的Cause值 |
| N2 (NGAP) | ngap.procedureCode == 13 (Handover Preparation) |
HO-based的触发标志 |
| N1 (NAS) | nas_5gs.message_type == 0x5e (Registration Accept) |
查看IWK_N26 bit |
| N11 (HTTP/2) | http2.headers.value contains "nsmf-pdusession" |
SMF会话状态变更 |
| N26 (GTPCv2) | gtpv2.message_type == 44 (Forward Relocation Request) |
N26接口核心消息 |
| S1-MME | gtpv2.message_type == 32 (Create Session Request) |
EPC侧承载建立 |
| S1-MME | nas_eps.message_type == 0x41 (Attach Request) |
无N26场景的Attach |
故障1:EPS Fallback失败导致掉话
现象:UE发出SIP INVITE后,被叫未振铃,UE回到Idle态
排查路径:
1. 检查gNB是否发送了VoiceFallbackIndicator → NGAP Response
2. 检查AMF是否收到HANDOVER REQUIRED → 无则gNB配置问题
3. 检查N26 Forward Relocation Request/Response → MME是否响应
4. 检查MME Create Session → SGW/PGW是否正常
故障2:无N26场景下Attach被拒
现象:UE重定向到LTE后,Attach Request被MME拒绝
排查路径:
1. 检查HSS/UDM是否正确同步了UE订阅数据
2. 检查PGW-C/SMF是否可达(DNS解析PGW FQDN)
3. 检查Request Type=handover是否正确携带
4. 检查UE是否在Attach中携带了正确的DRX参数
故障3:语音建立超时(Late Call Setup)
现象:主叫SIP INVITE发出后,超过5秒才听到回铃音
根因:Redirection-based场景下,SIP 100 Trying/183丢失
解决方案:
1. 优先启用HO-based with N26(缩短中断时间)
2. 配置IMS SIP Timer B适当增大(>5s)
3. 确保PGW-U/UPF缓冲下行SIP消息
三种路径的端到端时延分解(典型值):
| 阶段 | HO-based N26 | Redirection N26 | Without N26 |
|---|---|---|---|
| gNB决策 | ~10ms | ~10ms | ~10ms |
| N26上下文迁移 | ~50ms | ~50ms | N/A |
| RAN切换/重定向 | ~50ms | ~100ms | ~100ms |
| LTE Attach/TAU | N/A (HO完成) | ~100ms | ~800ms |
| 语音承载建立 | ~100ms | ~100ms | ~500ms |
| 总计 | ~210ms | ~360ms | ~1410ms |
注:以上为实验室典型值,现网受覆盖、负载影响可能偏差±30%
Q1: EPS Fallback和CS Fallback有什么区别? A: CS Fallback(CSFB)是4G→2G/3G的语音回退机制,用于LTE初期不支持VoLTE的场景,UE回落到GERAN/UTRAN建立CS语音。EPS Fallback是5G→4G的语音回退机制,回落到EPS后建立VoLTE语音。两者设计理念相似但技术栈完全不同:CSFB涉及CS域与PS域的协调,而EPS Fallback是纯PS域的跨系统迁移。
Q2: 运营商应优先选择哪种EPS Fallback路径? A: 强烈建议部署HO-based with N26。原因:(1)时延最短(~210ms),对SIP会话影响最小;(2)切换过程中数据面不中断,用户体验最佳;(3)IMS注册状态得以保持,无需重注册。无N26方案仅作为过渡或特殊场景(如跨PLMN互操作)的备选。
Q3: EPS Fallback后UE如何回到5G? A: 语音通话结束后,UE通过Fast Return to 5G机制返回NR。具体方式:(1)eNB在释放RRC连接时携带 redirection 到NR频点信息;(2)UE自主搜索NR频点并驻留;(3)UE发起5GC Registration(Mobility Registration Update)。整个过程通常在1-3秒内完成。
Q4: N26接口的Forward Relocation Request中包含哪些安全上下文? A: 包含完整的5G安全上下文映射:(1)KAMF衍生出的KNAS Enc/Int密钥;(2)UE安全能力列表(支持的NR/LTE加密和完整性算法);3)Key Set Identifier用于密钥标识;(4)Next Hop参数用于密钥链推演。MME收到后通过KDF将5G安全上下文映射为EPS安全上下文。
Q5: SMF如何知道需要触发EPS Fallback而不是拒绝语音请求? A: 判断链路:SMF收到PCF下发的Voice QoS Flow建立请求 → 通过AMF向gNB发起PDU Session Resource Setup → gNB返回REJECT + VoiceFallbackIndicator → AMF将此指示转发给SMF → SMF触发EPS Fallback流程。如果gNB直接返回REJECT且无VoiceFallbackIndicator,则SMF会通过PCF向IMS返回错误,最终导致SIP 488或500响应。
本文由「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 等场景全覆盖。
