如何理解eMTC概念 與NB-IoT有什么不一樣

　　在我們談?wù)揘B-IoT總是會提及到eMTC這個(gè)概念，eMTC到底是什么？你對它又是真的了解嗎？

　　eMTC（enhanced Machine-TypeCommunicaTIon）終端主要指那些廉價(jià)且較低復(fù)雜性物聯(lián)終端，這一類終端具有較低廉的成本/收益、較低的速率并對時(shí)延不敏感，因此這類終端Tx/Rx天線收發(fā)的能力也大大簡化了。 Cat.0（Category 0）終端需要通過解碼SIB1以確認(rèn)網(wǎng)絡(luò)側(cè)是否允許Cat.0終端接入，如果SIB1中指示不支持Cat.0終端，那么網(wǎng)絡(luò)側(cè)禁止接入，終端認(rèn)為小區(qū)禁止駐留（cell barred）。網(wǎng)絡(luò)側(cè)可以通過UE發(fā)起的CCCH請求的LCID（LogicalChannelID）和UE的能力來判定UE是否為Cat.0終端。S1信令也將UE射頻能力包含進(jìn)了尋呼消息，eNB將UE的能力信息提供給MME，MME將這些終端能力信息通過尋呼請求提供給eNB。

　　eMTC終端主要分為兩種形態(tài)，一類是Bandwidthreduced Low complexityUE（BL UE）窄帶低復(fù)雜度UE，簡稱為BL UE，這類終端可以工作在任何LTE系統(tǒng)帶寬上，上下行頻域只占用6個(gè)PRB（對應(yīng)信道帶寬為1.4MHz的LTE系統(tǒng)）。當(dāng)小區(qū)MIB包含支持BLUE的SIB1調(diào)度信息，BL UE可以駐留訪問該小區(qū)，否則認(rèn)為小區(qū)禁止接入。

　　另一類被稱作UE in EnhancedCoverage，即支持覆蓋增強(qiáng)的UE。這類終端支持使用覆蓋增強(qiáng)功能訪問小區(qū)，協(xié)議規(guī)定（R13）這類終端需要支持兩種覆蓋增強(qiáng)模式，模式A和模式B。對于BL UE，覆蓋增強(qiáng)模式A是至少必須支持的。支持覆蓋增強(qiáng)類的終端不一定都是窄帶低復(fù)雜度終端（BL UE），這類終端支持測量上報(bào)以及網(wǎng)絡(luò)側(cè)控制的切換，與BL CE一樣不需要在連接態(tài)檢測SIB消息變化。

　　這兩類eMTC終端分別從性能的兩個(gè)維度進(jìn)行了定義，BL UE從系統(tǒng)帶寬以及工藝程度進(jìn)行了定義，覆蓋增強(qiáng)類終端從覆蓋增強(qiáng)功能維度進(jìn)行了定義。這兩類終端的劃分范疇不是經(jīng)緯分明的，意味著BL UE可以具備覆蓋增強(qiáng)的功能，而具備覆蓋增強(qiáng)功能的終端范疇甚至可以延展至LTE的用戶終端。綜合而言，BL UE屬于覆蓋增強(qiáng)類終端的一個(gè)簡化版本。

　　某種程度上，對于eMTC技術(shù)的理解可以認(rèn)為是簡化了的LTE版本，因此很多機(jī)制流程的設(shè)計(jì)是相通的。MIB傳輸周期與LTE相同，是40ms，即MIB起始傳輸于SFN mod4=0的無線幀的0號子幀，并且在其他無線幀的0號子幀上重復(fù)傳輸。為了確保MIB能夠被正確解調(diào)，對于支持eMTC且系統(tǒng)帶寬大于1.4MHz的FDD或TDD系統(tǒng)，MIB可以分別在其他的子幀額外重復(fù)傳輸，例如FDD系統(tǒng)在每個(gè)傳輸MIB無線幀的前一個(gè)無線幀的9號子幀進(jìn)行傳輸，TDD系統(tǒng)在每個(gè)當(dāng)前傳輸MIB的無線幀的5號子幀額外重復(fù)傳輸。MIB固定占用頻域6個(gè)物理資源塊（例如，0號子幀0號時(shí)隙占用0-4個(gè)OFDM符號，0號子幀1號時(shí)隙占用4-6個(gè)OFDM符號）。SIB1也采取周期為80ms的固定調(diào)度方式，除了像LTE那樣以每二個(gè)無線幀的5號子幀進(jìn)行重復(fù)傳輸外，會在80ms固定調(diào)度周期內(nèi)增加額外的重復(fù)傳輸。額外重復(fù)傳輸?shù)南到y(tǒng)消息命名為SystemInformaTIonBlockType1-BR，額外重復(fù)傳輸?shù)腡BS格式以及重復(fù)的次數(shù)通過MIB中的schedulingInfoSIB1-BR字段進(jìn)行明確，UE通過MIB中的SIB1-BR調(diào)度信息可以確定TBS（傳輸塊大?。┖?0ms內(nèi)的重復(fù)次數(shù)，并根據(jù)重復(fù)次數(shù)、系統(tǒng)制式（FDD/TDD）、小區(qū)物理識別ID和分配帶寬可以分別確定重復(fù)傳輸?shù)臅r(shí)域（無線幀，子幀）和頻域的位置。對于有些不具備解調(diào)寬帶（》6PRB）SIB1能力的eMTC終端，解調(diào)額外的SIB1-BR重傳信息就顯得尤為重要。

　　圖1 MIB中關(guān)于SIB1-BR的調(diào)度信息

　　表1 schedulingInfoSIB1-BR字段與SIB1-BR重傳次數(shù)的映射關(guān)系（0代表SIB1-BR沒有調(diào)度）

　　表2 schedulingInfoSIB1-BR字段與承載SIB1-BR的PDSCH傳輸塊大小映射關(guān)系（0代表SIB1-BR沒有調(diào)度）

　　eMTC獲取除SIB1-BR之外的其他系統(tǒng)消息（SI）首先需要獲取SIB1-BR中的系統(tǒng)消息窗長（si-WindowLength-BR）以及重復(fù)傳輸格式（si-RepeTITIonPattern）。至于獲取具體的時(shí)頻域調(diào)度信息則參考結(jié)合了NB-IoT與LTE的方式，既可以通過解碼SI-RNTI獲取動(dòng)態(tài)調(diào)度的系統(tǒng)消息（SI），也可以采取在SIB1-BR中獲取具體時(shí)頻域的調(diào)度信息和傳輸塊信息（TBS）。

　　圖2 SIB1-BR中明確了SI系統(tǒng)消息傳輸?shù)木唧w時(shí)域位置（可通過窗長計(jì)算窗起始位置，通過fdd-DownlinkOrTddSubframeBitmapBR（可選）字段明確時(shí)域接收幀和接收子幀）

　　圖3 SIB1-BR中明確了SI系統(tǒng)消息傳輸?shù)木唧w頻域位置和傳輸塊格式（TBS）

　　eMTC在計(jì)算系統(tǒng)消息（SI）窗的起始位置時(shí)暫時(shí)不需要獲取H-SFN信息，但是在系統(tǒng)消息變更周期以及eDRX獲取周期中可能會用到，因此H-SFN在SIB1-BR中以可選的形式進(jìn)行配置（如果系統(tǒng)不配置eDRX獲取周期，并且系統(tǒng)消息變更周期配置為512系統(tǒng)幀，此時(shí)H-SFN可以不用配置）。

　　圖4 SIB1-BR中的超幀配置（H-SFN）

　　系統(tǒng)幀（SFN）獲取方式與LTE一樣，通過解碼MIB獲取SFN高位8比特，并結(jié)合解碼40ms的PBCH隱式獲取低位2比特，這樣就可以確定具體的無線幀號（SFN）。

　　圖5 MIB中的系統(tǒng)幀（SFN）高位8比特

　　eMTC終端監(jiān)測系統(tǒng)消息變更的流程與NB-IoT/LTE基本上一樣，不失一般性我們不在此進(jìn)行重復(fù)的贅述。然而值得關(guān)注的有以下兩點(diǎn)區(qū)別：

　　（1） LTE終端在成功確認(rèn)系統(tǒng)消息可靠之后的3個(gè)小時(shí)考慮系統(tǒng)消息失效；NB-IoT終端在成功確認(rèn)系統(tǒng)消息可靠之后的24小時(shí)考慮系統(tǒng)消息失效；如果SIB1-BR中沒有配置si-ValidityTime字段，eMTC終端在成功確認(rèn)系統(tǒng)消息可靠之后的24小時(shí)考慮系統(tǒng)消息失效，否則在成功確認(rèn)可靠之后的3小時(shí)考慮系統(tǒng)消息失效。

　　（2） LTE/NB-IoT/eMTC終端通過接收尋呼消息的方式可以知道系統(tǒng)消息變更，但是無法確認(rèn)哪些系統(tǒng)消息變更。在NB-IoT中可通過MIB-NB中的systemInfoValueTag字段得知系統(tǒng)消息發(fā)生變更，進(jìn)一步解讀SIB1-NB中的systemInfoValueTagSI字段可具體確知哪些系統(tǒng)消息發(fā)生了變更；在eMTC中可以通過SIB1-BR中的systemInfoValueTag字段和systemInfoValueTagSI字段來確認(rèn)系統(tǒng)消息是否發(fā)生變更以及具體哪些系統(tǒng)消息發(fā)生了變更。

　　圖6 SIB1-BR中可選配置si-ValidityTime

　　圖7 SIB1-BR中可選配置systemInfoValueTagSI字段來確定具體系統(tǒng)消息變更情況（0-3循環(huán)設(shè)置）

　　eMTC或者NB-IoT在RRC_CONNECTED狀態(tài)時(shí)（T311定時(shí)運(yùn)行時(shí)，eMTC切換除外）不需要獲取系統(tǒng)消息（eMTC切換時(shí)只獲取目標(biāo)小區(qū)MIB），如果此時(shí)發(fā)生系統(tǒng)消息變更，UE可以通過解讀尋呼消息中的

　　systemInfoModification字段來評估系統(tǒng)消息是否發(fā)生了改變。在RRC_CONNECTED狀態(tài)下，eMTC或者NB-IoT終端仍然使用已存儲的系統(tǒng)消息。另一方面，如果變更的系統(tǒng)消息對于eMTC或者NB-IoT終端很重要的情況下，網(wǎng)絡(luò)側(cè)可以觸發(fā)連接釋放。UE通過連接釋放從RRC_CONNECTED轉(zhuǎn)為RRC_IDLE狀態(tài)時(shí)，也可以通過解讀systemInfoValueTag字段來判斷系統(tǒng)消息是否發(fā)生了改變。

　　eMTC數(shù)據(jù)傳輸模式與NB-IoT一樣，也分為三種，分別為CP數(shù)據(jù)優(yōu)化傳輸模式、建立DRB承載傳輸數(shù)據(jù)以及UP數(shù)據(jù)優(yōu)化傳輸模式。為了避免重復(fù)贅述，本文不進(jìn)行相關(guān)定義的描述，著重選取需要關(guān)注的方面進(jìn)行描述：

　　1、 eMTC中SRB中與LTE一樣，包括SRB0/SRB1/SRB0，沒有NB-IoT專屬的SRB1bis，eMTC能夠支持8個(gè)DRB（與LTE一樣）；

　　2、 eMTC中同樣存在針對UP數(shù)據(jù)優(yōu)化傳輸模式的掛起（Suspend）-恢復(fù)（Resume）流程，eMTC中的

　　RRCConnectionResumeRequest/RRCConnectionRequest相比LTE現(xiàn)網(wǎng)版本（R9、R10）多出一條mo-VoiceCall（R13版本中這兩條請求信令的觸發(fā)原因集合相同）。解碼現(xiàn)網(wǎng)VoLTE終端主叫觸發(fā)原因字段一般設(shè)置為mo-Data，如果觸發(fā)原因是多媒體電話視頻業(yè)務(wù)請求，并且駐留小區(qū)SIB2消息中包含voiceServiceCauseIndication字段，那么RRC連接連接建立/恢復(fù)請求的觸發(fā)原因就可以設(shè)置為mo-VoiceCall，從這里也可以看出，eMTC物聯(lián)網(wǎng)不僅僅能夠傳輸數(shù)據(jù)，還可以傳送語音。

　　圖8 RRCConnectionResumeRequest//RRCConnectionRequest主叫觸發(fā)原因值字段