LTE网络与终端DRX寻呼周期不一致导致CSFB失败分析

摘要：随着LTE网络的发展，CSFB作为一种新的语音方案成为4G通信的一个重要组成部分，它基于原有成熟2G和3G网络来满足4G初期对于语音通信的需求。文章结合实际案例来探讨CSFB呼叫失败问题，意在提升客户感知。关键词：LTE网络寻呼；CSFB呼叫失败

1现象描述

某城市现网测试中，在LTE强覆盖区域，CSFB UE处于空闲态，被叫CSFB UE失败概率接近70%，但CSFB UE主叫成功率较高。

2问题分析

该案例中呼叫失败以被叫为主，但测试区域LTE为强覆盖区域，可排除因信号覆盖因素造成的被叫失败。此后，检查被叫失败的CSFB UE LoG，发现UE一直未收到LTE网络侧下发的寻呼消息（Paging），检查eNodeBLoG，发现eNodeB己下发该UE的寻呼消息。进一步检查eNodeB配置，系统消息System Information Block 2中defaultPagingCycle配置为1280ms，终端根据此周期侦听寻呼，但实际上eNodeB却以320ms为周期下发寻呼，从而导致终端与网络间收发寻呼周期不匹配，导致被叫较大概率失败。通过进一步分析终端、网络侧各接口LoG，问题最终定位为由于不同厂家MME与eNodeB对于协议的理解差异，导致网络与终端DRX（DiscontinuousReception，非连续性接收）寻呼周期不一致，空闲态终端不能正常接收寻呼消息，寻呼失败。

终端处于空闲态时，LTE网络寻呼机制如下：

（1）DRX的工作机制和UE对寻呼消息的接收。

出于节电的考虑，UE的寻呼接收遵循非连续接收（DRX）的原则。eNodeB会通过系统消息广播小区默认的DRX寻呼周期给小区中所有UE。此外，标准也允许每个UE根据自身的电量等设置UE特定的DRX参数，并通过NAS消息AttachRequest，TAU Request等上报给MME。

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

关于PF的计算，有公式SFN mod T=（T/N）*（UE_ID modN），凡满足该公式的所有SFN的值，都是PF。PF计算中相关参数含义如下：①T=min（TUE，TC），TUE指UE特定DRX周期，TC指eNodeB广播的默认DRX周期；②N=min（T，nB），nB由网络在SIB2中广播；③UE_ID=IMSI mod 1024。

P0是终端需要监听的PDCCH在寻呼无线帧上的子帧号，因此计算出PF后，需再计算出本终端的P0在PF上的位置i_s，然后再根据i_s与P0之间的映射关系，从而精确地获得终端应去监听的PDCCH物理信道所出现的精确的时间位置。其中，i s=floor（UE ID/N）mod Ns。

（2）寻呼DRX参数的传递和寻呼消息的发送。

LTE核心网MME对每个eNodeB使用寻呼消息（Paging）发起寻呼过程，每条寻呼消息携带一个被寻呼的用户信息，包括：UE Paging Identity（IMSI或S-TMSI），Paging DRX，CNDomain（CS域或PS域）和List of TAIS等字段，其中PagingDRX参数为可选。eNodeB接收到Paging消息后，解读其中的内容，得到该用户终端的跟踪区域标示（TAD列表，并在其下属于列表中跟踪区的小区进行空口寻呼。

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的参数的总结如表1所示。

不同厂家MME设备如何下发Paging DRX，以及不同厂家eNodeB设备如何决定实际的寻呼下发周期的协议理解和实现略有不同，本案例出现问题正由此导致。具体原因分析如下：

（1）厂家A的eNodeB配置SIB2中下发的defaultPagingCycle为1280ms，测试uE未设置特定DKX（UE specific DRX），也未上报UE特定的DR）（参数，因此待UE收到SIB2得知小区默认DRX寻呼周期后，按照T=min（TUE，TC）=1280ms侦听寻呼（见图1）。

（2）厂家A的eNodeB配置S1-Setup Request消息中Default Paging DRX固定为320ms，并上报给MME；因uE未设置特定DRX，通过NAS上报给MME的DRX为空；厂家B的MME获知上述消息后，虽然uE未上报特定DRX，仍通过S1 Paging消息下发Paging DRX给eNodeB，且Paging DRX与DefaultPaging DRX相同，均为320ms（见图2）。

（3）厂家A的eNodeB收到Paging DRX（320ms）后，即认为UE上报了特定DRX给MME，将其与配置的默认DRX周期（1280ms）取小后，得到下发寻呼的周期320ms。

由问题分析可知，在UE未上报特定DRX时，厂家B的MME按照厂家A的eNodeB上报的Default Paging DRX下发Paging DRX，且厂家A的eNodeB在S1-setup Request上报给MME的DRX和通过SIB2下发给uE的DRX周期不一致，两者结合导致终端侦听寻呼和网络下发寻呼的周期不一致，从而导致被叫失败。

3问题分类

核心网设备设置问题。

4解决方案

MME是否在S1 Paging消息中下发Paging DRX需考虑uE是否上报特定DRX，即如果UE上报了特定DRX，S1 Paging中才携带Paging DRX，否则不可以携带。若携带Paging DRX，则接收到的eNodeB需对Paging DRX和默认DRX周期取小后，作为该用户下发寻呼的周期。

eNodeB在S1-Setup Request消息中携带的Defaultpaging DRx与SIB2下发的defaultPagingCycle需保持一致。

5效果评估

目前厂家B的MME可通过修改软参262303为0，这样在S1Paging消息中的Paging DRX参数只以uE上报的特定DRX参数为准：如果UE上报则在S1寻呼中携带Paging DRX参数，否则就不携带，不再参考eNodeB在Sl setup中上报的DefaultPaging DRX参数。效果待验证。

此外，也可通过厂家A的eNodeB修改上报的DefaultPaging DRX与SIB2下发的defaultPagingCycle一致的方式解决。效果待验证。

6结语

CSFB问题的分析重点首先在于区别是4G侧的问题还是2G，3G网络的问题，其次根据方向来优化CSFB质量，既要保障4G参数配置以及无线环境的良好，更要在成熟的2G，3G网络上多下功夫，精益求精。