NB-IoT MAC協議主要負責數據傳輸(Data Transfer)及實體資源/無線資源分配(Radio Resource Allocation)，而本文偏重無線資源分配，在此說明NB-IoT無線資源之規劃。

由于物理層可用的帶寬較LTE少(180kHz一個載波)，物理層程序也較以往大不相同，考慮到NB-IoT增強信號覆蓋需求，因此3GPP標準制定團隊利用「重復傳送」之方式獲取時域之增益，達到覆蓋增強(Coverage Enhancement, CE)之目的：在標準規范中，下行鏈路傳輸僅允許跨子訊框排程(Cross-Subframe Scheduling)，上行鏈路傳輸支持跨子訊框和跨子載波排程。

NB-IoT采用集中控制方式管理演進節點B(eNB)與用戶裝置(UE)之間，數據傳輸所需的無線資源。 與LTE系統相同，UE傳輸或是接收數據皆聽從于eNB指示． 分別為下行鏈路傳輸分配(Downlink Assignment)與上行鏈路傳輸授權(Uplink Grant)；即下行鏈路傳輸控制指示(Downlink Control Indicator, DCI)，上行部份使用DCI格式， 下行部份為DCI N1格式，尋呼(Paging)部份則使用DCI N2格式。

UE在與基地臺鏈接的過程會周期性地監測/監聽(Monitor)DCI傳送的區域，即窄頻物理下行控制頻道(NPDCCH)，亦稱搜索空間(Search Space)。 UE收到屬于自己的DCI后，再依其內容指示至相對應數據傳送區域，即窄頻物理下行分享頻道(NPDSCH)接收數據。

基于NB-IoT跨子訊框排程的特性，對比LTE以DCI告知UE當下子訊框(Subframe)數據所擺放的資源區塊位置、資源區塊數量，讓UE知道數據位于那個「頻率區間」內，NB-IoT則是告知一個排程延遲參數( Scheduling Delay，標準上稱為k0)，以及資源區塊長度，讓UE知道屬于自己的數據位于那個「時間區間」內。 針對NB-IoT資源分配與排程相關部分，有以下幾項說明。

降低DCI獲取成本 善用搜索空間提升UE效率

與LTE相同，UE可以透過搜索一個特定的區間獲得DCI信息，可減少UE耗費不必要的功耗盲解不相關的數據。

在NB-IoT中，搜索空間以一個時間區間作為呈現；透過預先告知UE相關的參數，如系統信息區塊類別2(NB-IoT System Information Block Type 2，SIB2-NB)中帶共同搜索空間(Common Search Space)參數，隨機存取(Random Access)流程中之RRC Connection Setup Message帶特定搜索空間(UE Specific Search Space)參數， 使UE可以得知在哪一個時間范圍能夠有機會盲解出自己的DCI。

標準規范下，搜索空間的訂定有很大的彈性，在長度方面可以根據所服務UE的特性去選擇適當的長度；同時，在相同的搜索空間上，根據標準可以進一步選擇性劃分1、2、4、8等四種比例，作為不同UE的DCI傳送時間， 劃分后的長度即為該DCI所重復傳送的次數(T1CSS可選擇更多種比例劃分)。

藍色區域為所設置搜索空間長度為Rmax(此例設為8)，根據四種比例的劃分，依序為R=Rmax/8，R=Rmax/4，R=Rmax/2，R=Rmax/1，以此例而言分別為1、2、4、8，R即是重復次數，此時R所涵蓋的時間區塊即稱為備選區塊(Candidate)，所選擇的劃分比例也可看成此搜索空間所含備選區塊數量。

此外，可以透過參數設定調整不同搜索空間起始的時間位置，避免過多UE處于同一搜索空間設定，導致基地臺在單位時間所能服務的UE有限。 不同參數與比例訂定將影響基地臺在單位時間內所能夠服務的UE數量，以及CE成效，因此在實作上可根據當下決定的排程策略進行調整選擇。

當UE選定駐留(Camp)某一個基地臺后，UE根據目前所處于的聯機狀態會監測相對應的搜索空間，目前的標準定義了Type1-NPDCCH共同搜索空間(T1CSS)、Type2-NPDCCH共同搜索空間(T2CSS)、 NPDCCH UE特定搜索空間(USS)等三種不同用途的搜索空間：

T1CSS

當UE閑置(Idle)時，會根據與核心網絡(CN)之間約定之尋呼周期(Default Paging Cycle)監測T1CSS。 鑒于不同CE層級的UE皆是相同的T1CSS長度設置，其備選區塊劃分根據標準，可以有更多的選擇滿足各CE層級UE的重復傳送次數；當UE在這個尋呼周期搜索空間、解出DCI且正確收到尋呼訊息時，UE便會進行隨機存取程序， 并將所搜索的空間調整為T2CSS。

T2CSS

當UE處于未與核網注冊，或是已注冊但處于閑置狀態時，若UE欲進行傳送數據，或接收到基地臺的尋呼訊息，UE便開始進行隨機存取程序。 此時，UE便是依據T2CSS設定盲解DCI。

USS

當UE完成隨機存取程序，且進入鏈接(Connected)狀態時，UE便會根據隨機存取過程獲得的USS參數設定信息進行搜索，直到狀態又切換為閑置或隨機存取狀態時，再進行對應搜索空間之切換。

搜索/傳輸作業多元化 邏輯信道無明確劃分規則

下行信道

在NB-IoT系統中，排除必要的系統/同步訊號(如NPBCH、NPSS、NSSS、SIB-NB)所占用的資源，信道有NPDCCH與NPDSCH兩種，然以整個NB-IoT系統面來看，此兩種信道并沒有明確時間上的劃分規則。

原因之一在于前述所談到，搜索空間不論起始位置或長度，皆可以依照不同UE以及CE構成非常多種組合表現；其二則歸因于下一節將提及之排程延遲，賦予數據傳輸時間點多樣化的可能性。 因此，在下行信道我們應以實際排程結果來看劃分的結果，意即某區塊時間若傳送DCI，則此區間即作為NPDCCH使用；若傳送下行數據，則此區間即作為NPDSCH使用。

上行信道

相對于下行信道，上行信道劃分則較為簡單：根據SIB2-NB中所設定之隨機存取工作發送Preamble的時間區塊作為NPRACH，其余皆作為NPUSCH來使用。

其特殊之處在于，考慮到NB-IoT上行支持跨子載波排程，排程上須根據所選擇的NPUSCH format進一步針對子載波頻率之間的資源分配進行考慮。

藉有限帶寬傳遞DCI/數據 排程延遲有助兼顧效率

3GPP MAC協議標準定義PDCCH周期(Physical Downlink Control Channel period，簡稱pp)，意即從目前的搜索空間起始點到下一個搜索空間起始點的間隔時間， 對于NB-IoT即作為NPDCCH的周期。 如圖2所示，藍色區域可視為某個/群UE的NPDCCH，白色區域為NPDSCH，區域的組成是依照標準訂定參數組合而成，約有90種組合的可能性，周期組合的選擇將會與排程策略、CE的考慮而有即高的彈性去選擇。

NB-IoT是透過跨子訊框方式來進行排程，原因之一在于系統所定義的帶寬較小，DCI與數據皆無法在同一時間傳送完成；且在正常情況下，對于一個傳送區域(Transport Block, TB)需要多個NPDSCH進行才可組成完成。因此，如何去處理DCI與數據的時間關系便是NB-IoT特有的機制，時程k0扮演著最重要的角色。

當UE從備選區塊解出DCI后變會獲得基地臺所給予的k0，UE便會等待k0時間后再開始進行收取NPDSCH的動作。而k0的規定在上行/下行，或者在一些特定訊息上皆有不同的需求與限制，例如當UE收到DCI后必須等待至少4ms過后才可進行NPDSCH的接收，至少等待8ms過后才可進行NPUSCH的傳送， 原因在于UE必須要有足夠的時間去解DCI所帶的訊息，或是進行UL/DL傳送與接收模式轉換的時間。

為上行與下行使用目前標準Release 14所訂定最大的TB size與MCS下排程間隔的示意圖，透過此圖我們也可以算出在Release 14標準NB-IoT UE所能達到的最大速率的數值。

NB-IoT的k0數值是依照標準文件所規定的固定值進行選擇，因此在選擇上便會缺少相當的彈性，再加上前面所提到的搜索空間起始位置與長度的多樣性，以及傳送一個TB所需花的時間長度影響，因此在排程上將會是一個具有挑戰性的工作。 在加上當中衍生的議題都有待研究與討論，以下針對相關排程議題進行說明。

有限資源下擴充UE服務 MAC排程重要性與時俱

由于NB-IoT支持多載波傳輸，讓不同UE可在不同載波上傳輸，以擴充服務UE數量，MAC排程與無線資源分配將扮演至關重要的角色。

NB-IoT多載波分為錨載波(Anchor Carrier)以及非錨載波(Non-Anchor Carriers)，錨載波是UE獲取系統信息和同步訊號(NPSS/NSSS/NPBCH/SIB-NB)之載波 ；而非錨載波若系統有支持，則可以視為一個空白的資源區塊。 由于錨載波作為傳送系統信息與同步訊號的關系，這些信息將被視為最高優先權進行資源的占用。 因此，在標準規則上，NPDCCH與NPDSCH如果遭遇上述訊息傳送的時間，便須要進行延后傳送的動作。

有鑒于此，在錨載波排程上，我們必須考慮這些延后所帶來的資源排程上的影響；另外，Release 14標準規范相較于Release 13，可以將隨機存取程序與尋呼程序在非錨載波上進行， 此方式提高了系統的效率但也相對提到排程分配的復雜度。

若以整個通訊協議與IoT服務來看，一道IoT訊息的傳送在NB-IoT系統上必須經過幾道訊息的交換才會完成；若以UE所發起的訊息回報來看，必須經過完整的隨機存取程序才可完成一筆上層服務數據的傳送， 此UE所發起傳送的完整程序即為所謂的行動發送數據程序(MO Procedure)。

但在許多如帶寬限制、排程周期、搜索空間的限制之下，基站在有限的資源下就必須針對一些議題進行抉擇，例如上行/下行分配比例、UE資源分配比例、公平性等等，如圖4即為一個10個UE進行MO Procedure的簡易時間軸對應示意圖。 此外，若再考慮省電機制例如DRX狀態尋呼的功能，以及多重CE層級設置上的排程，在MAC資源分配管理上將會是一大挑戰。

本文針對NB-IoT MAC層進行重點技術描述，由于在變化上NB-IoT在資源分配邏輯上有著明顯與其母技術LTE差異，因此本篇我們著重于此部份的說明與描述。 雖然NB-IoT是個相對于LTE簡單化的技術，但由于為了去滿足簡單化后以時間資源換取頻率資源的概念，在排程邏輯上相對有較為復雜的新議題需要解決；若以整個系統面來看，排程方法將會有更大的影響力影響整體效能。 考慮到未來標準訂定會再增加更多排程上議題，例如Release 14訂定的2-HARQ Process，MAC將會扮演著關鍵與重要的角色。