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

利用信令手段挖掘信隐患提升运营商服务质量.doc

利用信令手段挖掘信隐患提升运营商服务质量.doc

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

利用信令手段挖掘通信隐患提升运营商服务质量 摘要:随着通信行业竞争的加剧,手机终端功能、服务类别的不断增多,人们对通信服务的质量要求越来越高,客户在选择运营商时,参考标准不仅仅局限于话费价格、单纯的话音质量,客户更注重的是使用过程中的感知,在遇到问题的时候能否及时有效地给予服务和解决。本文通过介绍运营商从网络侧利用信令手段对严重影响用户感知的案例分析过程,证明移动全网信令排查的有效性,阐述了这一新型全网排查手段对运营商提升用户感知、提高满意度的重要意义。 关键词: 位置更新,插入用户数据,信令流程,呼转号码、用户感知、满意度 中图分类号:s972文献标识码: a 文章编号: 一、 引言 随着移动用户数量的不断增多,服务要求的不断提高,移动网络不断的建设扩容,网络架构变得越来越复杂。在网络建设的大潮中,基于安全和其他各种原因,不可避免的会出现不同厂商设备共存的局面,由于各个厂商对标准协议的一些可选或没明确的地方理解上的不一致,往往会出现一些设备间兼容性地问题,通常这种情况在同一城市比较容易发现,但在城市之间设备混搭网络的兼容性问题却是关注的盲点,相对比较隐蔽,不容易发现。 对于设备混搭的兼容性隐患问题,通过对各种信令的失败原因分析、信令消息的解码、用户数据的检查、厂商软件功能块设置的查看、标准协议的解读等方面能一层层地抽丝剥茧深入分析问题产生的真实原因,从而能有针对性的提出网络改善建议,有效提高用户感知、提升用户满意度。 二、 通过信令主动挖掘问题 信令分析手段是目前运营商越来越重视的隐患排查手段,信令手段不但能有效地分析处理用户投诉,而且能先于用户投诉之前主动发现问题,及时查漏补缺,为提高用户感知和服务满意度提供了强有力的技术保证,同时也是有效的网络隐患监控利器。 在深圳大运保障的隐患排查项目中,我们通过对一个pool网络多接口的信令采集(mc口、c口等)数据分析,发现部分福建、贵州、河南省份的用户漫游到深圳爱立信设备网络下时,用户一直无法登记网络,位置更新一直失败,无法做主被叫,但这些用户只要离开深圳,回到当地即可作正常网络登记,同时主被叫正常。此类问题严重影响了用户的使用感知,让用户对运营商网络的满意度大大降低,因此分析解决问题尤显重要。 三、 故障原因分析 为深入分析用户漫游到深圳做位置更新失败的原因,我们详细分析map位置更新的信令流程,以找出位置更新失败的原因。 其中该类故障问题的位置更新信令流程模型如下: 从流程可以看出,用户在发起map位置更新操作后,用户归属hlr向vlr插入用户数据,但是vlr却向hlr返回errcode=36(unexpected data value),即vlr收到未期望的数据值,导致插入用户数据失败,致使位置更新不成功,最后用户归属hlr向vlr返回位置更新结果,并携带errcode=34(system failure)的失败原因值,且指向网络节点vlr出错。 由上分析可以判断问题点在于插入用户数据的信令消息,那么hlr是插入了什么用户数据导致vlr不接受从而使插入用户数据失败的呢?我们提取了大量这种因map位置更新插入用户数据失败的消息进行解码对比,发现这些用户都有一个共同特征,即都有插入呼叫前转的补充业务数据,其中抽取两个用户的消息进行查看,用户1插入了3条ss-data信息和4条呼转信息: 用户2:插入了4条呼转信息和1条呼叫限制信息: 从用户的行为共性来看,问题很有可能在插入呼转数据上。 提取这种失败类型用户的呼转信息数据进行解码分析,发现这些用户插入的呼转号码位长都为16位。以用户一为例,用户一所属hlr发给vlr的insert subscriber data_req消息中呼转信息如下,为16位的呼转号码8613800371309689。 紧接着vlr返回用户一所属hlr消息insert subscriber data_ack,并携带错误原因值36(unexpecteddatavalue)。 最后,用户一所属hlr回送携带失败原因值为34(system failure)的lu_ack消息 纵观整个信令流程,奇怪的是为什么vlr插入这16位的呼转号码不成功呢?查看相关资料,在爱立信hlr局数据规范中发现,对呼叫转移分析表关于呼转号码的位长的要求是呼叫前转号码位长为15位的,具体hlr局数据规范如下: ***************************************************************************** hlr通过f表来限制用户可以转移的号码。呼叫前转号码(c用户号码)位长为15位,一般以“86+区号+市话号码”、“86+13s”的国际号码形式存储。” *************************************

文档评论(0)

ipuflu + 关注
实名认证
内容提供者

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

1亿VIP精品文档

相关文档