VoLTE无法寻呼案例分析.docx

《VoLTE无法寻呼案例分析.docx》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、VoLTE无法寻呼案例分析一、问题现象：在进行VoLTE测试时，在做UE主被叫测试时，发现UE处在idle状态下，无法被寻呼到。二、问题分析1.基站故障问题：对测试基站进行告警查看，无任何告警，查询历史告警，也无异常。在该基站下作数据业务，也为发行异常，排除基站故障引起的可能性；2.核心网设置问题：对核心网侧发端进行抓包，确定Paging已经发出。3.参数设置问题：在基站侧，确定是否收到Paging包。若收不到，那么，就要排查传输。若收到，就是eNodeB本身的问题。4.而确定基站是否收到Paging方法有2种。可以上前台用Wires

2、hark抓包，也可以后台通过信令确定是否收到Paging消息。使用后台系统工具-----统一信令跟踪，对Paging进行跟踪。因此，确定，基站自身收到核心网发来的Paging消息，问题排查，关注基站本身。三、优化方案1.终端UE收到的寻呼消息中如果带有UEID列表，终端需要用自己的UEID来跟寻呼消息中携带的UEID一一进行匹配，以判断此寻呼消息是否是在呼叫自己。同时，在寻呼消息中如果所指示PagingID是S-TMSI，则表示本次寻呼是一个正常的业务呼叫；如果PagingID是IMSI，则表示本次寻呼是一次异常的呼叫，用于网络侧的错

3、误恢复，此种情况下终端需要重新做一次附着(Attach)过程。1.从传输信道角度来看，最终由PDSCH下行共享物理信道承载寻呼信息。在接收寻呼消息之前，终端UE需要先去监听PDCCH物理信道，然后根据PDCCH物理信道上是否有携带P-RNTI，来判断网络在本次寻呼周期是否有发寻呼消息给自己。2.终端在一个DRX的周期内，可以只在相应的寻呼无线帧(PF)上的寻呼时刻(PO)先去监听PDCCH上是否携带有P—RNTI，进而去判断相应的PDSCH上是否有承载寻呼消息。如果在PDCCH上携带有P—RNTI，就按照PDCCH上指示的PDSCH的

4、参数去接收PDSCH上的数据；如果终端在PDCCH上未解析出P—RNTI，则无需再去接收PDSCH物理信道，就可以依照DRX周期进入休眠。利用这种机制，在一个DRX周期内，终端可以只在PO出现的时间位置上去接收PDCCH，然后再根据需要去接收PDSCH。而在其它时间可以睡眠，以达到省电的目的。3.反复排查基站本身的配置，由于是涉及寻呼的问题，因此，检查【无线业务配置→UE寻呼】。由于是涉及VoLTE下的寻呼问题，因此，当Paging周期置为最小时，在idle态下的VoLTE呼叫建立时延能够达到最小，所以，在进行Idle态下时延相关测试

5、时，设置“UE监听寻呼场合的DRX循环周期”为“32帧”。具体见下图：按照上述分析修改完后，被叫UE寻呼正常，问题解决：一、经验总结：针对VoLTE测试时，根据现有的测试经验，当Paging周期置为最小时，在idle态下的VoLTE呼叫建立时延能够达到最小，所以，在进行Idle态下时延相关测试时，设置“UE监听寻呼场合的DRX循环周期”为“32帧”。