CDMA案例介绍

DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍珠海世纪鼎利通信科技股份有限公司2008年11月16日鼎利通信,鼎力支持DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话12007年9月11日海南现场测试时，被叫在9:10:56出现了一次掉话。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话1从无线参数来看，RxAGC=-96dBm，TotalEcIo=-24dB，TxAGC=20dBm，很明显是脱网了，造成此次掉话。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话22008年9月26日长春现场测试时，主叫在2:00:47出现了一次掉话。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话2从现场的无线参数来看，移动台的接收功率(RxAGC=-51dBm)和导频信号(TotalEc/Io=-1.06dB)都很好，移动台的发射功率达到最大(TxAGC=24dBm)，FFER增加到100％，一定时间后移动台在同一导频上初始化。移动台的接收功率和导频信号EcIo都很好，说明前向链路很好，而移动台的输出功率却已达到最大，说明反向链路很差。这表明前反向链路严重不平衡。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话2前反向链路不平衡的原因：1、反向链路存在强干扰；2、用户过多导致反向链路阻塞；3、基站发送的导频功率过高。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话32008年4月28日，锦州测试时主叫在3:52:28发生一次掉话。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话3从无线参数来看，掉话前的无线环境较好；通过信令窗口来看，手机连续收到了多条UniversalHandoffDirectionMessage，由此可以推断是基站发了切换命令，但手机一直没有回应，一定时间后停止了前向业务信道的发射，导致掉话。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话42008年10月29日，广州天河区测试时主叫在1:46:03发生一次掉话。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话4从无线指标来看前反向的覆盖都很好，从信令分析来看掉话前手机连续发送多个PowerMeasurementReportMessage，应该是反应链路误码率比较高，导致基站收不到这条消息，连续收到多个坏帧后基站停止发射引起掉话。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话5【现象描述】2010年7月上海-南京高铁测试无锡段语音测试05:29:23主叫手机掉话，经纬度：120.30624731.587165掉话前最后一个EcIo好的位置DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话5掉话后EcIo突然变差的位置DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话5EcIo突然变差后FFER随即恶化DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话5前向链路失败，掉话时激活集状况DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话5【原因分析】主叫手机的激活集导频信号突然变差（从-5到-16dB），手机监测到PN33和PN165进入候选集，上报PSMM消息后由于前向很差没有收到下发的切换指导消息导致掉话，掉话后手机同步到PN165；手机频繁的连续的上报PMRM，前向FER恶化达到90%以上，前向变得非常差，激活集EcIo在掉话前始终非常差。可以看到这是一个典型的信号突变导致的来不及软切换造成的掉话。【优化建议】高铁由于速度快，信号被阻挡后来不及切换，因此必须保证覆盖的连续性。建议检查振奋厂第三扇区和中百集团第一扇区的覆盖，看这两个扇区PN447和PN33是否在高铁路线上有明显的阻挡，如果有可以考虑抬高天线或者在阻挡物上增加信号转发设备。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话6【现象描述】2010年7月上海-南京高铁测试南京段语音测试06:06:08主叫手机掉话，经纬度：118.94646832.1386679掉话点的位置和信息DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话6掉话前手机切换请求信息DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话6掉话前切换完成信息，PN147无法加入激活集DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话6系统无法响应手机后续上报的切换请求DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－掉话6【原因分析】主叫手机在呼叫过程中监测到PN288和PN417并进入候选集，上报PSMM消息后完成切换并将PN288加入激活集，但是PN417在信号很强的情况下一直无法加入激活集，系统在手机回切换完成消息后（HCM）没有发送扩展邻区更新消息（ENLU）,同时此时前向FFER迅速升高到97%，系统也无法响应手机后续上报PSMM消息添加PN417进入激活集的请求。手机连续上报PMRM，FFER达到100%，前向变得越来越差。这是一个由于近端强信号无法软切换加入激活集造成的掉话。【优化建议】检查测试时掉话发生时间红枫公园基站第三扇区ＰＮ４１７的工作情况和性能指标，是否工作异常导致手机无法切换到这个小区。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－接入失败12008年10月29日，广州天河区测试，主叫在2:18:40发生了一次接入失败。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－接入失败1从信令分析来看，主叫发出Originationmessage，收到了基站的回应PCHOrder-BaseStationAcknowledgement，但后续没有收到基站下发的ChannelAssignmentMessage，而收到SyncMessage，导致接入失败。从无线指标来看，EcIo值很差，下行链路不是很好，所以很可能是基站下发的ChannelAssignmentMessage移动台没有收到引起的。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－接入失败22008年10月29日，广州天河区测试时，主叫在1:49:43发生了一次接入失败。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－接入失败2分析前面的正常呼叫，通话时长都是1分30秒，而本次接入失败从起呼到SyncMessage的时长也是1分30秒，结合手机信令分析发现，其它信令都正常，就是缺少了ServiceConnectMessage和ServiceConnectCompleteMessage，应该是关键信令丢失引起的接入失败。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－接入失败32008年9月26日，河南郑州测试时，被叫在3:00:41发生了一次接入失败。DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－接入失败3通过查看参数发现Num_Step=3，MAX_RSP_SEQ=2；每个AccessProbeSequence由1……1+NUM_STEP个AccessProbe组成；达到了呼叫尝试次数，移动台初始化，导致接入失败；DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－接入失败4【现象描述】上海-南京0718苏州段7月18号05:20:06被叫手机未接通，经纬度：120.5906331.328428手机寻呼响应时信号强度DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－接入失败4前向链路失败手机无法接收到系统确认消息DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－接入失败4呼叫接入路段前向信号很弱DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－接入失败4PN15信号弱手机无法重选到该小区DingliCommunicationsInc.鼎利通信鼎力支持CDMA案例介绍－接入失败4【原因分析】被叫手机占用小区PN183收到基站下发的寻呼指令，上报PageResponseMessage进行响应，接入时PN183的信号强度迅速恶化，TotalEc/Io降到-18.58dB，前向链路失败导致手机无法收到系统确认消息而未接通。被叫手机响应寻呼时正对该路段的PN441和PN15信号都很差，手机占用背向信号覆盖到该路段的PN183进行响应寻呼。【优化建议】观察被叫手机，在未接通发生前短时间内在PN183和PN15之间发生了来回的切换，说明该地无主导频，建议调整PN15和PN441两个小区天线角度加强该路段的信号覆盖，调整PN183小区天线角度避免该小区覆盖该路段，使手机有一个稳定的主导频，不会因为信号的突然恶化而发生未接通。DingliCommunicationsInc.鼎利通信鼎力支持CDMA1X/EVDO案例介绍－掉线1徐州—连云港铁路0708数据上行鼎利2中的FTP上传掉话DingliCommunicationsInc.鼎利通信鼎力支持CDMA1X/EVDO案例介绍－掉线1【现象描述】徐州—连云港铁路0708数据上行鼎利7月8日14:42:08.186FTP上传发生PPP掉话，经纬度：117.39897934.267965这个PPP掉话被识别成UserDrop，下一个正常的PPP呼叫被识别成PPPDrop，应该是异常事件判断导致的。从以下FTPDrop事件统计中可以看到。FTP事件列表窗口DingliCommunicationsInc.鼎利通信鼎力支持CDMA1X/EVDO案例介绍－掉线1接收电平图DingliCommunicationsInc.鼎利通信鼎力支持CDMA1X/EVDO案例介绍－掉线1上传速率图DingliCommunicationsInc.鼎利通信鼎力支持CDMA1X/EVDO案例介绍－掉线1QuickConfig消息ColorCode=1DingliCommunicationsInc.鼎利通信鼎力支持CDMA1X/EVDO案例介绍－掉线1QuickConfig消息ColorCode=0DingliCommunicationsInc.鼎利通信鼎力支持CDMA1X/EVDO案例介绍－掉线1【原因分析】可以看到在该路段，接收电平良好，DRC请求正常，上传速率在600k以上，信令上没有问题，突然PPP层发生了释放，随后进行了PPPSession的重建，可以看到在PPP挂断后，手机进行了UATI请求分配，说明手机跨越了不同RNC。通过检查QuickConfig消息可以看到，ColorCode从1变到0（14：39：17.778最后一次收到ColorCode=1,14：39：17.778时变为0），从ColorCode变化到释放PPP进行UATI申请中间隔了2分50秒，我们怀疑这次PPP释放和A13口相关设置或者跨PDSN的AN切换相关定时器有关。【优化建议】我们在分析中发现了多次这类跨AN的PPP掉话，有的是从安徽境内进入江苏导致的，这是和跨PDSN未启用MobileIP有关系的，而省内的跨AN的PPP掉话要知道PDSN和AN的组网结构及相关接口配置。建