由於物理層可用的頻寬較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可選擇更多種比例劃分).
如圖1所示, 藍色區域為所設置搜索空間長度為Rmax(此例設為8), 根據四種比例的劃分, 依序為R=Rmax/8, R=Rmax/4, R=Rmax/2, R=Rmax/1, 以此例而言分別為1, 2, 4, 8, R即是重複次數, 此時R所涵蓋的時間區塊即稱為備選區塊(Candidate), 所選擇的劃分比例也可看成此搜索空間所含備選區塊數量.
圖1 搜索空間備選區塊示意圖
此外, 可以透過參數設定調整不同搜索空間起始的時間位置, 避免過多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的考慮而有即高的彈性去選擇.
圖2 排程周期與時間關係示意圖
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傳送與接收模式轉換的時間.
圖3為上行與下行使用目前標準Release 14所訂定最大的TB size與MCS下排程間隔的示意圖, 透過此圖我們也可以算出在Release 14標準NB-IoT UE所能達到的最大速率的數值.
圖3 NB-IoT排程示意圖
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資源分配管理上將會是一大挑戰.
圖4 NB-IoT排程示意圖
本文針對NB-IoT MAC層進行重點技術描述, 由於在變化上NB-IoT在資源分配邏輯上有著明顯與其母技術LTE差異, 因此本篇我們著重於此部份的說明與描述. 雖然NB-IoT是個相對於LTE簡單化的技術, 但由於為了去滿足簡單化後以時間資源換取頻率資源的概念, 在排程邏輯上相對有較為複雜的新議題需要解決; 若以整個系統面來看, 排程方法將會有更大的影響力影響整體效能. 考慮到未來標準訂定會再增加更多排程上議題, 例如Release 14訂定的2-HARQ Process, MAC將會扮演著關鍵與重要的角色.