结合IubIu/Uu接口数据诊断UMTS网络问题

loveyxh

1 前言
在UMTS网络部署和优化阶段，网络问题（例如邻区丢失、弱覆盖、干扰、导频污染和设备本身的故障等等）的诊断往往是决策者和技术工程师们都是非常头疼的事情，无论对于设备商来说还是对于运营商来说都是这样。
工程师们一般通过对路测数据的分析来定位问题产生的原因和寻找解决问题的方案。路测数据反映的是以手机的角度来考察的网络性能，一方面没有上行链路信息，另一方面对于设备本身故障造成的问题事件（例如掉话和呼叫建立失败等）往往无能为力。从UMTS试验网优化的经验来看，设备本身或者是设备间的互操作性能带来的网络问题非常普遍。
那么我们如何分析和定位由于设备本身带来的更为深层的网络问题呢？ACTIX公司提出的解决方案是通过同步路测数据和有线口的协议分析仪数据来端到端（End-to-End）地分析UMTS网络问题。

2 IubIu/Uu接口数据的结合过程
IubIu接口数据通常是通过协议分析仪采集的，常见的设备有安捷伦（Agilent）、泰克（Tektronix）和网鹰（Nethawk）。Uu接口数据一般是通过使用路测前台做路测或者定点测试来获取，常用的路测前台有安杰伦、Nemo、Tems和中国华为等等。
将IubIu口数据和Uu口数据结合起来实现端到端地分析网络问题，跨越接入网的各个接口来跟踪信令流程是个美好的愿景，但是真正实现起来是非常复杂而且非常耗费人力的工作。因为这里有两步操作需要完成，第一步操作是将路测手机在有线口IuIub数据中提取出来，另一个工作是将路测手机Uu接口的数据与IuIub接口的数据按照每次会话分别对应起来，由于这两个数据参考时间不同因此对应过程中需要工程师有丰富的协议分析经验来借助Excel功能完成。
为了解决这个问题，ACTIX UMTS IVS软件将这个工作完全自动化了。
第一步ACTIX UMTS IVS软件通过路测的IMSI来将IubIu口数据中这个用户的数据提取出来，第二步通过鉴权请求和响应信令在这两个数据中分别发生的时间之差计算出来实现这两个数据在时间上的同步。当然，具体操作信令的提取和同步时绝非如此简单，例如RRC相关的信令和掉话等网络时间都会成为二者同步的准绳。

3 网络问题的端到端诊断过程
   
下面我们通过分析两个掉话问题来看一看端到端地诊断一般的操作过程。
  
3.1 第一个掉话的分析
   首先我们考察一下掉话前的无线链路性能。图1显示了掉话前手机激活集和检测集的导频以及导频强调，从这里我们可以看出，激活集中的导频是SC257强度为-32dB，而检测集中的导频是SC33、SC385和SC113其EcNo分别是-25、-22、-20和-21dB。因此，我们可以初步判断为由于弱覆盖造成的掉话，从检测集中的导频要比激活集中的导频好的多但是没有切换进入激活集，我们可以知道真正导致掉话的不是弱覆盖问题，而很可能是切换时延设置不正确造成的。
图1 掉话前无线链路激活集和检测集导频情况

    下一步，我们回到IuIub接口数据对该掉话原因进一步确认。我们将IuIub接口数据与Uu接口数据进行同步，检查掉话时IuIub口信令的状态。如下图所示。
图2 Uu口掉话时IuIub口信令状态指示无线链路失败

掉话时，IuIub口信令提示“radio Link Failure Radio Link Failure Indication”，这样我们就能够准确判断是无线链路覆盖原因造成的掉话。
3.2 第二个掉话的分析
同样，首先我们考察一下掉话前的无线链路性能。图3显示了掉话前手机激活集和检测集的导频以及导频强调，从这里我们可以看出，激活集中的导频是SC393强度为-9dB和SC33为-16dB，导频质量很好。再通过图4考察UE的发射和接收功率，值都在正常范围之内。也就是说无线质量较好，不是造成掉话的原因。
图3 掉话前无线链路激活集和检测集导频情况
图4 掉话前手机的接收和发射功率

下一步，我们回到IuIub接口数据对该掉话原因进一步确认。我们将IuIub接口数据与Uu接口数据进行同步，检查掉话时IuIub口信令的状态。如下图所示。
图5 Uu口掉话时IuIub口信令状态

     图5给出了穿插再一起的IuIub和Uu接口的信令信息（注意穿插后的RRC协议有的来自于Uu口有的来自于Iub口，根据Protocol值可以区分出来），而且从与Uu口掉话同步的信令指示中我们找不到掉话原因信息。只能找到消息直传CC Disconnect消息、无线链路拆除（radioLinkDeletion）请求和响应消息以及IuIub口链路的拆除消息。
     我们还可以发现掉话起始于NBAP协议的RadioLinkDeletion RadioLinkDeletionRequest，而且查看这个消息中的IE没有发现NodeB发出该指示的原因信息。
图6 系统发出的RRC BCCH-BCH消息

    但是我们对掉话前信令进一步研究发现掉话前UE很长时间（近一分钟）没有收到系统广播消息，因此断定很可能是NodeB不稳定造成的掉话。
4 总结
通过上述的两个例子我们可以发现，通过使用有线口数据和路测数据结合分析网络问题一方面可以造成问题的原因一目了然，另一方面可以解决由于设备本身原因造成的网络事件，而这往往仅仅通过路测数据是无法定位问题原因的。
另外有线口数据的特点是，对于网络问题大多能够返回一个问题代码信息，明确指出是无线链路问题还是设备本身故障问题等，但是其缺点是没有经纬度信息。而路测数据却相反，具有经纬度信息，但是对于网络问题产生的原因需要工程师根据当时的无线状态分析具体原因而不是直接给出问题产生的原因。
无疑，将这二者结合起来定能够加速网络问题的定位和解决！


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/21004/showart_131325.html