ue存活检测机制参数优化改善掉线问题.docVIP

UE存活检测机制参数优化改善掉线问题 问题描述 大唐后台网管发现福州闽侯-闽侯春江御园(丹宁顿)-DLH-3掉线次数持续偏高 问题分析 查看系统原因统计，发现掉线原因全部为：激活检测-UE丢失。相关信令为：基站触发S1 UE Context Release流程。在MME发给eNB的S1 UE Context Release Command信令中，携带释放原因：value Cause:radio Network:radio-connect-with-ue-lost。网管统计为UE掉线。 分析UE的存活检测机制。该机制为小区级MAC层下行调度算法相关机制，协议中没有具体的规定，由各厂家自行实现。大唐实现方法如下。在空闲态及业务态时，采用不同的处理方法。 1、空闲态：UE存活检测定时器超时处理机制 当检测到上下行BO都为0时，启动定时器T（UeInactiveTimer）一旦上行或下行有数据到达，终止T。终止T不触发额外操作。如果T超时（OMC可配置，目前配置为10s）则基站通过PDCCH Order触发随机接入流程如果终端随机接入成功，则向EPC申请释放E-RAB，原因为UE_Inactive；如果终端随机接入失败，则向EPC申请释放E-RAB，原因为UE_LOST 2、业务态：ACK/NACK存活检测机制 对于有业务调度的用户， 根据目前的上下行配比（1：3）以及特殊子帧的配置，以10ms的无线帧为周期，假设只有单用户，则应该有8个ACK/NACK。M值为100，则意味着，如果基站在100/8*10ms=125ms的时间内没有收到用户下行数据的上行ACK/NACK反馈，则会将用户判定为UE_LOST。 问题解决 查看掉线UE的接收电平及SINR情况，发现这些UE都是处于小区边缘的用户，上行链路质量较差，较容易发生ACK/NACK异常。但是这些UE实际上仍具备业务能力，不应该被判断为掉线。因此，根据上述对UE存活检测机制的分析，考虑应适当提升ACK/NACK存活检测异常次数门限，来避免此类UE掉线问题。 经与大唐后台技术支援部门沟通，将由默认的100次修改到300MAC下行算法参数。 总结 将ACK/NACK存活检测异常次数门限修改为300后，该小区未再出现UE激活检测未通过而导致的掉线问题。