zoukankan      html  css  js  c++  java
  • 无线基站侧的信令风暴根因——频繁的释放和连接RRC产生大量信令、设备移动导致小区重选信令增加、寻呼信令多

    全局思维(核心网和无线基站侧都会有信令风暴):

    LTE网络系统可能出现信令风暴的原因,大致可以总结出以下几点:

    1.网络架构的变化,导致4G核心网信令流量较2G/3G大幅增加

    a)架构扁平化:LTE网络采用两级结构,取消RNC(Radio�Network��Controller)/BSC(Base�Station�Controller)中间的网络节点,核心网直接管理无线基站。

    b)寻呼信令激增:寻呼信令不再通过RNC/BSC汇聚,S1接口寻呼信令大增

    c)切换等其他信令也大幅增长:跨eNodeB的切换需要通过MME,切换信令大增。

    2.信令流程和协议状态变化,导致4G信令大幅增加,4G用户状态大为简化,只有连接态和空闲态两个状态,而3G采用URA-FACH/PCH等状态,无数据传送时无需很快进入空闲态,导致LTE网络中Service Request信令增加。

    3.智能终端的普及和移动互联网的飞速发展,移动用户相关行为导致的网络注册,重注册、请求位置更新、请求分配资源等服务流程的信令量大幅增加。

    与传统的因为大数据流量冲击造成的网络拥塞不同,因信令风暴而引发网络拥塞时,此时实际承载数据流量的网络资源大部分处于空闲状态,但负责接纳、管理 UE 的信令信道资源却被消耗殆尽,导致网络无法为新用户提供服务。 需要说明的是,网络信令交互可以分为两大类:一类是核心网侧信令交互,专指核心网元(如 MME 和 S-GW)与基站间的信令交互;另一类是接入网侧的信令交互,专指 UE 与基站间的信令交互。在核心网侧与接入网侧均有可能出现网络信令负荷过载的情况。

    本文仅仅探讨无线侧的信令风暴(专指 UE 与基站间的信令)。

    全球各个UMTS网络中Iphone、Blackberry、Android、Nokia等智能3G终端的市场占有率逐渐上升,智能终端内置的部分PS应用程序(IM,Mail类软件)会以较短的周期与Internet服务器频繁同步通信,造成大量PS呼叫并且单次PS呼叫的数据量较小。部分智能终端为了节约电量消耗在与服务器通信完成后会主动发送SIGNALLING CONNCETION RELEASE INDICATION信令给RNC来释放RRC连接,于是每到同步周期此类终端都会进行RRC接入->同步PS数据->RRC释放一整套流程,频繁的接入释放产生大量信令。

    这种由于智能终端业务特点引发的大信令流量,对RNC的SPU单板和PIU单板和NodeB基带单板的CPU处理能力消耗增多,而且对运营商并不带来业务收入。有部分局点由于未能及时对智能终端信令风暴采取应对措施,而出现了RNC或者NodeB 的CPU过载问题,严重影响网络的容量和稳定性。

    此外,由于智能终端的数据小、连接时间短且非常频繁的特点,直接导致空口的寻呼次数大大增加。通过对当前如加拿大或新加坡等典型网络分析之后发现,在网络话务量基本不变的前提下,PS寻呼每隔几个月就成倍增长,总的寻呼量很快就会达到控制器的容量上限。如果网络侧不改进,可以预期将来寻呼信道必然面临崩溃。

    1.1 应用场景

    根据信令触发源的不同,信令风暴解决方案的应用场景可分为接入信令风暴场景,小区重选信令风暴场景和寻呼信令风暴场景。

    (1)接入信令风暴场景

    对于大量的PS RAB接入信令,可以通过使用PCH/R8 FD/EFD功能来从源头上减少接入信令,R8 FD/EFD功能使得RNC在接收到终端发送的SCRI信令后,不释放RRC连接,而是将终端迁移到CELL_FACH/PCH,这样大大减少了PS RAB接入信令

    (2)小区重选信令风暴场景

    在使用CELL_PCH方案后,在高移动性场景中,会带来小区重选信令的大量增多,可以通过URA_PCH来解决,即将某些移动性高的小区规划到一个URA区中,这样来减少终端移动带来的小区更新信令。用户在小区间移动需要发送小区重选信令。

    (3)寻呼信令风暴场景

    对于寻呼信令多的场景,通过URA_PCH态分级寻呼和IDLE态分级寻呼来解决。在智能UE渗透率不断上升的场景下,越来越多的业务会引起寻呼,特别是PS寻呼。当现网的空口寻呼量比较大(PCH物理信道利用率大于60%)。

    小区寻呼信道拥塞.本特性通过对处于IDLE状态的UE实现两级寻呼机制:

    第一级寻呼:首先在最近活动小区及其邻区内寻呼。

    第二级寻呼:在寻呼无响应的情况下再在LA/RA全小区进行寻呼。

    这样,有效的减少全系统寻呼量,避免寻呼信道的拥塞。

    补充5G相关基础知识:

    UE:用户设备,一般是手机或者物联网终端。

    (1)5G空口协议:

    制面协议栈和用户面协议栈共同构成了 LTE 的空口无线协议栈,具体又包括物理层(PHY),媒介接入控制中心层(MAC),分组数据汇聚层(PDCP),无线链路控制层(RLC)和无线资源控制层(RRC)

    RRC 层:作为整个 LTE 系统的控制实体,完成了包括系统信息广播,寻呼,RRC 连接建立、释放、配置、重建立,无线承载的管理,信令消息的加密与安全控制,切换与测量上报等功能。 
    PDCP 层:该层主要负责对数据进行处理,包括对用户面和控制面的数据进行完整性保护,加密解密处理,重复数据丢弃等功能。 
    RLC 层:该层主要负责保证上层消息分组的可靠传输,其具体功能包括数据分组的级联、分段和重组,分组的重复检查和顺序递交等。 
    MAC 层:该层主要完成逻辑信道与传输信道的映射,上层协议数据单元的复用和解复用,随机接入过程,测量和上报,HARQ 纠错,UE 优先级管理等功能。 PHY 层:该层完成实际数据的收发工作,具体功能包括传输信道的错误检测、纠错编码与译码,传输信道向屋里信道的映射,调制与解调,频率与时间的同步,多天线处理等。

    RRC 协议位于 E-UTRAN 的控制平面,其所完成的功能可简要分类概括如下[11]:  广播系统信息:广播包括接入层及 NAS 层的系统信息广播。  寻呼:包括主动寻呼和被动寻呼。UE 高层在收到寻呼消息后可以发起 RRC连接。  RRC 连接控制:包括 RRC 连接建立/重建立/重配置/释放。  无线承载管理:信令无线承载(SRB)、数据无线承载(DRB)的建立、配置、释放。  安全机制:密钥的管理等。  移动性管理:UE 进行切换时的小区选择及重选、上下文信息的传输,UE的测量上报等。

    对 RRC 层而言,状态机及状态转换是其关键部分,而频繁的状态转换正是引发信令风暴问题的根源。本小节接下来将对状态转换中两个最关键的过程(RRC连接建立和 RRC 连接释放)进行介绍,并展示了其对网络信令负载的影响。 首先是 RRC 连接建立过程,该过程由 UE 侧的高层主动发起或收到寻呼消息后发起,该过程涉及到随机接入过程以及 NAS 层的诸多信令交互,连接建立成功后 UE 将进入到 RRC 连接态,而后就可以建立数据承载,开始用户面数据的收发。与以上过程相对的是 RRC 连接释放过程,当 UE 的用户数据收发完毕后将触发该过程。具体而言,该过程实际由网络侧控制,在 UE 无数据收发一段时间后网络侧会主动释放连接并通知 UE。此外,在一些特殊情况下 UE 也可根据自身高层的指示而主动释放连接并进入空闲态。

    从前文的介绍中可知 UE 频繁的 RRC 状态转换过程是导致信令风暴问题的一个主要原因,那么一次 RRC 状态转换到底会消耗多少信令资源?参考文献[13]对此进行了实际的仿真与数据收集,假设所有的信令消息在收发过程均不存在差错,那么一次 RRC 连接建立与释放过程所消耗的信令资源如表 2-1 所示。 
    从上表可知,一次 RRC 连接释放与建立会产生数十条信令消息。假设一个基站在繁忙时段需要同时为众多 UE 服务,而每个 UE 又频繁的发生 RRC 状态转换,此时网络内传输的信令消息将会消耗掉大量网络资源,出现网络信令过载,最终导致网络拥塞。

     

    在 LTE 系统中同样存在出现网络信令过载的问题,其原因大致可以归为以下三类: 1) 协议设计的原因 从上一节关于 LTE 系统关键技术的概述中可知,LTE 系统的无线资源控制层(RRC)存在状态转换机制。UE 在接入网络成功后会驻留在 RRC 空闲态,此时UE 仅拥有接受寻呼消息、广播消息等有限功能,无法进行用户数据的收发。当UE 有用户数据达到时就必须将状态切换到 RRC 连接态,这一过程伴随着核心网侧和接入网侧的诸多信令交互,其信令交互流程如图 2-9 所示。UE 在进入 RRC连接态后可以进行持续的数据收发,但此时处于高能耗状态且持续占用网络时频资源(所以上网过程是很耗电的因此 LTE 协议设定了一个 RRC 连接释放定时器,当 UE 处于 RRC 连接态且在上述定时器超时之前都没有用户数据的收发,则网络侧会主动释放该 UE 的RRC 连接[16]。由此可知,RRC 连接释放定时器的取值与 UE 所发生的 RRC 状态转换次数紧密相关。具体而言,当设置较大的 RRC 连接释放定时器值时,UE 在通信过程中发生 RRC 状态转换的频次将明显降低,相反,较小的 RRC 连接释放定时器值则会导致较为频繁的 RRC 状态转换。 然而问题就出现在在新兴的移动互联网业务应用冲击下,这种 RRC 连接建立与释放机制会被频繁触发,每次触发都会伴随着如图 2-9 所示的十几个交互流程,而每个交互流程都会在核心网侧或接入网侧产生数条甚至数十条信令交互。这种频繁的 RRC 状态转换正是当前频繁爆发的信令风暴问题的根源。

    2) 移动数据业务流量特征的原因 由上述分析可知,网络信令风暴的一个重要原因在于频繁的 RRC 状态转换,而 RRC 状态转换的发生与 UE 所运行的移动数据业务的流量特征密切相关。随着移动互联网的快速发展,许多新的移动数据业务开始出现,这些新业务相比于电话、网页浏览等传统业务,其应用特征大大不同:实时在线,频繁的网络连接,频繁突发的小数据包传输等。移动 QQ、微信等是该类特征应用的典型代表。而且这些应用还附带有背景流量以及心跳信息,这更是加剧了 RRC 状态转换的频繁发生。 由参考文献[17]可知,背景流量和心跳信息等频繁的小数据包传输不仅导致了频繁的 RRC 状态转换,还降低了网络资源的利用效率,因为一次小数据包传输和一次连续的大数据量传输需要消耗的信令资源几乎相同(一次 RRC 状态转换),但论传输效率(数据流量/信令流量)比率,前者则大大低于后者。这就意味着网络中控制信道的信令资源被大量小数据包传输所消耗,但实际所传输的用户数据流量却很少,网络资源的利用效率低下。

    3) 信令攻击的原因 任何人为设计的协议难免总会存在漏洞,一些恶意的用户就会利用这些漏洞发起攻击为自身牟利。LTE 协议同样存在一些考虑不全的地方,也难以避免被发起攻击。有部分信令风暴问题便是这些恶意用户所发起的信令攻击。 参考文献[18]给出了一种针对 LTE 系统的信令攻击方式。在这种攻击方式中,攻击者利用了建立与拆除专用承载需要消耗大量信令资源这个特点。攻击者通过同时向网络申请建立大量专用承载,而后在承载建立完成后不去使用,直到网络侧因为这些专用承载超时而选择拆除它们。攻击者只需要不断重复上述过程就可达到放大攻击效果,最终造成网络信令负荷过载的目的。

    (2)RNC和E NodeB:

    演进节点B(Evolved Node B),也被称为E-UTRAN节点B(E-UTRAN Node B),其英文缩写为eNodeB或者eNB。其为LTE系统中E-UTRAN的组成部分,是对于UMTS系统中节点B部分的演进。该设备是用于在移动网络中,连接用户手机和移动电话网络之间的硬件设备。其功能类似于GSM网络中的BTS。

    传统上,节点B具有最小的功能设置,并由RNC(无线网络控制器)进行控制。然而,eNB没有单独的控制器元件。这简化了系统架构,并且可以提供较低的网络响应时间。

  • 相关阅读:
    iOS 面试题搜集
    iOS 常用第三方类库、完整APP示例
    iOS 键盘遮挡输入 解决办法
    iOS UIColor RGB HEX
    iOS APP性能优化
    iOS Swift 数组 交换元素的两种方法
    iOS CoreData primitive accessor
    iOS Start developing ios apps (OC) pdf
    iOS 传值方式
    iOS IB_DESIGNABLE IBInspectable @IBDesignable @IBInspectable 加速UI开发
  • 原文地址:https://www.cnblogs.com/bonelee/p/9528597.html
Copyright © 2011-2022 走看看