物联网小课堂之NB-IoT黑科技——长连接方案x2

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/qq_43359106/article/details/84334494

各位技术大人们,我唐三鸽回来了!
在这里插入图片描述
But鸽不鸽的都不怪我,隔壁老田非要逼我闭关修炼,所以。。。
其实是我连续出差一个月了啊,我的内心是崩溃的。。。算了,我毕竟是佛系工程师,不吐槽了,还是正事要紧。
进入正题,那我们今天就来讨论下很多老铁们关心的NBIoT长连接实现方案
PS:今天的内容有点多,大家准备好小版本,迎接拖堂吧!
其实对于NBIoT网络来说,本身针对低频次、小数据,对长连接模式并不友好;为了满足社会主义建设的需求,经过充分的理论和实践,也有如下两种方案能够实现NB终端的长连接。
But!老田又说了,研究问题要先理解原理。So,在研究两种方案之前,我们先来刨根问底一下,究竟了哪些因素限制了NBIoT网络下终端的长连接。
注意各位老铁们,前方高能预警!干货来了!赶紧记笔记!!
在这里插入图片描述
上图是通常情况下,设备终端(UE)通过基站(eNodeB),经过公网(Internet)连接到上层应用服务器(Server)的简单逻辑结构。
首先,从无线接入网的角度来看,因为NBIoT引入了低功耗模式(PSM状态)-(不要问我什么是PSM状态!请看本鸽王第一期科普贴!),终端进入PSM状态后,意味着终端与网络之间的连接已经断开;此时,终端处于断网的状态,任何上层应用服务器下发的数据终端都不可能收到。
上图中限制点1 即为这种情况。
为了解决限制点1引起的不能保持终端与服务器长连接的问题,我们需要在终端模组上关闭PSM功能;终端关闭PSM功能后,当数据交互完毕RRC连接断开后,模组会一直处于IDLE状态,在这种状态下,终端将会按照寻呼时间窗的间隔,周期性的监听网络寻呼,从而实现终端与网络保持长连接。
解决了限制点1的问题,再往上层看,终端数据最终经过在PDN网关(P-GW)后汇入公网并传输到上层应用服务器;由于IPV4资源限制,所有终端在通常情况下都不可能使用单独的公网IP,也就是说,在网络结构图上来看,实际上设备终端(UE)到PDN网关(P-GW)是与公网隔离开的;对于公网来说,UE到P-GW之间的交互不可知,为了解决IP资源不够的限制,P-GW通过资源池的方式,每次分配一个IP+Port给本次终端业务使用,如果在超过一定的时间限制后,该IP+Port没有新的数据流进行保活,P-GW就会将该IP资源回收,分配给其他业务使用。
上图中限制点2即为这种情况,实际上这种资源使用逻辑也被称为IPV4 NAT映射老化时间(各位老铁,IPV6有多重要!有没有体会到!)。
为了解决限制点2引起的不能保持终端与服务器长连接的问题,我们需要一些特别的方式来维持IPV4 NAT映射不被老化回收,一般来说我们有如下两种方式(分别为入门级和进阶级):

  1. Class 1 – 入门级(心跳**)
    顾名思义,第一种方法就是使用心跳包来保持长连接(遭了,是心动的感觉)。
    在这里插入图片描述
    入门级方法,非常简单。仅仅通过周期性发送心跳数据到服务器,刷新NAT映射老化计时器时间,从而维持IPV4 NAT映射不被回收,此时上层应用服务器下发的数据便能随时通过该NAT映射发送到P-GW,P-GW通过寻呼即可将数据发送到终端。
    但但但但但但但但但但是!入门级方法一点都不Coooooooool!并且存在应用缺陷,为什么?且看我给大家仔细分析。
    3GPP协议标准定义,NBIoT制式使用的载波带宽为200kHz。
    这是个什么概念呢?(请注意下面这段话的描述!)
    我们使用的2G网络的带宽为1M,在诸如火车站这种人多终端多的场景,如果使用2G网络会经常出现连不上网的情况(大家可以试试,或者以前每年春运应该都体会过!);目前4G网络的带宽为6M,在类似演唱会/大型运动会这样的突发用户密集地区,却依然要通过通信保障车(临时基站)来缓解因用户过多而导致终端不能上网的问题。
    也就是说,带宽越窄,其容量就越小——搞通信的老铁们,有没有很熟悉的感觉?对的,香农定理!!信道容量与信道带宽成正比!!!
    NBIoT制式仅仅只有200kHz的带宽,并且目前部署的网络子载波为15kHz,这就意味着,除去保护带20kHz:

(200kHz – 20kHz)/15kHz = 12
NB-IoT的并发网络容量仅仅只有12个!

至此,心跳方案凸显出了的巨大缺陷,那就是当一个小区下很多终端都在同时发送心跳的时候,极有可能产生因为网络并发容量不够而引起的终端数据发送失败!在这种情况下,甚至可能引起终端掉网,网络严重阻塞的问题。
2. Class 2 – 进阶级(GRE隧道**)
上面一通分析猛如虎,那进阶级的方案如何规避这个问题呢?
首先,心跳方案已经凉了,肯定是不能用了;那我们需要找到一种不使用心跳就能维持IPV4 NAT映射不被老化回收的手段。
此处干货!本鸽王用如下这个图来做解释:
在这里插入图片描述
IPV4的NAT映射是由于公网资源有限而引入的,那么是否可以通过专用网络的方式解决资源受限的问题,从而规避NAT映射这种机制带来的影响(如上图红标所示)。
答案是肯定的。
并且,这种方案就是传说中的GRE隧道方案!
至于如何分配不同的终端到不同的专用网络中,这里就要提到非常非常非常(说三遍)重要的另一个概念,接入点名称——APN(Access Point Name)。
APN是一个用户通过P-GW可连接到公网的标识,其通常作为用户签约数据储存在HSS(归属用户服务器)中,分组业务中MME根据用户签约的APN,通过DNS进行域名解析,从而获取到P-GW的IP地址,将用户接入到APN对应的PDN中;从而实现通过APN将不同的用户接入到不同的网络中。
在这里插入图片描述
如此这般,我们已经解决了公网资源限制的问题,将终端接入到了私网中进行传输,由于私网资源宽裕,所以在P-GW中可以绕过NAT映射,将一个IP+Port资源固定给一个业务上下行使用;这样就能规避心跳机制实现无需心跳维持NAT映射老化的长连接功能。
这就是本鸽王墙裂推荐大家使用的——传输GRE隧道**!
这种方式可以无需心跳维持长连接,不会因为频繁心跳导致多个终端出现并发受限,导致发送数据失败或者引起网络阻塞的问题。
本期表演到此结束,额好像内容有点多,不过想来各位老铁老妹看完之后肯定都有对NBIoT的长连接有较深的了解。
溜了溜了,下期再见老铁们!(我才不会说要等着老田催我更我才更!)
谢谢鸽王唐老师分享!想要了解更多模组相关问题的各位大佬,可以之直接文末留言或者添加小编微信公众号“中移模组”,欢迎加入我们和唐老师一起交流!

展开阅读全文

没有更多推荐了,返回首页