前言
对于经常关注物联网通信技术的人应该对NB-IoT这个词不会陌生，关于它的一些基础概念与来源大家可以自行看网上已有的介绍，这里不再阐述。这段时间刚好在学习NB-IoT并尝试将其应用到一些项目的改良中，在学习和使用的过程中对其有新的认识，因此将一些要点整理了下来，希望对后续有意接触NB-IoT的同学有所帮助。
NB-IoT要点概括
1、为解决传统2G/3G/4G(GPRS)网络不能满足物联网终端设备低功耗、低成本的问题；
2、对比GPRS，减少了一些信令，寻呼周期加长，增加PSM状态，降低功耗(用实时性换取续航)；
3、终端数据通过运营商基站接入核心网，汇入运营商的物联网专网，经IoT平台与用户的平台进行数据交互
NB-IoT的工作状态：
NB-IoT在默认状态下，存在三种工作状态，三种状态会根据不同的配置参数进行切换，笔者认为这三种状态较深刻地影响了NB-IoT的特性，如其对比传统GPRS的低功耗特性，均可以从中获得解释，同时在后续对NB-IoT的使用和相关程序的设计时，也需要根据开发的需求与产品特性对这三种工作状态进行合适的定制。
三种工作状态如下：
Connected(连接态)：
模块注册入网后处于该状态，可以发送和接收数据，无数据交互超过一段时间后会进入Idle模式，时间可配置。
Idle(空闲态)：
可收发数据，且接收下行数据会进入Connected状态，无数据交互超过一段时会进入PSM模式，时间可配置。
PSM(节能模式)：
此模式下终端关闭收发信号机，不监听无线侧的寻呼，因此虽然依旧注册在网络，但信令不可达，无法收到下行数据，功率很小。
持续时间由核心网配置(T3412)，有上行数据需要传输或TAU周期结束时会进入Connected态。
NB-IoT三种工作状态一般情况的转换过程可以总结如下：
① 终端发送数据完毕处于Connected态，启动“不活动计时器”，默认20秒，可配置范围为1s~3600s；
② “不活动计时器”超时，终端进入Idle态，启动及或定时器(Active-Timer【T3324】)，超时时间配置范围为2秒~186分钟；
③ Active-Timer超时，终端进入PSM状态，TAU周期结束时进入Connected态，TAU周期【T3412】配置范围为54分钟~310小时。
【PS：TAU周期指的是从Idle开始到PSM模式结束】
NB-IoT终端在不同工作状态下的情况剖析：
1、NB-IoT发送数据时处于激活态，在超过“不活动计数器”配置的超时时间后，会进入Idle空闲态；
2、空闲态引入了eDRX机制，在一个完整的Idle过程中，包含了若干个eDRX周期，eDRX周期可以通过定时器配置，范围为20.48秒~2.92小时，而每个eDRX周期中又包含了若干个DRX寻呼周期；
3、若干个DRX寻呼周期组成一个寻呼时间窗口(PTW)，寻呼时间窗口可由定时器设置，范围为2.56s~40.96s，取值大小决定了窗口的大小和寻呼的次数；
4、在Active Timer超时后，NB-IoT终端由空闲态进入PSM态，在此状态中，终端不进行寻呼，不接受下行数据，处于休眠状态；
5、TAU Timer从终端进入空闲态时便开始计时，当计时器超时后终端会从PSM状态退出，发起TAU操作，回到激活态（对应图中①）；
6、当终端处于PSM态时，也可以通过主动发送上行数据令终端回到激活态（对应图中②）。
定时器参数的配置
在整个NB-IoT工作的过程中，有一些定时器参数可以进行设置，从而改变各个工作状态的内部细节和周期占比，而这些定时器参数需要通过设备NB卡地签约APN来实现。以电信NB SIM卡为例，默认签约的APN为“ctnb”，终端在入网时由网络自动下发。不同的APN代表着一组不同的定时器参数，如"ctnb"的APN描述为【监测上报类，激活定时器=2s，开启PSM、关闭eDRX】。若使用APN"psmc.eDRXC.ctnb"，则对应的参数为【开启PSM、开启eDRX，激活定时器=180s，eDRX周期=20.48s，寻呼窗口=10.48s】。当然，APN也支持用户的定制，对应的APN名称为"ue.prefer.ctnb"，工作状态的开关与定时器参数由终端上报的参数决定。
写在后面
看完NB-IoT工作状态的特性，我们不难发现，NB-IoT协议在设计语言上与大部分的低功耗传输无线传输协议上并无二致，如ZigBee通过控制终端节点向父节点的数据轮询频率(可通过NLME_SetPollRate函数调节)，从而实现对功耗的调控。而NB-IoT的方法也与此类似，使得终端在大部分时候处于低功耗的PSM态，只要需要数据上报的时候才进入激活态，因此NB-IoT比较适合应用在一些数据定时上报的场景（抄表、环境监测），但并不适合用于反控。NB-IoT通过降低寻呼的频率，用牺牲实时性的方式换来较低的功耗，使得它在接收下行数据的实时性上显得吃力，这也是可以理解的。
笔者在学习NB-IoT的过程中，对今年电信在北京宣布NB-IoT商用时提到的OFO使用NB锁感到好奇，如果按照官方所说的使用NB-IoT锁的小黄车可以一秒解锁、仅靠太阳能就可满足功耗，结合NB-IoT的特性，如果采用的是云端下发指令或密码至锁的方式，这是基本不可能实现，笔者会在后续的文章详细讨论其他方法的可行性。
以上为本人在学习过程中的一些想法，对于NB-IoT的应用，个人觉得目前有它较为适用的场景，且由于其数据的传输方式，相比很多方式有着不言而明的优势，但绝不是可以用在物联网中任何场景的方式。不管如何，将答案交给市场。后续会从测试环境搭建、代码设计、产品设计的角度对NB-IoT进行进一步剖析，欢迎各位同行互相交流、互相学习。
文章来源：King_Mumumu的博客