VoLTE业务资料VoLTE问题案例集
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
为了统一思路前后方重新整理问题和思路寻求新的突破口，正对不同终端在同一个华为站点PTH112下面验证总共得到以下3种失败场景如下：
Case1:VoLTE注册过程中网络下发401鉴权挑战消息，终端未收到；
图9：Case1网络下发鉴权挑战401终端未收到
Case2: Sony终端基于UDP的Register消息异常；
通过多次抓包和定点分析最终确定网络拓扑图如下：
图4：英国VDF实验室组网图B
2.分段隔离分析
针对现场所有华为站点分析，现场总共有6个华为站点PTH100/101/102/104/110/112，而发现在华为PTH102站点(未配置IPSEC)进行测试，VoLTE业务有大概率60%左右成功率(剩余40%失败主要和核心网相关)，当时已经怀疑和IP SEC隧道(SeGW节点)强相关。
3.eNodeB版本和配置以及话统分析
检查eNodeB版本：BTS3900 V100R009C00SPC160；
检查EUTRAN支持VoIP能力开关：ENodeBAlgoSwitch.EutranVoipSupportSwitch=ON；
检查小区信号质量：正常；
检查数传业务成功率：正常；
检查所有基站配置和VoLTE业务：总共6个基站PTH100/101/102/104/110/112，VoLTE均失败；
图1：正常VoLTE用户注册流程
图2：正常VoLwk.baidu.comE用户语音呼叫流程
图3：VoLTE业务所使用的承载方式
1.2网络拓扑分析
11.18日下午，一线实验室复测抓取了 S-PGW------P-CSCF 上的抓包。分析华为和爱立信基站下主要有如下两个差异点
1) 华为基站下注册的终端是诺基亚，爱立信基站下注册的终端型号未知。2）注册到华为的register消息是通过TCP承载，且在TCP层有分包，对端SBC回503 service unavailable，而注册到爱立信的register消息是UDP承载，无分包，对端SBC正常回复401。
[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
2.3 IPSec旁路方案三
图7：IPSec旁路方案三
方案三实际上没有改变组网，而是将基站和安全网关的IPSECPROPOSAL的加密算法设置为NULL，验证算法不改；VoLTE业务测试结果为失败。
同时抓取路由器和安全网关两端报文，确认SIP_401消息已经从安全网关发送到基站；此时排查重点转移到基站，需要确认eNodeB是否成功转发401消息；
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
根据现场组网信息启动网络逐点抓包隔离异常网元，开始尝试Ping不同大小报文并且抓包分析结果如下：
对Nokia和Sony两款终端异常场景抓包分析发现P3段会丢弃大于1500Bytes的报文，统计数据结果如下：
同时对Nokia和Sony两款终端在友商E///抓包分析发现报文在P3段传输固定为1420Bytes的报文，统计数据结果如下：
VoLTE网上问题案例集
文档版本
V1.0
发布日期
2015-01-28
华为技术
修订记录
Date
日期
Revision Version
修订版本
CR ID
CR号
Section Number
修改章节
Change Description
修改描述
Author
作者
2015-01-22
V1.0
初稿完成
曾佳00130333
Huawei从IMS CORE到SBC
WWW-Authenticate: Digest nonce="+cF5iJzFh0c1ulqe4K+f0gqf1fC3WAAA2YG/KEDpHPQ=",realm="ims.vodafone.co.uk",algorithm=AKAv1-MD5,qop="auth",ck="31ED1CC2BAE29058057070437894DBC0",ik="71CF825E807149738C7EF51A794D7FEF"
至此，发现丢包问题最终锁定在P3(SeGW-->CPN)抓包段，并且此段只会丢弃大于1490Bytes的报文；而对比友商E///网络传送的1420Bytes报文能够成功传输；最终问题锁定在SeGW和CPN网元节点。
7.UE侧问题分析
7.1华为 P7
现场使用的P7不支持VoLTE，临时升级到研发部版本但是仍然测试失败;
图10：Case2 Sony终端基于UDP的注册失败
Case3: Nokia终端基于TCP的Register消息异常；
图11：Case3 Nokia终端基于TCP的注册失败
根据以上3种失败场景，根据不同终端和网元节点跟踪定位分析确定如下失败模型；至此很明显最初得到的Case1所描述的失败类型是一个错误的判断，是因为Nokia和Sony终端不同的失败表现产生混淆导致：
通过测试发现P7使用的SIP基于UDP承载，并且Register消息总共才1172Bytes，MTU值可通过root权限配置但是设置未生效；待进一步验证。
P7升级到测试成功，但在E///的基站下，接入失败。IMS直接回494消息，CN侧抓包如下：
如下是P7失败和sony成功（E///基站）的对比，差异如红圈出，但P7发送的也符合协议RFC3329.
正常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: "ims.vodafone.co.uk"
Algorithm: AKAv1-MD5
QOP: "auth"
Cyphering Key: "31ED1CC2BAE29058057070437894DBC0"
检查话统话统来确认QCI 5是否丢包：话统正常无丢包；
Cell DT和IFTS跟踪：确认eNodeB的PDCP和MAC层无丢包且调度正常；
eNodeB跟踪CELL DT和终端侧QXDM数据分析
从Cell dt 132跟踪看，有些时候VoLTE建立的时候QCI5的下行有数据包，有些时候又没有下行数据包。
至此，通过以上分析判断排除终端和核心网异常；而从P1点抓包来看也能够确认eNodeB成功转发了Register和401 Unauthorized消息。
6.诸点抓包分析
通过华为站点和E///站点对比分析，已经明确问题出现在S1接口所连接设备上面，但是由于eRAN7.0版本(部确认eRAN8.0以上版本可以)不具备SIP信令跟踪和足够的证据，来证明eNodeB成功转发SIP消息；即便我们能够证明PDCP和MAC无丢包且调度正常。
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
进一步锁定在PTH112站点(配置IPSEC)分析，通过修改S1接口上链路，尝试旁路CPN和SeGW，并且修改IPSec加密算法为空加密等方案后，发现VoLTE业务均能建立成功，最终问题隔离到和IPSEC相关。
2.1 IPSec旁路方案一
图5：IPSec旁路方案一
安全网关SeGW旁路之后，基站配置不变，基站的下一跳地址配置到跟SGE比较靠近的路由器上，基站直接拉线到该路由器；VoLTE业务测试结果为OK。
2
2.1
案例1：
【问题描述】
英国VDF在11月15号下午反馈同一终端同一套核心网，在爱立信/诺西基站下成功打通VoLTE call，在华为基站下必然失败；
问题表现为：VoLTE终端开机后，QCI5、默认承载均可建立但无法建立QCI1导致不能通话；
【问题分析】
1.组网环境信息分析
1.1VoLTE业务原理分析
从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抓包条件；问题分析未能取得突破进展。
此旁路方案同PTH102站点，102站点没有配置IPSec，从102站点的S1用户面地址ping SpGW地址，8000字节的报文都可以ping通，整条链路没有报文大小限制。
2.2 IPSec旁路方案二
图6：IPSec旁路方案二
相对于方案一，方案二直接把在连接安全网关SeGW两端的路由器互联，基站配置不变；VoLTE业务测试结果为OK。
1
本文根据以往网上问题整理VoLTE相关问题的相关案例，在处理网上语音问题时，可以先翻阅本文相关案例，以拓展思路并缩小问题围，最终提升问题定位效率。
本文所包含案例包括从各产品收集到的历史案例，以及GTAC VoLTE专题组启动后处理的问题提取出来的案例，在案例格式上有些差异，后续逐步统一。
本文档会逐步完善，新需求或建议，请联系曾佳 00130333。
Authentication Scheme: Digest
Nonce Value: "6TbnQHPNBhWjXau/+X5Q3CTBZv5lNwAAogwDWpz3r+Y="
Realm: "ims.vodafone.co.uk"
Algorithm: AKAv1-MD5
QOP: "auth"
Cyphering Key: "673C3B94B35314C9FE03432A239BA836"
[Security-mechanism]: ipsec-3gpp
q=0.1
alg: hmac-sha-1-96
ealg: aes-cbc
prot: esp
mod=trans
spi-c: 3437 (0x00000d6d)
spi-s: 3438 (0x00000d6e)
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="ims.vodafone.co.uk",algorithm=AKAv1-MD5,qop="auth",ck="673C3B94B35314C9FE03432A239BA836",ik="FFD4EB7997DCB64E714184274286A155"
Case1:VoLTE注册过程中网络下发401鉴权挑战消息，终端未收到；
图9：Case1网络下发鉴权挑战401终端未收到
Case2: Sony终端基于UDP的Register消息异常；
通过多次抓包和定点分析最终确定网络拓扑图如下：
图4：英国VDF实验室组网图B
2.分段隔离分析
针对现场所有华为站点分析，现场总共有6个华为站点PTH100/101/102/104/110/112，而发现在华为PTH102站点(未配置IPSEC)进行测试，VoLTE业务有大概率60%左右成功率(剩余40%失败主要和核心网相关)，当时已经怀疑和IP SEC隧道(SeGW节点)强相关。
3.eNodeB版本和配置以及话统分析
检查eNodeB版本：BTS3900 V100R009C00SPC160；
检查EUTRAN支持VoIP能力开关：ENodeBAlgoSwitch.EutranVoipSupportSwitch=ON；
检查小区信号质量：正常；
检查数传业务成功率：正常；
检查所有基站配置和VoLTE业务：总共6个基站PTH100/101/102/104/110/112，VoLTE均失败；
图1：正常VoLTE用户注册流程
图2：正常VoLwk.baidu.comE用户语音呼叫流程
图3：VoLTE业务所使用的承载方式
1.2网络拓扑分析
11.18日下午，一线实验室复测抓取了 S-PGW------P-CSCF 上的抓包。分析华为和爱立信基站下主要有如下两个差异点
1) 华为基站下注册的终端是诺基亚，爱立信基站下注册的终端型号未知。2）注册到华为的register消息是通过TCP承载，且在TCP层有分包，对端SBC回503 service unavailable，而注册到爱立信的register消息是UDP承载，无分包，对端SBC正常回复401。
[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
2.3 IPSec旁路方案三
图7：IPSec旁路方案三
方案三实际上没有改变组网，而是将基站和安全网关的IPSECPROPOSAL的加密算法设置为NULL，验证算法不改；VoLTE业务测试结果为失败。
同时抓取路由器和安全网关两端报文，确认SIP_401消息已经从安全网关发送到基站；此时排查重点转移到基站，需要确认eNodeB是否成功转发401消息；
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
根据现场组网信息启动网络逐点抓包隔离异常网元，开始尝试Ping不同大小报文并且抓包分析结果如下：
对Nokia和Sony两款终端异常场景抓包分析发现P3段会丢弃大于1500Bytes的报文，统计数据结果如下：
同时对Nokia和Sony两款终端在友商E///抓包分析发现报文在P3段传输固定为1420Bytes的报文，统计数据结果如下：
VoLTE网上问题案例集
文档版本
V1.0
发布日期
2015-01-28
华为技术
修订记录
Date
日期
Revision Version
修订版本
CR ID
CR号
Section Number
修改章节
Change Description
修改描述
Author
作者
2015-01-22
V1.0
初稿完成
曾佳00130333
Huawei从IMS CORE到SBC
WWW-Authenticate: Digest nonce="+cF5iJzFh0c1ulqe4K+f0gqf1fC3WAAA2YG/KEDpHPQ=",realm="ims.vodafone.co.uk",algorithm=AKAv1-MD5,qop="auth",ck="31ED1CC2BAE29058057070437894DBC0",ik="71CF825E807149738C7EF51A794D7FEF"
至此，发现丢包问题最终锁定在P3(SeGW-->CPN)抓包段，并且此段只会丢弃大于1490Bytes的报文；而对比友商E///网络传送的1420Bytes报文能够成功传输；最终问题锁定在SeGW和CPN网元节点。
7.UE侧问题分析
7.1华为 P7
现场使用的P7不支持VoLTE，临时升级到研发部版本但是仍然测试失败;
图10：Case2 Sony终端基于UDP的注册失败
Case3: Nokia终端基于TCP的Register消息异常；
图11：Case3 Nokia终端基于TCP的注册失败
根据以上3种失败场景，根据不同终端和网元节点跟踪定位分析确定如下失败模型；至此很明显最初得到的Case1所描述的失败类型是一个错误的判断，是因为Nokia和Sony终端不同的失败表现产生混淆导致：
通过测试发现P7使用的SIP基于UDP承载，并且Register消息总共才1172Bytes，MTU值可通过root权限配置但是设置未生效；待进一步验证。
P7升级到测试成功，但在E///的基站下，接入失败。IMS直接回494消息，CN侧抓包如下：
如下是P7失败和sony成功（E///基站）的对比，差异如红圈出，但P7发送的也符合协议RFC3329.
正常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: "ims.vodafone.co.uk"
Algorithm: AKAv1-MD5
QOP: "auth"
Cyphering Key: "31ED1CC2BAE29058057070437894DBC0"
检查话统话统来确认QCI 5是否丢包：话统正常无丢包；
Cell DT和IFTS跟踪：确认eNodeB的PDCP和MAC层无丢包且调度正常；
eNodeB跟踪CELL DT和终端侧QXDM数据分析
从Cell dt 132跟踪看，有些时候VoLTE建立的时候QCI5的下行有数据包，有些时候又没有下行数据包。
至此，通过以上分析判断排除终端和核心网异常；而从P1点抓包来看也能够确认eNodeB成功转发了Register和401 Unauthorized消息。
6.诸点抓包分析
通过华为站点和E///站点对比分析，已经明确问题出现在S1接口所连接设备上面，但是由于eRAN7.0版本(部确认eRAN8.0以上版本可以)不具备SIP信令跟踪和足够的证据，来证明eNodeB成功转发SIP消息；即便我们能够证明PDCP和MAC无丢包且调度正常。
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
进一步锁定在PTH112站点(配置IPSEC)分析，通过修改S1接口上链路，尝试旁路CPN和SeGW，并且修改IPSec加密算法为空加密等方案后，发现VoLTE业务均能建立成功，最终问题隔离到和IPSEC相关。
2.1 IPSec旁路方案一
图5：IPSec旁路方案一
安全网关SeGW旁路之后，基站配置不变，基站的下一跳地址配置到跟SGE比较靠近的路由器上，基站直接拉线到该路由器；VoLTE业务测试结果为OK。
2
2.1
案例1：
【问题描述】
英国VDF在11月15号下午反馈同一终端同一套核心网，在爱立信/诺西基站下成功打通VoLTE call，在华为基站下必然失败；
问题表现为：VoLTE终端开机后，QCI5、默认承载均可建立但无法建立QCI1导致不能通话；
【问题分析】
1.组网环境信息分析
1.1VoLTE业务原理分析
从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抓包条件；问题分析未能取得突破进展。
此旁路方案同PTH102站点，102站点没有配置IPSec，从102站点的S1用户面地址ping SpGW地址，8000字节的报文都可以ping通，整条链路没有报文大小限制。
2.2 IPSec旁路方案二
图6：IPSec旁路方案二
相对于方案一，方案二直接把在连接安全网关SeGW两端的路由器互联，基站配置不变；VoLTE业务测试结果为OK。
1
本文根据以往网上问题整理VoLTE相关问题的相关案例，在处理网上语音问题时，可以先翻阅本文相关案例，以拓展思路并缩小问题围，最终提升问题定位效率。
本文所包含案例包括从各产品收集到的历史案例，以及GTAC VoLTE专题组启动后处理的问题提取出来的案例，在案例格式上有些差异，后续逐步统一。
本文档会逐步完善，新需求或建议，请联系曾佳 00130333。
Authentication Scheme: Digest
Nonce Value: "6TbnQHPNBhWjXau/+X5Q3CTBZv5lNwAAogwDWpz3r+Y="
Realm: "ims.vodafone.co.uk"
Algorithm: AKAv1-MD5
QOP: "auth"
Cyphering Key: "673C3B94B35314C9FE03432A239BA836"
[Security-mechanism]: ipsec-3gpp
q=0.1
alg: hmac-sha-1-96
ealg: aes-cbc
prot: esp
mod=trans
spi-c: 3437 (0x00000d6d)
spi-s: 3438 (0x00000d6e)
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="ims.vodafone.co.uk",algorithm=AKAv1-MD5,qop="auth",ck="673C3B94B35314C9FE03432A239BA836",ik="FFD4EB7997DCB64E714184274286A155"