解读蜂窝物联网

         

网优技术领先品牌

扫码关注，总有不一样的惊喜

网优小谈

物联网技术已经是全社会关注的一个热点问题，带动了新一轮的生产方式和行业的变革。已有太多的文章解读了物联网的产业格局和应用。小编从今年年初开始跟进物联网技术领域，尝试用一个工程师的视角去解读蜂窝物联网整体框架与技术精髓，也许相比各种大部头的饕餮盛宴，这一类技术文章解读仅仅是像清粥小菜那样，虽不一定为业内茶余饭后的津津乐道，甚至可以说枯燥的晦涩难懂，但小编力求以专业的视角，严谨的态度，甚至夹杂普世的人文情怀，力图呈现一个有温度、有态度的技术写作。然而初涉领域不久，视角难免狭隘，理解难免偏颇，这在回顾最初的几篇文章时发现了这样的问题，怎奈文已成章，只好和一众行业精英共同研习，不断提升。技术没有完美的，总是不断发展的，个人的理解感悟也其实如此。

小序

物联网技术已经应用在我们的日常生活中很久了，在一个餐馆吃完饭，准备用信用卡结账，侍应生会拿来移动pos机供顾客刷卡，刷卡结算信息的回传就是靠GPRS移动蜂窝网络进行回传。相比用WiFi热点传输，对于这类涉及金融交易的物联网应用，移动蜂窝网络的优势相当明显，首先是更大范围的移动性，保险公司的业务员可以开着车，拿着pos机等待在公司楼下办理业务。另外就是数据安全性，移动蜂窝网络设计的重要因素之一就是对于用户数据的加密鉴权机制，通过这样的安全措施保障，使得用户数据不会被轻易截获。当然还有一些基于WiFi热点的物联网应用，比如无线监控摄像头，智能电饭煲等等，这些应用主要特征是小范围，热点型，家居应用居多。由此可见，物联网应用并不是新鲜东西，随着国家信息化战略提出开创万物互联的新时代，越来越多的基于移动蜂窝网络的物联网技术，甚至基于私有协议标准的物联网技术登上历史舞台。

物联网技术的一个重要标签就是低功耗，这也是物联网应用与服务能否成为全球范围内下一个最重要的技术浪潮的关键，因此低功耗广域网络（Low Power Wide Area Network, LPWAN）也成为了物联网的代名词。涉及到LPWAN的技术标准阵营众多，比如IEEE,ETSI ,3GPP,IETF,LoRa Alliance等，当然包括的协议标准更是汗牛充栋，不仅有物联网那些元老级的技术标准WiFi, Bluetooth, ZigBee，更有那些物联网技术新贵，比如NB-IoT,eMTC,Sigfox,LoRa等等。为了了解一个个全新技术的基本原理，最好的办法就是我们循着这些技术的发展轨迹从新走一遭。

前生

前几期文章主要关注了蜂窝物联网技术的一个重要分支，NB-IoT（窄带物联网），窄带物联网的重要技术特点是广覆盖，低功耗（超长待机），海量连接，数据可靠性，据说最初源自的需求是对于水表计量中对于用水量的自动计算，并以无线数据的方式进行回传。

那么NB-IoT这样的新型物联网技术是怎样一步步形成标准的呢？其他的物联网技术还有哪些呢？

对于物联网标准的发展，不可否认作为中国本土通信企业，中国移动，华为很早介入进来。尽管我们的文章一贯秉持中立的技术视角，并不是为哪种商业阵营或者团体进行背书，但是为了说明为什么有这么多的技术标准共存的现状，不得不提及技术发展的一些背后的故事。

早在2013年，包括运营商，设备制造商，芯片提供商等产业链上下游就对窄带蜂窝物联网产生了前瞻性的兴趣，为窄带物联网起名叫LTE-M，全称为LTE for Machine to Machine，名字蕴含的期望是基于LTE产生一种革命性的新空口技术，该技术既能做到终端低成本低功耗，又能够和LTE网络共同部署。另外，LTE-M从商用角度同时夜提出了广域覆盖和低成本的两大目标。从此以后，窄带物联网的协议标准化之路逐步加快了步伐

NB-IoT之路

在初期的技术选型中存在两种思路，一种是对于GSM网络的演进思路，另一种是华为提出的新空口思路，当时命名为NB-M2M，尽管这两种技术思路都被包含在3GPP GERAN标准化工作组立项之初，但是相比暮气沉沉的GSM技术演进，新空口方案反而引起了更多运营商的兴趣，2014年5月，LTE-M的名字也演变为Cellular IoT，简称CIoT，从名称的演变更直观的反应出了技术的定位，同时对于技术的选型态度更加包容。

随着全球金融投资对物联网带来的经济效益集体看涨，在GERAN最初立项进行标准化的CIoT课题得到了越来越多运营商、设备商的关注，不过GERAN的影响力相对来说已经日趋式微，2015年4月底，3GPP内部的项目协调小组（Project Coordination Group）在会上做了一项重要决定，CIoT在GERAN研究立项之后，实质性的标准化阶段转移到RAN进行立项，这也说明3GPP标准化组织顺势而为，通过将CIoT技术的标准化工作转移到更大的平台上，以期收获全球更多产业链的关注，其实这里也释放了一个信号，CIoT已经逐步脱离开老东家GSM的技术思路，走向了更新颖，更创新的技术选型。

2015年5月，华为与高通基于达成共识的基础上，共同宣布了一种融合的解决办法，上行采用FDMA多址的方式，下行采用OFDMA多址方式，融合之后的方案的名字叫做NB-CIoT（Narrow Band Celluar IoT），这一融合方案已经基本奠定了窄带物联网的基础架构，这一阶段的某些命名也在协议标准上留下了痕迹，例如涉及到核心网协议的3GPP 24.301 R13统一将蜂窝物联网技术称作CIoT，并不区分是NB-IoT的接入方式还是非NB-IoT的接入方式。

通信技术的更新换代往往孕育着巨大的商业市场，华为和高通在窄带物联网通信领域的前瞻性投入也带来其他厂商纷纷跟进，爱立信联合其他几家公司提出了NB-LTE（Narrow Band LTE）的方案，从名称可以直观的看出，NB-LTE最主要希望能够使用旧有的LTE实体层部分，并且有相当大的程度能够使用上层的LTE网路，使得营运商在布建时能够减少设备升级的成本，在建置上也能够沿用原有的蜂巢网路架构，达到快速布建的目的。NB-LTE与NB-CIoT最主要的区别在于采样频率以及上行多址接入技术的选型。两种方案各有特点

2015年9月份，经过多轮角逐和激烈讨论，各方最终达成一致，NB-CIoT和NB-LTE两个技术方案进行融合形成了NB-IoT，NB-IoT的名称正式确立。从标准的角度来看，NB-IoT的名称频繁出现在接入网协议中，这也某种意义上说明各方对于窄带物联网技术的创新与探索主要在接入网技术中。

2016年底，3GPP规范Release13最终完成冻结，至此NB-IoT从技术标准中彻底完备了系统实现所需的所有细节。当然，随着技术标准版本的不断演进（Release 14, Release 15.....）,对应的系统设计也会不断的更新升级。

2017年2月，中国移动在鹰潭建成全国第一张地市级全域覆盖NB-IoT网络，预示着蜂窝物联网已经开始从标准理念向正式全网商用落地迈出实质性的一步。2G GSM网络从1982年创立研究小组到1995年中国GSM数字电话网正式开通走过了13年，3G移动通信网络从2000年国际电信联盟技术标准的确立到2009年1月国家为三大运营商发放商用牌照走过了9年，4G移动通信网络从2009年ITU在全世界范围内征集IMT-Advanced候选技术开始到2013年12月工信部位三大运营商发放商用牌照只走过了短短的4年，按照这个趋势看来，下一代面向物联网的通信网络不会让我们等待太久。

eMTC之路

早在2002年时，Machine to Machine(M2M)，这一物物通信，万物互联业务的雏形概念已经被提出，但碍于通讯技术尚未成熟，发展仍属于启蒙阶段，例如自来水、电力公司的自动抄表及数位家庭应用等。随着无线通讯技术的快速发展，M2M的应用服务进入快速发展的阶段，在农业、工业、公共安全、城市管理、医疗、大众运输及环境监控上，都可看到M2M的应用，例如：智慧节能、智慧车载、智慧医疗、智慧城市、智慧物流等。3GPP标准组织将M2M称之为机器型态通讯（Machine Type Communication， MTC），是一种新兴的通讯架构，以机器终端设备为主，具备网路通讯能力，可智慧互动地提供各式各样前所未见的应用与服务，例如：监控、控制、资料撷取等资讯化的需求。

早在2010年左右，学术界就开始进行了基于物联网需求的Machine Type Communication（MTC）技术的相关研究。作为物联网的候选通信技术，LTE很早就纳入了业界的视野当中。LTE （Long Term Evolution）七八年以前在3GPP Release 8 中最早被定义下来之后，就从来没有停止过演进。其发展大概有两个方向：一是不断追求更高的用户体验,通过一系列调制，编码，天线技术的革新，不断提升频谱效率，提供更高的用户吞吐率；另一个方向是LTE 整个网络和终端的简化，以面向海量部署、低成本、低功耗，从而支持未来物联网市场的技术。3GPP在22.368中明确定义了物联网技术MTC的服务要求，明确了MTC提供一种有别于个人通信的全新市场形态，同时提供低价值，低功耗，小数据流量，面向大链接的数据服务，其中也对其技术特征进行了明确要求，就是低移动性，低频次的被叫业务，MTC设备状态监控，MTC设备组的流控以及广播信息优化，定时发送数据或者分时计费，提供稳定安全的连接。为了满足MTC更低传输速率及更低功耗的需求，3GPP R12在原有面对用户提供更高吞吐能力的终端分类基础上新增Cat0的UE传输等级，用以支持低速率的终端类型，UE工作带宽为20 MHz，支持半双工，最大发射功率为23 dBm；3GPP R13的将该技术进一步演进，命名为eMTC，意味着这一物联网技术性能上的升级。这一个e(enhancements)进一步简化终端功能，UE工作带宽为1.4 MHz，支持半双工，UE可使用更低发射功率20 dBm；3GPP R14阶段也将新增定位功能、SC-P2M 下行广播功能、异频测量功能等。LTE eMTC 相比NB-IoT 能够提供更高的传输速率，拥有更丰富的应用场景。

在接入网协议中并没有直接以MTC/eMTC的名称出现，而是以Low Complexity UE进行代替，R13中进一步明确了两种终端类型与技术标准，分别是Bandwidth Reduced Low Complexity UE和UE in Enhanced Coverage，体现在物理接入带宽和服务覆盖区域的变化

相比国内产业链对于NB-IoT的热捧，eMTC似乎没有受到同样程度的关注，这不仅从能搜索到的互联网相关信息或是从国内运营商的网络部署进度来看都能看出一些端倪。从目前掌握的情况来看，全球物联网络部署中，北美主流运营商更倾向于优先部署eMTC，而对NB-IoT优先级相对不高，这可能源于资本家企业一贯对于建设投资“抠搜”的风格，也可能是运营商基于提供服务需求角度出发进行的决策考虑。另外，欧美主流运营商对于2G网络的退网以及频率重耕策略，也更加为从数据，语音，容量，覆盖等多维度具备完全替代现有2G网络能力的eMTC技术奠定了频率资源基础。（注：AT&T宣布2017年1月1日已正式关闭2G网络、Verizon明确2G退网计划、从2009年开始NTT DoCoMo、KDDI就陆续宣布中止2G服务、去年12月Telstra宣布关闭2G网络）

这两种技术在实质上没有什么颠覆性的区别，基带的调制复用技术都是源自OFDM，频谱利用率也都基本相似，不过在组网基本带宽，上下行频率选择（FDD/TDD），吞吐率方面有所区别，这就意味着二者本身并不成为竞争关系，而恰恰是适合不同应用领域的互相补充，比如NB-IoT适合静态的，低速的，对时延不太敏感“滴水式”的交互类业务，比如用水量，燃气消耗计数上传之类的业务，而eMTC具备一定的移动性，速率适中，对于实时性有一定需求，比如智能穿戴中对于老年人的异常情况的事件上报，电梯故障维护告警等。3GPP中的业务应用就对eMTC有一段很有趣描述，因为eMTC具备移动性，那么恰恰网络侧可以利用检测到的物联网设备移动情况来判断那些一般处于静态的物品是否已经被盗窃，这是利用移动性作为一些辅助应用的展望。另外eMTC可以通过VoLTE技术支持语音，这也是eMTC的一个特征所在。

              协议规定各类型终端能力以及技术参数

对于运营商而言，某一物联网技术能够提供更深的覆盖，更大规模的连接数量，更稳定的性能，更少的建设投资以及后期维护的成本固然令人欣喜，但是更关键的考量在于运营获取的收入，对于物联网技术带来的变革，势必对传统的运营模式也带来冲击，也许物联网的运营模式也要借鉴互联网初期的模式，规模效应，跑马圈地才有后续的不断增值发展空间，而这恰恰又是技术发展带给通信人的舞台，也是时代给予的馈赠。

EC-GSM之路

EC-GSM的英文全程是Extended Coverage-GSM，可以从名称上直观看出，这是基于老牌2G通信技术向更广范围覆盖延伸的一种物联网技术。EC-GSM主要由一些老牌的通信设备企业所倡导，比如爱立信，诺基亚等，不仅意味着在原有GSM运营模式上继续挖潜新的商业价值增长点，在某种意义上，也意味着老牌通信企业对于通信技术尊严的捍卫。

EC-GSM的技术创新在于采取了新的逻辑信道结构，也是类似NB-IoT采取在时间轴上重传的方式，提升覆盖，同时结合了CDMA实现多址的方式提升容量。同时还通过诸如系统消息的优化（没有异系统互操作），扩展DRX时间，完保加密算法的升级等新的技术在终端节电和安全方面进行了强化。该技术的另一个优势在于，它是对现有的无线通信网络进行软件升级，无需额外的硬件即可实现全国性的物联网覆盖。

                       三种蜂窝物联网技术参数对比

EC-GSM测试已在法国开展，采用900MHz频段，将设备覆盖提高20dB，这一覆盖提升是相当可观的，可以到达较难覆盖的区域，例如装有多台智能计量表的深层室内地下室，或者已部署传感器进行农业和基础设施监控的偏远地区。另外不管是基于OFDM调制的物联网技术还是GSM的覆盖延伸的物联网技术都可以采用PSM（Power Saving Mode）模式，达到降低功耗，省电的作用。

SigFox之路

被称作搅局物联网阵营“鲶鱼”的SigFox其实是一家公司的名字。早在2012年，SigFox作为一家初创公司，以其超窄带（UNB）技术开始了低功耗广域网络的布局，很快成为全球物联网产业中的明星企业。作为在通信领域的一条强有影响力的“鲶鱼”，SigFox促进了运营商对低功耗广域网络的重视，让很多主流运营商因此踏上了部署低功耗广域网络之路。所谓UNB是Ultra Narrow Band的简称，即超窄带技术。该技术采取窄带BPSK调制提供上行100bps的极低速率，上行消息每包大小12byte，下行消息每包大小8byte，同时限制主要用来承载配置信息的下行消息一天最多不超过4条这样的方式提供海量设备连接和极低功耗。另外该技术的协议栈相比传统电信级的协议要简单的很多，不要参数配置，没有连接请求以及信令交互，这样的协议栈虽然设计简单，节省芯片成本，但站在CT技术的视角，对于提供稳定，安全的物联网接入是否可能存在隐患目前无法得知。

SigFox不是传统电信运营商，而是一家颇带有几分互联网基因的物联网技术公司，不仅提供物联网设备，模组，布网解决方案，同时也提供管理IoT的平台，甚至更有运营物联网的趋势。

该公司采取一种更开源的姿态提供给用户基于SigFox模组上的二次开发，这不仅是加强SigFox技术阵营影响力的一种方式，也是一种互联网思维在物联网技术上的延续。按照SigFox公司官方的宣传，目前这一私有物联网技术已经为32个国家，5亿人口提供服务，覆盖达200万平方公里，相当于1/5个欧洲。

目前SigFox采取的频率主要包括：欧洲、中东：868MHz(ETSI 300-220)、北美：902MHz(FCC part 15)、南美/澳大利亚/新西兰：920MHz(ANATEL 506， AS/NZS 4268)，这在当地运营商基本属于非授权频谱，不过"900M频段”一直被誉为频谱里的黄金频段，这也某种程度上助力了SigFox提供广域覆盖，中国这一频段主要作为GSM授权频谱。

LoRa之路

LoRa依然是低功率广域通信网（LPWAN）技术中的一员。是美国Semtech公司采用和推广的一种基于扩频技术的超远距离无线传输方案。Semtech是一家位于美国加州地地道道的硅谷公司，这是一家以专注提供模拟和混合信号半导体产品以及电源解决方案起家的公司，目前却成为了倡导低功耗，远距离无线传输LoRa技术的引领者。

2015年3月LoRa联盟宣布成立，这是一个开放的、非盈利性组织，其目的在于将LoRa推向全球，实现LoRa技术的商用。该联盟由Semtech牵头，发起成员还有法国Actility，中国AUGTEK和荷兰皇家电信KPN等企业，到目前为止，联盟成员数量达330多家，其中不乏IBM、思科、法国Orange等重量级厂商。

目前LoRa网络已经在世界多地进行试点或部署。截至目前LoRa联盟最新公布的数据，已经有17个国家公开宣布建网计划，120多个城市地区有正在运行的LoRa网络，如美国、法国、德国、澳大利亚、印度等等国家，荷兰、瑞士、韩国等更是部署或计划部署覆盖全国的LoRa网络。

LoRa联盟基于开源MAC协议制定了统一的LoRaWAN标准,LoRaWAN协议有点类似3GPP通信协议的风格，对于LoRa无线接入网进行了较严格的定义，整体网络架构偏应用部分的实现则相对宽松。

在LoRaWAN协议中，对于接入终端有新的命名，即Mote/Node （节点）。节点一般与传感器连接，负责收集传感数据，然后通过LoRaMAC 协议传输给Gateway（网关）。网关通过WiFi网络，3/4G移动通信网络或者以太网作为回传网络，将节点的数据传输给Server（服务器），完成数据从LoRa方式到无线/有线通信网络的转换，其中Gateway并不对数据做处理，只是负责将数据打包封装，然后传输给服务器。LoRa技术更像是一次通信物理层技术与互联网协议高层协议栈的大胆融合。LoRaWAN物理层接入采取线性扩频，前向纠错编码技术等，通过扩频增益，提升了链路预算。而高层协议栈又颠覆了传统电信网络协议中控制与业务分离的设计思维，采取类似TCP/IP协议中控制消息承载在Payheader而用户信息承载在Payload这样的方式层层封装传输。这样的好处是避免了移动通信网络中繁复的空口接入信令交互，但前提是节点设备具备独立发起业务传输的能力，并不需要受到网络侧完全的调度控制，这在小数据业务流传输，不需要网络侧统一进行资源调度的大连接物联网应用中，未尝不是一种很新颖去中心化尝试（并不以网络调度为中心）。

目前LoRaWAN技术采取上下行同频，节点伪随机调频，节点自适应进行传输功率调整，“纯Aloha”（可随时发起业务）的方式进行数据传输，这样的好处是通过避免周期侦听网络消息的方式与网络侧进行同步从而达到非常低功耗的目的，但是随着节点数的大量增加，会增大节点之间传输的碰撞概率，也会使得网络传输效率降低,同时不同用途的节点在数据传输中的QoS也难以保证。当然，随着产业的进一步发展，相信这些问题也会得到更有效的解决。

LoRa主要工作在1GHz以下免授权频段，免授权频段的设备种类相对多，难免会受到其他无线设备的干扰，但是免授权频段无需申请即可进行网络的建设，网络架构简单，运营成本也低，同时，LoRa的优势在于其专利技术，即使在复杂的环境中依然能保持较高的接受灵敏度，抗干扰能力强，因此，全球范围内的物联网运营新贵依然对LoRa青睐有加。相比NB-IoT技术的严谨性，LoRa更像是互联网思维下快速上线的产物，但是凭借其基于物联网应用的良好理解，定制化的进行技术设计，凭借其“绝活能力”，应用前景不容小觑。

物物通信之路

新兴物联网通信技术中除了蜂窝物联网通信技术之外，还有一个新兴的领域，就是短距离的物物之间直接通信进行数据交互，标准化制定中为了与M2M有所区别，称作Device to Device Communication(D2D)。随着移动互联网应用与服务的普遍提供，基于近场位置的物物通信有很多有趣的应用，比如电影院对于附近路过的影迷传递最新影片的小样；早晨晨跑时候路过某家咖啡馆被通知有相熟的朋友也在这里；，消防的即时通信服务，诸如此类等等。 早期的WiFi,Bluetooth，ZigBee技术都是一种近场低功耗的物物通信技术，但是由于其工作在非授权频谱，需要手工匹配，安全性难以得到保障，同时需要与蜂窝网络并行独立同时工作，这些技术特征会导致容量，质量难以保证，难以提供自动化近场服务，难以应用到公共安全通信领域，难以保障较低功耗等一些列的问题。始于3GPP R12 中LTE-advanced的D2D技术（注：协议中命名为sidelink）是一种端到端通信技术，是通过重用宏蜂窝用户资源来实现的。D2D技术主要包含两个功能，一个是D2D发现功能，它能够使得用户设备之间通过LTE射频空口在近场相互发现。另一个是D2D通信功能，它能够使得用户设备之间通过LTE射频空口复用LTE频率直接进行数据传输而避免通过网络进行路由，网络只负责一些资源协调和安全管控。D2D通信的目标距离是提供500米的服务，当然这也取决于网络传播条件和网络的负荷情况。

D2D技术支持小区用户之间直接进行通信，通过重用网络频带资源带来很多优点，可以增加LTE-advanced的频谱利用效率，有效改善无线通信系统频谱资源匮乏的问题，并且可以降低终端发射功率，节能降耗，减小小区负载并保证QoS提供新的服务。无疑，D2D技术来源于蜂窝通信网络技术，但是对于通信运营商的影响是深远的，尽管存在以上的一系列优点，D2D通过一定程度的网络去中心化不仅对于现在的网络运营还是未来的网络规划都将有重大意义的改变。当然，影响改变往往意味着与机遇共存，作为物联网通信的另一个范畴物物直连通信的先驱，D2D技术实现了网络轻量化结构，运营商如何提前布局，应对挑战，把握机遇，实现新的收入增长，值得更深入的思考。

今世

3GPP R14支持NB-IoT的定位功能以及移动性，国内最大的共享单车企业ofo已经与华为、中国电信达成NB-IoT战略合作，在全新单车上部署基于NB-IoT的智能锁模块，提供低成本自行车定位的解决方案。

AT＆T、Verizon、KPN、西班牙电信等4大洲9家主流运营商宣布支持eMTC，这些运营商分布在美国、欧洲、亚洲和澳洲四大洲，eMTC的全球市场版图开始强势扩大。

世界领先物联网连接提供商Sigfox近期宣布完成1.5亿欧元E轮融资,用来加快全球网络扩张和迅速实现全球覆盖,同时宣称能够提供免GPS应用超低成本的物联网定位服务。凭借在其网络上注册的1000多万个对象和目前涉及26个国家的覆盖面,Sigfox正在巩固其在物联网领域的全球领先地位。新一轮融资将让该公司能够在2018年之前把其国际网络扩大到60个国家,并达到财务损益平衡点。

中兴通讯与Semtech在2017年汉诺威消费电子、信息及通信博览会（CeBIT）现场签署基于LoRa定位技术的合作框架协议，双方决定就LoRa定位领域展开深入合作。基于该MOU协议，两家公司将联合开展LoRa定位应用的研究，以满足各种物联网应用的定位需求。据了解，“LoRa定位”是Semtech针对LoRa网关芯片最新设计并推出的免终端参与被动定位技术，通过多个LoRa基站接收终端数据信号时获取终端的信号传输时延，对不同基站的距离测算出终端的位置，提供免传感器零功耗定位能力，定位精度可以达到数十米级别。

从这些关于低功耗广域物联网通信技术最新的资讯来看，物联网技术下一个研究热点以及商业应用或许在于抛弃了传统GPS，更低廉成本的定位技术。

（1）接入网主要协议流程

5G是什么？目前业内已经达成了基本共识，它的一个重要属性是支持万物互联，也就意味着下一代通信网络构建的目的不仅是为用户提供更高的速率，同时也需要有效提供支持物联网的系统架构。这在协议标准里就进行了体现，3GPP的标准并没有直接为NB-IoT（NarrowBand Internet of Things，窄带物联网），eMTC等物联网技术单独立书作传，但是在LTE的接入网，核心网等协议中进行了融合升级，这样其实也表明了一种态度，物联网的核心技术（例如物理层的调制/解调技术）与LTE的是大体一致的，同时又是LTE技术的某种方向上的演进，与LTE网络技术长远来看是和谐共存的。

在开始这篇文章的阅读之前，我们先简单澄清一个概念。目前蜂窝物联网技术（CIoT）是一个总体的范畴，当然还有sidelink这样的物物数据传输技术，可以说CIoT又细分成了窄带物联网（NB-IoT）和非NB-IoT两个领域（非NB-IoT包括eMTC或BL UE或支持物联网技术的LTE终端等），NB-IoT技术相对比较独立，承接了某些GSM标准化组织早期的研究基因，这里我们不去天花乱坠的叙述物联网技术的前世今生，我们直接从协议标准的角度来理解物联网技术。

从接入网来看，NB-IoT等终端的工作状态与LTE一样，基本是两种，RRC_IDLE,RRC-CONNETED,但也有一些不同的细节，例如NB-IoT没有互操作的属性，意味着NB-IoT的终端无法切换，重定向，CCO（cell change order）到2,3G网络，NB-IoT终端只具备E-UTRA状态（只有一种工作模式）；NB-IoT终端在连接态下不读系统消息，而4G终端在连接态下可以获取系统消息；NB-IoT终端在连接态不提供任何信道反馈（没有QoS管控），同时也不提供测量报告（Measurement Reporting）；另外在NB-IoT里关于上行速率调度机制也不具备，相比较而言MTC终端由于根源自LTE，因此这些基本的机制还和LTE大网技术保持一致，但也有一些细微的区别，我们慢慢会提及到。

信令承载和系统消息

相较于LTE，NB-IoT没有SRB2，NB-IoT使用SRB1 bis作为专属逻辑信道的承载。

在LTE系统中，UE想要正常小区驻留，获取系统消息，首先需要获取MIB消息块，为了保证MIB的正确解读，LTE系统以40ms作为周期，每个周期之内重复发送4次MIB的方式提高MIB获取的可靠性。而相比之下，NB-IoT更加保守，不仅以640ms作为周期，每个周期内重发发送64次MIB-NB，同时每80ms子周期内MIB-NB被分别独立编码了8次，并在每个无线帧的0号子帧中进行下发，这样每80ms都重复着这样的编码循环，提升了MIB-NB的获取和解读的可靠性。

LTE系统中以80ms作为周期发送SIB1消息，每个周期之内重复发送4次SIB1消息，起始位置在SFNmod8=0的5号子帧中发送（即无线帧0,8,16,24.....）。NB-IoT里面的SystemInformationBlockType1-NB (SIB1-NB) 以2560ms为周期进行发送，SIB1-NB以16个连续的无线帧作为基本发送单位，在4号子帧上固定发送。在一个2560ms周期内等时间间隔的重复发送，可以分别按照4,8,16循环次数发送。SIB1-NB的传输块大小以及2560ms内的循环次数在MIB-NB中的schedulingInfoSIB指明。
至于其他的SI消息的相关调度信息（SI时/频资源占用，SI窗长，SI周期）在由SIB1-NB消息解码获取。

层3协议流程

涉及NB-IoT终端的协议流程大体与LTE的终端协议流程类似，不过也有几点更新以及需要关注的方面。

目前暂时不确定未来NB-IoT终端的形态，按照协议的设计，大致分为纯NB-IoT终端，以及和LTE公网接入混合类型终端，而纯NB-IoT终端从技术标准又分为两种，一种是通过NAS层协议栈传送小数据，不建立DRB。另外一种如同传统
的E-UTRAN协议栈，通过建立DRB传输数据。对于后者，在RRC的专用信令承载SRB1建立之时，SRB1 bis同时被隐式的建立起来，但是需要等到安全指令模式之后才被真正使用。这里通过不同逻辑信道标识实现，SRB1采用标识1，SRB1 bis采用标识3。

相比LTE接入网信令流程，NB-IoT多出了一个RRC connection resume（RRC连接恢复流程），而该流程不适用于NAS层控制面协议栈传送小数据的CIoT终端。

恢复是针对“挂起”流程而言的，为了使得NB-IoT终端更加省电，协议设计了“挂起-恢复”流程（当然该流程也可以适用大网），网络侧通过RRCConnectionRelease消息中的 rrc-Suspend字段告诉UE，RRC连接被挂起，UE存储接入层协议栈上下文和resumeIdentity,同时从连接态转变为RRC_IDLE（空闲态），挂起针对RRC层已建立的至少1个DRB，这也意味着对于NAS层协议栈传送小数据的NB-IoT终端，“挂起-恢复”流程是不适用的。恢复流程会重新激活安全模式和重新建立信令和数据承载，相比RRCConnectionRequest,不需要有后续安全模式控制流程了。这样可以使得终端快速“恢复”与网络侧的连接。另外，相比R13之前的协议版本中RRCConnectionRequest的触发原因，RRCConnectionResumeRequest多出一条mo-VoiceCall（R13中两者是中所含的触发原因是保持一致的）。如果触发原因是多媒体电话视频业务请求，并且驻留小区SIB2消息中包含voiceServiceCauseIndication,那么RRC接入/恢复的触发原因就可以设置为mo-VoiceCall，值得注意的是现网VoLTE主叫触发原因是mo-Data。从这里看出，窄带物联网也不仅仅是传输数据，还可以传送语音。

对于终端的“恢复”请求，网络侧可能会恢复之前“悬挂”起的RRC连接，或者拒绝恢复请求，或者建立一个新的RRC连接。

当UE发出RRCConnectionResumeRequest,而网络侧的响应消息为RRCConnecionSetup,此时意味着网络侧建立一个新的RRC连接，那么UE需要将之前存贮的AS上下文以及resumeIdentity丢弃，并且通知高层UE连接恢复被“回退”成新的RRC连接了。如同RRC连接请求一样，RRC连接恢复请求也同样受T300控制，T300超时后底层清空，RRC连接流程终止，后续行为由终端决定。

接入层对于终端的挂起一般是由处于EMM-CONNECTED模式下的网络侧高层（NAS层）触发的，而恢复NAS信令连接则对应的由UE触发，这与接入层的“挂起-恢复”流程是对应的，可以看到接入层的“挂起”是由NAS层的“挂起”触发的（源头是接入网向核心网发起请求），而NAS层的“恢复”则是由接入层的“恢复”触发的。这里要提到CloT的两种数据传输模式，一种是传统的由NAS用户面承载数据（user plane CIoT EPS optimization），另一种是由NAS控制面承载数据（control plane CIoT EPS optimization）。以上的“挂起-恢复”流程只和NAS用户面承载数据模式相关，并不适用NAS控制面承载数据。NAS控制面模式只能通过NAS信令连接释放的方式进行资源释放和优化。UE通过在TAU REQUEST中设置“signalling active"标签来指明释放通过NAS控制面信令进行数据传输。

对于NB-IoT终端来讲，control plane CIoT EPS optimization（简称CP）模式是必选项，而user plane CIoT EPS optimization（简称UP模式）是可选项，因此在RRCConnectionSetupComplete-NB消息体中只含UP模式的可选项。

而对那些非NB-IoT的终端，比如eMTC终端，或者LTE更新版本的终端，UP模式和CP模式都是可选项，RRCConnectionSetupComplete消息体里根据高层指示，选填这两个字段进行上报。这个取决于网络设备商如何实现了。

再来最后聊一个小问题，对于UP模式下的物联网终端的恢复请求RRCConnectionResumeRequest，网络侧什么时候会直接响应RRCConnectionSetup,一般理解是网络侧找不到用户上下文时会指示终端建立新的RRC连接，但一般什么时候网络侧会找不到用户上下文呢，根据前面分析提到的一个概念，恢复是对应挂起的，而挂起源自于核心网MME的触发，因此一般MME内部基站间切换都可以进行上下文的传递，而当跨MME切换的时候，由可能由于网络侧找不到用户上下文而直接响应用户建立新的RRC连接。这只是我们初步用力拍脑袋的一个理论分析，更多的实例有待于我们去发现。

（2）核心网关键技术流程

3GPP 23.401中对于蜂窝物联网（Celluar Internet of Things,CIoT）是短短一句话定义的，蜂窝网络支持低复杂度和低吞吐率的物联网设备。蜂窝物联网同时支持IP业务和非IP业务（非IP的业务指的是站在EPS的角度来看的一些非结构化数据，尽管还是会被分配APN）。

对于物联网，小包数据业务传输将成为应用的典型特征。因此，对于核心网而言，基于物联网的这种小数据，短时延传输模式进行了一些协议流程方面的优化。这种优化方式包含了两种模式，一种是基于用户面传输用户数据，而另一种是将用户数据封装在了NAS层消息里的控制面传输方式，这种方式减少很多控制面的信令开销。PDN连接可以采取控制面CIoT核心网承载优化方式处理，或者也可以采取用户面CIoT核心网承载优化方式处理。相比传统PDN连接需要使用S1-U接口进行传输，这里S11-U也可以被用来传输小包数据。

CIoT的数据可以包括物联网应用的状态信息以及测量数据。

5G当中支持物联网数据通信的MME可能有这么几种支持数据传输的模式，

MME支持控制面CIoT数据优化传输模式，

MME支持用户面CIoT数据优化传输模式，

支持传统的S1-U数据传输模式。

同时也包括了一些特殊的核心网功能，比如

是否支持无需联合附着的SMS消息传输，

是否支持没有PDN连接的附着，

是否支持控制面CIoT数据优化传输模式的包头压缩。

对于支持NB-IoT的终端，网络侧应该提供控制面CIoT数据优化传输模式的功能，对于S1-U传统用户面数据传输模式并不属于CIoT的数据优化传输模式范畴，但是支持用户面CIoT数据优化传输模式功能的UE也需要能够支持S1-U模式。

UE会通过ATTACH/TAU请求中附带消息体Preferred and Supported Network Behaviour与网络能力进行协商。值得一提的是，这种核心网对于数据传输的优化机制并不仅仅限于低复杂度，低吞吐率的物联网应用。

用户面CIoT核心网优化功能可以无需像传统LTE大网数据业务请求建立一样，通过NAS层消息Service Request触发一些列的接入网流程作为数据业务传输的承载。但是这里有个前提，就是UE与网络之间的RRC连接处于挂起状态，这也意味着UE与网络侧的接入网承载和接入网安全上下文已经协商分配好了。通过挂起流程，在UE转为ECM-IDLE过程中，UE与eNodeB分别存储了接入层相关信息以及承载上下文，同时MME存储了与S1AP和核心网承载相关的上下文，可以说“挂起”流程是一种“睡眠”机制，并不把UE连接建立相关信息删除。

         控制面优化数据传输模式下的用户面协议栈

从核心网控制面优化数据传输模式下的用户面协议栈结构中可以看出与典型LTE系统网络中用户面传输数据在协议架构中的不同。UE与MME之间通过NAS层信令之间传输数据，而LTE系统中S1接口的GTP-u传输隧道协议后移到S11接口中作为用户面数据传输协议。

在控制面数据传输模式下，UE上行数据包和相应的EPS Bearer ID（EBI）被封装在NAS DATA PDU中，通过S1-AP初始UE消息传递，MME在收到了初始消息后可以与SGW/PGW协商传递上行数据，同时并行的触发核心网移动性以及会话管理流程，比如鉴权和安全涉及流程。相对比而言，如果此时有来自于SGW/PGW的下行数据，则需要在MME缓存，等待EMM和ESM流程完毕之后进行传递。对于接入侧通过NB-IoT技术建立连接，并且触发原因是MO Exception Data，MME需要将此触发原因告知SGW。这里其实表达了一层逻辑，上行NAS PDU数据和上行NAS信令流程可以在MME进行分离，数据通过S11接口传出去，NAS鉴权安全流程可以并发进行，而下行的NAS PDU数据则需要等待NAS鉴权安全流程结束之后才能继续下发eNodeB。

在UE与MME采取控制面优化数据传输模式下，即UE处于连接态下，如果需要通过建立用户面传输数据，可以采取传统S1-U模式进行数据传输或者采取用户面优化数据传输模式，如果MME决定采取S1-U模式进行数据传输，UE就不需要重新发起Service Request，并通过后续的初始上下文请求告知eNodeB相关承载信息，包括安全上下文，信令连接ID，EPS承载QoS参数，S1连接标识等。如果采取用户面优化数据传输模式，UE需要发起控制面Service Request申请S1-U承载。不管控制面优化数据传输模式，用户面优化数据传输模式，还是S1-U数据传输模式，相应的PDN连接需要建立，而与之相应的EPS bearer也需要有MME进行分配建立。

 处于CP数据传输模式下的连接态UE转为UP模式或者S1-U模式进行数据传输

NAS信令流程

像Service Request这样的NAS层服务请求信令在目前的LTE网络问题日常分析中很常见，它主要在于处于空闲态终端为了主/被叫UE申请接入侧和核心网侧网络资源，由它触发了一系列的接入网信令流程建立，这样的数据传输模式是S1-U数据传输模式。什么时候使用SR，什么时候使用ESR（Extended Service Request，这里是针对非CSFB的数据业务），这个取决一个UE设备侧NAS控制消息中所带的标识 NAS signalling low priority，如果该标识置为1，且MME通过最近一次的Attach Accept/TAU Accept消息告知UE网络侧支持ESR，那么流程由ESR发起，否则由SR发起。该标识其实告知MME在核心网信令拥塞时优先对哪些信令进行处理响应。

对于采取控制面或者用户面的CIoT数据传输模式，则是通过CONTROL PLANE SERVICE REQUEST进行，区别在于对于CP模式，CPSR中包括了UE中需要通过NAS信令封装传送的数据，以ESM DATA TRANSPORT消息的形式封装在ESM message container IE中传送。而对于之前提及到的在CP模式连接态下转为UP模式数据传输的过程或者UE在IDLE态有数据需要传送，可以通过CPSR发起建立用户面数据传输优化模式，与CP模式区别的是，NAS消息不携带任何与数据相关的消息体，既不包含ESM message container IE也不包含 NAS message container IE，同时将active flag置为1。如果MME接受该流程，在完成一些EMM（核心网移动性管理）公共流程后（比如鉴权，安全模式等等），将EPS bear上下文相关信息关联，向UE发送SERVICE ACCEPT消息，表示该流程成功完成。可以概括的理解SERVICE ACCEPT是对通过NAS层控制面传输数据的确认，如果需要为UE的上下行数据再建立用户面承载，则不需要通过任何NAS信令再予以确认。在MME发送SERVICE ACCEPT之前如果有下行数据需要通过控制面进行发送，则先保证下行数据传递出去。

从这里NAS信令流程可以归纳几点核心网对于物联网技术的优化设计思路

1、数据优先，如果通过控制面承载，先于确认信息将待发数据发送出去；

2、新增SERVICE ACCEPT是为了确认CPSR请求的，对于通过用户面承载发送数据，则无需SERVICE ACCEPT再确认，应为两个为不同的面（控制面，用户面），可以没有严格的时间顺序；

3、相比LTE大网的设计思路，一切都由网络控制调度，为了保证传数据传输的时延，物联网的终端在一定程度上参与发起数据传输模式选择，这对UE设计更多了一些灵活性。而相比LTE网络单一的交互流程则更加丰富，为了物联网低时延，大容量的设计目标更加契合，但是站在解读协议或者分析网络实际问题的角度来看，可能会觉得更加复杂多变。

为了应对大量物联网连接对于核心网络的负荷带来的冲击，核心网对设备的上下行数据包还进行了流控机制。这里包含两种两种流控，一种是服务PLMN网络流控，另一种是APN流控，这二者的区别在于前一种流控机制主要为了由于NAS数据PDU引起的对于MME以及接入层相关信令冲击，而后一种机制在于运营商策略为了规定用户一天之内最多可以发送多少消息或者消耗多少数据流量，一般认为后者所规定的消息限额要小于前者，而且二者都可以在逻辑网元PGW或者SCEF上具体实现，不过APN流控机制一般会先于服务PLMN流控机制应用触发在用户数据上。

（3） NB-IoT下行物理层技术

蜂窝式物联网技术大体分为两种，一种是NB-IoT技术，一种是非NB-IoT技术（例如eMTC等），这两种技术在物理层架构，协议标准上有所区别。

NB-IoT技术提供了一种低功耗的网络接入方式。目前NB-IoT协议只支持FDD（频分双工）工作模式，载波带宽180kHz，相当于LTE网络的一个PRB的带宽，子载波间隔可以是3.75kHz或者15kHz。NB-IoT与Rel-8定义的LTE网络技术，UE是相对独立的，像跨系统移动性，切换，测量报告，GBR，载波聚合，双连接，CSFB回落，物物通信等技术功能在NB-IoT是不支持的。

NB-IoT与LTE大网之间的共存模式有三种，分别是In-band(带内),Guard-band（保护带）,Standalone（独立）。这也意味着NB-IoT如何组网，采取带内组网方式部署较容易，同厂家升级较快，但是对于LTE网内的资源调度会有一定影响。保护带组网方式相比带内频率效率更高，但是需要考虑和大网的干扰共存。独立组网方式与LTE大网可以完全分开，独立运维，但是需要额外的FDD频谱资源。

UE通过小区同步，解读MIB-NB系统消息可以得知组网的模式。

NRS（Narrowband Reference Signal）如同LTE的CRS，窄带参考信号也是NB-IoT里面重要的物理层信号，作为信道估计与网络覆盖评估的重要参考依据。在UE没有解读到MIB-NB里面的operationModeInfo字段时，UE默认NRS窄带参考信号分别在子帧0,4和9（不包含NSSS）上进行传输。当UE解码MIB-NB中的operationModeInfo字段指示为guardband或者standalone模式后，在UE进一步解码SIB1-NB前，UE默认NRS在子帧0,1,3,4和9（不包含NSSS）上进行传输。如果解码SIB1-NB后，UE默认NRS在每个不含NPSS或者NSSS的NB-IoT下行子帧进行传输。当UE解码MIB-NB中的operationModeInfo字段指示为inband-SamePCI 或者inband-DifferentPCI模式后，在UE解码SIB1-NB之前，UE默认NRS在子帧0,4,9（不包含NSSS）上进行传输。当UE解码SIB1-NB之后，UE默认在每个不含NPSS或者NSSS的NB-IoT的下行子帧进行传输。

单天线端口NRS位置vs双天线端口NRS位置（注：NB-IoT最多只支持下行双天线端口传输）

主同步信号NPSS（Narrowband primary synchronization signal）

NB-IoT的主同步信号仅作为小区下行同步使用。在NB-IoT中主同步信号传输的子帧是固定的，同时对应的天线端口号也是固定的，这也意味着在其他子帧传输的主同步信号的端口号并不一致。

蓝色部分为CRS的位置，黄色部分为NPSS位置

值得注意的是，传输NPSS的5号子帧上没有NRS窄带参考信号，另外如果在带内组网模式下与CRS小区参考信号重叠，重叠部分不计作NPSS，但是仍然作为NPSS符号的一个占位匹配项（详见36.211. R13 10.2.7.1.2）

辅同步信号NSSS（Narrowband secondary synchronization signal）

与NPSS位置部署原则大体一致，NSSS部署在偶数无线帧的9号子帧上，从第4个OFDM符号开始，占满12个子载波。该9号子帧上没有NRS窄带参考信号，另外如果在带内组网模式下与CRS小区参考信号重叠，重叠部分不计作NSSS，但是仍然作为NSSS符号的一个占位匹配项。

与LTE大网中PCI需要通过PSS和SSS联合确定不同，窄带物联网的物理层小区ID仅仅需要通过NSSS确定（依然是504个唯一标识），这意味着NSSS的编码序列有504组。

蓝色部分为CRS的位置，黄色部分为NSSS位置

通过UE角度看，NB-IoT下行是半双工传输模式，子载波带宽间隔是固定的15kHz,每一个NB-IoT载波只有一个资源块（resource block）。下行窄带参考信号被布置在每个时隙的最后两个OFDM符号中，每个下行窄带参考信号都对应一个天线端口，NB-IoT天线端口是1个或者2个。物理层同样被分配了504个小区ID，UE需要确认NB-IoT的小区ID与LTE大网PCI是否一致，如果二者一致，那么对于同频的小区，UE可以通过使用相同天线端口数的LTE大网小区的CRS（小区级参考信号）来进行解调或者测量。UE除了根据NSSS(Narrowband Secondary Synchronization Signal)确定小区物理ID之外，还需要像LTE大网小区驻留流程一样，根据这两个同步信号进行下行同步，NPSS的位置位于每个无线帧的第6子帧的前11个子载波，NSSS的位置位于每个无线帧的第10子帧上的全部12个子载波。

NB-IoT的下行物理信道与LTE大网的物理信道区别不大

NPBCH（Narrowband physical broadcast channel）以64个无线帧为循环，在mod64=0的无线帧上的0号子帧进行传输，同样的内容在接下来连续的7个无线帧中的0号子帧进行重复传输，NPBCH不可占用0号子帧的前三个OFDM符号，避免与LTE大网的CRS以及物理控制信道的碰撞。根据3GPP 36.211 R13定义，一个小区的NPBCH需要传输1600比特，采取QPSK调制，映射成800个调制符号，而每8个无线帧重复传输，64个无线帧将这800个调制符号传完，意味着每8个无线帧重复传输100个调制符号，那么在这8个无线帧的每个0号子帧中需要传输这100个调制符号。这里进行一个简单的计算，一个NB-IoT子帧包含12*7*2=168个RE，扣掉前三个OFDM符号，再扣掉NRS占用的RE，再扣掉CRS占用的RE（假设为双端口发射），那么一共168-12*3-4*4-4*4=100个RE，恰好对应100个QPSK调制符号，因此每个无线帧上的0号子帧恰好装满了NPBCH的符号。

蓝色部分为CRS的位置，斜线部分为NRS的位置，黄色部分为NPBCH位置

NPDCCH(Narrowband physical downlink control channel)，相比LTE下行较多的物理控制信道，NB-IoT只有NPDCCH信道传递控制信息。窄带物理控制信道通过连续的一个或者聚合两个NCCE（Narrowband control channel element）的方式进行传输。一个NCCE占据6个连续的子载波，其中NCCE0占据0~5子载波，NCCE1占据6~11子载波。每个NPDCCH是以R个连续的NB-IoT下行子载波进行重复传输的。NPDCCH有三种。第一种是Type1-NPDCCH公共搜索空间，UE通过检测该搜索空间获取寻呼消息。第二种是Type2-NPDCCH公共搜索空间，UE通过检测该搜索空间获取随机接入响应消息（RAR）。第三种是UE专用NPDCCH搜索空间，UE通过检测专属空间获取专属控制信息。

我们先计算一下NPDCCH的起始子帧位置，如果是Type1-NPDCCH公共搜寻空间模式，以k0为起始位置，这也是寻呼的起始位置。

---

这里有必要多说一下寻呼，寻呼消息是在寻呼帧（Paging Frame,PF）的寻呼子帧（Paging Occasion,PO）上发出的，因此UE需要周期性的监听这些位置。如果defaultPagingCycle=rf256,nB=twoT,SFN mod T= (T divN)*(UE_ID mod N),i_s = floor(UE_ID/N)mod Ns,UE_ID=IMSI mod 4096(LTE UE_ID=IMSI mod 1024),

例如IMSI为460003313889448经过计算UE_ID为168，那么PF为mod256=168的无线帧，PO为0号子帧，那么UE就需要侦听无线帧为168，子帧0上是否有P-RNTI，并且以256无线帧为周期循环侦听P-RNTI。

---

UE还需侦听连续的R-1个子载波获得可靠的重复发送NPDCCH，R是根据Rmax和DCI子帧连续数共同决定。UE如果没有把连续的Rmax通过获取小区系统消息块SystemInformationBlockType2-NB中的控制信息radioResourceConfigCommon中的参数npdcch-NumRepetitionPaging获取，该参数取值范围

{ r1, r2, r4, r8, r16, r32, r64, r128,r256, r512, r1024, r2048}

假设Rmax取值64，DCI子帧重复数取值为3，查表（36.213 R13 表16.6-2）可知对应R取值为8，那么根据以上寻呼起始位置的计算，意味着UE需要周期侦听无线帧168+256n(n=0,1,2,3....)，子帧0，同时连续重复8个子帧获取NPDCCH中的寻呼消息。值得一提的是，这里DCI子帧连续数并不是高层消息告知UE的，在这里UE采取盲检机制逐步尝试检测所有的DCI模式。如果没有检测到连续的控制信息，UE会将已检测到的NPDCCH丢弃。从这点来看，NB-IoT对于控制信道的解码可靠性还是极为看重的，要么不收，要么收全。

当然，在网络侧实际配置NPDCCH时需要与NPBCH的时隙错开，因此UE会尝试在非子帧0的其他子帧开始尝试检测NPDCCH。NB-IoT也可以采取多载波的方式进行数据传输，网络侧需要将NPSS,NSSS,NPBCH与UE专属NPDCCH分别配置在不同的载波。NPDCCH在子帧中的起始位置lNPDCCHStart取决于SIB1-NB里的eutraControlRegionSize参数设置，对于Type2-NPDCCH和UE专属NPDCCH的起始位置确定方式与Type1有所不同，具体细节可参考36.213 R13 16.6。

NPDSCH(Narrowband physical downlink shared channel)

NB-IoT对于NPDSCH的传输稳定性极为关注，通过重复传递同一NPDSCH的方式确保传输的质量，这也是NB-IoT宣称的强化覆盖技术手段之一。NPDSCH可以承载BCCH，例如承载系统消息，也可以承载一般的用户数据传输。对应这两种承载，传输信号加扰的方式有所不同。同时，子帧重复传输的模式也有所不同。

承载NPDSCH的子帧以及占位有一定规则，NPDSCH的子帧不可以与NPBCH，NPSS或者NSSS的子帧复用。另外，承载子帧中NRS和CRS的位置既不作为NPDSCH，也不作为符号匹配。

在收到传输NPDCCH以及DCI的最后一个子帧n后，UE尝试在n+5子帧为其实之后的N个连续下行子帧（不含承载系统消息的子帧）进行对应NPDSCH的解码。这N个连续下行子帧的取决于两个因素，也就是N=Nrep*NSF,一个是Nrep,意味着每一个NPDSCH子帧总共重复传输的次数，NSF意味着待传数据需要占用的子帧数量，这两个因素都是根据对应的DCI解码得出的，在协议中可以查表得出对应关系（36.213 R13 16.4.1.3）。根据不同的DCI（N1，N2）格式，需要注意的是在UE预期的n+5子帧以及实际传输NPDSCH的起始子帧之间存在调度延迟，如果是N2格式，该调度延迟为0。如果是N1格式，可以根据DCI的延迟指示Idelay和NPDCCH的最大重传Rmax依据协议规定（36.213 R13 表16.4.1-1）共同确定调度延迟。协议规定，UE在NPUSCH上传数据之后的三个下行子帧之内不认为网络会传输NPDSCH数据，另外一种在物理层体现延迟传输NPDSCH的技术是设置GAP，GAP的长度由系统消息中的公共资源配置参数决定的，这也为多用户的数据错峰传输预留了空间。

NPDSCH承载系统消息和承载非系统消息数据的物理层流程以及帧结构有所不同。承载非系统消息数据的NPDSCH每个子帧先重复发送，直到N=Nrep*NSF个子帧都传输完。而承载系统消息的NPDSCH先以NSF个子帧传输完，在循环重复，直到N=Nrep*NSF个子帧都传输完。这两种传输方式占用资源的方式相似，之所以在重复传输机制上有所差异，可能主要还是考虑UE对于系统消息响应的及时程度。对于承载非系统消息数据的NPDSCH是通过对应NPDCCH加扰的P-RNTI,临时C-RNTI或者C-RNTI进行解码的，同时NPDSCH持续占用的子帧情况也是通过解码DCI予以明确的。而与之不同的是，承载系统消息的NPDSCH起始无线帧以及重复传输占用子帧情况是通过解码小区ID和MIB-NB消息中的 schedulingInfoSIB1参数获得的，当然这样承载系统消息的NPDSCH是通过SI-RNTI进行符号加扰的。SIB1-NB是在子帧4进行传输的。对于在子帧内具体的起始位置则取决于组网方式，如果NPDSCH承载SIB1-NB并且是带内组网模式，则从第4个OFDM符号开始（避开前三个OFDM符号），其他组网模式从第一个OFDM符号（0号OFDM符号）。如果NPDSCH承载其他信息，说明此时已经正确解码了SIB1-NB，那么通过解读SIB1-NB中的eutraControlRegionSize参数（这是可选参数）来获取起始位置，如果该参数没有出现，那么从0号OFDM符号开始传输。

 除了承载系统消息以及非系统消息（一般用户数据，寻呼信令等），NPDSCH还承载对上行信道NPUSCH的ACK/NACK消息，UE在NPUSCH传完子帧之后的第4个子帧进行侦听。

通过对于整个NB-IoT下行物理层结构以及流程的了解，NB-IoT利用了延迟以及重传帧结构设计保障了数据传输的稳定性以及可靠性，提升了“软性”的覆盖，  同时也考量了与LTE大网的兼容共存，这可能是由于NB-IoT业务定位导向（设计NB-IoT的初衷据说就是为了查水表）进行调整设计的，这也再次指明了技术标准的一个发展方向，即不以技术本身的指标为考量，反而更多的以契合应用需求为准绳。

（4）NB-IoT上行物理层技术

相比LTE的上行物理信道，NB-IoT的上行物理信道可谓简化了很多，因此一些流程机制也改变很多。由于不需要在上行信道中传输CSI或者SR，因此在上行信道结构设计中也不需要专门保留上行控制共享信道。NB-IoT上行信道包含两种物理信道，一个是窄带物理上行共享信道（NPUSCH），另外一个是窄带物理随机接入信道（NPRACH），控制信息可以通过NPUSCH复用传输，这意味着NPUSCH不仅承载上行数据业务，同时也肩负了类似LTE中PUCCH承载一些上行反馈信息的功能。另外，由于没有了上行资源调度的概念，同时为了简化帧结构，作为全频段信道估计用的Sounding Reference Signal(SRS)也被省略掉了，上行物理信号只保留了窄带解调参考信号，这样不仅简化了物理层流程，同时也将有限的带宽资源尽可能预留给了数据传输。

NPUSCH（Narrowband Physical uplink shared channel）

上行传输有两种模式，一种是single-tone,另一种是multi-tone。对于single-tone传输模式，可以有两种子载波间隔3.75kHz和15kHz，资源块（Resource Block）在这里并没有定义，这意味着并不以LTE中的资源块概念作为基本调度单位。如果子载波间隔是15kHz,那么上行包含连续12个子载波，如果子载波间隔是3.75kHz，那么上行包含连续48个子载波。我们知道，对于通过OFDM调制的数据信道，如果在同样的带宽下，子载波间隔越小，相干带宽越大，那么数据传输抗多径干扰的效果越好，数据传输的效率更高，当然，考虑到通过IFFT的计算效率，子载波也不能设置的无限小。同时，也要考虑与周围LTE大网的频带兼容性，选取更小的子载波也需要考虑与15kHz的兼容性。当上行采取single tone 3.75kHz模式传输数据时，物理层帧结构最小单位为基本时长2ms时隙，该时隙与FDD LTE子帧保持对齐。每个时隙包含7个OFDM符号，每个符号包含8448个Ts(时域采样)，其中这8448个Ts含有256Ts个循环校验前缀（这意味着IFFT的计算点数是8448-256=8192个，恰好是2048（15kHz）的4倍），剩下的时域长度（2304Ts）作为保护带宽。single-tone和multi-tone的15kHz模式与FDD LTE的帧结构是保持一致的，最小单位是时长为0.5ms的时隙。而区别在于NB-IoT没有调度资源块，single-tone以12个连续子载波进行传输，multi-tone可以分别按照3,6,12个连续子载波分组进行数据传输。

相比LTE中以PRB对进行基本资源调度单位，NB-IoT的上行共享物理信道NPUSCH的资源单位是以灵活的时频资源组合进行调度的，调度的基本单位称作资源单位（Resource Unit）。NPUSCH有两种传输格式，两种传输格式对应的资源单位不同，传输的内容也不一样。NPUSCH格式1用来承载上行共享传输信道UL-SCH，传输用户数据或者信令，UL-SCH传输块可以通过一个或者几个物理资源单位进行调度发送。所占资源单位包含single-tone和multi-tone两种格式。其中

single-tone 3.75kHz 32ms, 15kHz 8ms;

multi-tone 15kHz 3子载波 4ms,6子载波 2ms,12子载波 1ms。

NPUSCH格式2用来承载上行控制信息（物理层），例如ACK/NAK应答。根据3.75kHz 8ms或者15kHz 2ms分别进行调度发送的。

NPUSCH信道基本调度资源单位（Resource Unit）

NB-IoT没有特定的上行控制信道，控制信息也复用在上行共享信道（NPUSCH）中发送。所谓的控制信息指的是与NPDSCH对应的ACK/NAK的消息，并不像LTE大网那样还需要传输表征信道条件的CSI以及申请调度资源的SR（Scheduling Request）。

NB-IoT上行物理信道进行了简化

NPUSCH目前只支持天线单端口，NPUSCH可以包含一个或者多个RU。这个分配的RU资源单位数量由NPDDCH承载的针对NPUSCH的DCI格式N0（format N0）来指明。这个DCI格式N0包含分配给RU的连续子载波数量nsc,分配的RU数量NRU，重复发送的次数NRep。UE通过解读DCI格式N0获取相关NPUSCH上行传输的时间起点以及所占用的视频资源，上行共享信道子载波间隔与解码随机接入grant指示Msg3发送采用的子载波间隔保持一致。另外NPUSCH上行具体的对应取值在协议中有明确的定义（见36.213 R13 16.5.1.1&16.5.1.2）。在子载波上映射的NPUSCH符号应该与上行参考信号错开。在映射了Nslots个时隙后，为了提升上行软覆盖，保证数据传输质量，这Nslots个时隙需要被重复次。具体的计算公式如下（36.211 R13 10.1.3.6）

                   

我们进行一点简单的计算。

对于NPUSCH格式1中子载波间隔3.75kHz,RU频域子载波数为1的情况，查表计算得出每个传输的时隙不需要重复。这样NPUSCH的待发符号会映射满一个RU（1个子载波，8个时隙，持续32ms），之后再重复次；

对于NPUSCH格式2中子载波间隔15kHz,RU频域子载波数为1的情况，查表计算出每2个时隙需要被重复发送，而RU内部重复次数为1，其实意味着和前一种情况一致了。NPUSCH的待发信号映射满一个RU（1个子载波，4个时隙，持续2ms），之后再重复次；

对于NPUSCH格式1中子载波间隔15kHz，RU频域子载波数为6的情况，查表计算出每2个时隙需要被重复发送，假设通过解码DCI获得的值为4，那么经计算为2，那么实际情况是在该RU持续的4个时隙内，NPUSCH符号先映射满2个时隙，然后RU内部一重复，这种映射方式直到NPUSCH符号被完全发送完，之后NPUSCH重复3次，也就是说每映射2个时隙的NPUSCH符号，实际总共需要16个时隙重传来保障上行数据接受的可靠性。

通过这些例子的简单计算，我们可以摸清NPUSCH映射传输的一些规律，NPUSCH采取“内部切片重传”与“外部整体重传”的机制保证上行信道数据的可靠性。对于格式2承载的一些控制信息，由于数据量较小，就没有采取内部分割切片的方式，而是数据NPUSCH承载的控制信息传完以后再重复传输保证质量。NPUSCH在传输过程中需要与NPRACH错开，NPRACH优先程度较高，如果与NPRACH时隙重叠，NPUSCH需要延迟一定的时隙传输（36.211 R13 10.1.3.6）。在传输完NPUSCH或者NPUSCH与NPRACH交叠需要延迟256ms传输，需要在传输完NPUSCH或者NPRACH之后加一个40ms的保护间隔，而被延迟的NPUSCH与40ms保护间隔交叠的数据部分则认为是保护带的一部分了，换言之，这部分上传数据被废弃掉了。在NPUSCH的上行信道配置中还同时考虑了与LTE上行参考信号SRS的兼容问题，这里通过SIB2-NB里面的NPUSCH-ConfigCommon-NB信息块中的npusch-AllSymbols和srs-SubframeConfig参数共同控制，如果npusch-AllSymbols设置为false,那么SRS对应的位置记作NPUSCH的符号映射，但是并不传输，如果npusch-AllSymbols设置为true,那么所有的NPUSCH符号都被传输。对于需要兼容SRS进行匹配的NPUSCH，意味着一定程度上的信息损失，这也是与LTE采取带内模式组网时需要考虑的。

NB-IoT上行共享信道具有功控机制，通过“半动态”调整上行发射功率使得信息能够成功在基站侧被解码。之所以说上行功控的机制属于“半动态”调整（这里与LTE功控机制比较类似），是由于在功控过程中，目标期望功率在小区级是不变的，UE通过接入小区或者切换至新小区通过重配消息获取，功控中进行调整的部分只是路损补偿。UE需要检测NPDCCH中的UL grant以确定上行的传输内容（NPUSCH格式1,2或者Msg3），不同内容路损的补偿的调整系数有所不同，同时上行期望功率的计算也有差异，具体计算公式可以参见36.213 R13 16.2.1.1.1。上行功控以时隙作为基本调度单位，值得注意的是在如果NPUSCH的RU重传次数大于2，那么意味着此时NB-IoT进行深度覆盖受限环境，上行信道不进行功控，采取最大功率发射，该值不超过UE的实际最大发射功率能力，对于class3UE最大发射功率能力是23dBm,class5UE最大发射功率能力20dBm。

DMRS(Demodulation reference signal)

不同格式的RU对应产生不同的解调参考信号。主要按照（一个RU包含的子载波数量）和两类来计算。另外NPUSCH两种格式的解调参考信号也不一样，格式1每个NPUSCH传输时隙包含一个解调参考信号，而格式2每个传输时隙则包含3个解调参考信号，这种设计可能源于承载控制信息的NPUSCH的RU中空闲位置较多，而且分配给控制信息的RU时域资源相对较少，因此每个传输时隙通过稍多的解调参考信号予以进行上行控制信息的解调保障。对于包含不同子载波的RU而言（当然我们也可以按照single-tone,multi-tone分类）需要保证每个子载波至少一个DMRS参考信号以确定信道质量，同时DMRS的功率与所在NPUSCH信道的功率保持一致。对于multi-tone中如何生成参考信号，既可以通过解读系统消息SIB2-NB中的NPUSCH-ConfigCommon-NB信息块中的参数（可选）获取，也可以根据小区ID通过既定公式计算获取（36.211 R13 36.211）。解调参考信号可以通过序列组跳变（Group hopping）的方式避免不同小区间上行符号的干扰。序列组跳变并不改变DMRS参考信号在不同子帧的位置，而是通过编码方式的变化改变DMRS参考信号本身。对于的RU，RU内部的每个时隙中的序列组跳变是一样的，而对于的RU，RU内部每个偶数时隙的序列组的计算方式就要重新变化一次。DMRS映射到物理资源的原则是确保RU内每个时隙的每个子载波至少一个参考信号，这个也很好理解，通俗的说就说保证每个时隙上的子载波能够被正确解调，同时又不由于过多的分配DMRS导致资源消耗够多，物理层设计的时候也进行了相应的权衡。当然在物理资源映射分配上格式1与格式2的DMRS还是有些差异。格式1在每个时隙每个子载波上只分配1个DMRS参考信号，格式2在每个时隙每个子载波上分配3个DMRS参考信号。                                                                        

NB-IoT上行SC-FDMA基带信号对于单子载波RU模式需要区分BPSK，QPSK模式,即基于不同的调制方式和不同的时隙位置进行相位偏置，这一点与LTE是不同的，LTE上行的SC-FDMA主要是由于考虑到终端上行的PAPR问题采取在IFFT前加DFT变换，同时分配给用户频域资源中不同子载波功率是一致的，这样PAPR问题得到了有效的缓解。而对于NB-IoT而言，对于single-tone的这种单子载波传输的方式，功率谱密度更高，对带外旁瓣泄露更加敏感，另外相比multi-tone传输方式，单DFT抽头抑制PAPR效果相对较弱，因此通过基于不同调制方式数据的相位偏置可以进行相应的削峰处理，同时又不会像简单clipping技术一样使得频域旁瓣产生泄漏，产生带外干扰。

NPRACH(Narrowband physical random access channel)

窄带随机接入信道顾名思义就是传输随机接入请求的。随机接入过程是UE从空闲态获取专用信道资源转变为连接态的重要方法手段。在NB-IoT中没有了同步状态下的SR流程对于调度资源的申请，NB-IoT主要靠随机接入流程申请调度资源。随机接入使用的3.75kHz子载波间隔，同时采取在单子载波跳频符号组的方式发送不同循环前缀的preamble。随机接入符号组如图所示，它由5个相同的符号与循环前缀拼接而成。随机接入前导序列只在前面加循环前缀，而不是在每个符号前都加（如NB-IoT的NPUSCH上行共享信道），主要原因是由于其并不是多载波调制，因此不用通过CP保持子载波之间的正交性，节省下CP的资源可以承载更多的前导码信息，基站侧通过检测最强径的方式确认随机接入前导码。随机接入前导码包含两种格式，两种格式的循环前缀不一样。

                           

                              随机接入符号组

                 

                               前导码参数配置

一个前导码（preamble）包含了4个符号组，同时被连续传输。通过一些列的时频资源参数配置，随机接入前导码占据预先分配的时频资源进行传输。UE通过解读SIB2-NB消息获取这些预配置参数。

如何通过这些配置参数确定前导码的起始位置？为了避免枯燥的参数解读与描述，我们通过简单的计算来说明。

起始

假设nprach-Periodicity=1280ms,那么发起随机接入的无线帧号应该是0,128,256....(128的整数倍)，当然随着这个取值越大，随机接入延迟越大，但是这对于物联网NB-IoT来说并不太敏感，基于抄水表的物联网终端更需要保证的是数据传递准确性，对于延迟可以进行一定的容忍。nprach-StartTime决定了具体的起始时刻，假设nprach-StartTime=8，那么前导码可以在上述无线帧的第4号时隙上发送（8ms/2ms=4）。这两组参数搭配取值也有一定的潜规则，如果nprach-Periodicity取值过小，nprach-StartTime取值过大，建议可以进行适当的调整。

重复

一个前导码占用4个符号组，假设numRepetitionsPerPreambleAttempt=128（最大值），意味前导码需要被重复传递128次，这样传输前导码实际占用时间为4*128*（TCP+TSEQ）TS(时间单位)，而协议规定，每传输4*64（TCP+TSEQ）TS，需要加入40*30720TS间隔（36.211 R13 10.1.6.1），假设采取前导码格式0进行传输，那么传输前导码实际占用时间为796.8ms，相比LTE的随机接入，这是一个相当大的时间长度，物联网终端随机接入需要保证用户的上行同步请求被正确解码，而对于接入时延来讲依然不那么敏感。

频域位置

分配给preamble的频域资源不能超过频域最大子载波数，即nprach-SubcarrierOffset+nprach-NumSubcarriers<=48,超过48意味着参数配置无效。这两个参数，决定了每个符号（注：我们这里并没有用OFDM符号这个词，由于随机接入前导码并没有采取OFDM调制技术，只是占用了OFDM符号的位置而已）中NPRACH的起始位置，NPRACH采取在不同的符号的不同单子载波跳频，但是有一个限制条件，就是在起始位置以上的12个子载波内进行跳频，具体的跳频位置计算比较复杂，可参见（36.311 R13 10.1.6.1）

nprach-NumCBRA-StartSubcarriers和nprach-SubcarrierMSG3-RangeStart这两个参数决定了随机过程竞争阶段的起始子帧位置，如果nprach-SubcarrierMSG3-RangeStart取值为1/3或者2/3，那么指示UE网络侧支持multi-tone方式的msg3传输。

基带导频信号生成

基带导频信号的生成和每个符号组跳频的偏置相关，是个复信号，具体计算公式参见36.311 R13 10.1.6.2。

随机接入过程

UE在发起非同步随机接入之前，需要通过高层获取NPRACH的信道参数配置。在纯物理层的角度看来，随机接入过程包含发送随机接入前导码和接收随机接入响应两个流程。其余的流程，比如竞争解决及响应（msg3，ms4），在共享信道传输，不单单只涉及物理层流程。

过程1:发送随机接入前导码（发送Msg1）

随机接入信道为每个连续的前导码符号占用一个子载波。层1的随机过程是由高层的接入请求触发的，随机接入的发射目标功率（随机信道受高层控制有功率抬升机制），对应的RA-RNTI和NPRACH资源分配也是由高层决定的。

过程2：接收随机接入响应获取uplink grant（解码Msg2,RAR）

UE通过RA-RNTI解码下行NPDCCH获取被对应RA-RNTI加扰的DCI，通过DCI获取对应DL-SCH资源传输块，将资源块传递高层，高层解析资源块，并向物理层指明Nr-bit的上行授权（uplink grant）。Nr=15，这15bit包含了如下的相关信息（从左至右）

通过解读NPDCCH中DCI获得随机接入响应资源预留，规定了Msg3发送占用的资源以及调制方式

为了更直观的说明物理层随机接入过程，我们用流程图的方式进行了整理

（5）LTE与NB-IoT的开机同步机制

任何通信系统的终端在开机的时候都需要与网络做同步，同步是为了更准确的获取网络消息，开机时的同步指的一般是下行同步，下行同步涉及两个流程，频率同步和时间同步，一般先有频率同步，才有时间同步。

LTE的终端在频率同步时候采取100kHz精度的方式步进搜索，先确认中间部署PSS的6个PRB的位置，再计算出中心频率。举例计算一下，band41对应的中心频率范围是2496~2689.9MHz，跨度193.9MHz。每一个在band41内可设置的中心频率都是以100kHz整数倍作为间隔的方式进行设置，因此100kHz作为栅格基本精度扫描，恰恰对应上了每一个可能被设置的中心频点。

如何确认中间部署的6个PRB呢么，协议上并没有进行规范。这里可能取决于芯片厂家的实现。一种可能的解决方案是以100kHz作为步进步长，1.08MHz作为基本窗长，这样每步进一次，就做一次基于已知PSS序列的相关，这样的好处是可以直接进行精细同步，准确确定中心频点的位置，但是劣势也是显而易见的，采取这种方式芯片进行处理对于计算的代价太大，效率太低，从而可能初次开机时间拉长很多，同时涉及到全频段全制式搜索，需要芯片具备不同的相关窗长，无形中增加了芯片的代价。另一种可能的解决方案是，每100kHz的步进时进行一次探测(其实就是尝试捕获一下能量脉冲)，以B41的D1频段举例，D1频段范围2575～2595，中心频点2585MHz，那么终端在首次开机，假设以B41作为其实搜索频段，从起始频点2496MHz开始，搜完6个PRB需要探测脉冲|(2585MHz-2496MHz)/0.1MHz|(上限取整)+1（初始探测）=897次，那么在过程中，如果出现了连续11次捕获脉冲呈现[0 1 1 1 1 0 1 1 1 1 0]这种模式，则可以认为基本捕获了中间6个PRB的位置，同时也确定了中心频点，接下来就可以根据芯片预先存储的PSS序列与接收到的序列做相关，这样不但可以精准确认中心频率同时也获取了实际的PSS码，同时也确定了后续CRS的位置，频率同步阶段可以说完成了。

LTE的开机频率同步都听着好像不那么简单嘛，别着急，NB也不简单，不信继续看。

NB-IoT的传输带宽为180kHz，在与LTE频谱共存的时候存在三种部署模式，分别为独立模式，带内和保护带模式。当UE开机时搜寻NB-IoT载频的时候，并不知道具体部署在哪里，也不知道采取以上三种模式的哪一种部署。

由于零中频接收的问题，NB-IoT采取独立模式部署和带内部署与保护带模式的OFDM符号的频偏是不一样的，独立模式下采取频偏7.5kHz的方式在零中频接收机下进行平衡。而带内模式或者保护带模式则严格与LTE子载波保持正交，同时基于LTE系统的中心子载波进行了一定的错位。这种错位UE事先不得而知，主要取决于网络侧的配置。这样的配置需要考虑两方面的因素，其一不能与LTE系统的PSS/SSS冲突，这意味着不能配置在中间6个PRB，另外一方面需要考虑是否能够被UE开机搜索到。

如同LTE的终端一样，NB终端也采取100kHz栅格扫频步进式的方式尝试捕获NB的锚定载波。当然也可以按照LTE的芯片开机搜索采取的两种解决方案。不过，第二种方案在这里不好用，为什么呢，因为NB-IoT的传输带宽与100kHz太接近，很难采取特定采样图的方式确定频域位置。最直接的方式就是采取180kHz频率同步窗，100kHz步进的方式。针对UE的这种搜索方式，NB如果采取带内部署模式，需要配置在特定的一些PRB上，满足搜索频宽恰好是100kHz的整数倍。以10MHzLTE带宽举例，NB可以被配置在第4,9,14,19,30,35,40,45PRB上。由于LTE/NB的PSS配置在特定子帧上，因此锁定LTE或者NB的PSS的频域位置时采取先固定100kHz后时域滚动采样再以100kHz步进进行频域同步还是按照100kHz与时域同步滚动步进的方式，这取决于芯片的实现（哪种效率高就采取哪种）。

另外值得注意的是，100kHz栅格恰恰能够同步中心频点时，而由于LTE的DC子载波的存在，NB部署在LTE高位PRB（可以认为示意图LTE中心频点的右侧）的中心频点，最小与100kHz步长有2.5kHz的错峰，因此协议规定对于10MHz和20MHz带宽的LTE采取带内部署NB，NB的中心频点与100kHz栅格精度可以偏差2.5kHz，而采取3MHz,5MHz和15MHz带宽的LTE采取带内部署NB，NB的中心频点与100kHz栅格精度可以偏差7.5kHz（1.4MHz的LTE与NB势不两立），这意味着终端在100kHz锁频过程中，每次都尝试轮询5组栅格偏置，分别是{-7.5kHz,-2.5kHz,0kHz,2.5kHz,7,5kHz}。

如果仍然以20MHz的D1频段（2575MHz～2595MHz）来举例，在初始频率同步时，OFDM接收机频移可能大于2.5kHz（包括高频的多普勒效应），可能会造成子载波间严重的ICI，这个就需要接收机侧的均衡器进行均衡调整了。

（6）eMTC/NB/LTE的技术特点对比说明

挂起-恢复流程

挂起恢复流程是eMTC/NB-IoT等蜂窝物联网技术才引进的，LTE并不具备这样的流程。这种机制的引入主要针对物联网海量连接，不活跃小数据包的特点，适时的挂起流程可以减少网络的资源开销，并且保证了物联终端的耗电。而恢复流程对于NAS的信令流程进行了优化，这样在简化信令流程的同时也可以减少海量物联对于核心网的信令冲击。

网络侧通过RRCConnectionRelease封装Suspend消息通知UE挂起，当RRC连接被挂起后，UE存储UE AS上下文和resumeIdentity，同时变为RRC_IDLE状态。挂起针对已建立的用户面承载，所以在至少一个DRB成功建立之后，挂起流程才能够执行。

如果有上行数据或者寻呼通知到来，UE会通过高层触发RRC连接恢复流程。当网络侧接收UE恢复请求后，UE从RRC_IDLE状态转变为RRC_CONNECTED状态。RRC层依据UE之前存储的AS上下文和接收来自网络侧的RRC配置信息重新对UE进行配置。RRC连接恢复流程重新激活安全机制和重建SRB和DRB。Resume请求携带resumeIdentity，该请求不被加密，但是进行MAC（message authentication code）保护。

接入网的挂起触发了核心网对于NAS层信令的挂起，挂起流程伴随着UP优化模式（user plane CIoT optimization），什么叫“伴随”呢？因为UP模式是一种不需要经过NAS信令触发获得连接，获取相应承载资源（DRB、EPS bear），因此UP优化模式流程往往都是UE被挂起后再resume执行的，可以说resume流程就是UP优化模式，resume之后不需要发送Service Request。而NAS层信令的恢复流程是由UE触发的。在UP模式下，RRC通知NAS层连接被挂起，此时UE携带悬挂指示进入EMM-IDLE模式，但并不释放NAS信令连接。根据进一步的底层指示，UE更新EMM-IDLE模式下的悬挂指示状态。当UE的NAS（UP/CP）触发RRC层恢复时，需提供RRC建立的原因值。

常用的几个原因值说明如下：

Emergency:紧急呼叫涉及的信令与业务请求，一般都是主叫发起。

mo-Signalling:一般是由于类似Attach Request/Tracking Area Update这样的NAS层信令触发,在VoLTE通话中的TAU也算作这一类型的触发原因；

mo-Data:一般由主叫Service Request/Extended Service Request触发该原因值，可以是主叫数据业务，也可以是主叫VoLTE话音/视频业务或者主叫SMSoIP业务，或者是主叫CSFB业务（CDMA2000 1xRTT例外），其中ESR里面所带服务类型标签“mobile originating CS fallback”

mt-Access:一般是被叫UE收到寻呼后触发Service Request/Extended Service Request/Control Plane Service Request，其中SR携带“PS”指示,ESR携带“packet services via S1”或者"mobile terminating CS fallback”，CPSR携带 "mobile terminating request"，这些主要针对类似数据业务寻呼响应，CSFB寻呼响应，NB/eMTC控制面传输数据业务寻呼响应

delayTolerantAcess:针对主叫数据业务，UE配置为NAS信令低优先级，那么RRC建立的原因设置为Delay tolerant。不过对于VoLTE话音( MMTEL video)，多媒体音频( MMTEL video)，SMSoIP之类的IMS业务依然设置为mo-Data类型。

mo-ExceptionData:针对NB的主叫信令发起，如果小区访问禁止，而UE允许使用接入异常事件标签，那么对于Attach/TAU/Service request可以继续发送，而RRC接入标签则可设置为mo-ExceptionData原因值。

mo-VoiceCall：如果UE支持mo-VoiceCall的设置，而且该小区通过SIB2中的 voiceServiceCauseIndication指示支持mo-VoiceCall,并且UE发起的业务是VoLTE，那么可以将RRC建立原因值设置为mo-VoiceCall。

highPriorityAccess：基于mo-Signalling请求，对于某一系列特定终端（AC11-15）可以设置该原因值，携带该值得接入对于NAS层EMM管理优先级较高，如同Emergency一样，不会由于流控被拒绝。

这些RRC侧请求携带的原因标签与NAS层的请求的优先级息息相关，NAS层可以直接通过reject消息进行流控，也可以通过S1发送OVERLOAD START通知eNodeB进行相应的流控机制触发。NAS层可以通过特定业务的NAS请求比率触发流控。而NAS和eNodeB两级流控机制可以根据实际业务请求情况进行调整，意味着可以趋缓或者激进。

当UE重选到新的小区发现TAC改变，准备发起TAU流程时，如果该小区不支持UP数据传输优化模式，那么UE就清理掉suspend indication，以“非挂起”的身份重新发起流程。

另外，当UE获悉RRC连接恢复以后，UE就进入了EMM-CONNECTED,而除了SERVICE REQUEST/CONTROL PLANE SERVICE REQUEST（不带数据包）/EXTENDED SERVICE REQUEST等NAS信令，其他的NAS初始消息都可以被发送。

我们将挂起-恢复的流程图梳理归纳下

RRC连接挂起流程

RRC连接恢复流程某种特定的原因所触发，例如可以当UE不活跃定时器超时后进行触发。

NB-IoT的非锚定载波的分配

借鉴了GSM主辅载波的概念，NB-IoT分为锚定载波（anchor carrier）和非锚定载波(non-anchor carrier)，锚定载波承载NPSS/NSSS/NPBCH/SIB-NB等一系列的的同步，系统消息。这意味着UE在IDLE态只能驻留在主载波上进行下行同步和系统消息侦听。而非主载波则通过专属信令流程指明。UE在锚定载波进行初始随机接入，而通过专属信令指明的非锚定载波进行数据传输，那么哪些流程会指派非锚定载波呢？先上一张图。

如图所示，RRC在连接建立，重配，恢复，重建立等信令中都可以通知UE可以从非锚定载波接入进行数据传输。UE对于以上信令的反馈都在非锚定载波进行发送。这表示非锚定载波的接入可能分别发生在初始连接建立、小区间切换流程、RRC连接恢复流程以及RRC连接重建立流程中。

UE Context Release谁发起

eMTC/NB/LTE中，用户上下文释放既可以由eNodeB发起也可以由MME发起。这一释放流程不仅释放S1-AP信令连接（S1-MME），同时也释放S1-U承载。而对于eMTC/NB中的CP优化模式，这一流程之间释放了S11-U承载。由于某些特殊的原因，例如S1信令传输丢失或者eNodeB/MME某个网元的问题，用户上下文可以在某个网元进行本地释放，这样就不需要使用或者依靠如下图网元之间的信令流程了。

eNodeB发起释放的原因主要有：O&M网管干预，没有指定的错误，用户不活跃（定时器超时），重复的RRC信令完整性保护校验失败，UE发起的信令释放，触发CSFB，异系统重定向；

MME发起释放的原因主要有：鉴权失败，去附着，非法CSG小区。

E-RAB Release谁发起

E-RAB释放既可以由MME发起，也可以由eNodeB发起。MME发起的释放指令中包含 E-RAB To Be Released List ，这是要被释放的E-RAB。eNodeB接收到指令后，不仅需要把列表中的E-RAB释放掉，同时通过空口（Uu）把对应的DRB以及分配资源释放掉，并将S1的分配资源释放掉，同时对于释放掉的E-RAB情况通过Response指令反馈给MME。

eNodeB也可以发起E-RAB释放流程。同样在eNodeB发起的释放指示中也需要携带E-RAB Released List 从而明确需要被释放的是哪些E-RAB。注意，如果eNodeB想要清除掉所有保留的E-RAB，例如当用户不活跃定时器超时后，那么取而代之的就是发起用户上下午释放请求流程了。另外，如果eNodeB在（通过重配信令）在空口释放相应DRB时，UE无反馈或者负反馈（重配失败），或者eNodeB无法成功释放MME指令要求释放的E-RAB，那么eNodeB也会发起S1 UE Context Release Request流程。

EPS bearer context去激活

MME发起EPS承载上下文去激活请求，一般主要是如下ESM原因导致（TS 24.031）

  #8：运营商决定禁止接入

#26：资源不足

#36：正常去激活

#38：网络失败

#39：重新激活请求

#112：APN限制值与激活EPS承载上下文不兼容

#113：对于一个PDN连接不需要有多个访问接入

除此之外，EPS承载去激活还可以由UE发起的承载资源修改流程或者UE要求的PDN连接释放流程触发，如果是这两种原因，EPS承载去激活请求必须携带分别来自BEARER RESOURCE MODIFICATION REQUEST或者 PDN DISCONNECT REQUEST的流程交易标识PTI（procedure transaction identity）

EPS bearer，E-RAB、用户上下文和PDN连接啥关系

不闲扯，先来一张图

一个PDN连接可以包含多个EPS bear,其中包含至少一个默认承载（default EPS bear）和若干专属承载（dedicated EPS bear）。一个EPS bear是基于QoS建立的逻辑概念，是对一系列数据集的QoS进行归类标识的基本单位。因此，EPS Bearer本身没有上下行Bear之分。不过，一个EPS bear可以分别对应上行TFT（ traffic flow template）和下行TFT。一个TFT又可以包含若干packet filter(s)，而这些packer filter通过自身优先级标签（precedence index）的机制分别将上下行的数据包封装映射进不同的EPS bear。

Radio Bearer是空口侧的承载，S1 Bearer是S1对应的传输承载。E-RAB是Radio Bearer与S1 Bearer的级联。Radio Bearer与E-RAB与EPS Bear是一一对应的。

CP优化模式一般发生在上行初始接入，对于NB-IoT终端，RRC重配和RRC重建立流程都省略了。况且DRB也不建立，导致EPS bearer也没有，因此也就无从提起QoS映射。CP优化模式伴随的主要业务形态都是封装在NAS信令里的上下行小数据包，通过RRC接入信令Piggybacking进行传输，如果非要说谁的优先级比较高，那么相对于DRB承载的EPS bearer，肯定是SRB承载的NAS信令的优先级比较高了。

用户上下文是指的一个用户所有的业务，是EPS承载业务的总和，因此用户上下文释放也意味着所有E-RAB被释放了，但是LTE为了保证永远在线，默认EPS承载是不释放的，否则就属于EMM-Deregistered状态了。

一个用户有可能有多个PDN连接么？答案是肯定的，例如VoLTE语音业务和数据业务的并发。这里PDP上下文激活会通过两个APN寻址，一个是PGW出口到IMS域，一个是PGW出口到Internet(IP network)，这时就建立了两个PDN连接。

eMTC/NB/LTE的功控机制

eMTC/NB/LTE三个系统对于上行信道都是有功控机制的，对于随机接入信道采取一种步长逐步抬升的功控机制。NB简化掉了PUCCH信道和SRS信号，三个系统对于PUSCH信道的功率控制计算公式分别汇总如下：

eMTC（CE ModeA）/LTE的功控计算公式

二者区别不大，主要在功控步长补偿值的解码信道格式有所不同。可以看出影响功率的因素主要取决于上行调度资源，初始参数设置，距离路损，以及功控算法这四个因素。

eMTC（CE ModeB）发射功率

更高等级的增强型覆盖采取一直满功率发射的策略。

NB-IoT功控计算公式

（分配RU重复次数>2）

(other)

NB-IoT主要是间歇性的小包业务，因此没有像LTE采取那么复杂的功控调度算法，从计算公式直观来看功控的机制大大简化了，影响发射功率的因素仅仅取决于分配载波资源数量，初始参数设置以及路径损耗这三个因素。从另外一个角度来看，这里并没有考虑到网内干扰抬升的问题，物联网间歇式小包业务的特性导致上行干扰不会是主要矛盾，即使稍微受了一些干扰，通过资源分配调度算法把上行分配的子载波资源以及MCS同时降下来，既能保证相对稳定的数据传输，同时也把功耗降下来了。这样“不行也别硬抗”的技术思路会导致滚雪球一样的连锁效应，整网的上行底噪也得以抑制，不失为一种聪明且有趣的技术策略。

eMTC终端的增强覆盖

协议规定eMTC终端包含两种类型。一种叫BL UEs（Bandwidth reduced low complexity UEs）,另外一种叫做UE in CE(Coverage Enhanced)。随着这两种UE命名上有所不同，但是对于以深度覆盖为关注焦点之一的eMTC物联网终端都关注于增强型的覆盖。而增强型覆盖则是以增强型的覆盖技术功能进行小区接入。增强型的覆盖功能包含Mode A和Mode B两种模式，对于BL UEs，支持Mode A是必选项。不同等级对应随机接入的时频资源，以及重复次数和最大传送尝试次数是不同的。当然除了增强覆盖类型，也包括一般覆盖类型，这就与一般的覆盖技术功能是一样的。

BL UEs与UE in CE的寻呼机制是一样的，寻呼的其实时刻，重复周期与覆盖等级无关。不过，UE在能力上报中可以上报ue-RadioPagingInfo，包括UE的类型以及相应可支持的增强覆盖等级。

除了在UE能力上报中携带这一UE寻呼能力消息，在MME下发eNodeB的S1-AP信令中的Paging request也可以携带这一消息以及相应的Cell ID，目的是告知eNodeB可以采取一些定制化的寻呼策略。这两类终端还有一些共同特点，例如连接态不检测系统消息改变，空闲态不通知网络enhanced converage改变。

BL UEs还有一个特点就是传输带宽只占用6个PRB,即系统最大带宽占用1.4MHz。可以认为BL UEs是UE in CE这一类型终端分别在带宽和覆盖等级上的子集， 在一般覆盖区域两种终端可以沿用BL UEs的系统消息，而在不同的增强型覆盖等级，两种类型终端可以使用特定的系统消息。

除此之外，对于增强型覆盖类型还有个有趣的规定，就是不论在本小区处于增强型覆盖区域多么好，如果异频邻区在此处区域处于正常覆盖区域，那么UE都应重选过去，这其实类似LTE异频小区重选机制中往覆盖好的区域进行重选。当然这个目标小区如果是故障或者高干扰小区，可以通过cell bar或者调整重选参数的方式进行规避了，这属于建设后期的网络精准优化了。

（7）蜂窝物联网终端低功耗技术

物联网终端的一个重要特性就是低功耗，标称可以达到的目标一般是待机10年。单纯的提升电池的续航能力不一定能达到目标，还需要结合一些特定的功能特性，今天我们就把这些特性说一说。

PSM（Power Saving Mode）:

节电模式功能

有没有一种听着名字就很霸气的感觉。没错，这个功能就是为了节电而生的。这个模式很像是关机状态，但是UE保存网络注册状态，并且不需要重新附着或者重新建立PDN连接。处于PSM状态下的UE无法进行被叫业务，这时UE处于一种睡眠状态，等到UE“睡醒”后进入连接模式或者连接模式后的Active Time，UE就可以进行被叫业务了。从PSM状态到连接态的触发主要依靠主叫数据传输或者信令（例如周期性TAU/RAU）。PSM适用于不频繁的主被叫数据业务和对被叫延迟有一点容忍度的业务。网络侧的CS域不支持PSM状态，PSM可以在PS域业务，SMS，主叫IMS业务和主叫CS业务被使用。这里网络侧不支持PSM意味着网络侧对处于PSM状态的UE不支持在这个期间的UE被叫CS业务，同时对延迟有一定容忍的被叫IMS业务也不支持，除非IMS启用了“超长延迟通信”（High latency）这一功能。这也符合通信业务的行为，话音一般都是实时的，因此对于PSM支持被叫话音导致延迟较高的业务特性需求没有太多实际意义，而且还会额外占用资源。IMS底层承载是PS业务，相应还好一些。

对于使用PSM状态的应用需要对终端被叫业务或者数据传输进行处理。网络侧下行数据传输机制可以有如下三种选择：

1、网络侧应用在UE可达时（UE睡醒了）发起SMS（短信）或者device trigger（设备触发指令）触发UE侧应用与网络侧建立通信

SCS通过Tsp接口向位于HPLMN的MTC-IWF发送Device Trigger，详见29.368

2、网络侧检测UE数据可达状态，一旦被通知数据可达，就可以立即下发下行数据

3、如果网元SCS（Service Capability Server）/AS具有周期的下行数据，更有效的下行数据传输方式是UE周期激活发起与SCS/AS的连接去轮询下行数据的情况。

不论网络侧在UE使用PSM机制下采取以上哪种下行数据传输机制，UE都需要向网络侧请求足够长的活跃时间（Active Time）用来获取被叫服务或者数据传输，这个Active Time是本质上是UE处于IDLE时候能够获取系统消息，侦听寻呼的“清醒”状态。如果UE想要使用PSM机制，需要在每次Attach和TAU/RAU流程中请求Active Time的值，网络侧参考UE的请求值，最大响应值（Maximum Response Time）以及本地MME/SGSN配置进行权衡考虑最终决定分配给UE的Active Time。如果后续UE需要改变Active Time的值，UE在后续的TAU/RAU流程中可以请求新的值。这段流程颇为有意思，就好比UE每次睡眠醒来会向网络侧发起请求，请求“清醒”多久，然后网络侧予以批准。最小推荐的“清醒”（Active Time）时间标准也有建议，应该是MME/SGSN触发短信下发的一个“往返”流程，例如 2DRX周期+10s(TS 23.682)。然而，Active Time可能会比这个值更短，甚至设置为0秒。一旦MME/SGSN将这个极端值分配给UE，那么MME和RAN侧需要将UE的连接态保持足够长不拆线从而使得UE在连接态期间能够等到网络侧发来的SMS。

处于PSM状态的UE从睡眠醒来没有特定的Timer来控制，主要是UE的主叫上行数据或者信令请求唤醒，因此如果UE的应用有类似周期TAU/RAU这样的数据请求模式，可以适当将周期性TAU/RAU的Timer设置略大与数据传输周期，这样可以避免频繁的TAU/RAU唤醒流程导致的功耗。

SCEF主要针对处理Non-IP数据的传输与处理，一般采取CP模式进行

SCS/AS请求SCEF对UE可达性进行监测。在监测事件配置请求中会携带相关的参数。例如最大响应时间（Maximum Repsonse time）就是一个可选参数被用来配置Active Time，二者的关系是Active Time=MRT-UE处于连接态时间。另外对于UE使用eDRX的情况，MRT还可以被用来决定上报UE可达性的时刻。

SCEF会将监测事件请求（Monitoring Request）继续下发HSS，如果HSS被要求特定的监测类型（例如 "Reachabilityfor SMS", 或者"Reachability forData", 或者两者都配置）并且服务MME/SGSN也同样支持该特定的监测事件，那么下发Insert Subscriber Data Request（作用等同于Monitoring Request）。如果特定的监测类型是"Reachabilityfor SMS"，那么监测流程仅支持“一次性”（One-time）的Monitoring Request下发反馈机制。

一旦UE进入PSM状态，对于UE的NAS层移动性管理而言，等同于脱网状态。EMM的状态是EMM-REGISTERED.NO-CELL-AVAILABLE。此时UE是无法进行小区重选或者PLMN重选的。UE通过Attach/TAU流程向网络侧发起使用PSM的请求（涉及到emergency的请求除外），同时在请求中附带T3324的请求值，网络侧通过Attach/TAU Accept信令分配T3324。一旦T3324超时或者网络分配为0，那么UE清除AS层，激活PSM模式进入 EMM-REGISTERED.NO-CELL-AVAILABLE。如果收到T3324是"deactivated"，则禁止UE进入PSM状态。这里重要的T3324其实就是前文提到的Active Time，在EMM-IDLE状态启用，进入EMM-CONNECTED终止。

对于物联网终端如果使用PSM模式，定制化的配置Active Time是关键，而且区别于LTE终端周期性TAU timer只能由网络侧配置，物联网终端同样也可以发起周期TAU timer的申请，不过值得注意的是如果在发起请求中不配置Active Time，那么也不应包括周期性TAU timer。Active timer是周期性TAU timer的先决条件。另外如果在请求中不包括Active timer的申请,网络侧在后续应答（accept）中也不会分配Active timer。

eDRX(Extended idle mode DRX):

延长空闲态DRX功能

除了PSM功能的使用，在物联网技术中还有另外一个节电“利器”，eDRX。顾名思义，相比LTE中常规的idle态的DRX，eDRX“睡眠”时间可以更长。如同PSM的机制一样，eDRX也是通过UE的与网络的NAS信令互动协商确定（Attach/TAU/RAU）。根据运营商配置策略，在UE与网络侧协商的过程中网络侧通过accept信令也可以提供UE不同的eDRX值。而如果由于网络侧拒绝或者网络侧不支持eDRX的原因使得accept信令不包含eDRX值，那么UE仍然会采取常规DRX的设置。 使用这一机制也需要UE对于被叫的业务有一点时延上的容忍度。除了短信业务之外，网络侧CS域不支持处于eDRX状态下的CS话音业务。除非IMS启用高延迟通信（23.682 4.5.7），否则除了SMS业务之外的IMS被叫业务也不支持eDRX功能。

在蜂窝物联网技术中，对于eMTC系统，eDRX的周期可以从5.12s起始（包含5.12s,10.24s,20.48s......）一直到2621.44s(大约44分钟)。而对于NB-IoT系统，eDRX的周期可以从20.48s起始（包含20.48s,40.96s,81.92s.......）一直到10485.76s（大约3个小时）。如果UE在Attach/TAU请求中包含5.12s的请求值，网络侧按照常规寻呼策略进行处理，将寻呼周期T设置为512，否则在网络侧配置的公共寻呼周期（DRX）与这个NAS信令请求的eDRX值取最小值作为寻呼周期进行寻呼。另外，即使在常规DRX配置中，NB-IoT也不具备ue-specific自主选择DRX（寻呼）周期的机制。

对于eDRX的寻呼，重要的寻呼参数有两个，一个是通过eDRX周期长度（TeDRX）来计算Paging Hyperframes(PH),寻呼起始以一个超帧（Hyperframe=10.24s）作为基本单位。另一个参数是Paging Time Window（PTW）。MME将这两个寻呼参数通过S1的paging消息下发eNodeB辅助进行寻呼。同时也会通过Attach/TAU accept消息将这两个参数通知UE。这两个参数都是ue-specific。PTW的起始位置就在寻呼超帧（PH）之内，而PTW长度也可通过高层消息获知，这样UE就可以(按照DRX的PO位置)计算PTW窗内每个SFN的PO寻呼位置。MME对于PTW的窗长设置还需要可以重复寻呼的问题，为了确保UE能够在正确的PO收到寻呼，MME需要在下发paging request时预留一点点提前量。针对eDRX，eNB与MME之间超帧松散同步，同步精度1~2s。值得注意的是，针对常规DRX，PF的计算取决于IMSI。eDRX中PTW寻呼接收窗起始SFN的计算取决于TMSI，而PO都是取决于常规DRX的计算。这里有意思的是，eDRX通过这种基于TMSI获取寻呼窗起始位置的方式更体现了eDRX是ue-specific。其实，两种计算方式没有太本质的区别，如果硬要说细微的差别，可能就是在UE初始Attach流程之前发生系统消息改变，网络会在基于IMSI计算（此时UE没有获取S-TMSI，而eNB也不知道UE的IMSI,因此会基于寻呼周期的配置在系统消息改变周期内的每个可能PO都进行寻呼通知）的每个PO位置下发寻呼通知UE系统消息改变，而这时候UE不会获取eDRX的网络确认。即使当后续处于eDRX状态后，PO的计算也是基于常规DRX中IMSI进行计算的。多说一句，对于物联网终端（eMTC/NB-IoT），系统消息改变不仅可以通过寻呼通知，也可以有另外一种方式Direct Indication，感兴趣的可以查阅36.331。

UE在Attach Request中如果携带T3324并且UE支持extended periodic timer，那么UE还可能包含T3412 extended value以请求网络分配特定的T3412值。这个值是为了申请更长的周期TAU时间所用。这两个值长度各占3个byte,其中T3412的网络侧默认值为54分钟。

UE可以向网络请求使用PSM和eDRX两种节电技术，网络侧可以决定到底使用哪种模式，既可以两者都不允许，也可以是其中之一，或者两者都使用。如果允许两者都使用，网络侧需配置eDRX参数使得active timer超时之前有多个寻呼时刻。这是为了确保即使UE处于Active Time的EMM-IDLE状态，也能够减少功耗。