? UE空闲态时：语音业务下发S1 Paging（S-TMSI、CS域）， 短信业务下发S1 Paging
（S-TMSI、PS域）
? UE连接态时：语音业务下发NAS 层CS service notificaion（TMSI标识），短信
则可直接下发给UE
4) 因为覆盖或其他原因，空闲态的终端没有及时响应寻呼，MME未收到该终端的CSFB
呼叫建立请求（Extended Service Request消息），也不会未返回SGs-service-request给SGs MSC
5) 根据配置的寻呼策略, SGs MSC将在寻呼间隔的定时器超时后，使用IMSI方式在SGs
接口发起对该用户的二次/三次寻呼，给MME下发SGs-Paging（IMSI、LAI、业务类型为CS）
6) MME根据用户的存储数据和状态，在S1接口下发寻呼消息
? UE空闲态时：语音业务下发S1 Paging（IMSI、CS域）， 短信业务下发S1 Paging
（S-TMSI、PS域）
? UE连接态时：语音业务下发NAS 层CS service notificaion（IMSI标识），短信
则可直接下发给UE
7) 若终端此时接收到该寻呼，在LTE网络发起响应，发送Extended Service Request消
息给MME；MME收到后，发送SGs-service-request给MSC，之后指示eNodeB CSFB连接释放，发送重定向命令指引终端回落
8) UE回落至GSM网络后，因为LTE寻呼使用IMSI，在GSM发送Paging Response（IMSI），
若回落跨LA，则将先执行位置更新，发送LAU（IMSI、CSMT标识）消息给BSC 9) 因核心网部署MSC POOL, 接收到该Paging Response（IMSI）的NNSF网元（BSC或
MGW），看到IMSI，若IMSI寻呼时记录的IMSI-MSC映射表中没有发现相关记录，就按照负荷分担原则选择并路由Paging Response（IMSI）或LAU（IMSI）至MSC POOL内任意一个MSC
10) 如果该MSC与UE联合注册/位置更新的SGs MSC不同， 即收到IMSI寻呼响应的
MSC与下发SGs-Papging（IMSI）的SGs MSC不同，被叫失败
流程中第（5）步到第（10）步可参见如下示意图，图中示意了MSC SGs接口采用IMSI寻呼、MME也仅采用IMSI寻呼导致的被叫失败。
21
图4-2 MSC SGs接口采用IMSI寻呼导致被叫失败示意图
3. 问题分类：核心网设备实现 4. 解决方案
案例中问题由于MSC在SGs接口以IMSI方式进行二次寻呼时，MME也以IMSI方式寻呼终端所致。解决方案可基于MSC或基于MME，同存在三种解决方案，如下：
1) 基于MME方案：MSC下发SGs-Paging（IMSI、LA、业务=CS/SMS）时，MME根据
数据库中用户的数据和状态（有效数据、SGs接口状态等），正常情况下总是按照S-TMSI方式寻呼
2) MSC分别配置SGs和2/3G接口的寻呼参数方案：2/3G的二次/三次寻呼可以配置
IMSI方式，但SGs接口永远为TMSI方式。
3) 过渡方案：MSC以IMSI方式寻呼时同时在SGs和同LA的2/3G接口寻呼方案：在
2/3G寻呼时，NNSF 网元（BSC或MGW）就可以记忆下发2G Paging（IMSI）消息的MSC和IMSI的映射关系，在CSFB终端回落至2G发送Paging response（IMSI）时，NNSF 网元（BSC或MGW）可以根据映射表正确路由消息至发起SGs-Paging（IMSI）的MSC。因该方案会增加2G 同LA下的寻呼量，且在同MSC POOL内，若UE跨LA回落时方案实效，呼叫失败；此外UE在跨MSC POOL回落时即使网络部署了MTRF功能也会因LAU流程使用IMSI原因，无法触发MTRF导致呼叫失败，不推荐。
测试过程中，因MME尚不支持方案1）、MSC尚不支持方案2），只能采用过渡方案，方案3），通过修改MSC配置方式暂时规避了被叫失败问题。
22
目前，已要求各厂家MME支持方案1），从而彻底避免该问题的发生。 5. 效果评估
杭州外场TA-LA匹配、终端回落同LA的场景下没有问题。
待厂家MME实现了方式1) 后，需要基于现网MSC POOL场景进一步验证。
4.2.2 案例2：网络与终端DRX寻呼周期不一致导致被叫失败
1. 现象描述
某城市现网测试中，在LTE强覆盖区域，CSFB UE处于空闲态，被叫CSFB UE失败概率接近70%，但CSFB UE主叫成功率较高。 2. 问题分析
该案例中呼叫失败以被叫为主，但测试区域LTE为强覆盖区域，可排除因信号覆盖因素造成的被叫失败。此后，检查被叫失败的CSFB UE LoG，发现UE一直未收到LTE网络侧下发的寻呼消息（Paging），检查eNodeB LoG，发现eNodeB已下发该UE的寻呼消息。进一步检查eNodeB配置，系统消息System Information Block 2中defaultPagingCycle配置为1280ms，终端根据此周期侦听寻呼，但实际上eNodeB却以320ms为周期下发寻呼，从而导致终端与网络间收发寻呼周期不匹配，导致被叫较大概率失败。通过进一步分析终端、网络侧各接口LoG，问题最终定位为由于不同厂家MME与eNodeB对于协议理解差异，导致网络与终端DRX（Discontinuous Reception，非连续性接收）寻呼周期不一致，空闲态终端不能正常接收寻呼消息，寻呼失败。
终端处于空闲态时，LTE网络寻呼机制如下： 1) DRX的工作机制和UE对寻呼消息的接收：
处于节电的考虑，UE的寻呼接收遵循非连续接收（DRX）的原则。eNodeB会通过系统消息广播小区默认的DRX寻呼周期给小区中所有UE。此外，标准也允许每个UE根据自身的电量等设置UE特定的DRX参数，并通过NAS消息Attach Request、TAU Request等上报给MME。
之后，UE在一个DRX的周期内，只在响应的寻呼无线帧（PF）上的寻呼时刻（PO）先去监听PDCCH上是否携带有P-RNTI，进而去判断响应的PDSCH上是否有承载寻呼消息。如果在PDCCH上携带有P-RNTI，就按照PDCCH上指示的PDSCH的参数去接收PDSCH上的数据；如果终端在PDCCH上未解析出P-RNTI，则无需再去接收PDSCH物理信道，就可以依照
23
DRX周期进入休眠。利用这种机制，在一个DRX周期内，终端可以只在PO出现的时间位置上去接收PDCCH，然后再根据需要去接收PDSCH。而在其他时间可以休眠，以达到省电的目的。
关于PF的计算，有公式SFN mod T=（T/N）*（UE_ID mod N），凡满足该公式的所有SFN的值，都是PF。PF计算中相关参数含义如下：
? T=min(TUE,TC)，TUE指UE特定DRX周期，TC指eNodeB广播的默认DRX周期；
? N=min(T,nB)，nB由网络在SIB2中广播； ? UE_ID=IMSI mod 1024。
PO是终端需要监听的PDCCH在寻呼无线帧上的子帧号，因此计算出PF后，需再计算出本终端的PO在PF上的位置i_s，然后再根据i_s与PO之间的映射关系，从而精确地获得终端应去监听的PDCCH物理信道所出现的精确的时间位置。其中，i_s=floor(UE_ID/N)mod Ns。 2) 寻呼DRX参数的传递和寻呼消息的发送：
LTE核心网MME对每个eNodeB使用寻呼消息（Paging）发起寻呼过程，每条寻呼消息携带一个被寻呼的用户信息，包括：UE Paging Identity（IMSI，或S-TMSI）、Paging DRX、CN Domain（CS域，或PS域）和List of TAIs等字段，其中Paging DRX参数为可选。eNodeB接收到Paging消息后，解读其中的内容，得到该用户终端的跟踪区域标示（TAI）列表，并在其下属于列表中跟踪区的小区进行空口寻呼。
eNodeB在空口Uu寻呼用户时，可以使用其配置的小区默认DRX参数，该参数在SIB2中下发小区内所有UE。
eNodeB在空口Uu寻呼用户时，也可以使用UE自己上报的特定DRX参数。UE在Attach Request、TAU Request等非接入层（NAS，Non Access Stratum）消息中告知MME，MME在发送给eNodeB的Paging消息通过Paging DRX参数携带该UE特定的DRX参数，eNodeB对接收到Paging消息中携带的UE特定的DRX和其默认DRX参数取小后，以此作为寻呼周期下发寻呼。该原则与UE侧接收寻呼消息时的T取值原则一致，即没有UE特定DRX参数时按照eNodeB广播的DRX参数接收，若有UE特定DRX参数时与广播的DRX参数取小后接收。
综上所述，LTE网络寻呼机制和MME、eNodeB、UE DRX的参数的总结如下：
24
表4-1 网络及终端DRX参数
UE MME DRX参数名称 UE specific DRX Paging DRX defaultPagingCycle 给所有UE eNodeB 通过S1-Setup Request或ENB CONFIGURATION 必选 Default paging DRX 参数所在消息 UE特定DRX，通过NAS消息上报给MME 通过S1接口Paging消息发送给eNodeB 小区默认DRX寻呼周期，通过Uu接口SIB2下发类型 可选 可选 必选 UPDATE 上报给MME
不同厂家MME设备如何下发Paging DRX，以及不同厂家eNodeB设备如何决定实际的
寻呼下发周期的协议理解和实现略有不同，本案例出现问题正由此导致。具体原因分析如下：
1) 厂家A的eNodeB配置SIB2中下发的defaultPagingCycle为1280ms，测试UE未设置
特定DRX（UE specific DRX），也未上报UE特定的DRX参数，因此待UE收到SIB2得知小区默认DRX寻呼周期后，按照T=min(TUE,TC)=1280ms侦听寻呼。
图4-3 终端收取系统消息SIB2消息中default Paging Cycle
2) 厂家A的eNodeB配置S1-Setup Request消息中Default paging DRX固定为320ms，
并上报给MME；因UE未设置特定DRX，通过NAS上报给MME的DRX为空；厂家B的MME获知上述消息后，虽然UE未上报特定DRX，仍通过S1 Paging消息下发
25