在我們談論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（傳輸塊大?。┖?0ms內的重復次數，并根據重復次數、系統制式（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字段來判斷系統消息是否發生了改變。

　　層3信令流程

　　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主叫觸發原因值字段