网站大量收购闲置独家精品文档,联系QQ:2885784924

终端案例-华为核心网MGW缺陷导致 HTC Z710t 终端呼叫异常.doc

终端案例-华为核心网MGW缺陷导致 HTC Z710t 终端呼叫异常.doc

  1. 1、本文档共4页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
终端案例-华为核心网MGW缺陷导致 HTC Z710t 终端呼叫异常

主题:HTC G3终端Z710t终端问题导致主呼异常 作者: 邮箱: 所在省:河南 关键字:呼叫异常;RAB;二次指派 专业:无线,TD无线网 设备类型:RNC 设备型号:R8 软件版本:R8C3SPH130 流程图: 故障描述: 2012年5月16日鲁山县移动公司反馈在5月15日RNC版本升级后HTC Z710t手机无法正常拨打电话,5月17日,通过对反馈地点现场测试,发现HTC Z710t手机在做主叫时,且主被叫均在普天RNC03TD网络下,被叫振铃后2-3s,此次通话就会结束,被叫手机显示一次未接来电。 故障诊断: 一、硬件故障和告警排查 首先查询该站点硬件是否正常运行,查看是否掉电、传输问题或操作维护链路配置错误等,导致查询不到问题站点的状态; 查询站点是否存在告警(当前告警、历史告警),导致该站点出现问题; 查询载波状态是否为故障不可用; 通过以上排查,均不存在硬件故障和告警。 二、无线环境排查 针对普天RNC03区域进行扫频测试,测试区域底噪保持正常,无干扰源存在; 从话统上提取UPPCH来看,RNC03区域UPPCH时隙干扰平均为-102dbm左右; 通过测试终端针对问题发生地区进行现场测试,LC8142在测试区域内接收电平良好,无明显波动。 通过上述排查,排除无线环境导致未接通。 三、终端测试 通过选取多种商务终端及测试终端,如:三星9108、中兴U880等进行全网海量拨测,各测试终端接收电平无明显波动,通话质量良好,同时发现该异常现象仅存在于HTC Z710t此款终端,且发生主叫异常问题网络单一,需满足Z710t主被叫需同时驻留在普天RNC03区域内的TD网络上。 通过上述排查,初步定位为终端问题。 四、信令分析 根据终端拨打测试中问题复现的情况,针对Z710t终端进行正常区域及异常区域拨打测试,并进行RCT信令跟踪,经初步分析在普天RNC03下终端起呼过程中,核心网在第一次RAB建立完成响应后400ms,再次下发了RAB指派,此次指派失败,而RNC04区域下的RAB二次指派均正常,对比如下: 通过上述信令分析发现,核心网在收到RAB请求后,均对测试终端下发两次RAB指派,经协议规定,主被叫在不同RNC或MSC下核心网仅需一次指派RAB即可,若在同一RNC下则需两次RAB指派,且第一次RAB指派默认通过,故通过进一步分析发现Z710t主叫终端上发语音编码方式为AMR2,而被叫手机发送语音编码方式为AMR,因编码方式请求不同导致核心网进行二次RAB指派,在RNC03下第二次RAB指派失败导致主叫呼叫异常,但此终端在普天RNC04下可正常进行语音主叫业务。 针对上述情况,通过抓取RNC的相应板卡Log进行进一步深入分析,同时对IU接口用户面信令进行过滤,并对指派失败信令进行原因提取,信令详情如下: 经分析发现,在相同RAB修改流程下,RNC发起IUUP重新初始化,该终端在普天RNC03的第二次RAB指派中IUUPModifyRsp失败的原因为3056,而该原因值译码为RNC用户面等待核心网响应超时。 对此,协调核心网方面在RNC与UMG之间进行相关信息抓包处理,并根据时间点进行不同区域IUUP报文匹配发现,在不同区域下,Z710t终端IUUP交互信息中RTP层PT值均为127,详情如下: PT(Payload type)是RTP报文头中的一个字段,用于表明不同RTP报文的类型,比如普通语音报文,2833音频报文等,而PT分为静态和动态两类:静态PT取值范围为0-95,动态PT取值范围为96-127,动态PT没有同编解码的对应关系,可由设备之间协商任意使用,经过分析RFC 3551协议中针对每一个静态PT值,规定了对应的编解码类型。 故结合上述情况,对故障场景做出如下判定: 一般情况下,核心网只会进行一次RAB指派,但由于HTCZ710T语音编码方式为AMR2,与大多数手机语音编码方式不同,所以当核心网发现主被叫编码方式不一致时,需要对主叫进行二次RAB指派。由于普天RNC的IUUP使用相同的RTP PT值填写RTP报文,当只需要一次IUUP初始化时,不存在问题。但当需要两次RAB建立,即两次IUUP初始化时,就会存在问题。 华为核心网在第一次呼叫RAB指派时, RNC和UMG之间UP协商完成后,HRU上会将2833报文的PT值默认配置为127,当后续再收到PT=127的报文,则会当成2833报文处理。一次RAB指派通过,当二次指配时,RNC侧再次发送PT=127的UP初始化报文,UMG会将其当做2833报文,而无法正常回复UP初始化响应报文,进而导致UP协商超时,呼叫失败。 若硬件为HRD时无此问题,HRD单板能够判断接收到的报文是否是UP报文,如果是UP报文则不校验PT头,能够正常响应UP报文,因此RN

您可能关注的文档

文档评论(0)

153****9595 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档