GSM拥塞率问题分析_第1页
GSM拥塞率问题分析_第2页
GSM拥塞率问题分析_第3页
GSM拥塞率问题分析_第4页
GSM拥塞率问题分析_第5页
已阅读5页,还剩49页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

GSM拥塞率问题分析

无线产品课程开发室课程内容

第一章TCH拥塞率第二章SDCCH拥塞率第一章TCH拥塞率定义原因及定位方法案例1.1TCH拥塞率定义TCH拥塞率=TCH占用失败次数/TCH占用请求次数*100%

TCH拥塞是指:话音信道指配是网络无业务信道可用TCH拥塞率的定义1.2TCH拥塞率原因及定位方法A口中继电路数据配置错误跳频小区的TSC与BCC不一致同频同BSIC导致切换时TCH指配失败单板故障或性能不稳定,引起高拥塞率基站硬件安装不规范,引起上下行电平不平衡,导致TCH拥塞小区下挂直放站,小区扩容后,直放站未扩容同一小区的主BCCH所在载频的发射功率大于TCH载频干扰引起拥塞孤站及地形复杂,TCH指配失败导致拥塞率TCH拥塞率高的原因:基站硬件安装不规范基站硬件安装不规范,引起上下行电平不平衡,导致TCH拥塞1、上行支路:天线-->塔放-->馈线-->避雷器-->机顶接头-->分路器或CDU-->TRX单板分路器级联半刚性电缆连接错误,导致上行电平差;半刚性电缆扭曲或接头不紧导致数据总线问题基站硬件安装不规范2、下行支路:TRX-->HPA-->合路器或CDU-->机顶接头-->避雷器-->馈线-->塔放-->天线发射支路存在天馈驻波比告警半刚性电缆扭曲或接头不紧导致小区天线连接错误,使得主BCCH所在载频和扩容载频的覆盖方向及范围不同,引起TCH拥塞1.2TCH拥塞率原因及定位方法远端分析拥塞率原因1、通过话统初步分析2、查看告警3、基站远端维护台4、使用信令分析仪测试分析ABIS口消息到基站近端进行检查TCH拥塞率高几种定位方法: 1.2TCH拥塞率原因及定位方法通过话统“小区TCH性能测量”,检查TCH拥塞率是否因遇全忙拥塞,若因遇全忙拥塞,可通过话务均衡手段,或建议扩容。若非遇全忙拥塞,分析拥塞率是否与干扰有关,即检查干扰带一~干扰带五,此时该小区受干扰其掉话率也会相应偏高。登记“接收性能测量”话统任务:1、按照对象查询话统结果,同一载频板上下行测量报告数是否均衡,可初步判断为该单板上下行硬件支路不平衡;2、按照时间查询话统结果,检查同一小区内是否存在某载频测量报告数异常情况,初步可判断拥塞率与该单板相关。远端分析之一:通过话统初步分析1.2TCH拥塞率原因及定位方法检查拥塞率高的小区所属站点告警,是否存在异常告警,如存在驻波比告警、PCM失步告警、上行数据总线告警等,结合话统判断拥塞率是否与告警存在关联性。远端分析之二:查看告警1.2TCH拥塞率原因及定位方法检查基站各单板软件是否统一,确认版本配套。使用基站远端维护台,轮流闭塞拥塞率高的小区载频板TCH信道,观察拥塞率是否与该小区载频板有关。远端分析之三:基站远端维护台1.2TCH拥塞率原因及定位方法远端分析之三:基站远端维护台处理原则:1、若拥塞率的涨落与载频板信道闭塞有关,则估计与该单板有关,可检查是否存在同频干扰、检查上下行硬件、单板硬件性能;2、若拥塞率与载频板无关,可能整个小区存在干扰或受地形的影响。1.2TCH拥塞率原因及定位方法跟踪拥塞基站的ABIS口消息,分析在SDCCH下发的指配命令AssignmentCMD,判断指配失败是否集中在某块TRX板上:若指配失败固定在某块TRX单板上,可以确定以下几种情况中的一种:1)TRX单板故障或性能不稳定2)上下行电平差导致,上行支路或下行支路硬件问题3)上下行信号质量差,结合手机TA值,初步确定哪路存在干扰。若指配失败随机分布在整个小区内的载频板上,分析测量报告,一般可能存在以下几种可能:1)因基站覆盖范围内,地形复杂2)存在整个小区内频点的干扰,如直放站的干扰;远端分析之四:使用信令分析仪测试分析ABIS口消息1.2TCH拥塞率原因及定位方法近端维护,查看是否存在异常告警,并及时处理。检查上下行天馈支路是否存在硬件问题,如接头松动、天线是否接反、电缆连接错误、背板连线松动等同一地点用测试手机拨测,指配失败是否集中在某一频点,或随机分布通过网络优化软件ANT-PLOT进行路测,检查是否存在切换关系异常、下行干扰,从中找到拥塞率问题的切入点。使用频谱仪查找干扰源观察是否基站覆盖地形复杂基站近端检查1.2TCH拥塞率原因及定位方法

对同一地点进行拨测方法:每载频每信道进行拨测,检查是否存在个别时隙、单板无法指配的情况检查每块载频下行电平是否接近,对于电平明显异常的载频板,可通过更换单板、上下行天馈系统,分段查找异常的原因。注意:对于使用跳频小区,则需要事先用命令行参数将该小区改为非跳频,便于近端拨测。1.3TCH拥塞率问题案例某本地网有1个BSC,从某天开始,整网的TCH拥塞率变高(频率计划一直未做调整),全网TCH拥塞率(不包括切换)达4%(遇全忙拥塞率很低)。且拥塞率变高的小区不是集中在某几个小区,而是很多小区。案例1现象描述1.3TCH拥塞率问题案例1、由于频率计划未做调整,所以排除无线口原因;2、大部分基站出现拥塞率异常,缩小范围,检查拥塞率异常的是否与模块、数据修改等有关;3、通过话统分析TCH占用失败的主要原因,最终定位数据或硬件故障问题。案例1分析思路:1.3TCH拥塞率问题案例1、查看话统,在BSC数据修改加载后出现该现象,估计与此加载BSC有关。2、分析话统,发现拥塞率高的小区基本集中在BSC的1模块,大致定位到1模块。3、查看该模块TCH占用失败次数主要因地面资源不可用,说明地面资源不可用是造成1模块TCH拥塞率高的主要原因。4、地面资源不可用的主要原因可能在Abis或A接口电路上,因为1模块下很多小区都有此现象,Abis接口同时出现故障的可能很小,集中在A接口上硬件或数据上。5、A口硬件检查正常,排除A口硬件的可能6、检查A口中继电路数据配置,发现1模块0群前32个时隙CIC编号为65535,而在中继群表中1模块0群对应电路为BSC至MSC的电路,显然CIC号配错。将其改为0~31后再动态设定。拥塞率恢复正常。案例1处理过程:1.3TCH拥塞率问题案例1、A口中继电路数据配置,CIC不能错误,否则会导致TCH指配失败,拥塞率高。2、同样,当两块FTC单板的CIC重复,即多条中继电路的CIC编号一样,也会出现该现象。案例1结论:1.3TCH拥塞率问题案例由于不存在干扰,且从基站开通之后一直都存在拥塞,每个小区都拥塞,其它基站没有类似现象,所以重点检查该基站硬件。1、硬件故障:每个小区都能够正常通话,每个小区硬件都故障的可能性不大。2、硬件连接:重点检查硬件连接。可通过话统分析故障出现在上行或下行,再检查上行或下行的硬件连接。案例2分析思路:1.3TCH拥塞率问题案例1、登记话统“接收电平性能测量”,按照时间查询话统结果。发现同小区内不同TRX单板的相同接收电平、接收质量条件下,下行测量报告数比较均衡,但上行测量报告数明显的不平衡,且有一定的规律性。2、检查发现同一小区两个SPL级连半刚性电缆连接错误,更改后,问题解决。案例2处理过程:1.3TCH拥塞率问题案例硬件连接错误会导致TCH指配失败。通过不同的话统任务分析可以准确定位问题。本案例利用“接收电平性能测量”定位出上行硬件接收存在问题。案例2结论:1.3TCH拥塞率问题案例某基站S6/6/5,从某天开始,有一个小区出现高拥塞率,期间没有做任何调整。案例3现象描述:1.3TCH拥塞率问题案例由于在出现故障前后没有做任何参数调整,重点关注硬件是否出现故障,是否有相关告警。案例3分析思路:1.3TCH拥塞率问题案例1、使用信令分析仪MA10跟踪该基站的ABIS口消息,分析信令发现,在出现TCH指配失败过程中,BSC下发ASSINMENTCMD指配命令后,测量报告中上行信号很好,但下行信号电平无法解析,即上下行信号电平不平衡,然后回ASSIFAILURE指配失败消息。并且发现都是指配该小区的最后一块TRX单板上。2、临时闭塞该TRX单板信道,该小区拥塞率降低到1%左右。估计该TRX单板及其下行链路硬件存在问题。3、检查发现,该TRX单板所连的合路器上有发射天馈驻波比超过2.5告警,解决天馈驻波比告警问题解决。处理过程:案例31.3TCH拥塞率问题案例天线驻波比告警导致损耗大,覆盖范围减少,从而指配失败。当手机处于小区BCCH覆盖范围,但不在驻波比告警单板覆盖范围时,一旦指配到该载频,很容易导致指配失败,造成小区拥塞率过高。案例3结论:1.3TCH拥塞率问题案例由于在扩容后拥塞率出现异常,可以:1、先检查出现拥塞的是否为所有载频,如果是,则重点检查基站的新增硬件的连接,故障等。2、如果出现拥塞的为其中之一个或几个载频,则重点检查这几个载频的硬件。3、排除硬件原因后,要考虑是否存在外界原因,如存在直放站没有扩容,导致指配失败。分析思路:案例41.3TCH拥塞率问题案例1、远端基站维护台闭塞后两块新增载频TRX,发现拥塞率大幅度降低到正常水平,估计与这两块单板有关;2、跟踪分析ABIS口的信令,指配失败发生在新增两块载频上。当指配失败时,从SDCCH上的测量报告分析,SDCCH上的电平正常,且TA值较大,即一般发生在较远的地方,但无SACCH(TCH)上的测量报告,估计这两块单板上下行支路硬件故障。但这两块单板也有指配成功的情况,排除了单板故障情况。3、因该小区采用了四合一合路器及一分四分路器,排除了天馈部分硬件故障;检查TRX单板到合分路器的半刚性电缆,未发现硬件问题。基本排除硬件原因。4、通过询问得知在此小区下挂了一个直放站,扩容后直放站没有锁定新增两个载频,导致指配失败。解决直放站频点问题后,拥塞问题解决。处理过程:案例41.3TCH拥塞率问题案例由于直放站关系,同一小区后两个载频与前两个载频的覆盖范围不一致,引起指配失败。结论:案例41.3TCH拥塞率问题案例1、由于拥塞率不是很高,所以数据问题和硬件故障的可能性不大。2、干扰带也正常,无线口的干扰原因也可以不考虑。3、重点分析指配失败是什么原因,结合掉话率高一起考虑,分析上下行的接收性能,包括电平、质量等。分析思路:案例51.3TCH拥塞率问题案例1、查看“掉话性能测量”,发现掉话时TA值比较大,在离基站25.6km到31.1km处。2、查看“接收电平性能测量”发现电平等级低的测量报告数比较多。3、通过分析其ABIS口的信令,发现指配失败时上行电平都很低(-98dbm左右)。4、到基站实地路测,此站为一个孤站,覆盖范围很大,地形条件很复杂。当手机离基站距离25公里以上,还能收到-90dbm的下行信号,但由于上行信号不够,导致TCH指配失败。处理过程:案例51.3TCH拥塞率问题案例1、上行覆盖差导致拥塞率高。可以通过:增加基站,形成连续覆盖;全向站改为定向站,通过调整天线方向角及倾角;增强发射电平和基站接收灵敏度,同时避免产生越区覆盖。2、在基站维护台上通过跟踪Abis口的消息,可以分析指配情况。结论:案例5课程内容

第一章TCH拥塞率第二章SDCCH拥塞率第二章SDCCH拥塞率基本原理原因及定位方法案例2.1SDCCH拥塞率基本原理SDCCH拥塞率=SDCCH占用遇全忙次数/SDCCH占用请求次数SDCCH占用遇全忙次数:SDCCH占用失败是因为遇全忙SDCCH拥塞是指:在立即指配时网络无信令信道可用2.1SDCCH拥塞率基本原理SDCCH占用原因包括:1)主叫的指配命令下发通道2)被叫的寻呼响应上发通道3)位置更新4)短消息5)IMSI分离、附着过程计算公式:2.2SDCCH拥塞率原因及定位方法位置区边缘导致SDCCH位置更新过多导致策略:修改位置区选择修改CRH(小区重选滞后参数)修改周期位置更新的参数设置修改双频网的频繁切换问题过多的发短消息、天气预报策略:不要集中发射增配SDCCH信道2.2SDCCH拥塞率原因及定位方法系统容量不够大:SDCCH配置过少策略:扩容系统参数设置不好、RACH的系统参数、实际多重指配SDCCH。策略:适当加大RACH接入门限(应付干扰)适当减小最大重发次数、加大扩展传输时隙数。单板(TRX/FPU)故障、传输故障导致SDCCH拥塞2.3SDCCH拥塞率问题案例某本地网无线接通率偏低,从话统上分析其主要原因为少数几个站SDCCH拥塞。【现象描述】案例12.3SDCCH拥塞率问题案例由于拥塞集中在几个基站,通过登记“SDCCH性能测量”分析这些小区SDCCH占用时各类占用原因的比例,着重解决。【分析思路】案例12.3SDCCH拥塞率问题案例1、分析话统:出现拥塞的小区忙时有300-400次SDCCH占用,均为S1/1/1基站,每个小区均配置8个SDCCH/8信道,按常理足够应付3、4百次SDCCH占用,奇怪的每个小区忙时均是出现了几十次不等的SDCCH拥塞。2、登记“SDCCH性能测量”:发现SDCCH占用中,绝大部分为位置更新造成。结合基站所处位置,发现上述拥塞基站大部分处在铁路线两个位置区交界处,由此联想到可能是突发的位置更新导致SDCCH拥塞。3、登记五分钟的“SDCCH性能测量”话统,发现位置更新大部分集中在某五分钟之内。后查询列车时刻表,该时段有四到五列客车经过,原来列车经过时,大量的突发位置更新集中在很短的时间内进行,导致拥塞。4、增加SDCCH配置,或者打开SDCCH动态分配功能。【解决过程】案例12.3SDCCH拥塞率问题案例位置更新导致的SDCCH拥塞需要查明是否是位置区设置不当。本案例属于特殊情况,可通过增加SD的配置或开启动态分配功能来解决。【结论】案例12.3SDCCH拥塞率问题案例某基站最近由O2站改为S2/1/1站(BTS20),一段时间来用户投诉通话断断续续,听不清楚。近2日该站2小区突然出现SDCCH严重拥塞,忙时SDCCH拥塞次数达到35000次/60分钟,拥塞率为60%,且有用户投诉话音断续。【现象描述】案例22.3SDCCH拥塞率问题案例扩容之后,不仅SDCCH拥塞,通话也有断续。说明SDCCH不是真正遇忙拥塞,而是单板或者传输出现故障,导致SDCCH占用失败。先排除干扰,重点检查硬件。通过查询告警、复位、更换单板等手段定位。【分析思路】案例22.3SDCCH拥塞率问题案例新开基站,开通后SDCCH信道一直基本上处于全忙状态(A),TCH信道为(I)或(A)状态,能拨通后通话正常。观察话统SDCCH分配失败次数在一千次左右(忙时)。【现象描述】案例32.3SDCCH拥塞率问题案例1、由于从基站开通SDCCH就拥塞,但TCH正常,且通话也正常,先检查数据和硬件。整个基站都拥塞,可通过与其它同类型基站端口对调,确认是否存在数据或Abis口以下的硬件问题。逐段检查确认。2、如果排除数据和硬件原因,可重点检查传输是否存在故障。【分析思路】案例32.3SDCCH拥塞率问题案例1、检查告警:LAPD链路故障告警和恢复告警(在一秒之内),告警频度在十分钟左右出一次。2、检查数据没有问题,同时在夜间与其它同型基站32BIE端口对换,其他基站工作正常,该站现象依旧,可以排除数据问题和BSC侧硬件问题;3、由于基站距市区较远首先进行传输有关话统登记,察看结果(传输相关)没有异常,但SDCCH话统依然异常;4、更换基站TMU、TRX单板现象依旧;5、测量传输,自环32BIE端口指示灯有时会闪,发现传输有误码,后通过逐段测试定位在某县到基站所走一段接入网有一2M传输单板有问题,更换该单板问题解决(两基站在同一块单板)。【处理过程】案例32.3SDCCH拥塞率问题案例造成SDCCH拥塞原因有很多,包括:1、数据配置错误2、SDCCH信道不足3、无线口原因(干扰、电平低、上下行不平衡)4、硬件故障5、传输质量问题。该案例是以上的第5条,由于传输误码,指配SDCCH信道时有大量数据丢失或数据丢失后多次重发超时,导致占用失败,出现高度拥塞。【结论】案例32.3SDCCH拥塞率问题案例某本地网反映有4个基站(ABCD)附近移动用户难以打通电话,但是告警维护台上没有任何相关告警信息。1、查看这4个基站各单板状态均正常,TCH信道几乎没有被占用,即使偶尔占用了1个TCH,几秒钟后也变为空闲状态;SDCCH信道状态全部为A。2、经过了解得知,基站A为S2/1的BTS30基站,B、C为O2BTS312基站,D为S1/1BTS312基站。4个基站的软件版本均为3.02R003.20000529。A基站下挂B、C基站,D基站使用了基群合路器(一种传输时隙复用设备)与A基站共用一条2M传输。【现象描述】案例42.3SDCCH拥塞率问题案例从故障现象,可以确定大致是硬件或传输出现问题,但这四个基站的硬件同时出现故障的可能性不大,由于四个基站传输之间有关系,所以重点检查传输是否存在故障。【分析思路】案例42.3SDCCH拥塞率问题案例1、仔细观

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论