做通信这行久了就会发现VoLTE和5G新通话里最值钱的经验不在PPT上而在信令面里。QCI 1、2、5、9这几个数字几乎就是一张移动业务质量的晴雨表语音卡不卡、视频稳不稳、为什么切了个小区就掉话翻翻Wireshark抓包里的QCI都能找到答案。这篇文章不发空理论直接带你从Wireshark的抓包窗口出发把QCI 1、2、5、9从建立到切换的全过程逐条拆开看——适合网优工程师、核心网测试人员还有刚入行想搞懂语音承载是怎么回事的同学们。文章里所有抓包位置、过滤条件、字段路径都是我实际跑过的照着手动一遍比看十遍规范有用。1. 先把QCI 1、2、5、9的底细摸清楚1.1 QCI到底是什么QCI的完整叫法是QoS Class Identifier翻译过来是服务质量类别标识。它不是一个带宽数值而是一套预先定义好的QoS行为模板相当于给每个数据包打上了一个“服务等级证书”告诉网络这个包该按什么优先级、什么时延预算、什么丢包率来转发。3GPP定义了不同的QCI编号每个编号背后都有一组标准参数包括资源类型GBR还是Non-GBR、优先级、时延预算、丢包率。这里有个初学者最爱搞反的点QCI数字越大优先级反而越低。QCI 9是最低优先级的默认承载QCI 1、2才是高优先级的语音视频承载而QCI 5虽然数字大但因为承载着IMS信令优先级排到了1比语音还高。这个设计逻辑很清晰信令丢了连呼叫都建立不起来语音包偶尔丢一点还能忍一下但视频和语音的时延一旦超标用户体感直接崩。所以网络侧对QCI 1、2的调度优先级和RB资源预留会做专门保障而对QCI 9则是“有资源就用没资源就排队”。1.2 QCI 1、2、5、9核心参数对比先上表格方便对照看QCI资源类型优先级时延预算丢包率典型业务QCI 1GBR2100ms10^-2VoLTE语音AMRQCI 2GBR4150ms10^-3ViLTE视频通话QCI 5Non-GBR1100ms10^-6IMS SIP信令QCI 9Non-GBR9300ms10^-6默认承载/Internet业务很多人不理解为什么QCI 5是Non-GBR却要保证优先级1。实际在现网中QCI 5承载的虽然是SIP信令数据量不大但它的实时性要求极高——发起呼叫、振铃、挂断全靠它。如果QCI 5被挤占用户最直接的感受就是电话拨不出去或者接通后听不到振铃音。QCI 9是所有终端默认建立的第一条数据承载浏览网页、刷视频、后台推送全走它。它没有带宽保证调度优先级最低。但注意QCI 9的时延预算是300ms丢包率要求反而是10^-6比QCI 1还苛刻因为数据业务靠TCP重传丢了包虽然能找回但会把吞吐拖下来所以核心网侧也会尽量保证其基本转发。1.3 从QCI到5QI5G新通话里的编号变化5G核心网换成了服务化架构接口改了QoS参数也跟着升级。5G里不再叫QCI改叫5QI5G QoS Identifier。名字变了但设计哲学一脉相承5QI 1对应实时语音、5QI 2对应实时视频、5QI 5对应IMS信令、5QI 9对应默认数据业务。不过有几个细节需要特别注意。第一5QI和QCI的优先级数值并不完全对齐比如5QI 1的默认优先级是20而QCI 1是2这是因为两套体系对优先级刻度重新定义了不能直接跨表对比。第二5G标准后来还增加了用于VoNR的5QI 82、83、84等专用数值不同运营商实现不同抓包时看到不一定是1、2、5、9这种整数编码要做综合判断。第三5G里承载单位从EPS Bearer变成了QoS Flow一个PDU Session里可以同时存在多个QoS Flow每个QoS Flow挂一个5QI抓包逻辑和LTE时代不完全一样。5G新通话本质上是在IMS基础上叠加数据通道语音走5QI 1视频走5QI 2而新通话的实时字幕、远程控制、AR标注等能力会用到额外的QoS Flow和内容类型协商抓包的复杂度比VoLTE高出一截。2. Wireshark抓包环境在哪个接口抓、怎么过滤最有效2.1 抓包位置决定你能看到什么很多新手上来就想“把手机空口抓包”结果发现Wireshark根本不认识LTE空口的MAC层。实际上Wireshark能直接解析的是IP之上的协议栈空口信令需要终端侧开诊断端口或者通过路测工具导出后才能看。我自己最常用的几个抓包位置如下抓包位置接口能看到的协议适用场景核心网侧S1-MME接口S1AP、NAS-ESMQCI承载建立/修改/删除核心网侧S11/S5/S8接口GTPv2-C、SIP间接承载上下文协商IMS边缘Gm/SGi接口SIP、RTP、RTCP呼叫流程和媒体协商终端侧DIAG/日志口RRC、NAS、SIP应用层空口-核心网全链路对照5G侧NG接口NGAPNGAP、NAS-5GSPDU会话和QoS Flow建立实际工作中我最推荐先抓S1-MME或NG接口的控制面因为QCI的分配、修改、删除都在控制面消息里明文可见。用户面GTP-U里虽然有TEID可以关联到具体承载但想在GTP-U里直接看到QCI是不行的必须对照控制面才能确定某个TEID属于哪个QCI。2.2 Wireshark过滤器配置少走弯路的几个组合Wireshark打开一秒就能产生几十万包不设置过滤器等于大海捞针。我自己电脑里长期存着一套模板按场景切换# 只看LTE控制面信令S1APNAS s1ap || nas-eps # 只看特定QCI的承载建立请求 s1ap.qCI 1 # 只看5G控制面信令 ngap || gsm.nas # 只看SIP呼叫流程 sip # 过滤出IMS专用承载建立相关消息 nas-eps.msg_type 0xc1 # Activate Dedicated EPS Bearer Context Request这里有个关键点要提醒很多Wireshark版本里s1ap.qCI这个字段仅在S1AP的E-RAB建立、修改、切换请求等消息里存在关联消息里如果只带了E-RAB ID你就得配合e_RAB_ID来查而不是直接搜QCI。我习惯同时加两个条件比如s1ap.qCI 1 || (nas-eps.msg_type 0xc1)这样能覆盖大部分现网抓包场景。2.3 在核心网侧抓包的具体操作步骤核心网侧抓包最简单的方法是镜像S1-MME或NG接口流量。在没有专业信令分析仪的情况下直接在MME或AMF的业务服务器上用tcpdump抓包是可行的但要注意业务量大的节点网卡吞吐极高不建议长时间全量抓取。我的建议是分三步走先用短时抓包确认网卡和IP地址信息比如tcpdump -i eth0 -w /tmp/mme.pcap host x.x.x.x -s 0其中x.x.x.x是你要跟踪的UE所在基站或固定IP。抓够30秒到一个呼叫周期就够了语音呼叫从INVITE到200 OK一般不超过5秒抓太久文件太大反而不利于分析。抓完立即关闭导出后用Wireshark打开先看Expert Info里的错误级提示优先排查异常消息。Wireshark 4.0之后对NAS-5GS和NGAP的解析已经很完善建议直接升级到4.0以上版本老版本在解析5G消息时经常出现“Unknown”或字段错位容易误判。3. 实战解析QCI 9和QCI 5是怎么建立起来的3.1 默认承载QCI 9的建立过程LTE终端开机后第一件事是Attach流程核心网会在Attach Accept里携带默认EPS承载上下文这个默认承载的QCI就是9。抓包里找到Attach Accept或ESM Information Response展开QoS相关的IE能直接看到QCI9。值得注意的细节是默认承载用户面数据从S1-U接口走GTP-U Header里的TEID和S1AP消息里的TEID是同一个靠这个关联可以验证QCI 9承载是否激活成功。很多“能打电话不能上网”的故障查到最后就是QCI 9承载的GTP-U路径异常TEID不匹配导致下行数据被丢弃。3.2 IMS信令承载QCI 5的出现时机QCI 5不像QCI 9那样随Attach自动建立它是在终端向IMS注册时由核心网专门为IMS APN拉起的专用承载。终端先发PDN Connectivity Request携带APN为ims网络侧根据用户的签约数据触发专用承载建立流程。抓包时重点关注Activate Dedicated EPS Bearer Context Request这条NAS消息。这个请求里会带一个EPS Bearer Identity通常和默认承载的EBI不同同时QoS参数明确写着QCI5。如果这条消息没出现说明IMS APN的接入被网络拒绝或者在PGW侧没有生成PCC规则原因多半是HLR/HSS签约里没配好IMS APN。QCI 5之所以单独建一条承载是因为SIP信令的控制通道要绝对稳定不能和用户的上网流量抢资源。即便用户在疯狂刷大流量视频QCI 5的SIP消息也能优先送达这样来电才能及时响铃。3.3 Wireshark里如何快速定位QCI 9和QCI 5我一般这样过滤先nas-eps筛选所有NAS消息再通过CtrlF搜索十六进制值快速定位。QCI的编码在NAS ESM消息里是单字节值QCI 9的十六进制就是0x09QCI 5就是0x05。选中任一承载上下文激活消息后在Packet Details面板里按路径Protocols NAS EPS EPS mobility management ESM message container就能看到完整的QoS参数。这里有个操作技巧可以直接右键QoS parameters字段选择Apply as Column这样所有消息的QCI值都能直接列在Packet List上方一眼看全。S1AP侧则是在S1AP ProtocolIEs E-RABToBeSetupList E-RABToBeSetupItem里看qCI字段同时还能看到e-RAB-ID和transportLayerAddress、gtp-TEID。多个UE同时呼叫时靠TEID和IP区分是最靠谱的。4. 呼叫阶段的核心QCI 1和QCI 2承载的建立与切换4.1 VoLTE主叫流程中QCI 1的完整建立路径一个正常的VoLTE主叫UE通过QCI 5发INVITEP-CSCF收到后通知PCRF做资源预留PCRF再下发PCC策略给PGWPGW发起到MME的Create Dedicated Bearer请求。这个过程中UE侧收到的关键NAS消息是Activate Dedicated EPS Bearer Context Request里面的QoS参数QCI1并且带上了GBR和MBR值比如语音编码AMR-WB 23.85kbps的话GBR可能配成23.85或这个速率的整数倍。紧接着eNB通过S1APE-RABSetupRequest给UE配置对应的DRBRRC层重配完成后这条GBR承载才算真正建立。抓包时在S1AP消息里能看到清晰的三条记录链E-RABSetupRequest下行 → E-RABSetupResponse上行 → UE侧ULInformationTransferRRC complete。很多朋友抓了包抱怨“看不到QCI 1”大概率是因为只用Wireshark抓了电脑网卡而VoLTE呼叫的数据面不在电脑网卡上控制面又被运营商内部网络隔离。此时要抓包只能从基站侧、核心网侧或者具备诊断抓包能力的测试终端上获取。4.2 ViLTE视频通话为什么需要QCI 2视频通话比纯语音多一条视频媒体流网络侧在INVITE的SDP协商里识别到视频编码后会为视频流单独构建QCI 2承载。和QCI 1相比QCI 2的时延预算略宽松150ms丢包率要求更严格10^-3同时同样是GBR意味着基站要为它预留固定的无线资源。抓包时你会看到终端同时保持两条专用承载一条QCI 1走AMR音频RTP一条QCI 2走H.264视频RTP。用Wireshark的Telephony菜单里的VoIP Calls可以看到每条RTP流的SSRC、抖动、丢包率等指标如果视频卡顿但语音正常重点看QCI 2承载的丢包和时延是否超标。QCI 1和QCI 2的优先级、时延特性决定了它们在调度器里有不同的处理权重。视频包可以容忍比语音包更大的抖动但丢包补偿成本高所以网络对QCI 2的调度策略一般更偏重“稳”而对QCI 1更偏重“快”。4.3 切换过程中QCI怎么保持不掉的切换是信令分析的高频场景。LTE内的切换分X2切换和S1切换两种。无论哪种源侧MME都会把GBR承载的上下文信息包括QCI、TEID、IP地址透传给目标侧确保QCI 1或QCI 2这样的GBR承载能无缝转移。在S1AP消息里切换的关键字段是HandoverRequired消息中的E-RABToBeSwitchedULList和E-RABToBeSwitchedDLList。这个列表用于标识哪些E-RAB需要切换路径我实际抓包看到的情况是QCI 1这条GBR承载基本都会出现在列表里而QCI 5、QCI 9这类NGBR承载有时候会被省略因为目标基站可以随时重建它们。如果在HandoverRequired里只看到QCI 9、QCI 5而看不到QCI 1就要高度警惕——这可能意味着语音承载在切换前就已经被释放是掉话的前兆。排查时要在切换流程里跟进目标侧是否发起E-RABSetupRequest重新拉起QCI 1如果目标侧没有资源预留UE会有短暂中断甚至掉话。4.4 5G VoNR和EPS Fallback中的QoS切换到了5G阶段情况更复杂。5G覆盖不好时IMS语音呼叫会触发EPS Fallback终端从NR回落到LTE此时5G侧的5QI 1会转换成LTE的QCI 1。抓包时要同时在NGAP和S1AP上抓才能看到完整的跨系统切换。EPS Fallback的典型信令特征是NGAP侧出现HandoverRequired或MobilityFromNRCommand随后在S1AP侧看到HandoverRequest携带QCI 1的E-RAB建立。5G核心网里的PCF通过N7接口把PCC规则传给SMFSMF再向PGW-C申请LTE侧资源这一层转换对终端是透明的但信令面有专属流程。我在实际项目里遇到过好几次这样的问题VoNR呼叫建立时5QI 1正常但在NR弱覆盖场景下切换后QCI 1丢失导致语音单向。这种问题的根因不是QoS参数配置错而是切换策略里没有把语音优先切换到可用的LTE频点。信令抓包能定位到哪一步丢承载但网络侧的回落策略调整需要和RRM、SON参数联动。5. 5G新通话里的新看点QoS Flow、5QI与数据通道5.1 5G QoS Flow和PDU Session的关系5G采用QoS Flow作为QoS控制的最小单位一个PDU Session里可以同时有多个QoS Flow每个Flow对应一个5QI。这和LTE时期一个PDN连接承载一条IP流集合不同5G的QoS Flow可以按业务动态创建、修改和删除灵活性高很多。抓5G的信令要看的协议从S1AP变成了NGAP从NAS-ESM变成了NAS-5GSM。Wireshark里过滤ngap能看到PDU Session Resource Setup Request其中会包含QoS Flow的建立信息gsm.sm里则能看到NAS层的5GSM消息里面直接有5QI值。关键字段路径是NGAP里PDUSessionResourceSetupRequest PDUSessionResourceSetupRequestTransfer qosFlowSetupRequestList qosFlowSetupRequestItem qosFlowLevelQosParameters fiveQI。5GSM里则是QoSFlowDescription QoSFlowIdentifier和FiveQI。5.2 VoNR建立流程里的5QI 5和5QI 1VoNR的呼叫流程和VoLTE几乎一样只是信令承载由QCI 5变成5QI 5语音承载由QCI 1变成5QI 1。UE发起INVITE时PDU Session里先有5QI 5的QoS Flow用于SIP信令P-CSCF完成媒体协商后网络通过PDU Session Modification为语音流创建5QI 1的QoS Flow。抓包时有几个容易踩的坑老版本Wireshark会把5QI 1解析成Unknown其实就是版本解码表不全升级到4.2以上基本能解决。5QII里看到1或2时还要看QoS Flow IdentifierQFIQFI和5QI是两码事经常有人搞混。简单说QFI是这条Flow在这个PDU Session里的编号5QI才是它对应的服务质量等级。同一个PDU Session里可能同时存在5QI 5、5QI 1、5QI 9三条Flow它们的QFI分别是不同的数值看到多个“QoSFlowDescription”字段别慌逐个对照5QI判断业务类型即可。5.3 新通话的数据通道怎么抓5G新通话的卖点是在通话过程中叠加数据通道比如实时字幕、共享屏幕、AI实时翻译。数据通道的本质是在IMS媒体会话里建立一个Data Channel它的控制走SIP通过SIP INFO或内容类型为application/dc的SDP媒体面走WebRTC。信令分析时Wireshark里主要看两条线SIP部分的SDP扩展字段比如adcsa、adcbind以及媒体面WebRTC的DTLS握手和SRTP流转发。QoS方面实时数据通道一般会复用5QI 1或5QI 2的QoS Flow或者单独建一条专用的QoS Flow具体要看运营商的策略和PCC流程。如果要从抓包里判断新通话是否真的承载在5QI 1而不是5QI 9上我的建议是抓完控制面信令之后再用RTP统计功能看媒体流的IP、端口和SSRC然后去NGAP或S1AP消息里搜对应的IP和端口看它被关联到哪个QoS Flow上。这是一条万能的关联思路适用于所有QoS问题定位。5.4 切换后QoS Flow的映射关系变化5G切换NG-RAN内切换时目标基站必须确认自己能够支持PDU Session里的所有QoS Flow否则核心网会触发QoS Flow的释放或降级。比如目标基站不支持高实时性的5QI 1网络可能把它降级成5QI 9用户感知就是“还在通话但质量明显变差”。抓包时在NGAP的PathSwitchRequest或HandoverRequired里能看到每个PDU Session对应的QoS Flow列表如果某些QoS Flow没有被包含进去说明它们可能在切换后被释放或重新协商。对比切换前后两个消息里的QoS Flow变化就能判断切换对通话质量的影响。这个知识点在基于服务化架构的5G网络里尤为重要因为一个PDU Session里可能同时承载了语音、视频、数据通道、普通上网四种业务切换时一个QoS Flow映射失败就会导致一种业务异常但其他业务还正常——用户报告“视频通话只有画面没声音”时优先级最高的检查项就是QoS Flow的切换映射。6. 高频问题与排查技巧把Wireshark用出老工程师的味道6.1 为什么抓包看不到QCI 1的专有承载建立最常见的原因是抓包位置不对。QCI 1的专用承载建立流程由PGW发起核心网侧如果只抓了S5/S8接口可能能看到Create Bearer Request但S1AP侧看不到的话说明流量在MME到eNB这一段没被镜像出来。另一个原因是终端不支持VoLTE或运营商没开通VoLTE此时UE在CSFB模式下语音走电路域S1AP里永远不会出现QCI 1。还有一个容易忽略的细节很多测试设备在VoLTE呼叫时会做静默期IP层抓包看到SIP INVITE成功但迟迟不见专用承载激活就有可能是因为网络侧PCC策略下发延迟或HSS里没有该用户的VoLTE签约数据。这时候要检查IMS APN的签约数据是否被激活再检查PCRF是否生成了对应的PCC rule。6.2 QCI显示Unknown或乱码怎么办Wireshark显示Unknown的原因一般有两个。一是Wireshark版本太旧没有S1AP或NAS的完整解码表升级到最新稳定版基本能解决。二是部分运营商在私有扩展字段里封装了自己的QoS参数Wireshark无法自动识别这时候只能手工解析原始十六进制数据。遇到乱码时不要慌先看这个字段所在的协议层是否被错误解码了。比如NAS-ESM消息如果被当成普通IP包解QoS参数就会变成一堆乱码。右键消息选择Decode As强制指定为NAS EPS或S1AP通常能立刻恢复正常。如果还是解不出来可以把原始十六进制复制下来参考3GPP TS 24.301和TS 36.413手工判断QCI值。6.3 长时间抓包怎么控制文件大小核心网侧抓包动辄每秒几十万包不限制大小的话几分钟就是几个G。我的习惯是用-c参数限制抓包数目或者用环形缓冲区# 每个文件500MB最多保存10个文件超出循环覆盖 tcpdump -i eth0 -w /tmp/mme.pcap -C 500 -W 10 -Z rootWireshark打开大文件也会卡如果抓完要分析整段建议先用tshark做一轮预处理把要关注的协议过滤出来另存# 只保留S1AP和NAS消息别的全部丢弃 tshark -r big.pcap -Y s1ap || nas-eps -w small.pcap这个操作能把几十G的pcap压缩到几十兆分析效率提升巨大。6.4 判断单通和掉话的独门信令特征单通问题从QCI承载看最典型的是QCI 1建立成功但另一侧的RTP流没起来或者RTP流虽然存在但承载路径上GTP-U TEID不匹配。在Wireshark里可以看呼叫的RTP流菜单Telephony VoIP Calls找通话时间对应提取两条RTP流上行和下行对比它们的方向、SSRC、目标IP和端口。如果一方有RTP包而另一方完全没有大概率是中间网元路由或NAT问题。掉话场景里信令层面看两条线一是看是否出现了Detach Request或PDN Connectivity Request说明终端主动释放了承载二是看E-RAB Release Command是否在通话未结束时异常触发如果是S1AP释放了QCI 1承载去查释放原因值。我印象最深的案例是某个区域频繁掉话抓包发现S1AP里的E-RAB Release Command携带的原因值是radio-network-layer-failure进一步分析发现目标小区在切换流程里一直分配不出QCI 1的GBR资源。最后定位到是目标基站CAC准入策略配置过严把语音GBR承载挤掉了。这种问题单看核心网日志很难发现配合Wireshark抓包的S1AP消息和时序五分钟就能锁定方向。再提一句5G场景的排查差异。5G里看QoS Flow的释放和修改重点盯SMF发出的PDUSessionResourceModifyRequest里面会明确列出哪些QoS Flow被释放、被降级。如果新通话的数据通道业务突然失效优先检查这个Request里的QoS Flow列表看看DC对应的QoS Flow是否还在能不能匹配到已有的DRB上。实测跑完一圈你会发现QCI和5QI的抓包分析并不难难的是把控制面的每个消息和用户感知对应起来。抓包之前先想清楚业务场景用户是在注册、呼叫、切换还是释放每条控制面消息都对应一个网络动作动作有没有成功看QCI/5QI建立和保持状态就够了。我个人的习惯是整理一份“每个QCI承载的关键信令链路表”从NAS到S1AP/NGAP再到RRC层层对照这比临时打开Wireshark乱翻效率高得多。