TCH掉话切换拥塞.docx
- 文档编号:8714648
- 上传时间:2023-05-14
- 格式:DOCX
- 页数:19
- 大小:313.43KB
TCH掉话切换拥塞.docx
《TCH掉话切换拥塞.docx》由会员分享,可在线阅读,更多相关《TCH掉话切换拥塞.docx(19页珍藏版)》请在冰点文库上搜索。
TCH掉话切换拥塞
1.TCH掉话问题处理
1.1.TCH掉话的统计点及类型
在移动通信中,掉话是指在分配了话音信道(TCH)后,由于某种原因,使呼叫丢失或中断,正常通话无法进行的现象。
掉话对用户造成许多不便,是目前用户投诉的热点。
TCH掉话次数统计点为:
BSC向MSC发起CLEAR_REQ消息,Ms当前占用的信道类型为TCH。
掉话主要有以下几种类型:
1、射频丢失掉话(即无线链路故障掉话);
2、切换失败掉话;
3、Lapd掉话。
1.1.1.射频丢失掉话
射频丢失掉话示图:
射频丢失掉话分上行和下行两部分。
A.下行链路失败:
GSM规范定义,移动台中有计时器S(T100),在移动台通话开始时被赋予一个初值,即无线链路超时(radio_link_timeout)。
此值在BCCH上广播。
每当移动台无法正确解码一个SACCH消息(4个SACCHBLOCK)时,S减1。
每当移动台正确解码一个SACCH消息时,S加2。
但S不会超过radio_link_timeout定义的初值。
当S计数为零时,移动台放弃无线资源的连接,进入空闲模式。
发生一次掉话。
B.上行链路失败:
系统监视上行链路失败的参数是link_fail。
当基站不能正确解码一个SACCH消息时,HDPC中的计数器(最大值由link_fail定义)减1,基站正确解出一个SACCH消息,计数器加2(计数器不超过Link_fail定义的值)。
当计数器为零时,基站停止发射下行的SACCH,同时启动rr_t3109定时器(rr_t3109>T100)。
当移动台的T100超时,移动台返回空闲模式,发生掉话。
基站等到rr_t3109定时器到时,释放无线信道。
BSC还需要向MSC发一个Clearrequest消息。
上下行链路任何一方失败,都会停止向对方发送SACCH。
从而启动对方释放无线资源的过程。
在TCH上发生一次link_fail,统计为一次RF_LOSSES_TCH。
1.1.2.切换失败掉话
切换失败掉话原理:
Ms在原小区收到HandoverCommand或Assignment(Bsc启动相应的切换控制定时器)消息后,没有成功切入目标小区,也没有返回原小区。
即Ms没有成功占用目标小区信道发HandoverComplete或AssignmentComplete消息,也没有成功返回原小区信道发HandoverFailure或AssignmentFailure消息,MS与网络脱离联系。
此时,BSC的切换控制定时器就会超时,通知MSC来清除释放,并将该异常事件统计为切换失败掉话。
BSC切换控制的定时器主要分为:
T8定时器超时(不同Bsc下的小区间切换)、T3103定时器超时(同一Bsc下的小区间切换)、T3107定时器超时(小区内部切换)。
切换失败掉话示图:
T3103超时(小区间切换失败)
T3103超时(小区间切换失败)
T3107超时(小区内切换失败)
T3107超时(小区内切换失败)
T3103超时(小区间切换失败)
T8超时(小区间切换失败)
1.1.3.Lapd掉话
Lapd含义:
LAPD链路断时,载频上正在进行的通话会中断。
当Bsc接收到LAPD断消息时统计。
1.2.产生掉话的原因:
1.2.1.射频丢失掉话的主要原因:
射频丢失掉话的主要原因:
1、存在覆盖弱区,无线信号差;
2、存在干扰。
如频率规划不当而导致的网内干扰以及其他系统外干扰等;
3、无线参数设置不合理;
Ø小区最小接入电平设置过小,导致移动台在覆盖弱区通话,易掉话;
ØNCCPermitted设置不合理。
有些网络可能存在主小区和邻小区采用不同的NCC,这就需要在NCCPermitted中添加相应的邻区采用的NCC。
一旦设置不合理,将导致移动台不侦测某一NCC的邻区,导致无法切换,产生射频丢失掉话;
Ø无线链路故障定时器设置过小,导致移动台陡然恶化情况下就超时掉话,但如果设置过大,则会造成无线资源利用率的下降;
Ø功控参数设置不合理。
如电平、质量功控门限不合理,可能将导致移动台在信号差、质量差的时候还在降功率等问题;
Ø跳频参数设置不合理。
Maio配置不合理,导致同一站内存在同邻频干扰;
Ø邻区数据定义不全或配置错误,导致移动台无法通过切换来改善信号,导致信号恶化掉话;
Ø切换参数设置不合理,导致移动台在质量很差的情况下无法及时切换来改善无线质量而掉话;
Ø邻区存在拥塞,导致移动台在质量很差的情况下无法及时切换来改善无线质量而掉话。
重点需解决邻区的拥塞。
4、设备硬件故障。
如功放输出功率过低,不同载频发射功率差别大,载频发射机、合路器、分路器设备故障等;
5、天馈系统故障。
如小区内两根天线倾角和方位角不一致,天馈驻波比大,天线过高或下倾角不合理造成覆盖范围过大,造成越区覆盖,形成远端孤岛效应而产生掉话等;
6、用户原因造成。
如移动台电池接触不良易掉电等。
1.2.2.切换失败掉话的主要原因:
对切换掉话的优化要结合切换成功率,尤其是切出成功率的优化来进行。
切换失败掉话的主要原因:
1、存在干扰。
如频率规划不当而导致的网内干扰以及其他系统外干扰等;
2、设备硬件故障。
如目标小区或本小区存在时钟故障,功放输出功率过低,不同载频发射功率差别大,载频发射机、合路器、分路器设备故障等;
3、无线参数设置不合理。
Ø目标小区同BCCH同色等问题,导致切出失败高,从而形成掉话;
Ø邻区关系定义不当或邻区数据错误,导致切出失败高,从而形成掉话;
Ø切换参数设置不合理,导致乒乓切换等问题,易形成掉话;
1.2.3.Lapd掉话的主要原因
Lapd掉话的主要原因:
1、基站传输问题。
如传输中断或传输不稳定(时断时续)等;
2、基站侧硬件故障。
如E1线不可靠,CMM板,背板连线存在故障等;
3、BSC侧硬件故障。
如Lapd处理板凳。
1.3.问题处理流程:
建议以无线参数检查及硬件排查的方法定位。
掉话问题的处理步骤如下:
1、性能报表分析,确定高掉话小区的掉话原因;
2、针对掉话类型进行针对性的分析处理;
3、如果是射频丢失掉话居多,建议进行如下处理:
Ø检查无线参数设置。
对不合理的无线参数设置进行调整;
Ø检查BER、空闲干扰带等级等指标,减小消除无线干扰;
Ø通过路测查看是否存在覆盖问题。
针对弱覆盖区,需重点排查硬件故障;针对越区覆盖,需重点排查功率参数、切换参数,天线下倾角等;
Ø检查排除设备硬件。
对问题板件等进行更换;
Ø检查天馈系统。
对问题部分进行排查;
4、如果是切换失败掉话居多,建议进行如下处理:
Ø检查无线参数设置。
对不合理的无线参数设置进行调整;
Ø检查BER、空闲干扰带等级等指标,减小消除无线干扰;
Ø检查排除设备硬件。
对问题板件等进行更换;
5、如果是Lapd掉话居多,建议进行如下处理:
Ø排查Bsc侧硬件故障;
Ø排查基站传输;
Ø排查基站侧硬件故障。
掉话问题处理大致流程图如下:
2.TCH切换失败处理
2.1.切换类型及其算法
移动通讯最大的特点是客户手持的移动台是不固定的,而网络侧的基站则固定不动,再加上周围环境的干扰,通讯的质量可能趋向恶化。
一种有效的挽救措施就是切换。
切换流程保证了通讯的正常进行,有的切换甚至使通讯的质量提高。
所以,正确运用各种切换算法,是提高网络质量关键的一项工作。
所谓切换,就是指当移动台在通话过程中从一个基站覆盖区移动到另一个基站覆盖区,或者由于外界干扰而造成通话质量下降时,必须改变原有的话音信道而转接到一条新的空闲话音信道上去,以继续保持通话的过程。
切换目的主要有以下五点:
1、挽救切换,挽救正在进行的呼叫;
2、边缘切换,改善正在进行的呼叫;
3、小区内切换,降低小区内的干扰;
4、定向重试,提高呼通率;
5、强制切换,平衡小区间的业务分布。
根据GSM规范,切换主要有四种方式:
1、小区内部的切换;
2、同一BSC内部小区之间的切换;
3、同一MSC内部不同BSC之间的小区切换;
4、不同MSC之间的小区切换;
同一个BTS不同小区内部的切换由于在切换前后不需要向BSC发送TA(TimeAdvance)值,我们将其称为同步切换,而将其它在切换前后GSM系统需要重新测量TA值的切换称为异步切换。
切换的主要算法:
1、上行或下行干扰切换;
2、上行质量/下行质量切换;
3、上行电平/下行电平切换;
4、更好小区(PBGT);
5、MS-BS距离;
6、定向重试切换;
7、快速电平下降;
8、宏微切换;
9、同心圆切换;
10、话务量切换;
Tch切换的流程图如下:
当移动台在原小区收到HandoverCommand消息后,便会根据HandoverCommand中的切换信息,尝试接入目标小区,如成功,便会在目标小区上发HandoverComplete消息,如失败,便会返回到原小区上发HandoverFailure消息,如果返回原小区也失败,意味着Ms与网络脱离联系,发生了切换失败掉话。
2.2.切换失败的主要原因
切换失败的主要原因:
1、参数设置不合理。
存在同频同BSIC的邻区,切换门限设置不合理(偏高、偏低、边缘切换门限比功控门限高),换优先级设置不合理最佳小区统计时间P、N设置不合理,外部小区描述数据表”的CGI、BCCH、BSIC等与对方实际数据不符,MSC中配置的“位置区小区表”的BSC的目的信令点错误;
2、
覆盖。
如果目标小区与源小区之间没有足够的重叠覆盖区域,切换可能应无法登陆目标小区的TCH而失败。
在这种情况下,重新回到旧小区的概率会较低;
3、干扰。
由于干扰而引起的高误码率,使得移动台不能与BTS建立起第二层链路,导致切换失败;
4、基站硬件故障。
CDU故障、载频故障、时钟板故障、内部通信电缆;
5、天馈系统,天馈驻波比过大,小区天线安装反,小区天线安装不规范、小区方位角、下倾角不合理,天线隔离度不满足要求,电缆扭曲或接头不紧、错误等;
6、与其他厂家对接对端在A接口、E接口的各类信令与我方不一致,不能识别或不支持,导致切换失败。
如语音版本、切换号码、TUP电路、寻址方式(CGI或LAI)等。
2.3.问题处理流程:
建议以无线参数检查及硬件排查的方法定位。
另外,可通过创建切换观测任务,分析至每个目标小区的切换失败率情况。
TCH切换失败问题的处理步骤如下:
检查无线参数设置是否合理,如邻区是否存在同频同色,切换参数是否设置合理、外部小区数据配置数据正确等,对不合理的参数进行优化调整;
1、检查BER、空闲干扰带等级等指标,减小消除无线干扰;
2、通过路测检查覆盖情况。
针对覆盖差或目标小区与源小区之间没有足够的重叠覆盖区域,需重点排查硬件故障,改善覆盖;
3、检查小区硬件,如检查CDU、收发信机、时钟板,板件间的射频连线等,对故障硬件进行排查更换;
4、检查天馈系统,如排查天馈驻波比,同一小区的天线是否朝向一致,有无天馈线接错接反等问题,对存在的故障进行排查更换;
TCH切换失败问题的处理流程图如下:
3.TCH分配失败问题处理
3.1.TCH分配失败的定义
移动台在SDCCH信道向BSC发出要求分配TCH信道的请求,而未能成功接入TCH信道的情况。
必需是移动台主叫或被叫,不包括切换(除小区内切换)。
话音信道分配失败率是按照如下的公式计算的:
忙时话音信道分配失败总次数(不含切换)/忙时话音信道试呼总次数(不含切换)*100%,其中:
“忙时话音信道试呼总次数(不含切换)”是指所有占用SDCCH后对TCH的试呼次数。
统计的为第一步中MSC向BSC发出的分配请求消息“AssignmentRequest”;
“忙时话音信道分配失败总次数(不含切换)”是指占用SDCCH后不能成功占用TCH的所有呼叫总次数。
统计的为分配失败消息“AssignmentFailure+ClearRequest(radiointerfacefailure)”。
分配失败的原因可能是BSC无可用的TCH资源,在新信道上发生了低层故障等。
话音信道分配流程:
ASSIGNMENTFAILURE是和ASSIGNMENTREQUEST对应的,反映了一次TCH分配失败。
对于第
(1)种失败情形,其原因多数情况下是由于没有空闲的信道;对于第
(2)种失败情形,其原因是由于基站故障而导致信道分配失败;对于第(3)种失败情形,主要指发生在空中接口的信道指派失败,原因有覆盖、干扰等等。
3.2.分配失败的主要原因
常见的TCH信道分配失败可能由以下的故障引起:
Ø小区话务拥塞
小区的拥塞率很高,当MS申请话音信道时,系统会发现无TCH资源可以分配,导致分配失败。
Ø硬件故障
收发信机故障:
当TRX出现故障时,一般分配失败率都会很高,而且切入失败也会很高,因为切入时BSC也会给MS指配信道。
如果小区分配失败率超过了10%,那么TRX故障的可能性最大。
对这部分小区,为了定位是哪个载频引起的问题,可录取这些小区的Abis口信令,从信令分析上帮助找出导致分配失败的具体的载频。
合路器故障,如无前向功率输出等。
Ø同频或者邻频干扰
由于干扰而引起的高误码率,使得移动台不能与BTS建立起第二层链路,导致分配失败。
Ø天馈系统出现故障
由于天馈线受到折损、腐蚀,导致因驻波比过高而影响收发性能。
主分集天线受到阻挡或覆盖不均匀。
当仅携载TCH的天线受到障碍物的阻挡或覆盖的地区和另一根携带BCCH或者SDCCH信道的天线不一样时,就有可能导致MS占用不上该TCH信道。
Ø参数不合理
如果采用了跳频,而HSN或MAIO设置的不合理,可能导致小区内或跳频组相同的小区间的同频或邻频干扰较大,从而导致分配失败严重。
如果T3107设置的过小,使得网络在未收到指配完成时,就由于T3107的逾时已将信道释放掉。
ØA接口或Abis接口传输故障
如果A接口或者Abis接口传输误码率大,就会导致MS和网络之间的不能正常的完成信令的交换,从而导致分配失败现象。
Ø直放站造成的影响
当采用室外直放站时候,一般采用微波传输的方式。
因此直放站在将所需基站的上下行信号放大的同时,也会将干扰信号放大,从而引起信号质量的下降,最终导致掉话,从而导致TCH分配失败率明显的上升。
3.3.问题处理流程:
建议以无线参数检查及硬件排查的方法定位。
TCH分配失败问题的处理步骤如下:
1、检查小区话务是否存在拥塞,如存在,应通过扩容、话务均衡等方法来解决;
2、检查小区无线参数设置是否合理,如跳频参数、频率数据等,对不合理的参数进行优化调整;
3、检查BER、空闲干扰带等级等指标,减小消除无线干扰;
4、检查小区硬件,如收发信机、合路器、分路器,板件间的射频连线等,对故障硬件进行排查更换;
5、检查天馈系统,如排查天馈驻波比,同一小区的天线是否朝向一致,有无天馈线接错接反等问题,对存在的故障进行排查更换;
TCH分配失败问题处理流程:
4.TCH/SDCCH拥塞问题处理
随着移动通信行业的发展,竞争机制的引入以及用户对网络质量需求的提高,无线网的服务质量愈加显得重要,网络服务质量的好坏具体体现在拥塞率、掉话率、通话品质等网络指标上,其中,拥塞会给用户的正常通信带来诸多不便,因而成为用户申告的热点问题。
此外,无线系统网络拥塞还是考核网络运行情况的重要指标,拥塞率过高同时也会影响系统的掉话率、切换成功率、接通率等指标,所以如何降低无线系统网络拥塞,提高网络运行质量是当务之急。
无线网拥塞大致有两类:
一类是话音信道的拥塞即TCH的拥塞,另一类是信令信道的拥塞即SDCCH的拥塞。
4.1.Sdcch拥塞
Sdcch信道的申请与分配:
当BSC收到Ms通过Bts发来的信道请求后,就会查询Sdcch信道资源,发现没有可用的Sdcch时,BSC将向移动台发出“ImmediateAssignmentReject” ,该消息还包含T3122,它定义了暂时禁止移动台发出下次呼叫的最小时间间隔,以避免网络进一步的拥塞。
4.2.Tch拥塞
Tch信道的申请与分配:
当BSC收到Msc下发的“AssignmentRequest”,就会查询Tch信道资源,发现没有可用的Tch时,BSC将会向MSc返回“AssignmentFailure”消息,原因为没有可用的无线资源,上图中为第
(1)种失败类型。
4.3.无线网拥塞产生的原因
通常造成信道阻塞的主要原因是:
1.话务密度高,超出基站的设计容量;
2.设备硬件故障。
如由于设备的不稳定造成的可用资源缺乏,信道拥塞;
3.邻小区存在故障;
4.LAC规划不合理。
如LAC的边界在高话务地带、主要交通干道等用户多且移动频繁的区域,使得位置更新过于频繁形成不合理的呼叫模型,降低了系统容量;
5.无线参数设置不合理。
如小区重选滞后,切换容限,小区切出触发电平等定义的不合理造成的乒乓位置更新和乒乓切换;
6.覆盖过大,存在孤岛现象。
4.4.问题处理流程:
建议以无线参数检查及硬件排查的方法定位。
TCH拥塞问题的处理步骤如下:
1、检查小区和它的邻小区是否工作正常,检查TCH可用性以确定不稳定设备。
如邻小区工作不正常,本小区会额外承担其部分话务;
2、检查话务移动性,看是否是由于过量来切换引起的TCH拥塞,如存在,可通过优化切换参数(增加HO_Margin)来减少邻区至拥塞小区的切换次数,来减小拥塞;
3、检查无线参数设置。
如小区重选滞后,切换容限,小区切出触发电平等定义的不合理造成的乒乓位置更新和乒乓切换;
4、通过场强测试,分析是否覆盖过大,有孤岛现象存在。
当某一区域出现一个小区的覆盖孤岛时,由于在这样的点通常都检测不到预定义的邻小区,这就势必会造成移动台始终保持在起呼服务小区上,无论信号发生怎样的变化也不能正常切换,直至掉话。
为了避免这样的情况,可以采取两种手段:
最好是调整孤岛小区的天线,消除孤岛现象。
但由于电波传播的复杂性,要做到消除孤岛而又不明显影响覆盖区域,往往要经过多次试验,而且难以彻底消除高层建筑的孤岛现象。
另外一个手段是:
为孤岛小区定义新的邻小区,其参数的定义原则是:
从孤岛小区向正常小区的切换/位置更新优先于反方向的切换/位置更新;
5、拥塞由话务密度高引起。
检查基站是否已达最大配置,否,规划扩容足够数量的Trx。
Tch拥塞问题处理大致流程图如下:
Sdcch拥塞问题的处理步骤如下:
1、检查小区是否工作正常,检查Sdcch可用性以确定不稳定设备;
2、检查话务移动性,看是否是由于过量位置更新引起的Sdcch拥塞;
3、如过量位置更新引起,检查LAC规划是否合理;如合理,可通过优化小区重选滞后来降低位置更新次数;不合理,就需考虑改变LAC边界以减少位置更新;
4、拥塞由话务高造成,检查Tch的信道数以及话务量,在Tch话务不高无拥塞的前提下,可增加Sdcch信道;适当加大计时器T3122。
Sdcch拥塞问题处理大致流程图如下:
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- TCH 切换 拥塞
![提示](https://static.bingdoc.com/images/bang_tan.gif)