NB-IoT网络RRC连接成功率问题分析与处理.docx

NB-IoT网络RRC连接成功率问题分析与处理.docx

  1. 1、本文档共9页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多

?

?

NB

IoT网络RRC连接成功率问题分析与处理

?

?

程闽明叶蔼笙陈潇

【摘要】随着NB-IoT技术的快速发展,NB-IoT网络RRC连接成功率问题的分析与处理成为无线优化面临的难题。首先对日常影响NB-IoT网络RRC连接成功率的原因进行分析,然后提出定位原因的分析方法以及相应的处理方案,并以广州高沙村NB-IoT基站为例进行实践验证。通过大量实践,研究出一套实际可行的RRC连接成功率问题分析与处理方案。目前该方案已在广州得到全面应用,为NB-IoT业务项目售前评估提供了有力保障。

NB-IoT;RRC连接成功率;弱覆盖;同频/MOD3干扰

1引言

随着通信技术由2G、3G发展到如今的4G、5G阶段,人们的生活方式已悄然发生了巨变,生活中衣、食、住、行的方方面面都离不開移动通信技术。从早期的短信和语音电话,到现在的图片、视频、高清语音通话,甚至是同步互联网游戏,人与人之间已实现高速、高效的信息传递。

近几年,NB-IoT由于其低功耗、广覆盖及海量连接的优势,得到了快速发展。中国电信已在2017年开启NB-IoT商用阶段[1],相关业务如智能抄表、智慧消防、停车等。

大量NB-IoT业务接入,亟需保障用户长期、稳定的网络服务质量。在实际的NB-IoT网络维护工作中,为了提升客户感知,需对NB-IoT网络的接入、保持、完整性能等各项关键指标进行定期监管[2]。NB-IoT无线网络的RRC连接成功率是检验NB-IoT网络接入性能的主要指标。因此,在实际场景中,遇到RRC连接成功率较低的情况该如何进行有效分析与处理的方案亟需完善。

2RRC原理简介

NB-IoT是R13阶段LTE的一项重要增强技术,在蜂窝网络中构建,频段仅约180kHz,上行采用SC-FDMA,下行采用OFDM。NB-IoT的设计原则都是基于“妥协”的态度,将LTE技术进行设计简化、信令简化,并降低功耗。因此,NB-IoT网络的RRC连接协议原理与LTE相似。

(1)RRC子层协议原理:RRC位于LTE协议栈层3,属于接入层与非接入层的主要控制中心,控制着各层间的主要接口,地位至关重要。RRC不仅要为上层提供网络侧的无线资源参数,还要控制下层的主要参数与行为。RRC子层功能包括接入层AS与非接入层NAS相关系统信息的广播,寻呼、建立以及维持/释放UE与E-UTRAN之间的RRC连接、临时标识的分配和用于RRC连接的信令[3]等。因此RRC层就是无线资源控制层,是终端协议的接入、非接入平面对话的桥梁。无线资源控制层的完善度与可靠性在很大程度上影响了整个LTE协议栈软件的性能。

(2)在NB-IoT中,与LTE类似,UE同样是在空闲模式和连接模式下进行随机接入过程,但是NB-IoT在R13(Release13)中仅支持基于竞争的随机接入以及在下行数据到达情况下由PDCCHorder触发的随机接入[5]。除此之外,它不支持PUCCH信道以及切换功能,因此在NB-IoT系统中触发随机接入的相关应用场景也被简化成如下4种[4-5]:

◆无线资源控制(RadioResourceControl,RRC)空闲状态下的初始接入过程;

◆RRC连接重建过程;

◆RRC连接状态下,接收下行数据时(上行失步);

◆RRC连接状态下,发送上行数据时(上行失步或者触发调度请求时)。

3RRC连接问题分析与处理

3.1LTERRC连接问题分析

RRC连接是UE接入网络时网络为其分配无线资源,RRC连接建立成功率是RRC连接建立成功次数和尝试次数的比值,该指标体现了eNodeB或者小区的UE接纳能力[6],是衡量呼叫接通率的重要指标。

目前主流设备(中兴/华为)厂家判定影响RRC建立失败的常见原因主要有“三大类”和“七因素”[7]。

“三大类”为:定时器超时、eNB接纳失败、其他原因。

“七因素”主要为以下七项:

◆基站故障;

◆PRACH参数配置,最小接入电平设置;

◆上行干扰太高,导致MSG3/MSG5/UCI解析失败;

◆弱场接入,RRC无法完成;

◆用户数多导致SR容量不足;

◆上行功控参数设置不合理;

◆CPU负荷过高。

针对“三大类”原因,存在不同的处理措施:

(1)定时器超时

◆检查CPU负荷是否偏高,用户数是否很多,如果是则调整SR容量进行优化;

◆检查上行/下行功控类参数;

◆检查干扰是否偏高;

◆检查RRU输出功率;

◆检查是否MR任务和其他实时跟踪任务导致接入定时器超时;

◆检查是否弱场导致接入定时器超时。

(2)eNB接纳失败

◆检查接纳控制类参数设置;

◆检查板件是否受限,如受限则需更换软件版本。

(3)其他原因

◆检查是否CPU冲高导致;

◆检查是否传输故障,进行传输ping包检测;

◆提交故障单交研发处理。

3.2NB-

文档评论(0)

胡珍 + 关注
实名认证
内容提供者

90后

1亿VIP精品文档

相关文档