VoLTE语音质量优化
1
案例1：VoLTE窄带与宽带语音质量对比
【问题现象】
在3GPP LTE中，VoLTE业务编码有AMR-NB窄带和AMR-WB宽带两种编码，两种编码速率具有不同的话音质量，所以又分别称为VoLTE标清语音（或VoLTE 12.2kbps）和VoLTE高清语音（或VoLTE 23.85kbps）。
【问题分析】
AMR-NB和AMR-WB这2种编码具有如下特点：
? 每20ms产生一个语音包，包括了RTP/UDP/RLC-Security压缩头； ? 每160ms生成一个SID语音静默包。 ? 帧长20ms； AMR-NB编码特点为：
? 4.75kbps到12.2kbps共8个码率，分别为：4.75、5.15、5.9、6.7、7.4、7.95、
10.2、12.2kbps； ? 采样率为8kHz。 AMR-WB编码特点为：
? 6.6kbps到23.85kbps共8个码率，分别为：6.6、8.85、12.65、14.25、15.85、
18.25、19.85、23.05、23.85kbps； ? 采样率为16kHz。
可见两者显著的差异是采样速率不一样，窄带一个语音帧是160个点，宽带一个语音帧采样320个点。AMR NB的语音带宽范围：300－3400Hz，8KHz采样。AMR WB的语音带宽范围： 50－7000Hz，16KHz采样。用户可主观感受到话音比以前更加自然、舒适和易于分辨。
AMR WB与AMR NB不同之处在于AMR WB按16kHz采样，分别按频率带50~6400Hz 和6400~7000Hz 进行编码。用来降低复杂度，AMR WB将位算法集中到更重要的频率区。低频带使用ACELP算法进行编码。 添加几个特征来达到一个高的主观质量。 线性预测（LP）算法是在每隔20ms 的帧要进行一次线性预测算法，每5ms搜索一次自适应码本，这个过程是
2
在12.8Kbs 速率下进行。高频带是在解码器端使用低带和随机激励的参数重建的, 目的是调整与在声音基础上的低频有关的高频带. 高频带的声频通过使用由低带LP 过滤器产生的LP 滤波器进行重建。
AMR WB与AMR NB的MUSHRA评分（multi-stimulustest with hidden reference and anchor，ITU-R recommendation BS.1534.)参考见下图。
利用传统的MOS值进行AMR-NB和AMR-WB进行对比测试，结果如下图：
5.004.504.003.503.002.502.001.501.000.500.004.324.184.164.144.284.14.254.084.054.224.053.93.853.73.63.53.6AMR-WBAMR-NB23.85, 12.223.05, 10.219.85, 7.9518.25, 7.415.85, 6.714.25, 5.912.65, 5.158.85, 4.756.6 由以上分析可见AMR-WB比AMR-NB有更高的话音质量。
【问题解决】
在语音质量上AMR-WB更优于AMR-NB，因此AMR-WB又称为高清语音。
3
案例2：VoLTE与GSM语音质量比较
【问题现象】
杭州现场使用POLQA SWB评分标准，评估GSM打GSM，VoLTE（23.85kbps）和VoLTE（12.65kbps）三种长呼语音质量，VoLTE MOS相比GSM有较大改善，MOS评分参见下表。
语音拨打类型 2G打2G VoLTE（23.85kbps） VoLTE（12.65kbps） MOS(POLQA SWB) 2.64 3.98 3.84
【问题分析】
2G使用窄带语音AMR-NB 12.2k和EFR编码方式，使用POLQA SWB评分时会比传统PESQ评分会低，具体映射关系如下：
表从上可以看出：AMR（12.2k）/EFR POLQA评分先比PESQ评分低0.5分左右。 按照上表，将2G打2GMOS(POLQA SWB)折算为PESQ MOS分应为2.64+0.5=3.14分。分析2G MOS分值，大量2分MOS分值对应的语音编码方式为EFR，AMR 12.2k编码MOS分一般在3分左右。
【问题解决】
POLQA SWB评分按照64Kbps采样率进行语音质量评分，评分标准比传统PESQ高。同样的2G语音， POLQA评分先比PESQ评分低0.5分左右。
4
案例3：VoLTE与OTT语音质量比较
【问题现象】
微信电话本是腾讯公司在2014年11月11日推出的基于微信的VoIP电话，其具有低接通时延、无通信费用（仅有流量费用）和高清晰音质等特点。微信电话本对语音业务有很强的替代作用。对微信电话本和VoLTE电话进行了对比测试，分析其产品差异。
【问题分析】
VoLTE试点区域内共有4G基站400个，主覆盖区域为D频段，覆盖良好。使用设备为ASCOM公司的TEMS16.1.3，测试手机为HTC M8t。
1、音质对比分析
从现有的PDCP层速率和MoS进行推测，微信电话本采用的编码为skype的SILK Codec。SILK Codec是一个语音和音频编解码算法, 对于音频带宽、网络带宽和算法复杂度都具有很好的弹性，支持4种采样率：8KHz、12KHz、16KHz、24KHz；三种复杂度：低、中、高。编码码率在 6~40kbps（不同采样率具有不同的码率范围）以及还支持VAD、DTX、FEC等模块，已经在QQ，AIM，GOOGLE TALk上使用，性能在高掉包环境下优于AMR-WB。
为适应其编码方式，这里采用的打分标准使用基于48K采样的POLQA。微信电话本在好点（-88.33dBm，12.67）下，其MoS可以达到3.78，在坏点为1.93。在坏点的条件下，其
5
时延，抖动，丢包都在急剧上涨，用户感知急剧降低。而VoLTE具备QoS保障，其MOS比较稳定，无明显波动，祥见下表。
对比项目 微信电话本 VoLTE 端到端时RSRP SINR 延（POLQA） -88.33 -116.97 -89.53 -114.83 12.67 0.94 11.72 0.53 无 1151.00 255.14 227.36 7.21 28.44 8.13 5.93 抖动（ms） 丢包率（%） 0.33 4.73 0.09 0.25 最大连续丢包数（%） 2.00 无数据 3.40 2.00 控制面切换中断时延 35.62 31.31 MOS 3.78 1.93 3.86 3.89
为进一步对其微信电话本的语音MOS值进行分析，找出其能力拐点，优化人员对其RSRP的从-125dBm到-110dBm，SINR从-4到10的范围进行测试，详见下图。
微信和VoLTE的RSRP走势对比543210-125-124-123-122-121-120-119-118-117-116-115-114-113-112-111微信-MOSVoLTE-MOS1.88 2.15 1.79 1.78 1.78 1.78 1.98 1.90 1.74 1.74 1.71 1.88 1.57 1.51 2.62.92.92.92.933.33.33.43.43.53.63.63.73.7433.22 210 从RSRP走势中可以看出:在RSRP>-110dBm，SINR >10的在LTE轻载网络环境下，MOS可以保持在3.5以上。当RSRP>-111dBm的时候，语音质量会出现大幅提升，MoS会大于3.22，已经超过了GSM的MoS，其音质和VoLTE AMR-WB在感知上差异不大。
微信和VoLTE的SINR走势对比43210-5-4-3-2-101234VoLTE56789101.83 1.82 1.91 1.76 1.84 1.87 2.01 2.30 2.85 2.55 2.59 2.53 3.53.63.63.63.63.73.73.73.83.83.83.83.83.83.83.83.80 3.50 3.70 3.19 微信-MOS 从SINR走势中可以看出，其在3的时候，其质量会出现大幅提升，MoS会到2.85以上，
6
已经超过GSM的EFR的MoS，当SINR提升到9的时候，其值已经和VoLTE差距不大。
下图4个波形分为标准语料，GSM波形，VoLTE波形和微信波形。微信语音压缩方法与2G/4G不一样，微信语音对标准语料毛刺部分压缩比较干净，将标准语音样本中的背景噪声被简单给过滤掉了，故MOS峰值较低。在同样的MOS分下，用户可能会觉得微信声音更加干脆清澈。
测试标准语料
GSM语音波形
VoLTE 23.85高清语音波形
微信电话本语音波形
2、容量对比分析
微信电话本采用SLIK编码，具备VAD、DTX、FEC能力，具备不连续发射，静默期检查，前向纠错能力。微信电话本传输效率要低于VoLTE。下表为微信电话本和VoLTE在好点时候的资源占用情况。
微信电话本和VoLTE高清语音的网络好点资源占用对比
下行 类型 SINR 物理层速PDCP速平均MCS RB数 TB size物理层速PDCP速上行 MCS RB数 TBsize（bite） 1285.14 率（kbps） 率（kbps） 微信电话本 18.26 VoLTE 20.02 58.14 18.2 40.27 11.13 （bite） 率（kbps） 率（kbps） 52.76 21.82 40.33 11.21 19.77 3.28 1268.24 15.26 2.8 819.47 22.45 2.5 22.01 1.68 1086.69
微信语音每TTI调度RB数和VoLTE（23.85k）基本近似，微信没有语音静默包，每TTI调度次数明显高于VoLTE，微信语音总调度RB数明显高于VoLTE。
7
微信电话本和VoLTE高清语音的网络差点资源占用对比（下行）
类型 微信电话本 VoLTE SINR 物理层速PDCP速率传输模式 MCS 每TTI RB数 11.94 8.78 总调度RB数 910.89 227.22 TB size 率（下行） （下行） 50.48 15.61 36.23 10.44 -0.09 0.02 2.00 2.15 6.31 4.95 668.44 590.79
微信语音包走默认承载，没有RoHC功能，语音包大于VoLTE，与不打开RoHC的 VoLTE语音包相似）。RoHC功能开启对VoLTE语音包压缩参见下表。
语音 VoLTE 23.85 VoLTE 23.85（RoHC） AMR封装负荷 RTP UDP IP PDCP头 RLC头 MAC头 Total 477+21 477+21 96 64 320 40 8 8 8 8 16 16 1010 570
微信语音没有语音静默包，不具备头压缩功能，导致微信PDCP速率（40k左右）高于VoLTE（10k左右）。按好点的包大小计算，微信语音每分钟消耗流量为（40.27+40.33）*60/8=600kbyte，其通话一个小时占用流量为35Mbytes。如按移动的50元1G进行收费，其50元可以通话1700分钟左右，折合3分钱/分钟，且无长途，漫游费用，其资费优势明显。
在差点时，微信语音掉包和时延会恶化，资源占用会加大。从现网测试情况看：在-110dBm，SINR=0的情况下，会占用12个RB,资源占用增加了三倍，VoLTE占用9个RB。在资源紧张时，VoLTE有QoS保障机制，语音各项指标会远好于微信电话本。
从无线环境和微信电话本语音包大小进行走势对比，可以清楚的发现：当其无线环境好的时候，其语音包较大，语音采样编码方式越高，语音越清晰，用户感知越好。当无线环境恶化时，语音采样编码方式变差，用户感知不好。 微信电话本语音包大小与SINR关系2000 1500 1000 500 0 -6-4-202468101214161,2801,08088068048028080-128-125-122-119-116-113-109-106-103-100-90-86-83-80包大小（bite）微信电话本语音包大小与RSRP关系包大小（byte）
8
案例4：小区边缘通话时下行BLER较高导致质差
【问题现象】
统计发现，爱立信VoLTE测试的DL BLER在SINR低于-2dB后严重下降，高于10%。
【问题分析】
其他厂家多在8天线的环境下测试，而爱立信的测试结果都是在2天线的环境下测试得出，少了波束赋形的增益。
【问题解决】
在8天线的环境下，DL BLER有了较大的提高，在SINR=-6左右也没有达到10%。
【问题后续建议】
在8天线的环境下，DL BLER的指标有大幅提升，BLER控制在10%之内。厂家应针对2天线环境提出相应的算法改进，保证网络质量。
9
案例5： ZUC算法开启导致R8终端通话8S自动中断
【问题现象】
用HTC M8对在目前LTE弱覆盖或信号质量差的网络环境下的通话质量进行MOS评估时，发现通话拨打8S左右通话中断，手机进入FAST BOOT工程模式。更换站点后恢复，再回到问题站点拨打电话，分析基站侧EMIL包（EMIL为诺基亚内部用于分析基站侧log的一个工具）后发现该基站祖冲之ZUC加密算法开关打开，且ZUC算法优先级为最高。
【问题分析】
更改站点后手机通话恢复正常，可以判断为站点问题。在后台检查后发现该基站并无告警，排除由硬件故障造成的通话问题。由EMIL包中ATTACH REQUEST里UE CAPBILITY列出终端支持使用ZUC算法。（注意EEA3与EIA3的值都为1）
为确定M8在该站下是否使用ZUC算法，通话先在其他站点建立后再切换进问题站点，从切换请求中可以看出切换后进入问题站点选择的加密算法为EEA3、EIA3，且切换完成6S后手机进入FAST BOOT模式。确定问题为ZUC算法的启用导致。（下图为切换入问题站点后选择的加密算法，基站R10以前的版本是spare5， R11后改成了eea3和eia3）
由于ZUC是3GPP R9才加入的算法，故R9之前的终端并不支持ZUC算法。部分R9的终端（如HTC M8）并不完全支持在ZUC算法开启下进行所有业务。
【问题解决】
通过后台关闭ZUC算法，问题解决。
10
案例6：基站不支持VoLTE功能导致切换掉话
【问题现象】
终端无线链路失败后在PCI329上重新建立RRC连接，网络侧没有建立专用承载，5s之后网络侧发送SIP BYE 503 导致掉话。
【问题分析】
问题出现的过程如下图，当MO/MT UE在PCI 343上出现无线链路失败后，在PCI 329上进行重建，被拒绝。之后同时在PCI 329上建立RRC连接，但是网络侧并没有建立专用UM承载，RTP在AM承载上传输5s之后，MO/MT UE收到IMS发送的SIP BYE 503消息，原因是“Session released - loss of bearer”。
进一步确定站点的位置，如下图，我们可以发现PCI 329在试验区域之外，存在越区覆盖现象。该站未开启VoLTE功能。
11
【问题解决】
首先应保证测试过程中终端收到信号的所有基站均支持VoLTE功能。其次应对网络进行优化，尽量减少越区覆盖。此外，在VoLTE开通的过程中，应保证成片开通。
12
案例7：跨MME定时器超时导致切换失败率高
【问题现象】
丽水VoLTE测试区域采用新建D频段基站区域，为避免对现网影响，核心网侧采用单独的MME进行管理，与现网F频段基站分属不同的MME。测试中通过网管统计发现F频段与D频段间的S1切换成功率较低，从核心网侧信令看基站侧频繁进行S1切换请求和切换取消，见下图：
13
【问题分析】
根据核心网信令对应失败的基站ID，分析基站侧的日志文件，发现目标基站每收到一条HO REQUEST都回复了HO REQUEST ACK，没有FAILURE的消息，表明目标侧没有处理失败的；而源侧基站发送了HO REQURIED消息后，没有收到MME反馈回来的Ho Command消息，之后S1切换准备定时器超时后，源基站发起了Ho Cancel，从而导致切换失败，即切换的消息交互需要的时间较长，原因是两个基站处在不同的MME下。
14
【问题解决】
丽水VoLTE测试基站下挂在杭州MME下，与本地MME不在同一个POOL内，切换需要时间较长。为了避免定时器切换超时，可以将基站侧的S1切换准备定时器修拉长进行规避解决。
【问题后续建议】
因该类切换为跨MME切换，完成切换需交互时间变长，为了避免定时器切换超时造成切换失败，将基站侧的S1切换准备定时器调整到3s解决。
15
案例8：基站版本不同导致站间切换失败
【问题现象】
在进行室内外切换测试中，室外站为Band 38（EARFCN 37900，PCI 48），R10版本，室内站为Band40（EARFCN 38950，PCI 0），R8版本。当进行室外站至室内站切换时，出现RLF导致切换失败。
【问题分析】
如下图所示的信令，当UE驻留在PCI48（室外站）站上时，该eNB为UE配置的AntennaInfo参数为AntennaInfo-r10格式。
但是当UE切换至R8版本的PCI0（室内站）的过程中，eNB下发给UE的重配置消息中的AntennaInfo字段为AntennaInfo格式（即r8格式），而不是一个完整的配置，如下图信令：
16
UE对收到的切换命令进行检查时，发现对antennaInfo参数的配置不正确而导致切换失败，从而触发RLF。
【问题解决】
按照标准要求，在往低版本基站的切换命令中再增加一个内容为空的AntennaInfo-r10字段。
附：3GPP 36.311中如下规定此种情形。
17
案例9：跨厂家站点间切换失败
【问题现象】
在跨厂家区域做切换验证，从诺基亚到中兴切换都成功，中兴小区(PCI=29)到诺基亚小区（PCI=264），切换均失败，原因为网路侧配置错误。
【问题分析】
如下图所示的信令，当UE驻留在PCI29小区时，该eNB为UE配置的AntennaInfo参数为AntennaInfo-r10格式。
当UE切换至诺基亚小区PCI=264的时候，eNB下发给UE的重配置消息中的AntennaInfo字段为AntennaInfo格式（即r8格式），而不是一个完整的配置，如下图信令：
18
UE对收到的切换命令进行检查时，发现对antennaInfo参数的配置不正确而导致切换失败，从而触发RLF。
【问题解决】
9月中旬外场升级了基站版本。升级后用高通终端验证室内外切换均正常。
19
20
案例10：QoS配置不全导致切换失败
【问题现象】
测试发现爱立信pci440小区与pci89小区之间切换失败。
【问题分析】
复测之后回放log，发现VoLTE掉话频繁出现在pci440与pci89的两个小区切换的时候。UE在从pci440的小区往pci89的小区切换的时候，专载被释放。
检查了pci89的配置，虽然在同一个MME pool下，虽打开了VoLTE功能，但基站侧并没有做VoLTE所需的QoS配置（Multiple ERAB per user，RoHC，RLC UM等）。其中如果没有Multiple ERAB per user的话，基站侧将不会支持多个ERAB的建立，从而导致专用承载的释放。
在VoLTE站点pci440与非VoLTE站点pci89的切换过程中，由于关键的VoLTE QoS配置的缺失，造成网络侧释放专载。
【问题解决】
该站点做了VoLTE所需的QoS配置后，切换正常。
21
案例11：上行链路干扰导致VoLTE呼叫成功率低
【问题现象】
在定点测试所选择的某干扰严重基站，基站所接收到的干扰功率高达-69dBm，导致RRC连接不能正常建立，VoLTE的呼叫建立成功率仅为5%。
【问题分析】
我们分析测试log也可以看出，在此上行干扰严重的场景下，下行物理层重传比例很大，BLER非常高。
同时，由下图可以看出，由于未配置TPC Command或TPC Command=0，网络无法快速地提高PUSCH的发射功率。
22
针对干扰功率高的问题，首先排查该站点天面情况如下图，我们可以发现在移动TD-LTE站点天面的旁边存在电信FDD-LTE站点，两者天线距离较近，隔离度不够，电信Band 3 FDD-LTE的下行信号(1860 -1875MHz)对中国移动Band 39 TD-LTE的上行信号(1880 -1900MHz)存在干扰。
从TD-LTE的eNB侧统计的底噪（见下图）也可以看出，此站点存在明显的杂散干扰，与FDD频段对TDD频段的杂散干扰相吻合。
【问题解决】
建议全面排查Band 39基站上行链路的干扰水平。对于干扰严重的站点，采取相应措施，如调整天线位置，增加隔离度等。
【问题后续建议】
对于异常项目测试，修改配置未能做好记录和管理，导致影响到正常用例测试。后续将做好配置修改的记录和管理工作。
23
案例12：VoLTE终端被叫按CSFB接通
【问题现象】
在高通测试的过程中，被叫经常收到CS paging，发生CS fall back。
【问题分析】
在VoLTE普通拨测过程中，经常出现被叫CSFB的情况，如信令截图所示，收到CS paging，然后开始CSFB的流程，并不是预期的VoLTE通话。
复现问题，从IMS节点抓包分析：
24
可以看到在主叫发起invite之后，被叫回复的SIP信令100trying当中，这个通话并不被认为是VoLTE通话。再追溯原因，发现IMS在TADS查询的时候失败，继续查CSRN时返回“diameter unable to comply”，因此TADS回复的是2/3G，这个通话被认为是2/3G的通话
25
产生这个现象的原因是：
? 被叫终端设置为2/3/4G模式，因而在经过某些4G弱信号点时，会暂时重选登上
2G网络，回到4G信号好点时会自动返回4G。
? 2G回到4G的过程中，4G TAU流程会触发网络侧流程，通过HSS向HLR发起Cancel
Location清除用户原本在2G的位置信息。在GZUDC06的默认配置里，HSS以轮询方式选择HLR13、HLR14执行Cancel Location操作。由于南沙HSS13（包括HLR13）VoLTE调测并未完成，导致HSS选择HLR13进行Cancel Location时不能完全成功，用户在2G的位置信息会残留在系统中。
? 虽然该用户早已经回到4G并成功注册，上述的2G位置信息残留会导致错误的被叫
域选，因此出现了被叫CSFB的情况。
【问题解决】
该问题在调整HSS配置后解决，网络Cancel Location功能恢复正常，VoLTE被叫域选正确，不再出现CSFB呼叫。
26
案例13：不同速率自适应语音编码
【问题现象】
在RTP包的净荷中包含四个bit表达CMR(codec mode request)编码模式请求，由发送者向接受者的请求发送者编码器将来的编码速率模式，保存帧类型索引，如果是AMR，取值范围为0-7，表示8种速率模式，如果为AMR-WB，取值范围为0-8，表示9种速率。取值15意味着当前是没有指定哪个模式的请求。
【问题分析】
宽带语音编码速率自适应有两种方式：（1）终端自身触发；（2）基站侧的ECN（Explicit Congestion Notification）显示拥塞指示来触发UE修改自己的编码速率。对于ECN，在IMS SDP协商时，终端需要将其支持ECN机制的能力通知给网络。通过IP使用包头中的未使用字段来支持ECN。
IP包头中的8位的服务类型域(TOS)原先在RFC791中被定义为表明包的发送优先级，时延，吞吐量，可靠性和消耗等特征。在RFC2474中被重新定义为包含一个6位的区分服务码点(DSCP)和两个未用的位。
当UE B决定激活ECN时， UE B就在IP头ECN位打上“01”或“10”，当eNB A拥塞时，就会将ECN位设置为“11”。当UE A收到“11”的IP后，UE A就会在TCP的Ack 消息里面设置 ECN-echo标识。当 UE B收到ECN-Echo标识的ACK消息后，UE B就会降低速率。
ECN功能用于语音在TS 26.114中有描述，当发生大量丢包时，可以采用ECN功能降低包大小，需要通过CMR告知编码端，从而增加覆盖语音的覆盖。编码速率越高，语音质量越好，但是抗干扰能力越弱，所以根据信道传输状况优化编码类型，可以提供更好的话音质量。AMR在传输情况较好的情况下，更多的bit用来传送话音。增加网络容量及提升覆盖：在弱覆盖区域采用bit数目较少的编码方式可吸收更多话务提高网络容量且能保证一定的语音质量。在边缘的时候采用较少bit数目的编码方式对网络的干扰也会减少。
27
如下图所示，宽带编码速率自适应，主要是在近点采用较高的编码速率，在边缘采用较低的编码速率，Link Adaptation可以和Power Control并行，对切换也没有影响，因为执行两者的输入不同。
【问题解决】
采用自适应速率编码设置，以使得语音的容量和质量达到合理的目标。
28
案例14：终端侧Invite信令丢失导致呼叫建立过长
【问题现象】
在呼叫时延问题排查中，出现由于invite信令丢失多次重发导致时延过长现象。
【问题分析】
1、抓取UE侧的原始报文，在wireshark中通过 (sip) && (sip.Method = \过滤出所有的invite信令，发现UE侧接着发了下图标记的三条一样invite信令（包序号分别为2194、2196、2198，每条invite信令都分成了两片，第一片分别是2193、2195、2197）。在第一条invite 信令前有一个ACK信令（包序号为2192）。
对比这三条invite信令，除了IPV6头扩展头的Identification字段不一样(第一个invite信令是的Identification是0x0163,第二个是0x0164，第 三个是0x0165)，其它字段都一样。见下图：
29
对比源IP与目的IP相同invite信令，可以发现UDP的checksum字段是不一样的，同时IPV6头扩展头的Identification字段也不一样。如下图。
2、对比用户面内部抓包工具，通过invite信令字段内容对比找到了一条上图invite
30
信令所在的位置，如下截图：
包序号为350433和350436为PDCP层收到的第一片和第二片invite信令。包序号为350434为GTP层收到的invite信令的第一片,包序号为350437为GTP层收到的invite信令的第二片。包序号为350435和350438为S1口映射出来的第一片和第二片（可以根据GTP头的源端口为2152区别出来，用户面内部抓包GTP层的源端口为20020）。
查看基站侧包序号为350434的包，IPV6头扩展头的Identification字段为0x165,说明这条invite消息是UE发送的第三条invite消息。
同时对比包序为350434和UE侧2193的码流（第一片），发现两者的data是相同的。同时对比350437与UE侧2194（第二片），发现两者的data也是相同的（请注意，由于UE侧wireshare将第一片和第二拼起来了，所以第二片的data显示是全部invite 消息头部，可以从后面或者中间对码流信息），说明基站侧确实收到一个invite消息，且该消息是UE发送的最后一条invite消息。
31
同时也可以看到350439包是一条release消息，也说明确实有invite信令丢失导致承载释放。那么基站侧有没有收到另外两条invite信令呢？根据UE发送的信令顺序，UE侧在invite 信令之前发送一条ACK信令。在基站侧找到ACK信令的位置，包序号为334285和334286，也是两片。
在ACK消息（334285）和invite 消息（350433）中间查找invite消息的头部净荷（49
32
4e 56 49 54 45 20 73），找不到任何其它数据包。说明基站侧只收到了一条invite消息，其它两条都没有收到。
【问题解决】
对比基站用户面内部抓包结果与UE侧的原始报文，UE侧连着发送了三条发送了INVITE SIP信令，而基站侧只有收到一条INVITE SIP信令，另两条INVITE SIP信令在用户面内部各层都没有收到。经高通工程师反馈是芯片问题导致：INVITE SIP信令在UE的应用层到业务层的时候丢了。芯片升级到4.0版本后，INVITE SIP信令丢失问题解决。
33