NB-IoT与LoRa技术详解及竞争态势分析

“物联网”概念在1999年美国麻省理工学院首次被提出,狭义的物联网指的是“物—物相连的互联网”,这里相连的主体既包括物品到物品,也包括物品到识别管理设备。物联网是继互联网后对人类发展起到促进作用的重大技术创新。中国政府为此提出《物联网2020行动计划》。

物联网通信技术

物联网的无线通信技术很多,主要分为两类:一类是Zigbee、WiFi、蓝牙、Z-wave等短距离通信技术;另一类是LPWAN(low-power Wide-Area Network,低功耗广域网),即广域网通信技术。

LPWA又可分为两类:一类是工作于未授权频谱的LoRa、SigFox等技术;另一类是工作于授权频谱下,3GPP支持的2/3/4G蜂窝通信技术,比如EC-GSM、LTE Cat-m、NB-IoT等。

NB-IoT的标准及进展

RAN方面

2014年5月,华为收购了Nuel公司,开始和沃达丰进行窄带蜂窝物联技术的研究,提出了窄带技术NB M2M。2015年5月,华为、沃达丰联合高通共同制定了相关的上下行技术标准,融合NB OFDMA形成了NB-CIoT。

NB-CIoT提出了全新的空口技术,相对来说在现有LTE网络上改动较大,但NB-CIoT是提出的6大Clean Slate技术中,唯一一个满足在TSG GERAN #67会议中提出的5 大目标(提升室内覆盖性能、支持大规模设备连接、减小设备复杂性、减小功耗和时延)的蜂窝物联网技术,特别是NB-CIoT的通信模块成本低于GSM模块和NB-LTE模块。

此时,爱立信和诺基亚联合推出窄带蜂窝技术NB-LTE,与NB-CIoT的定位较为相似,但NB-LTE更倾向于与现有LTE兼容,其主要优势在于容易部署。2015年7月,爱立信和华为分别向3GPP提交标准提案。最终,在2015年9月的RAN #69会议上经过激烈讨论后协商统一,由3GPP在Rel-13版本中将两种技术融合形成了NB-IoT标准。

NB-IoT从窄带技术演变为3GPP的正式标准,相关厂商、运营商积极的推动和市场真实存在的需求是两个不可忽略的因素。

3GPP的通信技术标准主要可分为Core Part(主体功能)、性能标准及RF一致性测试标准等。其中,主体功能标准指的是协议的具体内容,包括信令协议、网络接入等,主要与开发相关;性能标准主要是各个子技术领域的性能,跟测试强相关;一致性测试标准,主要包括一些流程及功能的测试标准。

SA/CT方面

从Rel-12开始,3GPP逐步在研究MTC通信增强的核心网架构,至Rel-13开始重点研究NB-IoT及DECOR/eDECOR相关技术。

3GPP核心网侧与NB-IoT相关的主体标准大部分处于stage2(业务与系统架构),2016下半年至2017年初启动stage3(核心网与终端)的相关工作。

为了满足海量碎片化、低成本、低速率、低功耗的NB-IoT物联网应用,核心网方面主要考虑了以下方面的问题。

高效地支持非频繁小包传送

面向NB-IoT进一步提高对非频繁小包传送的处理效率。由于NB-IoT终端的数量可能呈指数型增长,但每个终端的数据量及通信周期都比较低,而以现有的EPS核心网(基于S1接口)去处理此类业务,其效率将非常低且有过载的风险,因此,需要最小化整个EPS系统的信令开销,尤其是空口部分(如:RRC连接的建立和释放),此外,还需要加强EPS系统安全流程(此部分是由SA WG出)。

目前有两种优化方向,一种是基于控制面的优化方案,即通过NAS过程来传送小包;另外一种是基于用户面的优化方案,即通过RRC suspend 态在UE 和RAN节点同时缓存用户的上下文,以减少信令的交互。以上两种优化方案在TS23.401 Rel-14版本中均已加入,方案一作为必选方案,而方案二为可选方案。目前,3GPP倾向于采用基于控制的优化方案,此部分标准在CT(核心网与终端)的主体工作目前还在进行当中。

使用小包传送高效地支持跟踪装置

3GPP没有专门定义此类业务的业务模型,目前还处于研究状态,预计在Rel-14版本中解决,其业务模型属于MAR(移动终端周期性上报)业务模型的变种,需要在定位、移动性、传输效率等方面有进一步的增强和优化。

高效的寻呼区域管理

针对海量静止或限制移动性的终端,由于空口资源稀缺、核心网接口资源有限等原因,3GPP SA2目前还在进行寻呼优化的讨论,预计将在Rel-14中完善此部分功能。寻呼优化的主要思路是考虑仅在用户上一次接入的eNB 或小区内进行寻呼而非整个TA(初步假设,NB-IoT小区的TA code与现有eNB小区的TA code 是不同的),以节省空口及核心网的相关资源。

在同样的覆盖区域,NB-IoT 的设备是海量的,远多于传统的蜂窝终端设备。运营商在窄带频谱下运营,有可能并不能提供足够的寻呼所需资源、UE的标识(S-TMSI,IMSI)。与传统蜂窝相比,由于小数据包的消息量限制,单次寻呼消息中要包含以上标识是极为受限的;另外一方面,覆盖增强是标准中强制要求的,因此,寻呼消息可能要占用更长时间(重复发送相同的寻呼消息的间隔周期更长)。

大部分NB-IoT设备被认为是静止或很少移动的,因此可以对其寻呼范围进行限制,不需要在其所属的整个TA进行寻呼,这样可以减少对寻呼资源的消耗。但是,当UE 进入IDLE模式时,eNB上报给MME的上一次为NB-IoT UE服务的小区信息可能是不准确的(甚至静止的用户也存在这种可能)。这是因为在UE 静止的情况下,用户的主服小区的改变可能由各种原因引起,如射频负载条件改变、邻小区的射频条件改变(类似建筑物的阻挡,导致UE接入其他基站)。

DECOR/eDECOR

现网部署时,核心网可能会存在多个NB-IoT的DCN(DedicatedCore Network)。根据TSG RAN侧TS23.236的输出,NB-IoT DCN可能会同时连接到E-UTRAN和NB-IoT的RAN节点,可以根据用户类型采取两种不同方案为其选择合适的DCN。一种是重定向方案,参考TR23.707 DECOR功能;另一种是UE辅助,参考TR23.711中的eDECOR。从目前协议的进展来看,由于重定向流程会导致UE与RAN及网络侧之间产生额外的信令交互,所以DECOR部署的可能性较小,可能会作为过渡方案;而eDECOR由于对UE有影响,目前还处于初期研究阶段,将在Rel-14后期逐步完善,未来随着虚拟化网络的部署,有望被广泛采用。

支持non-IP 数据类型

在M2M应用中,非I 数据使用是常见的,如6LowPAN、MQTT-S等。当此类应用部署在NB-IoT 网络时,应用服务器AS或业务能力服务器SCS与用户间的non-IP数据需要通过网络进行传送,有两种方案可供选择,一种是通过non-IP专属的PDN点对点隧道方式通过SGi接口进行传送,另外一种是通过SCEF进行传递。目前,由于CSGN与SCEF之间的T6a接口还处于初步研究阶段,而通过SGi接口传送non-IP数据可以使C-SGN统一数据出口,便于未来面向NB-IoT类业务进行计费点选择及计费模式设计,因此,SGi方式可能会被运营商优先采用。

支持SMS

部分已有M2M业务是采用SMS支持的,为了能够全面的覆盖此类业务,在部署NB-IoT后,需要考虑两个问题:①是否保留联合附着以获取短信传递能力或者只进行PS 的附着;②是否会存在只使用SMS进行信息传递而无需建立任何PDN连接的终端及其解决方案。在Rel-14中会进一步完善NBIoT核心网支持SMS的解决方案,但运营商现网部署时可以根据实际需求考虑是否部署SMS功能,例如仅部署IP 及non-IP数据承载方式,主要是考虑到支持SMS功能需C-SGN与短信中心之间开通SGd接口,且需对现网短信中心进行升级改造,对CSGN也有相关功能要求。

授权用户支持覆盖增强(CE)技术

对于传播环境较差的用户,例如地下管道内的设备,需要很强的穿透性能,此时需要使用CE技术以获得更好的穿透效果。但CE技术的使用,需要网络侧提供额外的资源。因此,应该对用户进行认证,对可使用CE技术的用户加以限制,以保证只有签约并得到CE授权的用户方可享受此特性,实现差异化的服务。

OverLoad控制

关于减少核心网过载的风险的议题,3GPP发起了多项研究,提出了包括接入等级划分、基于eNB辅助的(在eNB侧进行拒绝、延迟、队列)等多种方案,而在TS23.401中,针对NB-IoT设备采用的拥塞控制方案是基于EPS系统原有backoff timer机制的升级,采用离散化的方式对NB-IoT设备并发请求进行处理来实现过载控制。

头压缩增强

由于NB-IoT大部分应用场景使用的都是小数据包且通信频率很低,例如周期性MAR(Mobile Autonomous Reporting)和NC(Network Command)使用20~200 byte/30min或更长时间间隔的数据传输。考虑到IP 及传输层的头开销,如20 byte的IPv4 、40 byte的IPv6、8 byte 的UDP、20 byte的TCP、12 byte的RTP,为了更高效地支持海量NB-IoT/eMTC类的终端,采用头压缩增强技术势在必行。

由于非频繁的数据传输及移动性,eNB和UE中保留的头压缩上下文可能会被重置(例如,当UE进入IDLE模式或切换eNB时),如果频繁发送数据或移动,将导致数据包产生全量头开销或额外开销。此时,头压缩将是高效支持IP类小包业务的重要保障。因此,当采用基于控制面优化的小包传输的方案时,头压缩功能需要支持NB-IoT终端用户从连接态至IDLE态的转换及移动性管理。另外需注意,当non-IP类业务场景发生时,必须要将IP头压缩功能关闭,故网络侧还需要根据不同的情况来决定是否启用头压缩功能。

此条目发表在NB-IoT技术分类目录,贴了, , , 标签。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。 必填项已用*标注