由于IuCS口负荷分担光路问题导致掉话处理报告
由于Iu-CS口负荷分担的光路出现问题导致掉话问题处理报告关键字Iu-CS；负荷分担； AAL2PATH；MTP3B故障现象现场测试发现一些基站下有时会出现：CS接通时RNC向CN发起一条“RAB Release Request”。告警信息RNC的IuCS光接口板欠功率告警。原因分析由于Iu-CS口负荷分担的光路出现问题导致接通时RNC立即向CN发起RAB Release Request。处理步骤1、首先跟踪UE的信令，发现接通时RNC立即向CN发起RAB Release Request，释放的原因是“unspecified-failure”。如下：发现整个信令流程从“RRC connection request”到“RAB Assignment Resp”和connect acknowledge的“DIRECT _TRANSFER”都正常。由此可以判断，RNC和CN间Iu-CS信令控制面是正常的。RNC向CN发送一条消息“RAB_RELEASE_REQ”，由此判断RNC和CN间的Iu-CS用户面异常。2、使用DSP AAL2PATH查询RNC的Iu_CS用户面是否正常。发现RNC的25条AAL2 PATH的状态都是“不拥塞、空闲、可用”，都正常。3、使用DSP MTP3BLNK，发现RNC的Iu_CS控制面8条通道中前4条可用，而后4条不可用。4、RNC的Iu_CS的接口组网方式是采用APS 1+1方式，即APS负荷分担。APS 1+1，也就是RNC的Iu_CS接口使用2个光接口板A、B，2块单板负荷分担处理Iu_CS口；每块单板上有2个Iu_CS光口，2个光口互为主备。开通设备时，如果不对Iu-CS的AAL2 PATH端口进行测试，则Iu-CS的AAL2 PATH状态不能进行刷新，一直保持“不拥塞、空闲、可用”，即正常。所以，第一次开通时需要进行Iu-CS的AAL2 PATH测试。测试完毕后，其Iu-CS的AAL2 PATH的状态和实际情况一致。目前的状态是由于没有进行Iu-CS的AAL2 PATH测试，所以其状态一直是“正常”。A、B两块光板对Iu_CS口进行负荷分担，每块光板上光口1、2互为备份。在A光板上Iu_CS的用户面配置了前13条AAL2 PATH和前4条MTP3B链路；在B光板上Iu_CS的用户面配置了前12条AAL2 PATH和后4条MTP3B链路。由于B光板上的Iu_CS链路的信令控制面和用户面都不正常，所以需要排查B单板的光口或单板或光纤是否有问题。一般情况下，一个CS业务在Iu_CS口的多条MTP3B链路和AAL2 PATH通道是随机分配的。根据查询结果，只有A板的Iu_CS口的MTP3B链路可用，A板和B板Iu_CS口的AAL2 PATH通道可用，实际上B板Iu_CS口的AAL2 PATH通道不可用。所以，进行CS业务，其控制面一定分配在正常的A板，如果用户面链路分配在不正常的B板上时，则会出现“接通时RNC立即向CN发起RAB Release Request 而掉话”；其控制面一定分配在正常的A板，如果用户面链路也分配在正常的A板上时，则其业务能够成功。5、检查CN和RNC侧的Iu-CS光接口板，发现RNC侧的Iu-CS的B光接口板有欠功率告警，更换光纤后故障消失，RNC下的CS业务回复正常。故障总结新开通的RNC，一定要进行Iu口的AAL2 PATH测试，否则其状态无法实时刷新，而导致业务时通时不通。
