案例关于NBIoT eDRX时钟问题导致寻呼失败问题案例.docx

1、案例关于NBIoT eDRX时钟问题导致寻呼失败问题案例关于NB-IoT eDRX时钟问题导致寻呼失败问题案例一、问题描述用户来电反映深圳的NB-IoT网络在eDRX模式下，客户定制的APN下行无法下发。二、原因分析2.1现场测试分析现场测试，用户所在区域RSRP达到-64dBm，SINR值达到了12dB，如下图所示。图1 NB-IoT信号测试图从测试数据可以看出，用户所在区域NB信号覆盖良好，上行灌包也正常，因此可以排除无线覆盖类问题。2.2后台指标分析 查询后台服务小区无告警，关键指标正常:图2 服务小区指标2.3信令跟踪分析 Uu信令表明用户终端主动发起释放：图3 Uu口信令在Uu口信令

2、跟踪中，用户终端能正常附着网络，但马上主动释放连接，怀疑客户终端或模组问题。联系用户，用户表示其终端在示波器上一直是有信号的，初步排除客户终端问题，怀疑MME与基站侧的基准时间存在偏差，导致eDRX模式下NB寻呼失败。2.4时间同步分析 eDRX特性对eNB与MME时间同步诉求如图4所示。图4 eDRX特性时间同步诉求说明：寻呼消息是MME与UE约定的，到了这个时刻附近UE会启动接收窗口。其它时间UE处于休眠状态，可以省电为了减少寻呼消息的缓存时间，MME只在寻呼快到的时刻发寻呼消息（提前12秒发送）。要求MME、eNB、UE之间时间同步，由于eNB与UE本身是同步的；所以要求MME与eNB之

3、间同步。为了满足UE和MME侧对寻呼消息的约定，协议要求MME和eNodeB满足时间同步，同步精度为为12秒。MME以及eNB侧分别接入各自的时间参考基准，就可以满足eNB和MME的同步。2.5eDRX参数核查 检查现网时间同步配置，情况如下：eNB时标eNB侧方案MME时标时标对齐方式GPS频率同步+NTP超帧同步GPSeNB与MME配置相同的起始时间，MME GPS时标配置要考虑当前的闰秒偏置说明：eNB侧与MME侧时标对齐，因为eNB和MME会根据各自的时标计算超帧号，如果不对齐超帧号就不一致。通用场景里的GPS时标相差闰秒值（比如：以GPS起始，基于1980/1/6号的起始时间，截止2

4、018年闰秒相差18秒，后续每12年闰秒会增加1秒，所以每半年需要审视IERS官方网以站发布的闰秒差进行调整。eNB侧采用频率同步提供业务SFN帧连续偏置，利用NTP计算超帧号；可以确保eNB侧与MME侧的超帧对齐，超帧整体有10秒，超帧偏差有+/- 5秒，为了满足eDRX要求，需要核心网提前5+2=7秒左右发送给eNB，也就是要提前7秒发送。查询服务小区eDRX功能已开启，核心网时间源为GPS，基站侧时间源为NTP，已是闰秒差18s。图5 eNodeB时间源图6 MME时间源MME和eNB侧配置eDRX都使用UTC参考时间2010-01-01 00:00:00，UTC本身不需要考虑闰秒差，但

5、eNB侧计算帧号时使用其全局配置闰秒差18s，导致MME侧下发寻呼时间比eNB晚18s,但从配置上看，已有18s闰秒差。再次同客户联合测试，并在后台同步跟踪，客户反馈回测试结果：一开始平台下发数据下来，都能收到，然后停止1015分钟没有任何操作，再下发数据下来，刚开始几包数据下发之后，一直没收到，后面发多几次之后，就能收到后面的数据了，但是前面的几包已经丢失了。怀疑还是时间差问题，导致数据不同步。 三、解决方案eNB侧采用频率同步提供业务SFN帧连续偏置，利用NTP计算超帧号；可以确保eNB侧与MME侧的超帧对齐，超帧整体有10秒，超帧偏差有+/- 5秒，为了满足eDRX要求，需要核心网提前5

6、+2=7秒左右发送给eNB，也就是要提前7秒发送，修改脚本如下：SET TIMESRC: AUTOSWITCH=OFF;/关闭自动切换开关参数修改说明：外部时间源自动切换开关需要关闭，否则可能会发生时间源的切换，导致HSFN起始时间变化，影响eDRX寻呼。SET FNSYNCTIME: FNSYNCSW=ON, DATE=1980&01&06, TIME=00&00&07; /打开CIoT帧号同步调整开关，设置时间日期 参数修改说明：频率同步时，eNodeB的配置起始时间为DATE=1980&01&06, TIME=00&00&07，目的是为了达到MME寻呼消息提前7秒下发的目的。四、效果评估

7、参数修改后，用户故障已恢复，从基站日志分析，eDRX寻呼已能正常发到UE: 图7 eNodeB收到MME下发的eDRX寻呼消息图8 eDRX已经生效 图9 eNodeB将eDRX寻呼消息下发给UE五、总结及推广在本次案例中，由于NB-IoT eDRX模式基准时间存在偏差，NB寻呼失败，导致终端无法接收到下行报文。该类问题由于涉及到用户模组、核心网，无法单方面发现问题，因此需要无线侧联合核心网、用户侧同步配合测试分析，才能发现和解决问题。由于时钟类问题与硬件关系密切，本案例发生后，我们对优化关注的时钟类知识进行了梳理，各地市可以根据网络的实际情况，采取相应的时钟源和时钟参数。5.1时钟同步方式影

8、响对比LTE网络有两种同步方式：时间同步（符号完全对齐，RS信号互相干扰）和频率同步（符号不对齐）。频率同步相对于时间同步，RS SINR更高，路测SINR（只能测量到RS的信号质量）显得更高。随着负荷的增加，本小区的RS受到邻小区的数据域干扰变大，差异变小。频率同步和时间同步场景下RS SINR和Data SINR对比如下表。场景频率同步时间同步服务小区RS SINR偏移0/4/7/11符号（邻区相对服务小区）RS Power/(PCFICH+Noise)其它偏移RS Power/Noise 偏高RS Power/(PCFICH+Noise)偏低服务小区Data SINR偏移0/3/7/10

9、符号（邻区相对服务小区）Data Power/RS(12RE/RB)其它偏移Data Power/RS(16RE/RB) Data Power/RS(12RE/RB)实测数据与理论预期一致：（1）空载场景下：频率同步的SINR要优于时间同步约2dB左右；频率同步方式下吞吐率5%以内的提升（RS干扰降低改善中远点解调性能）。（2）有负荷场景下：随负荷增加，时间同步和频率同步的差异减少(30%负荷时，频率同步占优；负荷增加，差异减小)。建议：GPS时间同步方式为站间ULComp和站间SFN等新业务提前部署，在暂时没有业务需求的情况下站点配置为频率同步。5.2eNodeB 时钟源解决方案eNodeB

10、有多重时钟源，包括GPS、IEEE1588V2、NTP、自由振动等，下面对不同的时钟源优缺点进行对比，实际网络可以根据实际情况进行配置。图10 不同的时钟源优缺点对比5.3eNodeB关于GPS解决方案图11 GPS典型解决方案说明：使用RG8U跳线，GPS天线到基站的馈线长度不得超过150m；使用RG8U跳线+GPS放大器， GPS天线到基站的馈线长度不得超过270m；功分2路：使用RG8U跳线，GPS天线到基站的馈线长度不得超过130m；功分2路：使用RG8U跳线+GPS放大器， GPS天线到基站的馈线长度不得超过250m；功分4路：使用RG8U跳线，GPS天线到基站的馈线长度不得超过11

11、0m；功分4路：使用RG8U跳线+GPS放大器， GPS天线到基站的馈线长度不得超过230m；GPS超长拉远场景优先使用RGPS方案，如果必须使用GPS放大器，只支持GPS放大器安装在室内的场景。GPS放大器内置防雷，可以安装在避雷器前面或者后面。 建议放大器与GPS天线之间的距离在50m150m范围内，但前提要满足室内安装的要求。放大器需要做绝缘处理。为了便于维护，需要记录放大器安装位置（例如在设计图纸中说明）。对于CL共GPS的情况图12 CL共GPS的情况注意事项：功分2路：使用1/2跳线，GPS天线到基站的馈线长度不得超过80m（分路器到基站的2根馈线不重复计算）。功分2路：使用RG8

12、U跳线，GPS天线到基站的馈线长度不得超过50m（分路器到基站的2根馈线不重复计算）。功分4路：使用1/2跳线，GPS天线到基站的馈线长度不得超过60m（分路器到基站的4根馈线不重复计算）。功分4路：使用RG8U跳线，GPS天线到基站的馈线长度不得超过50m（分路器到基站的4根馈线不重复计算）。5.4eNodeB关于1588V2时钟解决方案图13 1588V2时钟解决方案网络结构图说明：实现1588的时间同步，要求数据承载网中的所有中间设备都支持1588协议。时间同步推荐方案：采用逐跳支持1588的方案，采用二层组播、全网BC的方式，全网BC方式时所有承载网设备都工作在BC模式，每个节点都进行

13、时间和频率精确同步，适用于环形组网、树形组网、链型组网、星型组网等各种场景时间同步时，每一个节点都通过同步报文和上级节点进行同步，中间的传输节点实现1588BC功能，接收上级的时钟报文，终结报文并和上级进行同步，同时根据同步状态给下级节点下发时钟报文，通过这种一级一级的同步实现全网的时间同步注意事项：时间同步模式下需要进行不对称补偿。按照1588协议的假设，双向线路传输路径是对称的。但在实际工程施工过程中，难以完全保证光纤的对称性，这会带来1588计算的不准确性，导致时间上有一个固定延迟（一般4ns/m），对于这部分固定延迟，需要通过人工补偿的方式进行修正。目前基站只支持作为叶子节点来实现1588时间同步，不支持作为hub节点的1588功能，即基站不支持BC功能。