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

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

《案例关于NBIoT eDRX时钟问题导致寻呼失败问题案例.docx》由会员分享，可在线阅读，更多相关《案例关于NBIoT eDRX时钟问题导致寻呼失败问题案例.docx（11页珍藏版）》请在冰豆网上搜索。

案例关于NBIoTeDRX时钟问题导致寻呼失败问题案例

关于NB-IoTeDRX时钟问题导致寻呼失败问题案例

一、问题描述

用户来电反映深圳的NB-IoT网络在eDRX模式下，客户定制的APN下行无法下发。

二、原因分析

2.1现场测试分析

现场测试，用户所在区域RSRP达到-64dBm，SINR值达到了12dB，如下图所示。

图1NB-IoT信号测试图

从测试数据可以看出，用户所在区域NB信号覆盖良好，上行灌包也正常，因此可以排除无线覆盖类问题。

2.2后台指标分析

查询后台服务小区无告警，关键指标正常:

图2服务小区指标

2.3信令跟踪分析

Uu信令表明用户终端主动发起释放：

图3Uu口信令

在Uu口信令跟踪中，用户终端能正常附着网络，但马上主动释放连接，怀疑客户终端或模组问题。

联系用户，用户表示其终端在示波器上一直是有信号的，初步排除客户终端问题，怀疑MME与基站侧的基准时间存在偏差，导致eDRX模式下NB寻呼失败。

2.4时间同步分析

eDRX特性对eNB与MME时间同步诉求如图4所示。

图4eDRX特性时间同步诉求

说明：

●寻呼消息是MME与UE约定的，到了这个时刻附近UE会启动接收窗口。

其它时间UE处于休眠状态，可以省电

●为了减少寻呼消息的缓存时间，MME只在寻呼快到的时刻发寻呼消息（提前1~2秒发送）。

●要求MME、eNB、UE之间时间同步，由于eNB与UE本身是同步的；所以要求MME与eNB之间同步。

●为了满足UE和MME侧对寻呼消息的约定，协议要求MME和eNodeB满足时间同步，同步精度为为1~2秒。

●MME以及eNB侧分别接入各自的时间参考基准，就可以满足eNB和MME的同步。

2.5eDRX参数核查

检查现网时间同步配置，情况如下：

eNB时标

eNB侧方案

MME时标

时标对齐方式

GPS

频率同步+NTP超帧同步

GPS

eNB与MME配置相同的起始时间，MMEGPS时标配置要考虑当前的闰秒偏置

说明：

●eNB侧与MME侧时标对齐，因为eNB和MME会根据各自的时标计算超帧号，如果不对齐超帧号就不一致。

●通用场景里的GPS时标相差闰秒值（比如：

以GPS起始，基于1980/1/6号的起始时间，截止2018年闰秒相差18秒，后续每1~2年闰秒会增加1秒，所以每半年需要审视IERS官方网以站发布的闰秒差进行调整。

●eNB侧采用频率同步提供业务SFN帧连续偏置，利用NTP计算超帧号；可以确保eNB侧与MME侧的超帧对齐，超帧整体有10秒，超帧偏差有+/-5秒，为了满足eDRX要求，需要核心网提前5+2=7秒左右发送给eNB，也就是要提前7秒发送。

查询服务小区eDRX功能已开启，核心网时间源为GPS，基站侧时间源为NTP，已是闰秒差18s。

图5eNodeB时间源

图6MME时间源

MME和eNB侧配置eDRX都使用UTC参考时间2010-01-0100:

00:

00，UTC本身不需要考虑闰秒差，但eNB侧计算帧号时使用其全局配置闰秒差18s，导致MME侧下发寻呼时间比eNB晚18s,但从配置上看，已有18s闰秒差。

再次同客户联合测试，并在后台同步跟踪，客户反馈回测试结果：

一开始平台下发数据下来，都能收到，然后停止10~15分钟没有任何操作，再下发数据下来，刚开始几包数据下发之后，一直没收到，后面发多几次之后，就能收到后面的数据了，但是前面的几包已经丢失了。

怀疑还是时间差问题，导致数据不同步。

三、解决方案

eNB侧采用频率同步提供业务SFN帧连续偏置，利用NTP计算超帧号；可以确保eNB侧与MME侧的超帧对齐，超帧整体有10秒，超帧偏差有+/-5秒，为了满足eDRX要求，需要核心网提前5+2=7秒左右发送给eNB，也就是要提前7秒发送，修改脚本如下：

●SETTIMESRC:

AUTOSWITCH=OFF;//关闭自动切换开关

参数修改说明：

外部时间源自动切换开关需要关闭，否则可能会发生时间源的切换，导致HSFN起始时间变化，影响eDRX寻呼。

●SETFNSYNCTIME:

FNSYNCSW=ON,DATE=1980&01&06,TIME=00&00&07;//打开CIoT帧号同步调整开关，设置时间日期

参数修改说明：

频率同步时，eNodeB的配置起始时间为DATE=1980&01&06,TIME=00&00&07，目的是为了达到MME寻呼消息提前7秒下发的目的。

四、效果评估

参数修改后，用户故障已恢复，从基站日志分析，eDRX寻呼已能正常发到UE:

图7eNodeB收到MME下发的eDRX寻呼消息

图8eDRX已经生效

图9eNodeB将eDRX寻呼消息下发给UE

五、总结及推广

在本次案例中，由于NB-IoTeDRX模式基准时间存在偏差，NB寻呼失败，导致终端无法接收到下行报文。

该类问题由于涉及到用户模组、核心网，无法单方面发现问题，因此需要无线侧联合核心网、用户侧同步配合测试分析，才能发现和解决问题。

由于时钟类问题与硬件关系密切，本案例发生后，我们对优化关注的时钟类知识进行了梳理，各地市可以根据网络的实际情况，采取相应的时钟源和时钟参数。

5.1时钟同步方式影响对比

LTE网络有两种同步方式：

时间同步（符号完全对齐，RS信号互相干扰）和频率同步（符号不对齐）。

频率同步相对于时间同步，RSSINR更高，路测SINR（只能测量到RS的信号质量）显得更高。

随着负荷的增加，本小区的RS受到邻小区的数据域干扰变大，差异变小。

频率同步和时间同步场景下RSSINR和DataSINR对比如下表。

场景

频率同步

时间同步

服务小区RSSINR

偏移0/4/7/11符号（邻区相对服务小区）

RSPower/（PCFICH+Noise）

其它偏移

RSPower/Noise偏高

RSPower/（PCFICH+Noise）

偏低

服务小区DataSINR

偏移0/3/7/10符号（邻区相对服务小区）

DataPower/RS（12RE/RB）

其它偏移

DataPower/RS（16RE/RB）

DataPower/RS（12RE/RB）

实测数据与理论预期一致：

（1）空载场景下：

频率同步的SINR要优于时间同步约2dB左右；频率同步方式下吞吐率5%以内的提升（RS干扰降低改善中远点解调性能）。

（2）有负荷场景下：

随负荷增加，时间同步和频率同步的差异减少（30%负荷时，频率同步占优；负荷增加，差异减小）。

建议：

GPS时间同步方式为站间ULComp和站间SFN等新业务提前部署，在暂时没有业务需求的情况下站点配置为频率同步。

5.2eNodeB时钟源解决方案

eNodeB有多重时钟源，包括GPS、IEEE1588V2、NTP、自由振动等，下面对不同的时钟源优缺点进行对比，实际网络可以根据实际情况进行配置。

图10不同的时钟源优缺点对比

5.3eNodeB关于GPS解决方案

图11GPS典型解决方案

说明：

•使用RG8U跳线，GPS天线到基站的馈线长度不得超过150m；

•使用RG8U跳线+GPS放大器，GPS天线到基站的馈线长度不得超过270m；

•功分2路：

使用RG8U跳线，GPS天线到基站的馈线长度不得超过130m；

•功分2路：

使用RG8U跳线+GPS放大器，GPS天线到基站的馈线长度不得超过250m；

•功分4路：

使用RG8U跳线，GPS天线到基站的馈线长度不得超过110m；

•功分4路：

使用RG8U跳线+GPS放大器，GPS天线到基站的馈线长度不得超过230m；

•GPS超长拉远场景优先使用RGPS方案，如果必须使用GPS放大器，只支持GPS放大器安装在室内的场景。

•GPS放大器内置防雷，可以安装在避雷器前面或者后面。

•建议放大器与GPS天线之间的距离在50m～150m范围内，但前提要满足室内安装的要求。

•放大器需要做绝缘处理。

•为了便于维护，需要记录放大器安装位置（例如在设计图纸中说明）。

对于CL共GPS的情况

图12CL共GPS的情况

注意事项：

•功分2路：

使用1/2跳线，GPS天线到基站的馈线长度不得超过80m（分路器到基站的2根馈线不重复计算）。

•功分2路：

使用RG8U跳线，GPS天线到基站的馈线长度不得超过50m（分路器到基站的2根馈线不重复计算）。

•功分4路：

使用1/2跳线，GPS天线到基站的馈线长度不得超过60m（分路器到基站的4根馈线不重复计算）。

•功分4路：

使用RG8U跳线，GPS天线到基站的馈线长度不得超过50m（分路器到基站的4根馈线不重复计算）。

5.4eNodeB关于1588V2时钟解决方案

图131588V2时钟解决方案网络结构图

说明：

Ø实现1588的时间同步，要求数据承载网中的所有中间设备都支持1588协议。

Ø时间同步推荐方案：

采用逐跳支持1588的方案，采用二层组播、全网BC的方式，全网BC方式时所有承载网设备都工作在BC模式，每个节点都进行时间和频率精确同步，适用于环形组网、树形组网、链型组网、星型组网等各种场景

Ø时间同步时，每一个节点都通过同步报文和上级节点进行同步，中间的传输节点实现1588BC功能，接收上级的时钟报文，终结报文并和上级进行同步，同时根据同步状态给下级节点下发时钟报文，通过这种一级一级的同步实现全网的时间同步

注意事项：

Ø时间同步模式下需要进行不对称补偿。

按照1588协议的假设，双向线路传输路径是对称的。

但在实际工程施工过程中，难以完全保证光纤的对称性，这会带来1588计算的不准确性，导致时间上有一个固定延迟（一般4ns/m），对于这部分固定延迟，需要通过人工补偿的方式进行修正。

Ø目前基站只支持作为叶子节点来实现1588时间同步，不支持作为hub节点的1588功能，即基站不支持BC功能。