volte掉话案例分析 TD-SCDMA掉话案例分析_图文.doc

volte掉话案例分析 TD-SCDMA掉话案例分析_图文 导读：就爱阅读网友为您分享以下“TD-SCDMA掉话案例分析_图文”的资讯，希望对您有所帮助，感谢您对92的支持! 内部公开▲ 二扇区220度，三扇区330度。为了证实掉话点的信号覆盖，通过后台将晋祠2扇区毙掉，毙掉后在路测软件中还是发现能接入晋祠2扇区，如图1.2-1所示，邻区界面显示服务小区是晋祠2小区，不过通过rab建立消息中我们可以看到Cell ID为41473，而晋祠的小区ID为49682，所以判定该呼叫是建立在小区41473上面的。从这里我们就发现肯定是同频同扰导致路测软件中邻区关系里面显示有误。切换目标小区关键参数是频点和扰码，如果同频同扰的话必然导致切换出现问题。在观察图1.1-2发现小区41473就是晋源南街3小区，就在掉话点的正东方，而这个小区的频点和扰码也为10120和90，该小区与晋源2 图1.2-1 3小区的信号3小区的邻区中没有配置的有晋祠2小区，当终端发现10120频点和扰码90后，会当做是晋祠2RNC下发的物理信道重配消息中可以看出，如图1.2-2中，在RNC下发的物理信道重配消息中，目标小区ID是49682晋祠2小区。接着UE上发重配完成，是在10120和扰码90的信道上上发，切换成功后下发测量控制，当然测量控制的信息是小区晋祠2的相关邻区关系。从上面的进程中发现了异常，就是物理信道是通过晋源南街3接入的，而相关的切换参数却是涉及到晋祠2小区。最终导致了上述的异常掉话。而这样的同频同扰现象让我们加大了分析出干扰源小区的难度，如果之前就发现是晋源南街3小区覆盖过远，将其天馈工程参数做调整的话，不会出现这样的问题。 本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 13 内部公开▲ 图1.2-2 3.3. 解决方法及验证 2小区的扰码，让其不和晋源南街33小区的天馈工程参数减少其覆盖范围。通过调整晋祠2小区的必要邻区加上后，业务可以正常切换3小区进行过渡切换。通过第二种方法将晋源南街32度压至6度，晋源南街3小区不是问题点的主覆2小区和晋祠3小区来覆盖，不在出现掉话现象。 2小区更改