如何理解eMTC概念 与NB-IoT有什么不一样

　　在我们谈论NB-IoT总是会提及到eMTC这个概念，eMTC到底是什么？你对它又是真的了解吗？

　　eMTC（enhanced Machine-TypeCommunicaTIon）终端主要指那些廉价且较低复杂性物联终端，这一类终端具有较低廉的成本/收益、较低的速率并对时延不敏感，因此这类终端Tx/Rx天线收发的能力也大大简化了。 Cat.0（Category 0）终端需要通过解码SIB1以确认网络侧是否允许Cat.0终端接入，如果SIB1中指示不支持Cat.0终端，那么网络侧禁止接入，终端认为小区禁止驻留（cell barred）。网络侧可以通过UE发起的CCCH请求的LCID（LogicalChannelID）和UE的能力来判定UE是否为Cat.0终端。S1信令也将UE射频能力包含进了寻呼消息，eNB将UE的能力信息提供给MME，MME将这些终端能力信息通过寻呼请求提供给eNB。

　　eMTC终端主要分为两种形态，一类是Bandwidthreduced Low complexityUE（BL UE）窄带低复杂度UE，简称为BL UE，这类终端可以工作在任何LTE系统带宽上，上下行频域只占用6个PRB（对应信道带宽为1.4MHz的LTE系统）。当小区MIB包含支持BLUE的SIB1调度信息，BL UE可以驻留访问该小区，否则认为小区禁止接入。

　　另一类被称作UE in EnhancedCoverage，即支持覆盖增强的UE。这类终端支持使用覆盖增强功能访问小区，协议规定（R13）这类终端需要支持两种覆盖增强模式，模式A和模式B。对于BL UE，覆盖增强模式A是至少必须支持的。支持覆盖增强类的终端不一定都是窄带低复杂度终端（BL UE），这类终端支持测量上报以及网络侧控制的切换，与BL CE一样不需要在连接态检测SIB消息变化。

　　这两类eMTC终端分别从性能的两个维度进行了定义，BL UE从系统带宽以及工艺程度进行了定义，覆盖增强类终端从覆盖增强功能维度进行了定义。这两类终端的划分范畴不是经纬分明的，意味着BL UE可以具备覆盖增强的功能，而具备覆盖增强功能的终端范畴甚至可以延展至LTE的用户终端。综合而言，BL UE属于覆盖增强类终端的一个简化版本。

　　某种程度上，对于eMTC技术的理解可以认为是简化了的LTE版本，因此很多机制流程的设计是相通的。MIB传输周期与LTE相同，是40ms，即MIB起始传输于SFN mod4=0的无线帧的0号子帧，并且在其他无线帧的0号子帧上重复传输。为了确保MIB能够被正确解调，对于支持eMTC且系统带宽大于1.4MHz的FDD或TDD系统，MIB可以分别在其他的子帧额外重复传输，例如FDD系统在每个传输MIB无线帧的前一个无线帧的9号子帧进行传输，TDD系统在每个当前传输MIB的无线帧的5号子帧额外重复传输。MIB固定占用频域6个物理资源块（例如，0号子帧0号时隙占用0-4个OFDM符号，0号子帧1号时隙占用4-6个OFDM符号）。SIB1也采取周期为80ms的固定调度方式，除了像LTE那样以每二个无线帧的5号子帧进行重复传输外，会在80ms固定调度周期内增加额外的重复传输。额外重复传输的系统消息命名为SystemInformaTIonBlockType1-BR，额外重复传输的TBS格式以及重复的次数通过MIB中的schedulingInfoSIB1-BR字段进行明确，UE通过MIB中的SIB1-BR调度信息可以确定TBS（传输块大小）和80ms内的重复次数，并根据重复次数、系统制式（FDD/TDD）、小区物理识别ID和分配带宽可以分别确定重复传输的时域（无线帧，子帧）和频域的位置。对于有些不具备解调宽带（》6PRB）SIB1能力的eMTC终端，解调额外的SIB1-BR重传信息就显得尤为重要。

　　图1 MIB中关于SIB1-BR的调度信息

　　表1 schedulingInfoSIB1-BR字段与SIB1-BR重传次数的映射关系（0代表SIB1-BR没有调度）

　　表2 schedulingInfoSIB1-BR字段与承载SIB1-BR的PDSCH传输块大小映射关系（0代表SIB1-BR没有调度）

　　eMTC获取除SIB1-BR之外的其他系统消息（SI）首先需要获取SIB1-BR中的系统消息窗长（si-WindowLength-BR）以及重复传输格式（si-RepeTITIonPattern）。至于获取具体的时频域调度信息则参考结合了NB-IoT与LTE的方式，既可以通过解码SI-RNTI获取动态调度的系统消息（SI），也可以采取在SIB1-BR中获取具体时频域的调度信息和传输块信息（TBS）。

　　图2 SIB1-BR中明确了SI系统消息传输的具体时域位置（可通过窗长计算窗起始位置，通过fdd-DownlinkOrTddSubframeBitmapBR（可选）字段明确时域接收帧和接收子帧）

　　图3 SIB1-BR中明确了SI系统消息传输的具体频域位置和传输块格式（TBS）

　　eMTC在计算系统消息（SI）窗的起始位置时暂时不需要获取H-SFN信息，但是在系统消息变更周期以及eDRX获取周期中可能会用到，因此H-SFN在SIB1-BR中以可选的形式进行配置（如果系统不配置eDRX获取周期，并且系统消息变更周期配置为512系统帧，此时H-SFN可以不用配置）。

　　图4 SIB1-BR中的超帧配置（H-SFN）

　　系统帧（SFN）获取方式与LTE一样，通过解码MIB获取SFN高位8比特，并结合解码40ms的PBCH隐式获取低位2比特，这样就可以确定具体的无线帧号（SFN）。

　　图5 MIB中的系统帧（SFN）高位8比特

　　eMTC终端监测系统消息变更的流程与NB-IoT/LTE基本上一样，不失一般性我们不在此进行重复的赘述。然而值得关注的有以下两点区别：

　　（1） LTE终端在成功确认系统消息可靠之后的3个小时考虑系统消息失效；NB-IoT终端在成功确认系统消息可靠之后的24小时考虑系统消息失效；如果SIB1-BR中没有配置si-ValidityTime字段，eMTC终端在成功确认系统消息可靠之后的24小时考虑系统消息失效，否则在成功确认可靠之后的3小时考虑系统消息失效。

　　（2） LTE/NB-IoT/eMTC终端通过接收寻呼消息的方式可以知道系统消息变更，但是无法确认哪些系统消息变更。在NB-IoT中可通过MIB-NB中的systemInfoValueTag字段得知系统消息发生变更，进一步解读SIB1-NB中的systemInfoValueTagSI字段可具体确知哪些系统消息发生了变更；在eMTC中可以通过SIB1-BR中的systemInfoValueTag字段和systemInfoValueTagSI字段来确认系统消息是否发生变更以及具体哪些系统消息发生了变更。

　　图6 SIB1-BR中可选配置si-ValidityTime

　　图7 SIB1-BR中可选配置systemInfoValueTagSI字段来确定具体系统消息变更情况（0-3循环设置）

　　eMTC或者NB-IoT在RRC_CONNECTED状态时（T311定时运行时，eMTC切换除外）不需要获取系统消息（eMTC切换时只获取目标小区MIB），如果此时发生系统消息变更，UE可以通过解读寻呼消息中的

　　systemInfoModification字段来评估系统消息是否发生了改变。在RRC_CONNECTED状态下，eMTC或者NB-IoT终端仍然使用已存储的系统消息。另一方面，如果变更的系统消息对于eMTC或者NB-IoT终端很重要的情况下，网络侧可以触发连接释放。UE通过连接释放从RRC_CONNECTED转为RRC_IDLE状态时，也可以通过解读systemInfoValueTag字段来判断系统消息是否发生了改变。

　　eMTC数据传输模式与NB-IoT一样，也分为三种，分别为CP数据优化传输模式、建立DRB承载传输数据以及UP数据优化传输模式。为了避免重复赘述，本文不进行相关定义的描述，着重选取需要关注的方面进行描述：

　　1、 eMTC中SRB中与LTE一样，包括SRB0/SRB1/SRB0，没有NB-IoT专属的SRB1bis，eMTC能够支持8个DRB（与LTE一样）；

　　2、 eMTC中同样存在针对UP数据优化传输模式的挂起（Suspend）-恢复（Resume）流程，eMTC中的

　　RRCConnectionResumeRequest/RRCConnectionRequest相比LTE现网版本（R9、R10）多出一条mo-VoiceCall（R13版本中这两条请求信令的触发原因集合相同）。解码现网VoLTE终端主叫触发原因字段一般设置为mo-Data，如果触发原因是多媒体电话视频业务请求，并且驻留小区SIB2消息中包含voiceServiceCauseIndication字段，那么RRC连接连接建立/恢复请求的触发原因就可以设置为mo-VoiceCall，从这里也可以看出，eMTC物联网不仅仅能够传输数据，还可以传送语音。

　　图8 RRCConnectionResumeRequest//RRCConnectionRequest主叫触发原因值字段