简介针对5G网络优化中语音业务连续性和回落机制的理解难点这份PPT课件围绕新空口语音VONR和增强型分组系统回落EPSFB两条主线对比直接在5G新空口承载语音与回退到4G长期演进网络两种路径梳理触发条件、信令流程和主要差异适合5G无线优化工程师、核心网运维人员及通信专业学生阅读。内容先梳理协议数据单元会话管理流程涵盖建立、修改、释放及数据网络名称、单一网络切片选择辅助信息、会话连续性模式、服务质量流标识等关键参数再拆解新空口语音在互联网协议多媒体子系统中的注册与服务质量建立过程并解释增强型分组系统回落至长期演进侧的触发条件和承载建立步骤。资源为1个演示文稿文件压缩包约5.86MB页面以流程图和信令步骤为主并附终端侧不上报测量事件等设计细节便于分模块阅读。已有393人学习可作为日常优化排查、技术培训或方案汇报的辅助材料。1. 5G语音的岔路口VONR和EPSFB为什么必须一起看做5G网络优化的同行应该都有同感语音业务在5G时代反而是最让人头疼的一块。数据业务可以靠大带宽硬扛语音对时延和连续性要求极高一旦没优化好用户感知就是从“很清楚”瞬间跌到“喂喂喂”。VONR和EPSFB这两条路一个是在NR上直接承载语音一个是把语音业务回落到LTE去处理看似二选一实际上现网中两者是并存的而且它们的切换逻辑、信令流程、QoS参数配置都绕不开一个核心——PDU会话管理。这份《VONR和EPSFB流程分享》PPT正是把这些串在一起讲透的。我拆完这份资料后最大的感受是如果不把PDU会话管理吃透VONR和EPSFB的流程看得再熟也容易出偏差。这篇文章就把三者的关系、关键信令参数以及实际调测中容易踩的坑展开讲适合刚接触5G语音优化的工程师也适合想系统梳理信令流程的熟手。2. 把PDU会话管理流程拆开看建立、修改、释放和关键参数2.1 PDU会话生命周期管理三种流程各自负责什么5G核心网和UE之间的会话管理本质上是PDU会话的建立、修改和释放。理解这三者的分工是后续理解VONR和EPSFB的前提。PDU会话建立发生在UE需要访问外部数据网络时比如手机开机后要连上互联网、要注册IMS网络都会触发UE发起PDU会话建立流程。这个流程的核心工作是给UE分配IP地址、选择合适的UPF、建立默认QoS流。PDU会话修改则是在QoS参数需要调整、UE能力变化、或者建立新的QoS流时触发5QI为1或2的语音承载建立时就非常依赖这个流程。PDU会话释放发生在UE不再需要某项业务时网络侧主动回收资源。这三个流程在信令上表现为不同的NAS消息和NGAP消息组合。建立流程以UE发起的PDU Session Establishment Request为起点以网络返回Establishment Accept为终点。修改流程则对应PDU Session Modification Request/Response。释放流程则是由UE或核心网发起Modification或Release流程。实际处理信令时最关键的是搞清楚“谁发起的”和“承载的QoS流是哪个”。2.2 QoS Flow和DRB的映射关系一个PDU会话对应多个DRBPDU会话和QoS流之间不是简单的一对一关系。一个PDU会话ID可以对应多个DRB一个DRB又可以承载多个QFIQoS Flow Identifier而每个QFI都对应一个5QI来规定QoS流的服务质量要求。这就是为什么在RRC重配置消息里你会看到PDU session ID、DRB ID和QFI同时出现——它们就是一组映射关系。PDU Session ID (例如: 1) ├── DRB ID 1 → QFI 1 (5QI5, IMS信令) ├── DRB ID 2 → QFI 2 (5QI1, 语音) └── DRB ID 3 → QFI 3 (5QI2, 视频)常见做法是在IMS会话建立时默认先建立5QI5的QoS流来承载SIP信令等到语音通话建立时再通过PDU会话修改流程新增5QI1的QoS流。这里有个容易混淆的点PDU session ID始终不变变的是DRB和QFI的组合。出现这个映射关系的原因在于5G的QoS模型是流级别的而无线侧的资源承载是DRB级别的网络需要通过QFI把流映射到对应的DRB上传输。参数说明QFI的取值范围是0到63在PDU会话内唯一DRB ID和QFI之间的映射关系由RRC重配置消息中的PDCP层配置决定。5QI1对应语音媒体流5QI2对应视频媒体流5QI5对应IMS信令这个对应关系在3GPP标准中固定不建议随意修改。2.3 PDU会话建立的关键参数详解DNN、S-NSSAI、SSC modePDU会话建立请求中携带的参数决定整个会话的行为模式。DNNData Network Name相当于LTE时代的APN现阶段最常见的取值是ims和cmnetims用于接入IMS网络cmnet用于普通数据业务。手机接入网络时也可以不携带DNN由核心网根据订阅数据分配默认DNN。S-NSSAISingle Network Slice Selection Assistance Information标识网络切片包含SST和SD两个部分SST区分切片类型如eMBB、URLLCSD是切片区分符。语音业务通常会选择配置了IMS切片的S-NSSAI。SSC mode有三种取值mode1适用于IMS语音等需要保持IP地址不变的业务mode2适用于缓存类视频业务mode3允许IP地址短暂变化但保证连续性。现网中语音业务基本是SSC mode1。PDU type标识IP地址类型现网主流还是IPv4VoNR场景下IPv6也在逐步部署。PCOProtocol Configuration Options用来请求DNS、P-CSCF地址等配置选项IMS注册时通过PCO获取P-CSCF地址就是最常见的用法。2.4 PDU会话资源建立基站侧的动作核心网发送PDU Session Resource Setup Request到基站后基站的处理路径是这样的首先把携带的NAS消息PDU Session Establishment Accept透传给UE此时UE获得了PDU会话地址、QoS规则和QFI等关键信息然后基站通过RRC重配置给UE配置DRB和QFI之间的映射关系最后UE完成配置后回复RRC重配置完成基站再向核心网回复PDU Session Resource Setup Response。这条信令链路上有四个关键观察点NAS消息透传是否正确、DRB配置是否和QFI对应、RRC重配置是否成功、基站和核心网之间的NGAP交互是否正常。# 基站侧观察QoS Flow和DRB映射常用命令示例 # 常见做法是在基站CLI中输出当前UE上下文 show pdu-session context ue-id 12345 # 观察输出中的PDU session ID、DRB ID、QFI映射表参数分析UE上下文里不仅记录了PDU session ID和DRB ID还记录了QFI对应的5QI值以及GBR/Non-GBR的QoS参数。优化时重点关注的是GBR资源是否按需分配以及在切换过程中这些映射关系是否保持一致。2.5 SSC mode的现场选型逻辑SSC mode在现网规划中通常被忽视但它直接关系到语音业务的连续性。SSC mode1保证IP地址不变UPF不改变适用于IMS信令、语音通话这类对IP连续性敏感的业务。SSC mode2允许在会话建立时重新分配IP地址适用于视频缓存这类对IP变化不敏感的业务也常用于需要重新选择更优UPF的场景。SSC mode3则在地址重分配前先保留旧地址一段时间实现平滑迁移。现网中对语音业务使用SSC mode1是标配因为P-CSCF地址绑定在PDU会话上IP一旦变更IMS注册随之失效通话必然中断。优化角度上看如果发现VoNR通话掉话点集中在UPF切换位置优先排查是否PDU会话发生了重建立而不是一味去调切换参数。SSC mode对无线侧的直观影响不大但它决定了核心网会不会在移动过程中重建PDU会话这个重建动作才是掉话的根因。3. 把VONR流程理清楚从注册到通话建立的完整链路3.1 VONR和VOLTE的差异点到底在哪VONR和VOLTE在IMS层面几乎完全一致区别集中在接入网和核心网承载差异上。VOLE承载在LTE网络上通过EPS承载来传输语音VONR承载在NR网络上通过QoS流来传输语音。这个差异带来的直接结果是VONR的语音时延更低、编解码质量更好但前提是NR覆盖足够好。一旦NR信号变弱语音业务就需要通过EPSFB回落到LTE这是VONR方案不可避免的兜底机制。IMS域架构在VONR场景下依然是CSCF体系。CSCF分为三个角色P-CSCFProxy-CSCF是UE接入IMS的入口负责转发SIP信令S-CSCFServing-CSCF是核心会话控制节点负责任务状态管理和服务触发I-CSCFInterrogating-CSCF负责查询和分配S-CSCF。这个架构在VOLTE时代已经成熟VONR只是换了一条传输通路IMS核心网并没有本质改变。3.2 注册阶段的三级能力协商VONR呼叫能否成功发起首先取决于注册阶段的能力协商结果。这个协商过程分为三个环节第一UE在注册请求中通过语音域偏好字段表明自己是voice centric还是data centric第二UE能力查询中携带IMS相关能力指示表明终端支持IMS第三网络侧在注册接收信令中明确是否支持IMS语音。三步全部通过VONR能力才算建立。UE Registration Request ├── 5GMM Capability → IMS support: 1 ├── UE Usage Setting → voice centric └── UEs PLMN list → (网络选择偏好) UE Capability Info Indication └── (承载IMS能力参数) Registration Accept └── IMS voice over PS session supported → 1逻辑说明注册过程中的IMS能力协商决定UE后续是否发起IMS注册以及是否允许在NR上进行语音业务。如果网络回复不支持IMS语音UE会直接进入EPSFB逻辑即使NR信号很好也无法发起VoNR呼叫。3.3 MTK终端设计陷阱不上报B1事件导致掉话PPT中提到了一个典型的MTK终端设计问题终端在处于VOLTE通话时不上报NR B1事件。这个设计本意是好的——避免在语音通话中测量NR导致RRC重配置中断通话但带来的副作用是如果VOLTE通话中进入了NR弱场区域由于B1事件被抑制网络无法通过重定向或切换把业务迁回更优的LTE小区掉话风险反而增加。现象表现为UE在LTE通话过程中RRC测量报告中迟迟不出现NR B1事件网络无法触发重定向。原因在于MTK终端设计中语音通话状态下的NR测量被有意抑制属于单方面的保护机制。解决办法是修改终端配置或网络侧参数确保在VOLTE通话状态下NR测量仍然周期性触发B1事件的上报同时通过设置B1事件的门限和触发时延避免不必要的测量导致掉话风险。这个案例说明在VoNR优化中不仅要看网络侧配置还要熟悉主流终端厂商的设计逻辑。3.4 IMS域呼叫信令和语音编码协商VONR呼叫建立过程中会接触到两次资源协商。第一次协商发生在INVITE消息阶段主叫和被叫交换SDP信息协商语音编码能力比如OPUS、AMR-WB哪种编码被两端同时支持。第二次协商发生在UPDATE或者后续的180/183响应阶段此时双方确认最终编码并完成资源预留。INVITE → 100 Trying → 183 (含SDP) → PRACK → 200 (PRACK) → UPDATE → 200 (UPDATE) → 180 Ringing → 200 INVITE → ACK参数说明5QI1承载的语音业务质量直接受编解码类型、RTP包大小和Jitter Buffer设置影响。AMR-WB 12.65kbps是VoNR最常见的语音编码分配的带宽一般在31.7kbps左右。RTP包的发送间隔通常为20ms如果网络侧出现语音断续最先检查的是RTP丢包率和抖动值。3.5 5QI和QFI的价值为什么QoS流要按会话粒度配置VONR的QoS配置和VOLTE有个显著不同VOLTE通过EPS承载来管理QoSBearer ID一旦建立就固定不变VONR则通过QoS流和QFI来管理因此在PDU会话内部可以同时存在多个QFI每个QFI对应不同的5QI值。语音通话和视频通话在VONR场景下通常是同一个PDU会话内的多个QoS流5QI5的信令流、5QI1和5QI2的媒体流互相独立任何一个流有问题都可以单独通过修改流程调整而不需要重建整个PDU会话。就是这个差异让VoNR的QoS参数调整比VOLTE灵活得多。比如视频通话时发现视频卡顿可以在PDU会话修改流程中把视频流的GBR和MBR收紧或放宽而不影响语音流的配置。排障时需要特别注意的是信令面上看到的QFI值必须是终端记录和网络侧配置完全一致一旦QFI不匹配就会出现流量调度异常表现为语音听起来单通或视频帧率骤降。4. 把EPSFB流程讲透触发条件、回落过程和关键信令4.1 EPSFB为什么不是普通重定向EPSFBEvolved Packet System FallBack是VONR的兜底机制当UE发起语音呼叫时如果NR网络不支持VONR或覆盖不满足要求UE会被引导回落到LTE网络在LTE上建立语音呼叫。很多刚接触5G优化的工程师会问EPSFB和重定向有什么区别EPSFB在触发的时机和信令流程上不同。重定向只是让UE换一个无线接入技术并不会触发IMS重新注册EPSFB则通常先通过RRC重配置或重定向让UE从NR回落到LTE然后UE重新接入LTE网络再发起或继续IMS呼叫流程。4.2 EPSFB的触发条件有哪些EPSFB触发的前提是UE发起了语音呼叫需求但NR网络不具备或不满足VONR条件。常见触发场景有三种一是NR覆盖不连续网络侧根据测量结果判断当前小区无法保证语音质量二是核心网数据配置中不支持IMS语音或未配置VoNR功能三是UE能力不支持VONR或者网络侧注册接受消息中未携带IMS voice over PS支持指示。UE → gNB: UL NAS TRANSPORT (PDU Session Establishment/Mofification Request, request typevoice) gNB → AMF: InitialUEMessage / UplinkNASTransport AMF → SMF: Nsmf_PDUSession_CreateSMContext / UpdateSMContext SMF → AMF: Namf_Communication_N1N2MessageTransfer (with PDU Session Resource Setup Info) AMF → gNB: N2 Request (PDU Session Resource Setup Request) gNB → UE: RRC Reconfiguration (携带EPS Fallback指示) UE → gNB: RRC Reconfiguration Complete gNB → AMF: N2 Response逻辑说明EPSFB的触发由核心网在N2消息中显式携带EPS Fallback指示gNB收到后决定是重定向还是切换。这个指示在PDU Session Resource Setup Request中带上UE侧在RRC信令中看到该指示才执行回落动作。4.3 回落过程中5GC和EPC的交互EPSFB和普通切换不同的是UE从NR回落到LTE之前5GC需要先和EPC建立隧道把PDU会话映射到EPS承载。这个映射过程的实质是把5G核心网的PDU会话转换为4G的EPS承载体系QoS流对应关系也要做相应转换。语音业务的5QI1映射为QCI1IMS信令的5QI5映射为QCI5。这个映射过程需要MME和AMF之间存在N26接口。没有N26接口时回落过程会退化为idle mode mobility流程即UE在LTE网络重新做位置更新和PDN连接建立时延增加且必须重新做IMS注册。有N26接口时可以执行PS Handover信令连续性更好。优化角度的建议是现网部署EPSFB但不具备N26接口语音建立时延会增加200到500毫秒用户感知差异明显。4.4 EPSFB中的测量和重定向参数怎么设EPSFB回落的无线侧执行方式有重定向和基于测量的切换两种。基于测量的切换先通过RRC重配置下发LTE测量控制UE上报测量报告后gNB再发起切换流程可靠性更高但时延更大。重定向则直接通过RRC Connection Release消息里带LTE频点UE释放NR连接后自行接入LTE时延小但可靠性依赖UE行为失败后需要重发。measConfig: { measObjectToAddModList: { measObjectId: 1, measObjectEUTRA: { carrierFreq: 3750, // 需要重定向的LTE频点 allowedMeasBandwidth: mbw6, ... } }, reportConfigToAddModList: { reportConfigId: 1, reportConfigEUTRA: { triggerType: eventA2, // 当前NR信号低于门限触发测量 eventId: eventA2, thresholdRSRP: -110 // RSRP门限 } }, measIdToAddModList: { measId: 1, measObjectId: 1, reportConfigId: 1 } }参数说明A2事件的RSRP门限决定了何时开始LTE测量建议在NR边缘设置-110dBm到-115dBm。如果门限设置太低NR信号已经较差时才开始测量回落准备时间不足可能掉话如果太高则过早回落丧失VoNR优势。4.5 EPSFB和VoNR并存时的业务连续性现网部署中EPSFB不是独立的孤岛而是和VoNR并存的整体语音解决方案。VoNR负责在NR覆盖好的区域提供高质量语音EPSFB在NR覆盖恶化或网络能力不足时作为备份。两者由同一个IMS核心网承载SIP信令在回落前后都保持连续只是承载通道从NR改成LTE。这个设计带来的优化思路很明确不能孤立地看待VoNR或EPSFB的任何一条信令而要从端到端语音呼叫建立的整体流程看问题。例如一个在NR覆盖边缘区域的用户发起语音呼叫网络侧选择EPSFB回落但如果回落目标LTE小区存在拥塞语音质量依然无法保证。因此EPSFB的优化也和LTE侧的负载均衡策略密切相关。5. 避坑与排查VONR和EPSFB常见问题的定位思路5.1 现象VoNR通话中突然掉话信令上看不到回落遇到这个问题时我一般的排查顺序是先看无线环境再看UE上下文最后查核心网。现象是VoNR通话正常进行UE从NR移到边缘区域后通话直接中断没有任何EPSFB或切换动作。原因通常是UE在通话中NR测量GAP配置不当或B1事件被抑制MTK终端设计问题或网络未下发LTE测量控制导致UE对LTE邻区一无所知一旦NR信号骤降语音承载因为无线链路失败而崩溃。解决办法是核查gNB是否在VoNR会话建立过程中下发了LTE测量配置以及UE能力是否支持异系统测量必要时强制开启GAP测量。5.2 现象EPSFB回落成功后IMS注册失败EPSFB过程本身走得通UE在LTE成功接入但随后IMS注册失败用户无法呼叫。原因通常是核心网N26接口未配置或PDU会话映射失败导致UE在LTE网络没有有效的PDN连接IMS注册请求无法携带有效的APN信息。解决办法是核查MME和AMF之间的N26配置确认5QI到QCI的映射表正确同时检查UE在LTE网络重建PDN连接是否成功。还有一种情况是UE的TAU流程没有执行完毕就开始IMS注册时序问题导致的注册竞争失败。5.3 现象PDU会话修改流程中QFI不匹配现象是网络侧通过PDU会话修改流程新增了QoS流但UE一直在默认承载上传输语音没有使用新建的QoS流导致语音质量极差或被网络侧丢弃。原因通常是QFI的映射关系没有在RRC重配置中准确下发或者UE实现中QFI处理逻辑有bug。解决办法是抓取RRC信令确认PDCP配置中DRB和QFI的映射表如果存在映射缺失手动修正网络配置重新下发RRC重配置。5.4 现象EPSFB回落目标小区错误UE从NR回落到一个LTE小区后信号极差或驻留失败。原因通常是重定向的EUTRA频点信息配置错误或LTE邻区关系不全。解决办法是核查RRC Connection Release中的redirectCarrierInfo以及gNB内的LTE邻区配置确保频点、PCI、Band对应准确。注意有些场景下回落目标小区虽然覆盖好但小区被设置为barredUE会重新搜索导致时延增加。5.5 现象VoNR通话建立时延过大从拨号到听到回铃音的时间超过了8秒用户明显感知迟延。原因主要集中在IMS信令流量抢占资源或QoS流建立延迟尤其是PDU会话修改流程等待核心网响应时间过长。解决办法通常是把5QI1的QoS流预建立或者在UE发起呼叫前先完成IMS PDN连接减少呼叫过程中的资源建立时间。也可通过调整网络侧的定时器参数缩短N2消息响应等待时间但这个动作需要谨慎因为过短的定时器会导致正常流程被判失败。5.6 排查工具和信令抓取建议遇到VONR和EPSFB问题我一般会先抓三层信令UE侧的AS信令、NGAP信令和IMS的SIP信令。NGAP信令关注PDU Session Resource Setup/Modify/Release三类消息重点看其中的5QI、QFI和EPS Fallback指示。SIP信令关注INVITE、183、UPDATE、PRACK这些消息的SDP内容重点看编解码协商是否正常。UE日志则通过终端厂商工具抓取MTK终端用CAT工具Qualcomm终端用QCAT看RRC和NAS层的行为。# Wireshark NGAP过滤示例 # 先使用ngap filter抓取PDU Session Resource Setup ngap.type 3 # 或具体proc code # 再看UE侧NAS消息 nas_5gs.type 0x01 # Registration request nas_5gs.type 0x03 # Service request # 最后定位PLMN和S-NSSAI nas_5gs.snssai.sst 1逻辑说明抓包的核心思路是“先定位问题在哪一层”。若是NGAP层正常、SIP层异常优先查IMS侧若是NGAP层已经有异常优先查RRC和核心网配置。这个过滤方法能帮助快速缩小范围避免在海量信令里大海捞针。6. 从信令走向优化把VONR和EPSFB的关键监控指标落到现网理解了整套流程之后真正的难点是把它变成日常维护的监控项。我习惯在每个优化项目中把信令流程的关键节点转成可量化的指标长期盯住几个关键点VoNR呼叫建立成功率、EPSFB回落成功率、PDU会话修改成功率、VoNR掉话率、回落时延。每个指标的恶化都对应特定的信令流程异常这样能从网络KPI的异常反向定位到底层哪个环节出了问题。监控指标清单 VoNR呼叫建立成功率 成功建立数 / 总尝试数 EPSFB回落成功率 EPSFB执行成功次数 / EPSFB触发次数 PDU会话修改成功率 修改成功次数 / 修改尝试次数 VoNR掉话率 通话异常释放次数 / 通话总次数 EPSFB平均时延 从触发回落到LTE成功建立语音的时长每个指标的变化都和具体的信令流程绑定。VoNR呼叫建立成功率低优先查看注册阶段的IMS能力协商是否通过EPSFB回落成功率低优先查看回落目标小区的可用性和RRC重配置是否成功PDU会话修改成功率低优先查看5QI1的新增QoS流是否触发了网络侧N2消息异常。在实际优化项目中我还习惯每次异常掉话都做一次“信令回放”把UE侧和基站侧的信令时间对齐把每个信令消息的时间戳列出来从呼叫发起到释放的每一个步骤都过一遍。这个习惯让我发现了不少蛛丝马迹比如某个版本的gNB软件在RRC重配置消息中漏掉了一个QFI映射导致DCI调度异常语音帧虽然下发但因为QFI不对应被UE丢弃。解决的方式也很简单——在QoS Flow和DRB的映射表中补上对应的QFI配置即可。从那以后我每次做VONR和EPSFB的优化分析都会强制走一遍这套完整的排查清单终端能力协商是否完成、PDU会话是否建立了正确的QoS流、回落目标是否准确、SIP信令是否异常。把这个流程固化下来解决现网问题时能少走很多弯路也希望这个思路能帮你在实际项目中快速定位到问题根因。本文还有配套的精品资源点击获取