精华内容
下载资源
问答
  • 基于全球3G网络中广泛出现的信令风暴问题及其对网络的破坏性影响,为避免此类问题在4G网络中再次爆发,系统性分析了LTE网络可能出现信令风暴风险的几大原因,得出LTE网络面临信令风暴威胁的结论;在此基础上,提出一...
  • 为了解决移动网络信令负载沉重、网络压力大这一问题,通过研究全球智能手机市场发展状况和近期智能手机信令风暴事件,指出省电、节约空口资源和连接重建等3个因素是造成智能手机信令风暴的主要原因,并对规范智能...
  • 很多人认为,移动互联网的应用其实占不了多少运营商的信号源,显然很多人不了解其中的原理,我的答案是:微信会占用过多的信令,从而可能产生「信令风暴」,导致网络不稳定。
  • 谈论信令风暴

    2015-06-17 11:01:00
    信令风暴的问题在去年開始有接触。影响不是一般的大,对于扩容,有60%是因为信令过载引起的,全部也想整理一下各方材料。信令风暴与空口有关,而有人在微博上却以为是承载在IP上的互联网消息。而迫不及待地开骂。 ...

    由于移动和腾讯微信负责争吵近期问题,很多混合“知道真相”的big mouth。商收费的问题。无厘头地作为电信运营商向用户收费而破口大骂。

    信令风暴的问题在去年開始有接触。影响不是一般的大,对于扩容,有60%是因为信令过载引起的,全部也想整理一下各方材料。

    信令风暴与空口有关,而有人在微博上却以为是承载在IP上的互联网消息。而迫不及待地开骂。

    终端在休眠时,触发向发送数据(如心跳消息发送,有如微博消息提醒的定期向server查询),须要主叫连接建立。分组控制功能块(Packet Control Function,PCF)主要作为射频部分与分组网络(IP网络)间的接口。

    终端在休眠时。假设服务器向它推送数据(如push,即业务在IP上的建立TCP长连接实施server à client推送消息,注意IP层是PSDN后面的事情了)。须要被叫连接建立。

    由此可见:

    1、 假设连接处于休眠。不管是终端主动发送,还收被动接收,应须要进行进行空口信令的协商以进行激活;

    2、 被动接收比主动发送须要的交换的空口信令多。寻呼过程中的容量表现为寻呼容量,接入过程中的前向信令容量容量表征为控制信道容量。接入过程中的发现信令容量有反向接入容量表征。而眼下的载扇的首要瓶颈在寻呼容量(寻呼容量小于控制信令容量和反向接容量)。假设容量不足必须进行扩容,否则会出现寻呼受阻。

    微博业务是查询类业务,为主叫连接。

    微信类业务是双向业务。为主叫连接和被叫连接。手机上有不同应用,不同业务之间的心跳/轮询的发送时间不一致,push时间也不一致,假设同一时候Andriod后台执行若干应用,则累加的信令很可观。而微信触发激活的频率特别高,特别消耗空口信令。

    问题的关键在于:为什么终端会出现休眠,而导致不断进行空口连接激活?

    导致休眠有两个方面:

    一、 智能终端系统通过高速休眠(Fast Dormancy)的方式实施节能省电,提高电池续航能力。以下资料来自未经验证的网络资料:Android智能手机频繁休眠所带来的信令是普通手机是否频率的7.5倍[1]。也有某些资料说是10倍。详细的Android和iOS系统进入休眠的时间查不到,能查到的仅仅是主进程堵塞的时间。大致是5秒,不清楚两者是否关联?

    当智能手机在短期内不使用时。它们将进入空暇状态。当用户须要使用时。须要和网络进行信令交换来唤醒手机。

    为了省电,高速休眠支持智能手机高速回到省电空暇状态。详细时间多长,没有查到,可是程序须要对应用户的操作,最要能在200ms(0.2s)之内。假设超过5秒没有反应,ActivityManager会没有提示就kill了activity进程,激活须要又一次onCreate(),因此对于长时间操作。须要採用后台程序。

    写过程序的都知道。要让程序对用户输入响应及时,避免程序在某个操作时僵死的情况,那就要把耗时操作放到后台去做。然后通过异步的通知或者回调来接着流程往下走。否则的话耗时操作会把主线程堵塞,导致程序非常长时间不回到主事件循环。这 在移动平台上尤其重要,一般移动平台上系统都会有一个专门的检查机制,看程序有没有非常长时间被堵塞住。没有回来检查主消息队列。发现这样的情况一般都是把程 序作为“无响应”干掉。iOS普通情况下是10秒为上限。10秒内程序没有回到主消息循环就被干掉。在前台后台切换时更严格,大概是5秒左右。[2]

    二、运营商基站,假设连接长时间不用。也会将资源释放出来

    依据资料[3]:中移动的 2.5G 网络为例。经过粗略測试,大约 5 分钟左右的基带空暇,连接就会被释放,这就是为什么微信 Android 版本号选择以“5 分钟”为周期发送连接心跳。

    导致不断激活也有两个方面:

    一、 应用是怎样实施心跳/轮询机制。依据资料[4],微信具有:1)单次传输的数据量较小。 2)接入和释放频次较高;;3)在线时间长但传送数据的时间非常短;;4)上下行传输的数据量较为对称。具有典型的信令风暴业务的特点。

    二、 有没有可能多个应用同步实时心跳,这样空口信令就可大量节省。


    中国移动和腾讯的矛盾在于用户为移动流量进行的支付,可是业务的空口信令资源,也即微信所依赖的基础建设所有由运营商支付,而作为微信业务的主要盈利者腾讯公司没有提供一分钱的基础建设费用。

    中移动方面提供的统计数据显示,微信已经占用了中移动60%的信令资源。但只带来了10%的移动数据流量[5]

    正如电信行业的资深专家韦乐平所说:产业链关系失衡,建网者赔钱(利润非常低),应用商赚钱(利润高速增长),利益相上层互联网应用上转移,底层电信运营商边缘化、低值化。韦总还说:基于IP承载层设计的移动互联网业务应用与基于集中调度的移动网是天然不匹配的。基于IP层平等理念的业务应用开发导致了大量网络容量和信令资源的浪费,但互联网和移动网这两边谁也动不了。这话非常精彩,移动基站要集中调度,反复地利用频谱资源。而平铺的互联网并不考虑这些。而在电信基础建设运营商向互联网运营商收费补贴基础建设的博弈中,有一拨人有意无意地误导为向用户收费进行煽动。而一些自觉得懂点IT就是,会点编程,就觉得懂电信通信的人在起哄,只能说明运营商在已经沦为弱势群体。

    为何公布这种感叹,有些以学富五车自居的如 @李开复 就发出了如此不懂技术并极具误导的微博,我分几条微博评论道:实际刚好和不学无术的 @李开复 所说相反,为了避免QQ和微信造成基站的信令风暴,应该避免要使用这类互联网服务。以保障基站有足够容量可以为真正有须要的服务,尽量使用短信,少使用语音,不要使用QQ/微信。@李开复 将这条删了,虽信口开河,但知错能改。

    但我仍极不喜欢他。他的big mouth常常不负责任。被称人生误导师,是有道理的。



    [1] http://www.gsta.com/news/15006.html

    [2] http://www.cnblogs.com/linyawen/archive/2012/07/24/2606709.html

    [3] http://www.alibuybuy.com/posts/81071.html

    [4] http://www.weste.net/2013/4-7/90227.html

    [5] http://jingji.cntv.cn/2013/04/05/VIDE1365097318724308.shtml

    转载于:https://www.cnblogs.com/blfshiye/p/4582659.html

    展开全文
  • 谈谈信令风暴

    2014-10-14 11:23:00
    信令风暴的问题在去年開始有接触,影响不是一般的大,对于扩容,有60%是因为信令过载引起的,全部也想整理一下各方材料。信令风暴与空口有关,而有人在微博上却以为是承载在IP上的互联网消息,而迫不及待地开骂。 ...

    因为近期移动和腾讯就微信收费的问题争吵,夹杂大量“不明真相”的big mouth。将电信运营商就基础设施向互联网运营商收费的问题,无厘头地作为电信运营商向用户收费而破口大骂。信令风暴的问题在去年開始有接触,影响不是一般的大,对于扩容,有60%是因为信令过载引起的,全部也想整理一下各方材料。信令风暴与空口有关,而有人在微博上却以为是承载在IP上的互联网消息,而迫不及待地开骂。

    终端在休眠时,触发向发送数据(如心跳消息发送,有如微博消息提醒的定期向server查询),须要主叫连接建立。分组控制功能块(Packet Control Function,PCF)主要作为射频部分与分组网络(IP网络)间的接口。

    终端在休眠时,假设服务器向它推送数据(如push,即业务在IP上的建立TCP长连接实施server à client推送消息,注意IP层是PSDN后面的事情了),须要被叫连接建立。

    由此可见:

    1、 假设连接处于休眠,不管是终端主动发送,还收被动接收,应须要进行进行空口信令的协商以进行激活;

    2、 被动接收比主动发送须要的交换的空口信令多。寻呼过程中的容量表现为寻呼容量,接入过程中的前向信令容量容量表征为控制信道容量,接入过程中的发现信令容量有反向接入容量表征。而眼下的载扇的首要瓶颈在寻呼容量(寻呼容量小于控制信令容量和反向接容量)。假设容量不足必须进行扩容,否则会出现寻呼受阻。

    微博业务是查询类业务,为主叫连接。微信类业务是双向业务,为主叫连接和被叫连接。手机上有不同应用,不同业务之间的心跳/轮询的发送时间不一致,push时间也不一致,假设同一时候Andriod后台执行若干应用,则累加的信令很可观。而微信触发激活的频率特别高,特别消耗空口信令。

    问题的关键在于:为什么终端会出现休眠,而导致不断进行空口连接激活?

    导致休眠有两个方面:

    一、 智能终端系统通过高速休眠(Fast Dormancy)的方式实施节能省电,提高电池续航能力。以下资料来自未经验证的网络资料:Android智能手机频繁休眠所带来的信令是普通手机是否频率的7.5倍[1]。也有某些资料说是10倍。详细的Android和iOS系统进入休眠的时间查不到,能查到的仅仅是主进程堵塞的时间,大致是5秒,不清楚两者是否关联?

    当智能手机在短期内不使用时,它们将进入空暇状态。当用户须要使用时,须要和网络进行信令交换来唤醒手机。为了省电,高速休眠支持智能手机高速回到省电空暇状态。详细时间多长,没有查到,可是程序须要对应用户的操作,最要能在200ms(0.2s)之内,假设超过5秒没有反应,ActivityManager会没有提示就kill了activity进程,激活须要又一次onCreate(),因此对于长时间操作,须要採用后台程序。

    写过程序的都知道,要让程序对用户输入响应及时,避免程序在某个操作时僵死的情况,那就要把耗时操作放到后台去做,然后通过异步的通知或者回调来接着流程往下走。否则的话耗时操作会把主线程堵塞,导致程序非常长时间不回到主事件循环。这 在移动平台上尤其重要,一般移动平台上系统都会有一个专门的检查机制,看程序有没有非常长时间被堵塞住,没有回来检查主消息队列。发现这样的情况一般都是把程 序作为“无响应”干掉。iOS普通情况下是10秒为上限。10秒内程序没有回到主消息循环就被干掉。在前台后台切换时更严格,大概是5秒左右。[2]

    二、运营商基站,假设连接长时间不用,也会将资源释放出来。依据资料[3]:中移动的 2.5G 网络为例,经过粗略測试,大约 5 分钟左右的基带空暇,连接就会被释放,这就是为什么微信 Android 版本号选择以“5 分钟”为周期发送连接心跳。

    导致不断激活也有两个方面:

    一、 应用是怎样实施心跳/轮询机制。依据资料[4],微信具有:1)单次传输的数据量较小; 2)接入和释放频次较高;;3)在线时间长但传送数据的时间非常短;;4)上下行传输的数据量较为对称。具有典型的信令风暴业务的特点。

    二、 有没有可能多个应用同步实时心跳,这样空口信令就可大量节省。


    中国移动和腾讯的矛盾在于用户为移动流量进行的支付,可是业务的空口信令资源,也即微信所依赖的基础建设所有由运营商支付,而作为微信业务的主要盈利者腾讯公司没有提供一分钱的基础建设费用。中移动方面提供的统计数据显示,微信已经占用了中移动60%的信令资源,但只带来了10%的移动数据流量[5]。正如电信行业的资深专家韦乐平所说:产业链关系失衡,建网者赔钱(利润非常低),应用商赚钱(利润高速增长),利益相上层互联网应用上转移,底层电信运营商边缘化、低值化。韦总还说:基于IP承载层设计的移动互联网业务应用与基于集中调度的移动网是天然不匹配的,基于IP层平等理念的业务应用开发导致了大量网络容量和信令资源的浪费,但互联网和移动网这两边谁也动不了。这话非常精彩,移动基站要集中调度,反复地利用频谱资源,而平铺的互联网并不考虑这些。而在电信基础建设运营商向互联网运营商收费补贴基础建设的博弈中,有一拨人有意无意地误导为向用户收费进行煽动,而一些自觉得懂点IT就是,会点编程,就觉得懂电信通信的人在起哄,只能说明运营商在已经沦为弱势群体。

    为何公布这种感叹,有些以学富五车自居的如 @李开复 就发出了如此不懂技术并极具误导的微博,我分几条微博评论道:实际刚好和不学无术的 @李开复 所说相反,为了避免QQ和微信造成基站的信令风暴,应该避免要使用这类互联网服务,以保障基站有足够容量可以为真正有须要的服务,尽量使用短信,少使用语音,不要使用QQ/微信。@李开复 将这条删了,虽信口开河,但知错能改。但我仍极不喜欢他。他的big mouth常常不负责任,被称人生误导师,是有道理的。



    [1] http://www.gsta.com/news/15006.html

    [2] http://www.cnblogs.com/linyawen/archive/2012/07/24/2606709.html

    [3] http://www.alibuybuy.com/posts/81071.html

    [4] http://www.weste.net/2013/4-7/90227.html

    [5] http://jingji.cntv.cn/2013/04/05/VIDE1365097318724308.shtml

    展开全文
  • 信令风暴的技术分析

    2013-05-20 10:09:00
     微信的信令风暴将人们的目光导向心跳机制,那么心跳机制是怎么回事呢?  最早的心跳机制用于服务器的安全备份机制,是为了防止服务器死机,而在服务器之间采用专用的端口和线路,周期性传送简短的信息,心跳就是...

    http://tech.sina.com.cn/t/csj/2013-04-24/09288273431.shtml

    孙宇彤,空中接口学园站长

      微信的信令风暴将人们的目光导向心跳机制,那么心跳机制是怎么回事呢?

      最早的心跳机制用于服务器的安全备份机制,是为了防止服务器死机,而在服务器之间采用专用的端口和线路,周期性传送简短的信息,心跳就是形象的比喻。一旦收不到对方的心跳信息,服务器可以接管对方的业务,避免业务的停滞。为了业务的顺畅进行,服务器发送的心跳信息可以非常频密。

      这种机制被手机上的互联网应用所借用,无论是Android的原生应用,还是QQ、微博和微信,都采用了这种心跳机制,也就是终端定时向应用服务器发送简短的信息。但是与服务器之间的心跳机制相比,还是有一些差别:

      1. 心跳信息是单方向的,只有终端发到应用服务器;

      2. 心跳信息的周期比较长,比如旧版QQ的心跳周期为30s,新版QQ为180s,微信为300s,Google原生应用为1680s左右。

      另外,互联网应用的心跳包除了宣告终端在线外,还有一项重要的任务,就是提供终端的即时地址,方便应用服务器的寻址。

      有了互联网应用的心跳机制,应用服务器可以及时下发(Push)用户相关的信息,比如微信中的短消息、图片或者语音等。

      心跳包也会带来很多副作用,比如终端更为费电,还可能给移动通信网络带来信令风暴。

      看起来很完美的心跳机制,为什么会给移动通信网络带来信令风暴呢?

      原来,移动通信网络中由于用户众多、资源稀缺,每个用户都是动态占用资源,比如IP地址以及无线信道。每次发送心跳包,都需要移动通信网络为用户分配资源,分配的过程体现在信令的发送和接收上。一次心跳包的发送过程,牵涉的信令多达几十条。

      随着互联网APP的普及,大量的终端周期性地发送心跳包,效果类似于IP网络中的DDOS(分布式拒绝服务攻击,一种常用的黑客攻击手段),必然对移动通信网络设备带来冲击,造成拥塞等情况,这种现象就是信令风暴。信令风暴不仅中国移动的GPRS网络存在,中国联通的WCDMA网络、中国电信的CDMA网络都存在。由于中国移动用户数量庞大,因此信令风暴的影响更显著而已,简而言之,就是50步与100步的差别。

      互联网APP的心跳机制对移动网络的冲击很大,那么有什么方法可以缓解乃至解决这个问题呢?

      从互联网APP的角度看,应该区分是移动网络接入还是WLAN接入,智能调整心跳包的发送频率。在移动网络接入时,降低心跳包的发送频率,这样虽然服务器推送的信息会有一些延迟,但是终端更省电,移动网络更稳健。比如旧版QQ的心跳周期为30s,新版QQ为180s,微信为300s,已经呈现出逐步延长的趋势,还可以再调整,直至接近Google原生应用的1680s左右。

      目前,互联网APP心跳包的发送频率由APP一手包办,这是不合理的,应该开放给用户进行设置,允许用户在省电和及时等多个场景间切换。

      现在每个人的手机上都装有多个互联网APP,比如QQ、微信、微博和淘宝等,如果每个APP都发送心跳包,心跳包的发送频率将大幅增加。像微信、QQ 等APP,可以考虑联合发送心跳包,这样可以减少不少心跳包。另外如果从操作系统的层面统一心跳包,效果会更好。苹果的IOS已经做了一个很好的尝试,建立了一个位置寄存器APNS,将所有的APP联合起来,统一发送心跳。Android系统其实也可以如法炮制,据称小米手机有意这样做,像阿里OS也应该可以做。运营商自己开发的OS更加应该是这方面的表率。

      终端侧的这些做法,将能有效减少心跳包的发送,从而缓解信令风暴。

      从网络侧的角度,如果终端发送心跳包是一个既成事实的话,及时进行设备扩容就是势在必行的了。目前看,基站控制器以及核心网的设备受信令风暴的影响大,需要优先扩容。当然,运营商有苦衷,认为是在帮APP打工。但是,运营商也必须明白顺势而为的重要性,与其被动接招,不如早作打算。

      什么打算呢?就是宣传从移动网络的角度看,心跳包并不是必须的。利用短消息与APP深度整合,不用心跳包也可以方便地实现APP消息的推送,又节省终端的电力,又避免对移动网络的冲击,两全其美,何乐不为呢?

      这样釜底抽薪后,心跳机制对移动网络的冲击将是可以控制的了。

    展开全文
  • 全局思维(核心网和无线基站侧都会有信令风暴): LTE网络系统可能出现信令风暴的原因,大致可以总结出以下几点: 1.网络架构的变化,导致4G核心网信令流量较2G/3G大幅增加 a)架构扁平化:LTE...

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

    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没有单独的控制器元件。这简化了系统架构,并且可以提供较低的网络响应时间。

     

    转载于:https://www.cnblogs.com/bonelee/p/9528597.html

    展开全文
  • pool,管理上万个eNB,因此,一旦发生信令风暴问题,MME 处理能力将下降甚至瘫痪,影响面更广,破坏性更大。 2.4 带宽拓展推动移动互联网应用的爆发式增长 根据爱立信消费者实验室的研究报告, 如图3 所示, 到...
  • A SURVEY ON THREATS, VULNERABILITIES AND SECURITY SOLUTIONS FOR CELLULAR NETWORK ...说的就是3G状态切换导致的信令风暴。不进行数据传输。   转载于:https://www.cnblogs.com/bonelee/p/9528881.html
  • 信令:手机开机后,先从USIM...在传统4G网络认证机制中没有考虑到这种海量认证信令的问题,一旦网络收到终端信令请求超过了网络各项信令资源的处理能力,则会触发信令风暴,导致网络服务出现问题,使整个移动通信系...
  • 信令风暴的产生来源于终端和网络之间的频繁交互,包括终端发起和网络发起的网络连接过程。信令风暴导致用户体验下降,网络扩容压力增大。为解决信令风暴问题,终端侧可以通过优化操作系统闹钟服务实现心跳分组对齐,...
  • 并与CDMA进行对比,LTE空口极限接入容量明显超过CDMA,一定程度上减缓了信令风暴问题。根据用户行为特征搭建随机接入模型,建立了LTE空口实际接入容量评估方法,能够指导用户聚集场景(如大型比赛、演唱会等场景)下...
  • 4G网络信令分析

    2017-03-25 16:53:20
    LTE资料
  • 微信的信令风暴将人们的目光导向心跳机制,那么心跳机制是怎么回事?又为什么会给移动通信网络带来信令风暴呢? 孙宇彤,空中接口学园站长 微信的信令风暴将人们的目光导向心跳机制,那么心跳机制是怎么回事呢...
  • 微信的信令风暴将人们的目光导向心跳机制,那么心跳机制是怎么回事?又为什么会给移动通信网络带来信令风暴呢?  孙宇彤,空中接口学园站长  微信的信令风暴将人们的目光导向心跳机制,那么心跳机制是怎么回...
  • 近年来,智能终端的快速普及和层出不穷的各类新应用成为移动互联网...本文从电信运营商的角度,对于移动互联网崛起所引发的流量冲击与信令风暴问题,剖析了其内在的机制,进行了量化分析,并探讨了各种可能的应对策略。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 941
精华内容 376
热门标签
关键字:

信令风暴