 |
善于提问，勤于回答，你也是专家
|
 |
SDCCH的掉话数很高且内切也很高，无上行干扰，无拥塞等。请问解决方法和原因
SDCCH的掉话数高且内切也很高，小区话务量不高，TCS统计的其他指标都良好。请问解决方法和原因？
我要回答
问题答案
这是我找到的一些资料，希望对楼主有用
（一）1、Nokia系统的SDCCH掉话本身统计就很高， 这与其Counter定义有关，基站只要收到了Channel request后，就会分配SDCCH，如果是Ghost的SD请求，那么等待T3101超时后，会记为掉话，这类掉话会表现为SDCCH掉话中Abis类，其实Nokia系统中SDCCH掉话中大多数均为该类型www.mscbsc.com0i!^.J7V:d
2、如果突发的SDCCH掉话达到了50％以上，基本通过重启BCF后会恢复，这一般由于进程故障导致；www.mscbsc.com(B&^0U2h.I0h$E
3、通过调整RET参数（改小）可以减少Ghost的Channel request，降低全网的SDCCH掉话
4、小区的BCCH受到干扰时，或存在同频同BSIC现象，SDCCH掉话会偏高，可修改BCCH频点移动通信论坛为国内领先的通信技术论坛，我们专注于移动通信技术，通信工程师的网上家园。'j,P6H4[3c E+_
5、查看是否存在SDCCH的7745告警，确认是否为载频故障，可重启载频恢复等移动通信论坛为国内领先的通信技术论坛，我们专注于移动通信技术，通信工程师的网上家园。3{7V.H4i%X7b'A#m*F
6、如果SDCCH的RF类型高，你就需要注意了，可能与TCH频点干扰、硬件故障等有关，这类SDCCH掉话对用户实质影响较大
7、对于SDCCH A口掉话，也会经常产生异常，通过重启BCF可恢复MSCBSC 移动通信论坛.5p3~5L.j;P/A
8、网络负荷太高会产生大面积的SDCCH ABIS掉话高，我在某地做优化时，情人节那天交换机负荷太高导致了大面积呼叫瘫痪，小区基本表现为高ABIS的SDCCH掉话移动通信,通信工程师的家园,通信人才,求职招聘,网络优化,通信工程,出差住宿,通信企业黑名单6X&N6e#w;n
9、当然，你提到的HYS规划对SDCCH掉话也有影响的，这个对于那个系统都是一样的
（二）（1）若只出现几天，又自然好转，则有可能是掉死，解决方法有：开关跳频、重LOAD、更换TRHwww.mscbsc.com+C#~5o i)|3A)O2_0T
（2）更换BSIC
（3）更换BCCH
（4）可能为载波故障，逐个闭载波找出是哪个载波有故障
（5）可能为载波故障，关跳频后重新激活，然后观察MOTS，看能否找出有故障载波 | 国内领先的通信技术论坛&`%m)T#v8s,P
（6）若为弱信号掉话居多，则可以将ACCMIN调高，再将CRO调高 | 国内领先的通信技术论坛.B*v"L$["?;k8d5R(O
（7）可能是频点干扰太厉害了，换些干净的频点
（8）更换一下硬件，
&`!k7O/e
最快速的方法是将SDCCH放到其他硬件上试一下。
（三）http://www.mscbsc.com/bbs/viewthread.php?tid=95215&highlight=sdcch
http://www.mscbsc.com/bbs/viewthread.php?tid=6368&highlight=sdcch
（四）SDCCH建立呼叫失败的几种原因
失败原因码
Cause Value 描述 可能的原因
Cause Value 31
“正常， 未详细说明”
这原因通常报告一个正常的事件仅仅当在正常的类别没有另外的原因适用时。 BSS（TCH拥塞）或MSC问题
Cause Value 34
“没有可用的电路/信道”
(在Assignment Command前) 这原因显示有目前得不到适当的电路/隧道处理呼叫。 TCH拥塞
Cause Value 34
“没有可用的电路/信道”(在Assignment Command后) 这原因显示有目前得不到适当的电路/隧道处理呼叫。 MSC拥塞
Cause Value 41
“暂时的失败”
(在Assignment Command前) 这原因显示网络运行异常, 达到要求的情况不能持续一个长的时段，移动电台可以很快地尝试另一次的呼叫。 BSS问题， 尤其是硬件问题
Cause Value 41
“暂时的失败”
(在Assignment Command后) 这原因显示网络运行异常, 达到要求的情况不能持续一个长的时段，移动电台可以很快地尝试另一次的呼叫。 MSC问题
Cause Value 42
“交换设备拥塞” 这原因显示交换设备正处于高通信量的处理时期。 MSC拥塞
Cause Value 44
“请求电路/信道不可用” 当电路或信道请求的实体不能被另一边接口提供时这原因被返还。 BSS问题，尤其是CIC拥塞
Cause Value 111
“协议错误， 未详细说明” 这原因通常报告一个协议差错事件，仅仅当在协议差错类别没有另外的原因适用时。 BSS或MSC问题
（五），TX和MAXRET这两个参数对于无线资源的合理利用有着举足轻重的影响，合理地取值与搭配，可以疏通无线通道，减少空中接口的冲突次数，降低SDCCH的掉话率，并减少不必要的重复试呼，避免恶性循环，有助于寻呼成功率、系统接通率和稳定性的提高。
（六） 如果SD分配失败率高，请确认是否存在以下问题：1、是否存在拥塞，解决拥塞问题牵涉到诸多问题，需要注意话务均衡、扩容、硬件排障、接入参数设置等；2、是否存在上行干扰，上行干扰往往导致接入困难，需注意对上行干扰原因的排查；3、是否存在较多的低电平起呼，用户在信号较弱的地方起呼，会导致SD接入时长偏长，而较多的低电平起呼会使SD总体占用时长偏长而导致假拥塞，解决这类问题往往需要通过调整天线、调节功控参数或增加延伸系统来解决。如果以上问题都不是，或者不是很明显，无法正确判断，建议更换BCCH载频的频点，选择较为干净的频点试试。
建议楼主在论坛搜索一下SDCCH掉话，有很多回答。
（一）1、Nokia系统的SDCCH掉话本身统计就很高， 这与其Counter定义有关，基站只要收到了Channel request后，就会分配SDCCH，如果是Ghost的SD请求，那么等待T3101超时后，会记为掉话，这类掉话会表现为SDCCH掉话中Abis类，其实Nokia系统中SDCCH掉话中大多数均为该类型www.mscbsc.com0i!^.J7V:d
2、如果突发的SDCCH掉话达到了50％以上，基本通过重启BCF后会恢复，这一般由于进程故障导致；www.mscbsc.com(B&^0U2h.I0h$E
3、通过调整RET参数（改小）可以减少Ghost的Channel request，降低全网的SDCCH掉话
4、小区的BCCH受到干扰时，或存在同频同BSIC现象，SDCCH掉话会偏高，可修改BCCH频点移动通信论坛为国内领先的通信技术论坛，我们专注于移动通信技术，通信工程师的网上家园。'j,P6H4[3c E+_
5、查看是否存在SDCCH的7745告警，确认是否为载频故障，可重启载频恢复等移动通信论坛为国内领先的通信技术论坛，我们专注于移动通信技术，通信工程师的网上家园。3{7V.H4i%X7b'A#m*F
6、如果SDCCH的RF类型高，你就需要注意了，可能与TCH频点干扰、硬件故障等有关，这类SDCCH掉话对用户实质影响较大
7、对于SDCCH A口掉话，也会经常产生异常，通过重启BCF可恢复MSCBSC 移动通信论坛.5p3~5L.j;P/A
8、网络负荷太高会产生大面积的SDCCH ABIS掉话高，我在某地做优化时，情人节那天交换机负荷太高导致了大面积呼叫瘫痪，小区基本表现为高ABIS的SDCCH掉话移动通信,通信工程师的家园,通信人才,求职招聘,网络优化,通信工程,出差住宿,通信企业黑名单6X&N6e#w;n
9、当然，你提到的HYS规划对SDCCH掉话也有影响的，这个对于那个系统都是一样的
（二）（1）若只出现几天，又自然好转，则有可能是掉死，解决方法有：开关跳频、重LOAD、更换TRHwww.mscbsc.com+C#~5o i)|3A)O2_0T
（2）更换BSIC
（3）更换BCCH
（4）可能为载波故障，逐个闭载波找出是哪个载波有故障
（5）可能为载波故障，关跳频后重新激活，然后观察MOTS，看能否找出有故障载波 | 国内领先的通信技术论坛&`%m)T#v8s,P
（6）若为弱信号掉话居多，则可以将ACCMIN调高，再将CRO调高 | 国内领先的通信技术论坛.B*v"L$["?;k8d5R(O
（7）可能是频点干扰太厉害了，换些干净的频点
（8）更换一下硬件，
&`!k7O/e
最快速的方法是将SDCCH放到其他硬件上试一下。
（三）http://www.mscbsc.com/bbs/viewthread.php?tid=95215&highlight=sdcch
http://www.mscbsc.com/bbs/viewthread.php?tid=6368&highlight=sdcch
（四）SDCCH建立呼叫失败的几种原因
失败原因码
Cause Value 描述 可能的原因
Cause Value 31
“正常， 未详细说明”
这原因通常报告一个正常的事件仅仅当在正常的类别没有另外的原因适用时。 BSS（TCH拥塞）或MSC问题
Cause Value 34
“没有可用的电路/信道”
(在Assignment Command前) 这原因显示有目前得不到适当的电路/隧道处理呼叫。 TCH拥塞
Cause Value 34
“没有可用的电路/信道”(在Assignment Command后) 这原因显示有目前得不到适当的电路/隧道处理呼叫。 MSC拥塞
Cause Value 41
“暂时的失败”
(在Assignment Command前) 这原因显示网络运行异常, 达到要求的情况不能持续一个长的时段，移动电台可以很快地尝试另一次的呼叫。 BSS问题， 尤其是硬件问题
Cause Value 41
“暂时的失败”
(在Assignment Command后) 这原因显示网络运行异常, 达到要求的情况不能持续一个长的时段，移动电台可以很快地尝试另一次的呼叫。 MSC问题
Cause Value 42
“交换设备拥塞” 这原因显示交换设备正处于高通信量的处理时期。 MSC拥塞
Cause Value 44
“请求电路/信道不可用” 当电路或信道请求的实体不能被另一边接口提供时这原因被返还。 BSS问题，尤其是CIC拥塞
Cause Value 111
“协议错误， 未详细说明” 这原因通常报告一个协议差错事件，仅仅当在协议差错类别没有另外的原因适用时。 BSS或MSC问题
（五），TX和MAXRET这两个参数对于无线资源的合理利用有着举足轻重的影响，合理地取值与搭配，可以疏通无线通道，减少空中接口的冲突次数，降低SDCCH的掉话率，并减少不必要的重复试呼，避免恶性循环，有助于寻呼成功率、系统接通率和稳定性的提高。
（六） 如果SD分配失败率高，请确认是否存在以下问题：1、是否存在拥塞，解决拥塞问题牵涉到诸多问题，需要注意话务均衡、扩容、硬件排障、接入参数设置等；2、是否存在上行干扰，上行干扰往往导致接入困难，需注意对上行干扰原因的排查；3、是否存在较多的低电平起呼，用户在信号较弱的地方起呼，会导致SD接入时长偏长，而较多的低电平起呼会使SD总体占用时长偏长而导致假拥塞，解决这类问题往往需要通过调整天线、调节功控参数或增加延伸系统来解决。如果以上问题都不是，或者不是很明显，无法正确判断，建议更换BCCH载频的频点，选择较为干净的频点试试。
建议楼主在论坛搜索一下SDCCH掉话，有很多回答。
回答者：tigermarx 回答时间：2008-11-25 23:43
23
29够精彩的了,
就个人所知,就是同频干扰或是硬件故障了,
佩服这位大侠
就个人所知,就是同频干扰或是硬件故障了,
佩服这位大侠
SDCCH的掉话数高且内切也很高，小区话务量不高，TCS统计的其他指标都良好。请问解决方法和原因？
兄弟曾经遇到了NOkia系统微蜂窝基站覆盖办公楼，现象和上面描述相似。后来发现这个办公楼内有手机生产车间，和手机测试车间，手机测试要进行拨打测试，通常拨打112，测试方式是拨通后挂机，可是问题出在这些测试人员为了完成任务，不安规范操作，拨通后就拔电池来“关机”，这样节约时间，不进行正常的关机。这样一来，基站统计SDCCH掉话，而且掉话高是在上班时间。我寻问手机测试车间的主管他说他们的员工都安规范进行测试操作，我建议主管强调一下操作规范，半个小时候掉话率由原来的35%下降到3%。
兄弟曾经遇到了NOkia系统微蜂窝基站覆盖办公楼，现象和上面描述相似。后来发现这个办公楼内有手机生产车间，和手机测试车间，手机测试要进行拨打测试，通常拨打112，测试方式是拨通后挂机，可是问题出在这些测试人员为了完成任务，不安规范操作，拨通后就拔电池来“关机”，这样节约时间，不进行正常的关机。这样一来，基站统计SDCCH掉话，而且掉话高是在上班时间。我寻问手机测试车间的主管他说他们的员工都安规范进行测试操作，我建议主管强调一下操作规范，半个小时候掉话率由原来的35%下降到3%。
回答者：cn-xa@126.com 回答时间：2008-11-30 11:42
1、掉话高确实会引起７７４５告警，首先查看ＢＳＣ有无７６０７、7606等有关载频、天线、连接跳线、合路器等告警，如果有做相应处理。
2、以上原因排除外，考虑载频内时隙功率下降和收发电平值不平衡。载频时隙功率一般在41-47DB，收发电平一般在110-117，收和发一般相差不得大于10DB。检测办法：BSC先将整个小区或者整个站锁起，然后通过Nokia BTS Manager软件Test菜单分别对小区内每个载频的每个时隙进行测试，测试时注意选择同个时隙对不同载频进行测试，如选择同个载频对不同时隙测试有可能不准确。测试结果如果不达标，则更换载频。
2、以上原因排除外，考虑载频内时隙功率下降和收发电平值不平衡。载频时隙功率一般在41-47DB，收发电平一般在110-117，收和发一般相差不得大于10DB。检测办法：BSC先将整个小区或者整个站锁起，然后通过Nokia BTS Manager软件Test菜单分别对小区内每个载频的每个时隙进行测试，测试时注意选择同个时隙对不同载频进行测试，如选择同个载频对不同时隙测试有可能不准确。测试结果如果不达标，则更换载频。
回答者：coolnews88 回答时间：2008-11-30 13:28
载波有故障，不然不会有那么频繁的内切。
