今天群里有人提问，如果UE发生了小区重选，UE是否会存在漏寻呼的可能？
现实生活中有时会遇到这样的情况，A给B打电话，没有打通，但是B的手机也没有显示未接电话。
以我自己的一点认识，来谈一下自己对这个漏寻呼问题的理解，如果有理解不正确的地方，欢迎大家拍砖！
首先，问题说的是重选，那么UE是处在IDLE态的，在NR中，或者也可能是Inactive态了。在之前的介绍中有提到过，对于IDLE和Inactive，UE底层的行为是一样的。
其次，给UE的寻呼是在一个Tracking Area中的所有基站都会进行下发的，而且一般不会只在一个周期性时间点上发送，会在若干个寻呼周期上都下发。
Tracking AreaCode是在SIB1中广播的。
例如，小区A，B，C具有相同的Tracking Area Code，在从小区A重选到小区B的过程，读取小区B的SIB1，发现小区B与小区A的Tracking Area Code，那么直接驻留小区B。UE再根据小区B的Paging配置，在小区B上接收寻呼。
一般来说，Paging的周期应该远大于SIB1的周期。
这种情况下，先不考虑UE端的问题，一般漏寻呼的可能是网络配置的重选参数/门限不太合理，在实际环境下，例如发现某个地方经常寻呼失败，网优需要做的事情是优化参数吧。
当然，不同厂家的UE，接收机性能不一样，可能存在X厂家的UE寻呼失败，而Y厂家的UE可以正常寻呼的可能。
这里疑问是，如果UE在小区A接收到寻呼，同时又触发了重选过程，那么这种处理是否有协议规定？觉得应该是重选到小区B，然后再在小区B上进行随机接入吗？
如果小区A和小区B的Tracking Area Code不一样，那么首先肯定不会在小区B上下发寻呼。
在读取了小区B的SIB1之后，发现Tracking Area Code不一致，UE先进行的是Tracking Area Code Update过程，告知网络UE所处的Tracking Area Code发生了变化，后续如果有寻呼，则在新的Tracking Area Code下的小区对UE发送寻呼请求。
由于这种情况下，网络在接收到UE的Tracking Area Code Update请求之后，网络之间是否有交互，例如是否会告知该UE在旧的Tracking Area有被寻呼过，然后再发起寻呼过程等我也不太确定。
如果不会，那么这种情况下也会存在漏寻呼的可能。
最后，有一个区别是，在IDLE态Tracking Area Code变化是进行Tracking Area Code Update过程，在Inactive态下是进行判断RAN-based notification area是否变化进行RAN-based notification area update (RNAU)。
欢迎评论指导和拍砖