VoLTE无法寻呼案例分析

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

2、否收到 Paging消息。使用后台系统工具统一信令跟踪，对 Paging进 行跟踪。-LtEldentii/lhcieWaiuenumbife = 10严 ink却何片111 W(BIT)Kp-uEPaglrtglD |-i- ui-s_ThflSi77 tOpftegsL IE_Ext&nsionsPresent = 0 -miviEC-眄恃n 11_TMSIn&cts = 4data=c5 IbSfWCHEX)因此，确定，基站自身收到核心网发来的Paging消息，问题排查，关注基站本身。三、优化方案1. 终端UE收到的寻呼消息中如果带有UE ID列表，终端需要用自己的 UE

3、 ID来跟寻呼消息中携带的UE ID 一一进行匹配，以判断此寻呼消息是否是在呼叫自己。同时，在寻呼消息中如果所指示 Paging ID是S-TMSI,则表示本次寻呼是一个正常的业务呼叫；女口 果Paging ID是IMSI，则表示本次寻呼是一次异常的呼叫，用于网络侧的错误恢复，此 种情况下终端需要重新做一次附着(Attach)过程。2. 从传输信道角度来看，最终由PDSCH下行共享物理信道承载寻呼信息。在接收寻呼消息之前，终端 UE需要先去监听 PDCCH物理信道，然后根据 PDCCH物理信道上是否有 携带P-RNT，来判断网络在本次寻呼周期是否有发寻呼消息给自己。3. 终端在一个DRX的周期

4、内，可以只在相应的寻呼无线帧(PF上的寻呼时刻(PO)先去监听PDCCH±是否携带有P RNTI,进而去判断相应的 PDSCH上是否有承载寻呼消息。如果 在PDCCH上携带有P RNTI,就按照PDCCH±指示的PDSCH的参数去接收 PDSCH上的 数据；如果终端在 PDCCH上未解析出P RNTI,则无需再去接收 PDSCH物理信道，就 可以依照DRX周期进入休眠。利用这种机制，在一个DRX周期内，终端可以只在PO出现的时间位置上去接收PDCCH然后再根据需要去接收PDSCH而在其它时间可以睡眠，以达到省电的目的。4. 反复排查基站本身的配置，由于是涉及寻呼的问题，因此，检查【无线业务配置tUE寻呼】。由于是涉及 VoLTE下的寻呼问题，因此，当Paging周期置为最小时，在idle态下的VoLTE呼叫建立时延能够达到最小，所以， 在进行Idle态下时延相关测试时，设置“ UE监听寻呼场合的 DRX循环周期”为“ 32帧”。具体见下图：4|1MIMMt 14：W： U四、经验总结：针对VoLTE测试时，根据现有的测试经验，当Paging周期置为最小时，在呼叫建立