NB-IOT系列专题2：长连接

---

  从上一篇发布的NB-IOT低功耗能力之后，好像距上次发文已经过了几个月了，实在抱歉，从今天起，我会不定期的连载NB-IOT专题。
  此专题后续会涉及到TCP/UDP、MQTT、LWM2M、HTTP等通信协议，也会涉及到模组对接各主流云平台的平台端操作，顺带着也会讲一些模块在各场景下的注意事项等等。大家拭目以待吧。
  
  那么今天就给大家分享一下，NB-IOT设备实现长连接的方案。

前言

  为什么要单独讲NB-IOT的长连接呢？有人会问，我之前用的2g、4g都是直接用的呀，连上服务器，发个心跳不就做到长连接了吗？没错，2g、4g的通讯模组这样做确实就可以了，但是NB-IOT不可以，由于NB-IOT的网络原因，本身就是针对低频次、小数据量的场景，对长连接方案并不友好。
  但是既然有需求，当然也就有解决方案，下文会针对需求，提供两种方案，来使NB设备达到长连接的效果。

理论分析

  都说NB-IOT不适合做长连接，那么是因为什么原因导致的呢？我们来仔细的分析下。  (由于博主不是专业的协议栈工程师，所以NBIOT的附着过程就不放出来了，有兴趣的可以自己百度下)。

  从NB-IOT的工作状态来看，因为NB-IOT引入了PSM机制(别说你不知道，第一章低功耗章节有讲到)，终端进入PSM模式后，也就是模块关闭了RF功能，也就意味着终端与网络的连接已经断开，此时终端处于断网状态，任何服务器下发的指令都不可能收的到。

  还一个就是IP老化问题，只是这个问题，我虽然遇到过，但是不知道用什么言语来形容的好，一般搞通信的都懂，归根到底是因为IPV4地址分配的问题。

实现方案

  首先为了解决上述PSM的导致的终端与服务器断开的问题我们需要关闭终端模组的PSM功能；当终端关闭PSM功能后，在数据发送完成断开RRC连接后，模块会一直处于IDLE状态，在IDLE状态下，模块会按照设置的寻呼时间窗，周期的监听网络寻呼，达到终端设备与服务器的长连接效果。

  1、入门方案—心跳
  没错，可以延续2g、4g模块的方案，定期的发送心跳数据到服务器，刷新NAT映射老化计时器时间，从而维持IPV4 NAT映射不被回收，此时上层应用服务器下发的数据便能随时通过该NAT映射发送到基站，基站通过寻呼即可将数据发送到终端。

  但是，心跳方案在一定的场合存在着不小的缺陷。且看下文分析：
  3GPP规定的NB-IOT使用的载波带宽为200KHz，并且当前部署的子载波带宽都为15KHz，这就意味着出去保护带20kHz，(200 - 20) / 15 = 12。这是啥意思？

  也就是说一个NB基站可以同时并发的NB设备，最大只有12台！！！
  突然想起教我信号系统的美女姐姐老师，好像讲过香农定理的，说的啥忘记了，本来没想往这块发展的。(PS: 有个理论是：信道容量由带宽及信噪比决定，增大带宽、提高信噪比可以增大信道容量)

  看到现在，可以看出心跳方案本身存在着巨大缺陷，那就是当一个基站下很多终端都在使用心跳方案进行长连接的时候，有很大的可能会因为网络的并发容量不够而引起的终端数据发送失败！在这种情况下，甚至可能引起终端掉网，网络严重阻塞的问题。

  说到这里，我想到了在我中学时，过年在家拿着大人的手机，浏览网页，经常会断网，当时还不知道啥原因，就被踢掉了！

  2、开通GRE隧道卡
  在第一种心跳方案不太适合一定场景的情况下，这时候就需要另寻途径解决IPV4 NAT映射不被老化回收的手段。
  IPV4的NAT映射老化是由于公网资源有限而引入的，那么是否有办法可以通过专用网络的方式解决资源受限的问题，从而规避NAT映射这种机制带来的影响呢？
  当然有，移动物联网为我们提供了一个OneNET专网，开通对应的隧道卡即可使用，这种方式无需发送心跳维持连接，不会因为频繁心跳导致多个终端出现并发受限，导致发送数据失败或者引起网络阻塞的问题。
  可以理解为，核心网为设备专门开通了一个IP PORT供设备上下行使用。
  这个方案呢主要是移动提供的，专网通道，具体原理呢咱也不知道，反正是这样用的。
  俗气的理解为别人都要通过高考挤独木桥，而你被保送清华了。

---