VoLTE业务资料VoLTE问题案例集
- 格式：doc
- 大小：13.02 MB
- 文档页数：93
下载文档原格式
合集下载
Volte-VoLTE语音质量优化案例精编个
VoLTE语音质量优化案例1：VoLTE窄带与宽带语音质量对比【问题现象】在3GPPLTE中，VoLTE业务编码有AMR-NB窄带和AMR-WB宽带两种编码，两种编码速率具有不同的话音质量，所以又分别称为VoLTE标清语音（或VoLTE12.2kbps）和VoLTE高清语音（或VoLTE23.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个点。
AMRNB的语音带宽范围：300－3400Hz，8KHz采样。
AMRWB 的语音带宽范围：?50－7000Hz，16KHz采样。
用户可主观感受到话音比以前更加自然、舒适和易于分辨。
AMRWB与AMRNB不同之处在于AMRWB按16kHz采样，分别按频率带50~6400Hz?和6400~7000Hz进行编码。
用来降低复杂度，AMRWB将位算法集中到更重要的频率区。
低频带使用ACELP算法进行编码。
添加几个特征来达到一个高的主观质量。
线性预测（LP）算法是在每隔20ms的帧要进行一次线性预测算法，每5ms搜索一次自适应码本，这个过程是在12.8Kbs速率下进行。
高频带是在解码器端使用低带和随机激励的参数重建的,目的是调整与在声音基础上的低频有关的高频带.高频带的声频通过使用由低带LP过滤器产生的LP滤波器进行重建。
VOLTE起呼失败的案例
VOLTE起呼失败的案例1. 问题描述使用HTC M8T的VOLTE版本，升级成最新的版本–RC25、R35新版本。
升级完成后注册IMS成功，但在华为MME下无法进行VOLTE呼叫，变成了CSFB语音方案回落至2G进行通话。
2. 问题分析终端使用测试卡已注册VOLTE网络成功，进行呼叫的时候，网络侧回复503错误（SERVICE UNAVAILABLE）。
具体的SIP信令流程如下。
1、UE->NW INVITE2、NW->UE Cancel503终端发起VOLTE呼叫，且支持Silent Redial机制：当VOLTE呼叫失败后，将转成CSFB 语音方案，因此呼叫回落至2G。
而使用相同卡插入三星S6测试VOLTE呼叫，呼叫成功。
问题原因：不同VOLTE终端，采用的附着建立默认承载的方法也不同，主要有两种不同的方法：1、终端附着网络时，使用网络默认APN建立默认承载。
比如，HTC M8T。
2、终端附着网络时，使用终端侧设置的APN建立默认承载。
比如，三星S6。
3、使用终端侧设置的APN建立默认承载，按照3GPP24.301章节8.3.20.2描述，在附着络过程中，建立PDN连接请求消息如果携带“ESM information transfer flag”( ESM 信息传输标记），表示终端希望使用自己提供的APN。
三星S6使用终端侧设置的默认承载信令截图如下：1、终端在Attach request请求信令携带“ESM information transfer flag”：2、网络侧发起APN请求，ESM information request，终端通过ESM information response回复网络侧终端上设置的默认APN。
HTC M8T使用网络侧设置的默认承载信令截图如下：1、终端Attach request请求信令未携带“ESM information transfer flag”：2、网络侧发起APN请求无ESM information request：经过测试分析发现，HTC M8T，使用LTE的APN进行IMS注册期间，终端发起了3次默认承载请求，在第三次默认承载请求，PDN类型为ipv6的PDN连接请求，网络侧处理此请求时，错误地建立了IMS承载。
(4G学习)中兴VoLTE优化案例5篇经验分享
VOLTE优化案例案例1：异频重定向掉话案例【问题描述】主叫占用广州天河区鱼珠木材市场D-ZLH-3（EARFCN=38100 PCI=83CELLID=135693）小区通话时，信号强度为-101dbm左右，出现一次RRC Connection Release，导致承载拆除，引起一次主叫掉话。
【问题分析】分析测试数据，发现UE占用服务小区广州天河区鱼珠木材市场D-ZLH-3（EARFCN=38100 PCI=83CELLID=135693）在通话的过程中信号越来越差，之后上报测量报告A2事件，eNODEB 收到报告后发起异频重定向判决，下发RRC Connection Release，由异频重定向后，eNodeB 向MME发送ue context release request，mme释放专用承载。
当UE被重定向后在新的小区发起RRC连接，网络只建立了默认承载，UE发送BYE消息，导致掉话。
从地理环境上看，服务小区与UE重定向目标小区相距较远，不需配邻区关系，UE在该路段仅是偶尔测量到目标小区的信号，这种环境极容易触发异频重定向。
【解决方案】关闭异频重定向，复测问题解决，服务小区后台统计指标无异常。
【问题总结】根据拉网统计，目前该类掉话占总掉话次数的82%以上，对测试指标影响非常严重。
异频重定向触发原理：小区间没定义邻区关系，当邻区满足切换条件时，主服务小区无法切换到邻区，基站会给UE下发系统内重定向。
优化办法：通过关闭异频重定向的功能来规避该事件，除此之外，异频邻区的完善需要加大优化力度。
后续解决办法：除了做好邻区优化外，中兴将在下个版本加入基于QCI的异频重定向功能，禁止专用承载的业务发生异频重定向。
案例2：异系统重定向掉话案例【问题描述】VoLTE测试eSRVCC过程中，发现eSRVCC执行的是CCO，而不是PS切换。
而CCO对于VoLTE语音来说，必然导致掉话。
【问题分析】具体如下图所示。
全网VOLTE终呼未接通分析案例分析
终呼未接通分析基于SEQ第一拆线原因对全网终呼未接通进行分析汇总。
终呼第一拆线原因占比表：根据第一拆线原因、拆线原因、拆线网元对终呼未接通进行分析汇总：1终呼580未接通1.1VOBB用户INVITE信息不符合协议规范VOBB用户拨打苹果VOLTE用户，由于VOBB用户INVITE信息里support中不携带100rel，导致苹果，SBC不发起承载建立导致未接通详细话单信令：VOBB下发的INVITE消息里Supported里不携带100rel,正常一般携带Supported:100rel,timer,histinfo,precondition。
被叫上发的183里不携带SDP信息，正常的是会携带Session Description Protocol 信息的，导致SBC不发起承载建立。
主叫发出183到被叫6秒后没有建立承载超时后主叫UE上发580 LOCAL QOS NOT ESTABLISHED(Cause:580)导致未接通处理建议：按照协议规范升级VOBB终端，使之VOBB终端INVITE信息符合规范。
1.2三星终端和彩铃平台配合异常在发给被叫的invite和update消息中，要求被叫终端完成preconditionMedia Attribute (a): curr:qos local sendrecv| | Media Attribute Fieldname: curr| | Media Attribute Value: qos local sendrecv| | Media Attribute (a): curr:qos remote none| | Media Attribute Fieldname: curr| | Media Attribute Value: qos remote none| | Media Attribute (a): des:qos mandatory local sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory local sendrecv | | Media Attribute (a): des:qos mandatory remote sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory remote sendrecv 但在终端返回的183和update 200ok消息中，终端没有完成承载预留Media Attribute (a): curr:qos local none| | Media Attribute Fieldname: curr| | Media Attribute Value: qos local none| | Media Attribute (a): curr:qos remote sendrecv| | Media Attribute Fieldname: curr| | Media Attribute Value: qos remote sendrecv| | Media Attribute (a): des:qos mandatory local sendrecv| | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory local sendrecv| | Media Attribute (a): des:qos mandatory remote sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory remote sendrecv 现有彩铃平台SNEC82版本是在继续等待被叫发送的新的完成资源预留的UPDATE，但是一直没有新来UPDATE，超时了。
VOLTE异常事件典型案例分析
异常事件典型案例分析未接通对第四轮测试数据进行分析发现未接通常见案例如下：未接通原因分类求和项:统计次数测试软件问题 6被叫振铃未接听 2测试设备断链 4端到端问题 4TAU与QCI建立流程冲突 1TCP链路问题 1切换与QCI1建立流程冲突 1终端在2G侧无响应 1核心网问题 5TAU与切换流程冲突导致TAU失败 4同一个MME下NAS消息sequence number不连续导致承载未建立 1其他原因 3人为挂断 3终端问题 2跨TAC但未发TAU导致服务拒绝 2总计201、测试软件问题（1）11月25日网格8 被叫振铃未接听主叫号码：136******** 被叫号码：136********（Time: 13:57:00.354，Latitude: 39.92886，Lontitude: 116.52397）13:56:25.184主叫占用朝阳平房乡政府南公园西北HLG-3发起呼叫，RSRP -78 dBm，SINR 17dB，无线环境良好，13:56:27.776主叫收到网络侧转发的被叫的invite 180后，由于被叫一直没有摘机导致在13:56:47.988被叫主动挂机上报invite 603，携带原因为decline，主叫判断为未接通，被叫判断为掉话。
此处属于测试软件问题，应该予以剔除。
（2）11月19日网格55 测试设备断链主叫号码：136******** 被叫号码：136********(Time: 12:57:39.940,Latitude: 39.86454,Lontitude: 116.43406) 12:57:30.631主叫占用丰台左安门桥南HLG-5发起呼叫，RSRP -99 dBm，SINR 6dB 空口良好，由于被叫终端设备断链导致未接通，应该予以剔除。
2、端到端问题（1）11月16日网格67 QCI1与TAU流程冲突主叫号码：136******** 被叫号码：136********（Time: 13:13:21.299，Latitude: 39.92329，Lontitude: 116.41997）13:13:11.358主叫占用东城语文出版社HL-1发起呼叫，被叫于13:13:13.870上发invite 183之后，开始建立QCI1承载，UL information transfer还没有上发时发起TAU，流程冲突导致被叫主动上发invite 580，属于端到端问题，需要集团规范协议流程。
VoLTE补充业务BAIC停机后被叫接通问题案例
VoLTE补充业务BAIC停机后被叫接通问题案例【问题】在进行补充业务停机测试验证时，发现VoLTE号码与非VoLTE号码签约补充业务BAIC停机后，被叫流程结果不一致。
VoLTE主叫号码拨打被叫能够接通。
CS主叫拨打被叫不能接通。
测试场景一、VoLTE号码861390809xxx在TAS不停机，在HSS侧ACT BAIC停机；861390809xxx注册在CS；1、当VoLTE主叫拨打时，HSS通过UDR-csrn返回漫游号码能够接通；HSS收到SCCAS发起的UDR-csrn请求HSS向MSC发起Provide_roaming_Number_Req获取漫游号码，并通过UDA 消息返回给SCCAS2、当CS主叫拨打时，HSS在SRI_rsp消息中返回barringServiceActive，呼叫拒绝。
为什么测试结果不一致呢？会不会是停机方式不一样导致？测试场景二、VoLTE号码861390809xxx在TAS不停机，在HSS侧ODBIC停机；861390809xxx注册在CS；1、当VoLTE主叫拨打时，HSS仍然通过UDR-csrn返回漫游号码，仍然能够接通；HSS收到SCCAS发起的UDR-csrn请求HSS向MSC发起Provide_roaming_Number_Req获取漫游号码，并通过UDA消息返回给SCCAS特别说明：这里UDR与PRMN消息的时间顺序不对，是当UDM20.5.1.21版本的跟踪消息打印问题。
不是本案例要分析的问题。
2、当CS主叫拨打时，HSS在SRI_rsp消息中返回operatorBarring ，呼叫拒绝这说明不是ODBIC或BAIC闭锁方式的问题。
【问题原因】MSC收到请求消息后，向HLR发送SRI（Send Routing Information）。
HLR用来查询被叫用户的签约信息，查询到该被叫用户的入呼叫闭锁处于激活状态HLR向MSC返回拒绝消息，其中携带有相应的错误码Call Barred而SCC AS向融合HLR/HSS发送UDR消息，通过融合HLR/HSS获取被叫号码的CSRN号码，不会触发HLR查询号码闭锁状态。
VoLTE语音质量优化案例(14个)
VoLTE语音质量优化案例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搜索一次自适应码本，这个过程是在12.8Kbs 速率下进行。
高频带是在解码器端使用低带和随机激励的参数重建的, 目的是调整与在声音基础上的低频有关的高频带. 高频带的声频通过使用由低带LP 过滤器产生的LP 滤波器进行重建。
VoLTE常见问题及优化策略
息包含重定向的目标频点，该频点与A3测报中小区频点一致。 ➢ 分析方法 检查异频A3测报中小区是否存在于异频邻区列表中。 ➢ 优化方法 1、基站侧增加区分QCI1业务的异频重定向关闭功能； 2、对于漏配邻区进行增补。
五、常见问题分析二 异系统重定向(1/2)
➢问题现象
终端在弱场区域，基站下发盲重定向的RRC Release消息，消息中包含重定向的2G 频点列表。
➢优化方法 1）可以通过调整天线方向角和下倾角、增加天线挂高、更换更高增益天线、 增强RS功率等方法来优化覆盖 2）对于相邻基站覆盖区不交叠部分内用户较多或者不交叠部分较大时，应新 建基站，或增加周边基站的覆盖范围，使两基站覆盖交叠深度加大 3）对于凹地、山坡背面等引起的弱覆盖区可用新增基站或RRU，以延伸覆盖 范围；对于电梯井、隧道、地下车库或地下室、高大建筑物内部的信号盲区可 以利用RRU、室内分布系统、泄漏电缆、定向天线等方案来解决
五、常见问题分析三 RSRP/SINR差（1/2）
➢问题现象 终端在弱场区域，RSRP/SINR过差，导致业务中断，原因多为RTP inactivity 导致RRC Release。 ➢分析方法 查看RRC Release之前的终端测量，确定终端是否处在RSRP/SINR过差区域。
五、常见问题分析三 RSRP/SINR差（2/2）
五、常见问题分析二 异系统重定向(2/2)
➢ 优化方法 1. LTE弱覆盖：优化LTE覆盖 2. 假性弱覆盖：优化切换、重选参数 3. 终端测量B2不及时：一是高通正在验证新的芯片，新芯片支持DRX休
眠期对异频异系统进行测量，缩短测量周期；二是通过删减无用的异 频频点，减少终端测量的频点数以达到缩短测量周期的目的 4. 2G邻区配置错误：做好eSRVCC的邻区精细化规划和周期一致性核查 5. 基站功能改进： 601P02版本可针对语音业务关闭重定向功能
五、常见问题分析二 异系统重定向(1/2)
➢问题现象
终端在弱场区域，基站下发盲重定向的RRC Release消息，消息中包含重定向的2G 频点列表。
➢优化方法 1）可以通过调整天线方向角和下倾角、增加天线挂高、更换更高增益天线、 增强RS功率等方法来优化覆盖 2）对于相邻基站覆盖区不交叠部分内用户较多或者不交叠部分较大时，应新 建基站，或增加周边基站的覆盖范围，使两基站覆盖交叠深度加大 3）对于凹地、山坡背面等引起的弱覆盖区可用新增基站或RRU，以延伸覆盖 范围；对于电梯井、隧道、地下车库或地下室、高大建筑物内部的信号盲区可 以利用RRU、室内分布系统、泄漏电缆、定向天线等方案来解决
五、常见问题分析三 RSRP/SINR差（1/2）
➢问题现象 终端在弱场区域，RSRP/SINR过差，导致业务中断，原因多为RTP inactivity 导致RRC Release。 ➢分析方法 查看RRC Release之前的终端测量，确定终端是否处在RSRP/SINR过差区域。
五、常见问题分析三 RSRP/SINR差（2/2）
五、常见问题分析二 异系统重定向(2/2)
➢ 优化方法 1. LTE弱覆盖：优化LTE覆盖 2. 假性弱覆盖：优化切换、重选参数 3. 终端测量B2不及时：一是高通正在验证新的芯片，新芯片支持DRX休
眠期对异频异系统进行测量，缩短测量周期；二是通过删减无用的异 频频点，减少终端测量的频点数以达到缩短测量周期的目的 4. 2G邻区配置错误：做好eSRVCC的邻区精细化规划和周期一致性核查 5. 基站功能改进： 601P02版本可针对语音业务关闭重定向功能
5.VoLTE案例分析
落的小区根本无需做位置更新。
注：该问题正在与终端厂家沟通中….
几类人工剔除异常介绍
平台规则问题：3分钟双bye收OK回复案例
现象：呼叫满3分钟后，终端上发SIP bye后3秒又上发sip bye消息，并收到OK回复。 规则：已有网络问题发现，存在双bye后掉话的情况，因此平台算法对全部双bye问题标记为掉话。 分析：虽然出现了双bye挂断，（1）满足呼叫规则3分钟挂断且收到OK回复，（2）期间RTP包交互正常 确认应为正常挂断，sip bye消息重发。
2. 被叫振铃不接听案例 现象：被叫update交互完成后，上发振铃，未上发 OK,主叫收到振铃，18秒后上发了cancel取消。 软件：惠杰朗CDS 分析：被叫上发振铃后，按照软件设置应在1秒后立 即接听，怀疑软件触发的接听AT指令未其作用。
注：平台对掉话判断规则，在出现sip invite OK后，监测后续 的sip bye消息，若出现sip bye且收到OK则判断为正常，若无 发生下1次起呼，则以下次起呼时间作为上次掉话的时间点。。
现象/原因分类 振铃不接听
呼叫过程中主叫再次起呼或被叫异常发起寻呼 终端主动挂机
LOG信令记录丢失 SIM卡故障
说明 被叫振铃但不接听 接通状态下起呼或寻呼 起呼或接通后的立即挂断 由于软件问题导致的LOG未记录 非人为因素导致的SIM卡松动
问题判定
问题子类判定
测试软件问题 测试设备问题
丢信令
如GSM下的信令丢失，TD、LTE信令不连续则需要仔细辨认，确 认非基站闪断造成
注：VOLTE未接通触发CSFB接通，仍然统计VOLTE未接通；特别说明由于是统计规则后续可能会按照集团要求变更。
HTC M8版本升级引入silent redial功能
注：该问题正在与终端厂家沟通中….
几类人工剔除异常介绍
平台规则问题：3分钟双bye收OK回复案例
现象：呼叫满3分钟后，终端上发SIP bye后3秒又上发sip bye消息，并收到OK回复。 规则：已有网络问题发现，存在双bye后掉话的情况，因此平台算法对全部双bye问题标记为掉话。 分析：虽然出现了双bye挂断，（1）满足呼叫规则3分钟挂断且收到OK回复，（2）期间RTP包交互正常 确认应为正常挂断，sip bye消息重发。
2. 被叫振铃不接听案例 现象：被叫update交互完成后，上发振铃，未上发 OK,主叫收到振铃，18秒后上发了cancel取消。 软件：惠杰朗CDS 分析：被叫上发振铃后，按照软件设置应在1秒后立 即接听，怀疑软件触发的接听AT指令未其作用。
注：平台对掉话判断规则，在出现sip invite OK后，监测后续 的sip bye消息，若出现sip bye且收到OK则判断为正常，若无 发生下1次起呼，则以下次起呼时间作为上次掉话的时间点。。
现象/原因分类 振铃不接听
呼叫过程中主叫再次起呼或被叫异常发起寻呼 终端主动挂机
LOG信令记录丢失 SIM卡故障
说明 被叫振铃但不接听 接通状态下起呼或寻呼 起呼或接通后的立即挂断 由于软件问题导致的LOG未记录 非人为因素导致的SIM卡松动
问题判定
问题子类判定
测试软件问题 测试设备问题
丢信令
如GSM下的信令丢失，TD、LTE信令不连续则需要仔细辨认，确 认非基站闪断造成
注：VOLTE未接通触发CSFB接通，仍然统计VOLTE未接通；特别说明由于是统计规则后续可能会按照集团要求变更。
HTC M8版本升级引入silent redial功能
volte案例
1voLTE典型案例汇总1.1VoLTE未接通案例汇总VoLTE未接通问题的基本排查思路，除了配置问题，更主要的是需要核查前后的标准信令（S1+空口）以及SIP信令，特别是对于SIP信令，某条信令延时过大或是缺失都会导致VoLTE呼叫失败。
对于比较复杂的问题，需要联合核心网与终端进行端到端的问题分析。
1.1.1无线弱覆盖导致VoLTE呼叫失败【问题现象】如下图1-1所示，终端处在弱覆盖区域，导致服务小区RSRP及SINR都非常差（RSRP为-124.8dBm；SINR为-4.1），导致SIP信令交互无法完成，最后呼叫失败。
图1-1无线弱覆盖图【问题解决】对于弱覆盖区域：首先明确当前的弱覆盖区域由哪些扇区的信号覆盖。
其次，根据网络拓扑结构和无线环境确定最适合覆盖该区域的扇区、并加强它的覆盖：（1）排除主覆盖小区的硬件故障（例如：基带及射频器件故障、天馈系统驻波比告警等）（2）上调主覆盖小区的RS功率（3）上调主覆盖扇区的功率（4）调整主覆盖扇区的天线下倾角（5）调整主覆盖扇区的天线方位角（6）建议加站，比如微站BS8912，并调整周边基站天线的方位角和下倾角最后，合理优化邻区，在主服务小区信号恶化前，通过系统内切换，保证呼叫接续流程完整。
1.1.2无线干扰严重导致VoLTE呼叫失败【问题现象】下行干扰，一般表现为RSRP良好但SINR偏差，干扰严重区域容易导致未接通。
同时也会导致掉线、切换失败等各类异常事件发生。
具体如图1-2所示。
图1-2 同频同PCI干扰图【问题解决】1.查看PCI规划是否合理，如近距离同频同PCI、以及模3干扰等问题。
2.这里说明，对于上行干扰问题，需要通过检查各个小区的底噪进行判断。
如果某一小区的底噪过高，并且没有与之相当的高话务量存在，则确认存在上行干扰问题，需要分析干扰来至系统内部或是异系统，具体解决方法不在赘述。
1.1.3QCI1专载建立与切换冲突导致VoLTE呼叫失败【问题现象】主被叫UE在呼叫建立过程中，QCI1专载建立与切换几乎同时发生，QCI1专载刚刚建立完成又在切换过程中被MME释放，终端回复invite580，VoLTE呼叫未接通。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
VoLTE网上问题案例集
文档版本
V1.0
发布日期
2015-01-28
华为技术
修订记录
Date
日期
Revision Version
修订版本
CR ID
CR号
Section Number
修改章节
Change Description
修改描述
Author
作者
2015-01-22
V1.0
初稿完成
曾佳00130333
为了统一思路前后方重新整理问题和思路寻求新的突破口，正对不同终端在同一个华为站点PTH112下面验证总共得到以下3种失败场景如下：
Case1:VoLTE注册过程中网络下发401鉴权挑战消息，终端未收到；
图9：Case1网络下发鉴权挑战401终端未收到
Case2: Sony终端基于UDP的Register消息异常；
通过测试发现P7使用的SIP基于UDP承载，并且Register消息总共才1172Bytes，MTU值可通过root权限配置但是设置未生效；待进一步验证。
P7升级到测试成功，但在E///的基站下，接入失败。IMS直接回494消息，CN侧抓包如下：
如下是P7失败和sony成功（E///基站）的对比，差异如红圈出，但P7发送的也符合协议RFC3329.
3.eNodeB版本和配置以及话统分析
检查eNodeB版本：BTS3900 V100R009C00SPC160；
检查EUTRAN支持VoIP能力开关：ENodeBAlgoSwitch.EutranVoipSupportSwitch=ON；
检查小区信号质量：正常；
检查数传业务成功率：正常；
检查所有基站配置和VoLTE业务：总共6个基站PTH100/101/102/104/110/112，VoLTE均失败；
图10：Case2 Sony终端基于UDP的注册失败
Case3: Nokia终端基于TCP的Register消息异常；
图11：Case3 Nokia终端基于TCP的注册失败
根据以上3种失败场景，根据不同终端和网元节点跟踪定位分析确定如下失败模型；至此很明显最初得到的Case1所描述的失败类型是一个错误的判断，是因为Nokia和Sony终端不同的失败表现产生混淆导致：
图1：正常VoLTE用户注册流程
图2：正常VoLTE用户语音呼叫流程
图3：VoLTE业务所使用的承载方式
1.2网络拓扑分析
11.18日下午，一线实验室复测抓取了 S-PGW------P-CSCF 上的抓包。分析华为和爱立信基站下主要有如下两个差异点
1) 华为基站下注册的终端是诺基亚，爱立信基站下注册的终端型号未知。2）注册到华为的register消息是通过TCP承载，且在TCP层有分包，对端SBC回503 service unavailable，而注册到爱立信的register消息是UDP承载，无分包，对端SBC正常回复401。
Integrity Key: "71CF825E807149738C7EF51A794D7FEF"
HUAWEI，从SBC到UE
Security-Server: ipsec-3gpp;q=0.1;alg=hmac-sha-1-96;ealg=aes-cbc;prot=esp;mod=trans;spi-c=3437;spi-s=3438;port-c=6000;port-s=7000
2
2.1
案例1：
【问题描述】
英国VDF在11月15号下午反馈同一终端同一套核心网，在爱立信/诺西基站下成功打通VoLTE call，在华为基站下必然失败；
问题表现为：VoLTE终端开机后，QCI5、默认承载均可建立但无法建立QCI1导致不能通话；
【问题分析】
1.组网环境信息分析
1.1VoLTE业务原理分析
至此，发现丢包问题最终锁定在P3(SeGW-->CPN)抓包段，并且此段只会丢弃大于1490Bytes的报文；而对比友商E///网络传送的1420Bytes报文能够成功传输；最终问题锁定在SeGW和CPN网元节点。
7.UE侧问题分析
7.1华为 P7
现场使用的P7不支持VoLTE，临时升级到研发部版本但是仍然测试失败;
正常VoLTE业务流程分为以下几个过程：
a)VoLTE终端完成TAU Attach流程建立QCI5承载；
b)VoLTE终端发起IMS注册流程, 注册使用的SIP信令使用QCI5承载；
c)VoLTE终端发起语音呼叫，建立QCI1专有承载，语音媒体使用QCI1承载；
d)VoLTE终端发起视频呼叫，建立QCI2专有承载，视频媒体使用QCI2承载；
Authentication Scheme: Digest
Nonce Value: "+cF5iJzFh0c1ulqe4K+f0gqf1fC3WAAA2YG/KEDpHPQ="
Realm: ""
Algorithm: AKAv1-MD5
QOP: "auth"
Cyphering Key: "31ED1CC2BAE2905805707图7：IPSec旁路方案三
方案三实际上没有改变组网，而是将基站和安全网关的IPSECPROPOSAL的加密算法设置为NULL，验证算法不改；VoLTE业务测试结果为失败。
同时抓取路由器和安全网关两端报文，确认SIP_401消息已经从安全网关发送到基站；此时排查重点转移到基站，需要确认eNodeB是否成功转发401消息；
Huawei从IMS CORE到SBC
WWW-Authenticate: Digest nonce="+cF5iJzFh0c1ulqe4K+f0gqf1fC3WAAA2YG/KEDpHPQ=",realm="",algorithm=AKAv1-MD5,qop="auth",ck="31ED1CC2BAE29058057070437894DBC0",ik="71CF825E807149738C7EF51A794D7FEF"
至此，通过以上分析判断排除终端和核心网异常；而从P1点抓包来看也能够确认eNodeB成功转发了Register和401 Unauthorized消息。
6.诸点抓包分析
通过华为站点和E///站点对比分析，已经明确问题出现在S1接口所连接设备上面，但是由于eRAN7.0版本(部确认eRAN8.0以上版本可以)不具备SIP信令跟踪和足够的证据，来证明eNodeB成功转发SIP消息；即便我们能够证明PDCP和MAC无丢包且调度正常。
从CELL DT34看，下行都是ACK，说明空口发送QCI5数据时没有误码。
终端侧QXDM看到，QCI5的RB ID为2，该RB下行也收到了数据包，但有时这些数据包能到PDCP层，有些到不了PDCP层，但是SIP层都收不到，不确定这些数据包是否就是401消息。
4.异常问题流程分析
由于前期从英国VDF一线和罗马尼亚GTAC二线得到信息是终端收不到SIP_401消息，前后方重点都放在下行SIP_401丢失问题上，但是前面分析SeGW证实已经下发；而eNodeB eRAN7.0使用Cell DT、IFTS、话统等都无法准确判断401是否从S1和UU接口转发，现场的终端Nokia和Sony也都不具备QXDM抓包条件；问题分析未能取得突破进展。
检查话统话统来确认QCI 5是否丢包：话统正常无丢包；
Cell DT和IFTS跟踪：确认eNodeB的PDCP和MAC层无丢包且调度正常；
eNodeB跟踪CELL DT和终端侧QXDM数据分析
从Cell dt 132跟踪看，有些时候VoLTE建立的时候QCI5的下行有数据包，有些时候又没有下行数据包。
Integrity Key: "FFD4EB7997DCB64E714184274286A155"
E///，从SBC到UE
Security-Server: ipsec-3gpp;q=0.1;alg=hmac-sha-1-96;ealg=aes-cbc;prot=esp;mod=trans;spi-c=3407;spi-s=3408;port-c=6000;port-s=7000
[Security-mechanism]: ipsec-3gpp
q=0.1
alg: hmac-sha-1-96
ealg: aes-cbc
prot: esp
mod=trans
spi-c: 3407 (0x00000d4f)
spi-s: 3408 (0x00000d50)
port-c: 6000
port-s: 7000
5.友商成功数据分析
针对相同终端在IMS侧抓包，分别从E///站点和华为站点比较分析，发现E///站点和华为站点的Register和401 Unauthorized消息没有明显差异；
E///，从IMS CORE到SBC
WWW-Authenticate: Digest nonce="6TbnQHPNBhWjXau/+X5Q3CTBZv5lNwAAogwDWpz3r+Y=",realm="",algorithm=AKAv1-MD5,qop="auth",ck="673C3B94B35314C9FE03432A239BA836",ik="FFD4EB7997DCB64E714184274286A155"
此旁路方案同PTH102站点，102站点没有配置IPSec，从102站点的S1用户面地址ping SpGW地址，8000字节的报文都可以ping通，整条链路没有报文大小限制。
2.2 IPSec旁路方案二
图6：IPSec旁路方案二
文档版本
V1.0
发布日期
2015-01-28
华为技术
修订记录
Date
日期
Revision Version
修订版本
CR ID
CR号
Section Number
修改章节
Change Description
修改描述
Author
作者
2015-01-22
V1.0
初稿完成
曾佳00130333
为了统一思路前后方重新整理问题和思路寻求新的突破口，正对不同终端在同一个华为站点PTH112下面验证总共得到以下3种失败场景如下：
Case1:VoLTE注册过程中网络下发401鉴权挑战消息，终端未收到；
图9：Case1网络下发鉴权挑战401终端未收到
Case2: Sony终端基于UDP的Register消息异常；
通过测试发现P7使用的SIP基于UDP承载，并且Register消息总共才1172Bytes，MTU值可通过root权限配置但是设置未生效；待进一步验证。
P7升级到测试成功，但在E///的基站下，接入失败。IMS直接回494消息，CN侧抓包如下：
如下是P7失败和sony成功（E///基站）的对比，差异如红圈出，但P7发送的也符合协议RFC3329.
3.eNodeB版本和配置以及话统分析
检查eNodeB版本：BTS3900 V100R009C00SPC160；
检查EUTRAN支持VoIP能力开关：ENodeBAlgoSwitch.EutranVoipSupportSwitch=ON；
检查小区信号质量：正常；
检查数传业务成功率：正常；
检查所有基站配置和VoLTE业务：总共6个基站PTH100/101/102/104/110/112，VoLTE均失败；
图10：Case2 Sony终端基于UDP的注册失败
Case3: Nokia终端基于TCP的Register消息异常；
图11：Case3 Nokia终端基于TCP的注册失败
根据以上3种失败场景，根据不同终端和网元节点跟踪定位分析确定如下失败模型；至此很明显最初得到的Case1所描述的失败类型是一个错误的判断，是因为Nokia和Sony终端不同的失败表现产生混淆导致：
图1：正常VoLTE用户注册流程
图2：正常VoLTE用户语音呼叫流程
图3：VoLTE业务所使用的承载方式
1.2网络拓扑分析
11.18日下午，一线实验室复测抓取了 S-PGW------P-CSCF 上的抓包。分析华为和爱立信基站下主要有如下两个差异点
1) 华为基站下注册的终端是诺基亚，爱立信基站下注册的终端型号未知。2）注册到华为的register消息是通过TCP承载，且在TCP层有分包，对端SBC回503 service unavailable，而注册到爱立信的register消息是UDP承载，无分包，对端SBC正常回复401。
Integrity Key: "71CF825E807149738C7EF51A794D7FEF"
HUAWEI，从SBC到UE
Security-Server: ipsec-3gpp;q=0.1;alg=hmac-sha-1-96;ealg=aes-cbc;prot=esp;mod=trans;spi-c=3437;spi-s=3438;port-c=6000;port-s=7000
2
2.1
案例1：
【问题描述】
英国VDF在11月15号下午反馈同一终端同一套核心网，在爱立信/诺西基站下成功打通VoLTE call，在华为基站下必然失败；
问题表现为：VoLTE终端开机后，QCI5、默认承载均可建立但无法建立QCI1导致不能通话；
【问题分析】
1.组网环境信息分析
1.1VoLTE业务原理分析
至此，发现丢包问题最终锁定在P3(SeGW-->CPN)抓包段，并且此段只会丢弃大于1490Bytes的报文；而对比友商E///网络传送的1420Bytes报文能够成功传输；最终问题锁定在SeGW和CPN网元节点。
7.UE侧问题分析
7.1华为 P7
现场使用的P7不支持VoLTE，临时升级到研发部版本但是仍然测试失败;
正常VoLTE业务流程分为以下几个过程：
a)VoLTE终端完成TAU Attach流程建立QCI5承载；
b)VoLTE终端发起IMS注册流程, 注册使用的SIP信令使用QCI5承载；
c)VoLTE终端发起语音呼叫，建立QCI1专有承载，语音媒体使用QCI1承载；
d)VoLTE终端发起视频呼叫，建立QCI2专有承载，视频媒体使用QCI2承载；
Authentication Scheme: Digest
Nonce Value: "+cF5iJzFh0c1ulqe4K+f0gqf1fC3WAAA2YG/KEDpHPQ="
Realm: ""
Algorithm: AKAv1-MD5
QOP: "auth"
Cyphering Key: "31ED1CC2BAE2905805707图7：IPSec旁路方案三
方案三实际上没有改变组网，而是将基站和安全网关的IPSECPROPOSAL的加密算法设置为NULL，验证算法不改；VoLTE业务测试结果为失败。
同时抓取路由器和安全网关两端报文，确认SIP_401消息已经从安全网关发送到基站；此时排查重点转移到基站，需要确认eNodeB是否成功转发401消息；
Huawei从IMS CORE到SBC
WWW-Authenticate: Digest nonce="+cF5iJzFh0c1ulqe4K+f0gqf1fC3WAAA2YG/KEDpHPQ=",realm="",algorithm=AKAv1-MD5,qop="auth",ck="31ED1CC2BAE29058057070437894DBC0",ik="71CF825E807149738C7EF51A794D7FEF"
至此，通过以上分析判断排除终端和核心网异常；而从P1点抓包来看也能够确认eNodeB成功转发了Register和401 Unauthorized消息。
6.诸点抓包分析
通过华为站点和E///站点对比分析，已经明确问题出现在S1接口所连接设备上面，但是由于eRAN7.0版本(部确认eRAN8.0以上版本可以)不具备SIP信令跟踪和足够的证据，来证明eNodeB成功转发SIP消息；即便我们能够证明PDCP和MAC无丢包且调度正常。
从CELL DT34看，下行都是ACK，说明空口发送QCI5数据时没有误码。
终端侧QXDM看到，QCI5的RB ID为2，该RB下行也收到了数据包，但有时这些数据包能到PDCP层，有些到不了PDCP层，但是SIP层都收不到，不确定这些数据包是否就是401消息。
4.异常问题流程分析
由于前期从英国VDF一线和罗马尼亚GTAC二线得到信息是终端收不到SIP_401消息，前后方重点都放在下行SIP_401丢失问题上，但是前面分析SeGW证实已经下发；而eNodeB eRAN7.0使用Cell DT、IFTS、话统等都无法准确判断401是否从S1和UU接口转发，现场的终端Nokia和Sony也都不具备QXDM抓包条件；问题分析未能取得突破进展。
检查话统话统来确认QCI 5是否丢包：话统正常无丢包；
Cell DT和IFTS跟踪：确认eNodeB的PDCP和MAC层无丢包且调度正常；
eNodeB跟踪CELL DT和终端侧QXDM数据分析
从Cell dt 132跟踪看，有些时候VoLTE建立的时候QCI5的下行有数据包，有些时候又没有下行数据包。
Integrity Key: "FFD4EB7997DCB64E714184274286A155"
E///，从SBC到UE
Security-Server: ipsec-3gpp;q=0.1;alg=hmac-sha-1-96;ealg=aes-cbc;prot=esp;mod=trans;spi-c=3407;spi-s=3408;port-c=6000;port-s=7000
[Security-mechanism]: ipsec-3gpp
q=0.1
alg: hmac-sha-1-96
ealg: aes-cbc
prot: esp
mod=trans
spi-c: 3407 (0x00000d4f)
spi-s: 3408 (0x00000d50)
port-c: 6000
port-s: 7000
5.友商成功数据分析
针对相同终端在IMS侧抓包，分别从E///站点和华为站点比较分析，发现E///站点和华为站点的Register和401 Unauthorized消息没有明显差异；
E///，从IMS CORE到SBC
WWW-Authenticate: Digest nonce="6TbnQHPNBhWjXau/+X5Q3CTBZv5lNwAAogwDWpz3r+Y=",realm="",algorithm=AKAv1-MD5,qop="auth",ck="673C3B94B35314C9FE03432A239BA836",ik="FFD4EB7997DCB64E714184274286A155"
此旁路方案同PTH102站点，102站点没有配置IPSec，从102站点的S1用户面地址ping SpGW地址，8000字节的报文都可以ping通，整条链路没有报文大小限制。
2.2 IPSec旁路方案二
图6：IPSec旁路方案二