在进行VoLTE测试时，在做UE主被叫测试时，发现UE处在idle状态下，无法被寻呼到。

1、基站故障问题；

对测试基站进行告警查看，无任何告警，查询历史告警，也无异常。在该基站下作数据业务，也为发行异常，排除基站故障引起的可能性；

2、核心网设置问题；

对核心网侧发端进行抓包，确定Paging已经发出。

3、参数设置问题；

在基站侧，确定是否收到Paging包。若收不到，那么，就要排查传输。若收到，就是eNodeB本身的问题。

而确定基站是否收到Paging方法有2种。可以上前台用Wireshark抓包，也可以后台通过信令确定是否收到Paging消息。 使用后台系统工具-----统一信令跟踪，对Paging进行跟踪。

因此，确定，基站自身收到核心网发来的Paging消息，问题排查，关注基站本身。

（1）终端UE收到的寻呼消息中如果带有UE ID列表，终端需要用自己的UE ID来跟寻呼消息中携带的UE ID一一进行匹配，以判断此寻呼消息是否是在呼叫自己。 同时，在寻呼消息中如果所指示Paging ID是S-TMSI，则表示本次寻呼是一个正常的业务呼叫；如果Paging ID是IMSI，则表示本次寻呼是一次异常的呼叫，用于网络侧的错误恢复，此种情况下终端需要重新做一次附着(Attach)过程。

（2）从传输信道角度来看，最终由PDSCH下行共享物理信道承载寻呼信息。在接收寻呼消息之前，终端UE需要先去监听PDCCH物理信道，然后根据PDCCH物理信道上是否有携带P-RNTI，来判断网络在本次寻呼周期是否有发寻呼消息给自己。

（3）终端在一个DRX的周期内，可以只在相应的寻呼无线帧(PF)上的寻呼时刻(PO)先去监听PDCCH上是否携带有P—RNTI，进而去判断相应的PDSCH上是否有承载寻呼消息。如果在PDCCH上携带有P—RNTI，就按照PDCCH上指示的PDSCH的参数去接收PDSCH上的数据；如果终端在PDCCH上未解析出P—RNTI，则无需再去接收PDSCH物理信道，就可以依照DRX周期进入休眠。利用这种机制，在一个DRX周期内，终端可以只在PO出现的时间位置上去接收PDCCH，然后再根据需要去接收PDSCH。而在其它时间可以睡眠，以达到省电的目的。

（4）反复排查基站本身的配置，由于是涉及寻呼的问题，因此，检查【无线业务配置→UE寻呼】。由于是涉及VoLTE下的寻呼问题，因此，当Paging周期置为最小时，在idle态下的VoLTE呼叫建立时延能够达到最小，所以，在进行Idle态下时延相关测试时，设置“UE监听寻呼场合的DRX循环周期”为“32帧”。

具体见下图：

按照上述分析修改完后，被叫UE寻呼正常，问题解决。

针对VoLTE测试时，根据现有的测试经验，当Paging周期置为最小时，在idle态下的VoLTE呼叫建立时延能够达到最小，所以，在进行Idle态下时延相关测试时，设置“UE监听寻呼场合的DRX循环周期”为“32帧” 。