无线网络优化实例分析.docx
《无线网络优化实例分析.docx》由会员分享，可在线阅读，更多相关《无线网络优化实例分析.docx（28页珍藏版）》请在冰点文库上搜索。
无线网络优化实例分析
无线网络优化实例分析
MPA仪表例析
以下我们对无线网络中出现的典型问题做一些说明和分析
由不正确的MSC数据配置引起的切换失败
即使使用先进的设备确保所有的相邻小区都能较好地交叉覆盖，测试依然表明4个被测的BSC中有2个BSC仍然存在不能成功切换的小区。
图表1：
小区9472-911到9483-28951及9483-29053之间的切换失败
图表2：
小区9472-872和9483-28981之间的切换失败
图表3：
小区9485-29272和9473-457之间的切换失败
图表1显示了在30分钟的测试中，小区9472-911和9483-29053之间的切换失败了294次。
图表4显示了切换失败是因为对切换的源小区而言，目标MSC不识别（invalidcell）
图表4：
切换失败的原因
我们可以看到，切换失败的次数和受此问题影响的呼叫的次数并不相同。
当BSC试图将一个呼叫切换到另一个小区时，切换失败了；但如果该目标小区仍是周围小区中综合指数最好的，那么BSC仍将继续试图完成切换。
对表1中的294次切换失败而言，仅有30次呼叫受到影响。
在这30次呼叫中一些因为用户移到了其它的区域而切换到其它小区；另一些则由于无线传输质量太差或用户移动到小区覆盖范围之外而被用户主动中断了呼叫，但有一些呼叫因为无线失败的原因而导致掉话。
图表5：
切换失败消息队列
表5是一个呼叫的典型实例。
即由于切换不能完成而导致无线失败的掉话。
我们可以看到BSC数次试图完成切换（向MSC发送切换请求HORQD），但MSC总回复切换请求拒绝（HORQDR）并最终导致无线接口失败从而造成掉话。
当把小区9427-911加入MSC的数据库配置中用来定位区域9483时，此问题得到了解决。
该两小区之间的绝大多数切换均能成功完成。
图表6：
9472-911与9483-29053之间的成功切换
表6显示了当问题解决后，在18分钟的测试中，9472-911和9483-29053之间共有75次成功切换。
TRAU故障
网络中的一个重要故障即TRAU故障，该问题已经存在很久，但长期以来由于它仅表现为不明原因（无事件值）的高掉话率，所以不能准确定位。
图表7：
设备故障引起的掉话
表7显示该问题的严重性。
在24分钟的测试中，共有170个呼叫由于1个BSC内的设备故障而造成掉话。
当进一步分析时就会发现这是由于TRAU故障而造成的。
图表8：
TRAU故障造成的掉话的信息队列和事件值（呼叫终结原因值）
由于在BSC内，TRAU被动态地分布到不同的小区，所以更详细地去确定到底是哪个TRAU有故障则几乎不可能。
系统自身也几乎不能发现是否TRAU存在故障。
干扰
两个小区被发现有相互干扰的问题，第一个被分析的是小区9472-953，该小区有一些由于无线接口失败引起的掉话。
图表10：
小区9472-953内的掉话情况
图表10显示了小区9472-953在18分钟的测试中共有19次掉话，即每分钟多于一次。
当我们考察这些掉话的情况时，可以知道他们都是在呼叫建立后迅速掉话。
但我们又发现这些掉话总是在该小区的几个特定位置发生。
这使我们可以得出以下结论：
干扰是造成掉话的主要原因。
图表11：
小区9472-953中一个TRX的干扰等级
表11中我们可以看到小区9472-953中BTS的干扰报告。
5表示干扰信号和普通的呼叫信号一样强。
干扰源我们不能确定，但经过进一步的调查研究（如：
使用调频技术改变频率直到干扰消除或在该小区中使用无线测试设备进行分析）可知，由于干扰并非恒定不变的，所以要检测出干扰及找出原因，相对较难。
第二个存在干扰的是小区9472-853。
在该小区中，干扰同时影响到了控制信道和话音信道。
图表12：
由于无线错误导致的掉话
表12显示了在30分钟的测试中，小区9472-853的呼叫有100次SDCCH分配失败，同时有20个呼叫由于无线失败而掉话。
对SDCCH分配失败的分析，我们要看那些使用SDCCH信道的TRX的干扰情况。
图表13：
使用SDCCH信道的TRX的干扰情况
表13中我们可以看到使用SDCCH信道的其中一个TRX具有较大的干扰。
和前一个小区的情况相似，由于干扰电平不恒定，对干扰源的定位较困难。
SDCCH信道大多数情况下处于忙状态而话音信道常处于空闲状态，当话音信道空闲时BTS将干扰情况经测试取得并上传给BSC。
如果该话音信道有干扰，则当有呼叫时，该信道被分配的优先权将降低；如果干扰电平很高，那么BSC有可能根本不使用该TRX。
这意味着可以通过发现某个TRX不寻常的话音信道低占有率来检测干扰是否存在。
图表14：
TRX存在干扰时话音信道的情况
图表15：
TRX正常时话音信道的情况
表15显示了用做话音信道的工作正常的TRX的统计情况。
这里我们可以看到，‘TOTAL’和‘AVERAGE’的时隙占有数大部分都是相同的，未用到的话音信道的数量和比率均很低。
未用是指呼叫激活了TCH，但却从未使用该TCH。
正如表14所示，有一个TRX具有很高的未用话音信道。
与表15相比，显得极不正常。
其中的原因是因为：
一旦某话音信道因为在某时期内有干扰而空闲，那么他就不会再被分配出去，直到干扰消除。
不可用话音信道指的就是BSC分配了话音信道，但由于干扰，这些信道不可用。
图表16：
用于话音信道的TRX的干扰情况
无线覆盖
我们发现被测试的两个小区存在无线覆盖问题。
小区9472-872在30分钟内由于无线失败而导致13次掉话。
图表17：
小区9472-872由于无线失败而导致掉话
当我们详细分析这些掉话时就会发现他们总是发生在小区中的几个相同位置。
当某个呼叫掉话时，我们从该小区的时间-距离（T-A）表和该掉话发生前其邻近小区的T-A表上可以得到以上的证实。
图表18：
掉话时典型的无线曲线
当我们在地图上查看这些掉话区域时，我们发现这些呼叫是在一个隧道内发生的。
在隧道内发生掉话并不是一个大问题（除非他严重影响了掉话率的统计）。
由于用户本身对隧道内发生掉话可以理解，所以我们没有必要去解决这个问题。
如果确实需要解决，那么就需要改变天线的方向和角度，使得可覆盖该隧道；或在隧道中安装转发器。
其他存在覆盖问题的小区有9485-29241。
在该小区内覆盖问题导致一些呼叫在接续后不久发生掉话。
图表19：
小区9485-29241中的高掉话率
图表19显示了该小区中掉话发生在相同的地方
图表20：
掉话时典型的无线曲线
图表20显示了掉话时典型的无线曲线。
T-A值是1表示该掉话发生在距BTS500---1000米处。
同时，我们可以看到从MS接收到的信号下降的非常快，所以即使邻近的信号可以被捕获到，仍然无时间去完成切换。
但由于其中也有一些呼叫是因为捕获不到邻近小区的信号造成的，所以我们认为这更像是无线覆盖不好造成的。
由无线覆盖不好导致的切换失败
在小区9485-29242和9502-282之间，有很多呼叫由于无线失败而导致切换失败。
图表21：
在小区9485-29242和9502-282之间由于无线覆盖导致的切换失败
不正确的BSC数据
从OMC系统中我们可以看到小区9474-381的利用率很低。
当我们分析该小区时我们发现该小区有两个TRX，但其中一个一直不能被占用。
图表22：
小区9474-381的处理报告
从测试得到的处理报告中我们可以发现该记录显示操作没有任何问题。
但其中一个A-BIS接口上无小区信息可被探测到。
这意味着LAPD协议层已被激活了，但却无信息送往TRX。
这也意味着TRX已被连接好并且信令链路也在工作了，可BSC永远也不能使用TRX（因为它不知道有TRX可用）。
原因就是TRX未被加到数据库中，从而该BSC不识别TRX，造成无线信道不可用。
如果这是一个呼叫负荷较高的小区，就表示即使有一个TRX空闲，仍有呼叫被拒绝。
图表23：
无无线资源可用导致的呼叫失败
表23显示了在15分钟内，小区9472-381由于无无线资源可用，拒绝了14次呼叫。
呼叫拒绝
测试过程中我们发现，在所有小区中均存在有由于信息与协议状态不兼容（不匹配）而造成的呼叫拒绝情况。
图表24：
信息与协议状态不匹配造成呼叫拒绝
表24显示了在30分钟的测试中共有102个呼叫由于信息与协议状态不匹配而被拒绝。
图表25：
不同小区中呼叫拒绝的分布情况
如表25所示，被拒绝的呼叫很平均地分布在不同的小区中。
我们对这些呼叫做进一步的分析以找出原因。
图表26：
呼叫拒绝信息
所有被拒绝的呼叫均以一个CMS开始业务请求，但MSC以信息类型与协议不匹配为由拒绝CMS业务请求。
这是由MSC中的时间功能设置不当造成的。
当一个呼叫终结时，MS和MSC中的时间功能模块也必须在下一个新呼叫建立之前终止。
如果时间功能模块在MSC中存在的时间比在MS中存在的时间长，则MS可以在MSC未释放前一个呼叫时完成一个新的呼叫，MSC接着就会认为此信息属于前一个呼叫但MS却未被允许发送CMS信息，造成所谓的信息与协议状态不符。
软件缺陷和硬件故障
所有被测的BSC均存在软件的缺陷或设备故障，这导致呼叫释放时出现问题。
即一个呼叫会因为“无线接口信息失败”而被释放。
其过程是：
MSC向BSC发送一个清除命令，但BSC忽略了该清除命令。
20秒后，MSC不得不重新初始化该电路（链路）以释放此次呼叫。
这意味着呼叫终结后电路仍要保留20秒的时间。
在一些测试中，30分钟的时间内发生了200多次这种类型的问题，即在30分钟的测试中会发生总时间超过1小时的电路拥塞。
以上的例子显示了所有的初始化信息和其他相关信息。
我们可以看到，初始化命令占到了所有命令的一半。
不平衡的无线路径
被测小区中有两个显示了小区中存在大量有不平衡无线路径的呼叫。
由于它是相同BTS控制下的2个相邻小区，并且该现象可以在所有的TRX上观测到；所以最大的可能就是：
该现象是由连接两个小区天线的电缆造成的。
Tx
上面我们已经用图例说明了该问题。
如果这真是导致该问题的原因，就意味着呼叫会象下面图示的那样：
MS从小区A接收而从小区B发送。
B
当我们深入观察这些小区中的呼叫后就会发现，在上行和下行的接收电平上有很大的差异。
第一个呼叫产生于其中一个小区的中央，那里接收电平在一个方向上非常好，但由于MS大部分时间都处于另一个天线的背部，所以另一个方向的接收电平较差。
对第二个呼叫，我们可以看到用户正在移动（T-A值在增加），同时可以看出他正在进入另一个小区（下行电平增加，上行电平减少）
下面的两份图表显示了上行和下行的平均接收电平，可以看出，该小区中存在着上下行的不平衡。
COMPASS可以计算链路的平衡度。
下面的图表指出了链路的平衡情况（此处BTS的发送功率设为33，链路的平衡情况随着BTS发送功率的不同而有所差异）
这两个小区中同样存在很多未用的信道（从下面的图表中可以得到此结论），那可能是引发这个问题的原因。
未分配信道
在一些小区中存在着这样的问题：
BSC收到了某个呼叫发出的信息，要求分配信道，但BSC却不能分配相关的信道给该呼叫。
这个问题与MS发出‘请求分配信道’这条信令后，其消息码中设置的接入延迟值有关。
即该值比BSC中设定的值要高。
在以上的呼叫中我们可以看到，接入的延迟值被设为了35，这意味着这个小区试图从外部小区接收呼叫或者该BTS在计算接入延迟时出现故障。
以下的图表说明的就是这些存在问题的小区：
位置更新失败
在所有的测试中，我们都发现了很多位置更新失败的故障。
所有失败的位置更新都有相同的HLR（如下示）：
这些位置更新失败的原因可能是由于连接到HLR的信令链路太多所致。
不正确的相邻小区设置
一些被测的小区和它相邻的小区同时存在问题。
我们必须注意的是：
这些测试仅仅持续了30分钟。
我们需要进一步测试这些小区以检测这些相邻小区的配置情况是否正常。
以上就是两个相邻小区的数据。
包括测试报告的数量和每个相邻小区的接收等级。
如果两个小区之间发生了切换，则切换的小区号将会被记录下来。
但如果相邻小区之间未发生切换，则小区标号栏将为空。
从上面的数据中我们可以看到，一些已经配置好的相邻小区只出现了一到两次，这些小区该不该从相邻小区列表中删去呢？
我们还可以看到一些相邻小区的报告出现了很多次，但他们的平均值较低并且相互之间未发生切换，所以我们也许应该将他们从相邻小区列表中删去。
升级会员 