典型案例分析-珠海分公司关于WCDMA编码协商优化.docVIP

典型案例分析 --珠海业务区WCDMA编码协商优化 中国联通珠海市分公司 赵涛 左年刚 问题简述 现网华为软交换端局，某用户反映当其使用Nokia N81终端做被叫时，主叫用户终端显示呼叫失败；模拟了用户的呼叫，发现只有当主被叫用户都登陆3G网，且问题终端手动网络模式选择仅UMTS时做语音被叫时有此问题；针对该情况，重点对用户被叫进行反复模拟测试，结果如下： 1.当被叫用户用诺基亚N81手机强制选择UMTS登录3G网时，中国移动、中国电信用户做主叫呼叫正常，联通2G用户做主叫呼叫正常，而联通3G用户作为主叫则呼叫失败；当被叫用户登录2G网时，所有被叫正常； 2.当用户用诺基亚N81选择自动模式登陆3G网络时，所有主被叫业务正常； 3.当用户更换为三星SGH-G808E手机采用强制或自动模式登录3G网时，被叫业务正常。 发生时间和地点 2009年7月，珠海业务区华为MSFOTX3000软交换端局3G网络出现该问题，无线侧RNC设备机型为爱立信。 原因分析 从测试情况分析，初步判定因被叫手机上报给网络的消息有问题导致呼叫失败，比较同样在3G网下呼叫的失败和成功两种信令流程： 被叫用户用诺基亚N81手机登录3G网，主叫用户用三星SGH-G808E手机登陆3G，被叫失败消息，见图一： 图一 被叫用户用SGH-G808E手机登陆3G网，主叫用户用诺基亚N81手机登陆3G网，被叫成功消息，见图二： 图二 比较后发现呼叫失败时交换机对IU-cs口主叫进行了两次指配，当第二次指配时RNC回“invalid-rab-parameters-combination”原因值。 被叫失败时，主叫set up携带的编解码如图三，其中40指的是支持UMTS_AMR2编码： 图三 而被叫侧手机在CALL CONFIRMED中没有携带支持的编解码信元，此时，核心网侧使用默认的UMTS_AMR编码，此时主被叫侧使用的编解码方式不一致，软交换MSOFTX3000将进行第二次指配，将主叫侧的编解码修改为UMTS_AMR，见图四： 图四 RNC在指配响应中回了“invalid-rab-parameters-combination”的失败原因值，见图五： 图五很显然是由于编解码不一致引起二次指配修改主叫编解码，而RNC回复失败消息导致呼叫失败。 解决方案 在UMTS中，编码器对语音进行压缩，以充分利用空中接口和传输网络的带宽资源。对于AMR（Adaptive Multi Rate）编码，最大编码速率为12.2kbit/s,固定传输网络中的传输速率为64kbit/s,为实现信号的处理，必须通过码变换器的处理。但是，语音编码的码变换操作显著降低语音质量。在UE和网络都支持相同类型编码类型的Mobile—Mobile呼叫情况下，如果不采用码变换器，则可以提高语音质量。并且，在CN(Core Network)内部和CN—CN接口间传输压缩信息，也可以节省带宽。 对于UMTS，R4版本后都支持TrFO（Transcoder Free Operation）特性，是通过带外信令Codec协商流程来实现。可通过MSC SERVER之间的信令进行协商，使得网络可以在呼叫建立前就对Codec的类型和模式进行协商，经协商后，移动用户之间的呼叫可以完全不经过编解码器，从而提高语音质量。因为采用的是带外的协商机制，所以TrFO不需要TC资源，从而节省了昂贵的TC资源及其带来的功耗。TrFO的另一优点是分组承载中使用时可以节省网络带宽，因为语音可以以AMR 12.2kbps的速率在核心网中传输。TrFO是使用ATM或IP承载的R4网络特有的技术。 华为MSOFTX3000支持3G到3G的局内呼叫的Codec协商过程；支持2G始发BICC出局和BICC入局2G终结呼叫的Codec协商过程；支持3G始发BICC出局和BICC入局3G终结呼叫的Codec协商过程。这些Codec协商流程，均需要Lisence支持TrFO，如果是局间呼叫还需要BICC局向支持TrFO。现网MSC SERVER之间没有开通BICC，LICENSE支持TrFO功能。因此现网只存在局内的Codec协商过程。3G主叫和被叫所使用的CodecList都是根据MGW、RNC、UE三者的Codec能力取交集获取，然后被叫选择的CodecList再与主叫选择到的CodecList取交集获取呼叫选择到的CodecList。同时若主叫手机支持AMR和AMR2，则主叫侧建立承载时优选AMR2。 我们模拟了多次呼叫来跟踪编解码情况，局内呼叫测试结果如下表