主頁(http://www.130131.com):NB-IoT容量規(guī)劃研究 0 引言 NB-IoT在幀結構、時隙結構、物理信道、數據傳輸過程等方面與傳統(tǒng)的LTE網絡都有較大的差別,為了增強下行和上行覆蓋,NB-IoT的NPDCCH、NPDSCH、NPUSCH、NPRACH等物理信道可以根據覆蓋等級進行多次傳輸,同時NPDCCH和NPDSCH在不同的子幀進行傳輸,NB-IoT需要采用與LTE完全不同的容量規(guī)劃方法。本文接下來分析NB-IoT的下行數據傳輸進程和下行峰值速率以及上行數據傳輸進程和上行峰值速率,然后分析NB-IoT用戶的業(yè)務模型和NB-IoT上行數據報告流程,最后給出NB-IoT容量規(guī)劃的方法。 1 NB-IoT數據傳輸進程 由于NB-IoT終端的成本低、處理能力弱,3GPP協(xié)議規(guī)定,NB-IoT的UE只能進行單進程傳輸,即某一個時刻只有1個進程傳輸下行數據或者上行數據。 1.1 NB-IoT下行數據傳輸進程 NB-IoT的下行數據傳輸進程如圖1所示,eNodeB通過NPDCCH信道發(fā)送DCI格式N1的調度消息給UE,通知UE接收下行數據,經過t1時間后,eNodeB通過NPDSCH信道發(fā)送下行數據給UE,UE接收NPDSCH信道并解碼出下行數據后,經過t2時間,UE通過格式2的NUPSCH信道發(fā)送UL A/N消息給eNodeB,通知eNodeB是否正確接收下行數據,UE發(fā)送UL A/N消息后的t3時間內,UE不監(jiān)聽NPDCCH信道,同時下一個NPDCCH信道的發(fā)送時刻需滿足:
圖1 NB-IoT下行數據傳輸進程
NB-IoT的1次下行數據傳輸進程的持續(xù)時間為:
式中: tNPDCCH——NPDCCH的傳輸時間,NPDCCH最多使用Rmax個下行子幀,Rmax在1到2 048之間共有12個取值 t1——NPDCCH結束傳輸到NPDSCH開始傳輸的間隔時間,固定為4個下行子幀,即4 ms tNPDSCH——NPDSCH的傳輸時間,占用NSF×NRep個下行子幀,其中NSF為1個NPDSCH(對應1個下行傳輸塊)占用的下行子幀數,取值為1,2,3,4,5,6,8,10,NSF由傳輸的數據塊大小和調制方式共同決定,該值越大,信道編碼速率越低,編碼增益就越大;NRep為NPDSCH的重復次數,在1到2048之間共有16種取值 t2——NPDSCH傳輸結束到NPUSCH傳輸開始的間隔時間,上行子載波帶寬為15 kHz時,占用12、14、16或17個下行子幀;上行子載波帶寬為3.75 kHz時,占用12或20個下行子幀 tNPUSCH2——格式2的NPUSCH的傳輸時間,占用 t3——UE發(fā)送NPUSCH后不監(jiān)聽NPDCCH的間隔時間,占用3個下行子幀,即3 ms T=Rmax×G,Rmax的取值見前文,G的取值為1.5,2,4,8,16,32,64,單位為ms[8]。 上述參數中的Rmax、NRep、 NB-IoT的下行速率計算公式如下: NB-IoT的下行速率=TBS/T2 (2) 假設Rmax=1,G=8 ms,則T=Rmax×G=8 ms,下行傳輸塊取最大值,TBS=680 bit,此時NSF=3,則式(1)中各個參數取值如下時,NB-IoT下行數據傳輸時間T1為最小值: Rmax=1,tNPDCCH=1 ms,NRep=1,NSF=3,tNPDSCH=3 ms;t2=12 ms; 則,T1=tNPDCCH+t1+tNPDSCH+t2+tNPUSCH2+t3 =1+4+3+12+2+3=25 ms。 下一個NPDCCH開始時間應大于25 ms,且為T=8 ms的整數倍,即T2=32 ms,因此可以計算出NB-IoT的下行峰值速率為680 bit/32 ms=21.25 kbit/s。 1.2 NB-IoT上行數據傳輸進程 NB-IoT的上行數據傳輸進程如圖2所示,eNodeB通過NPDCCH信道發(fā)送DCI格式N0的調度消息給UE,通知UE發(fā)送上行數據,經過t4時間后,UE通過格式1的NPUSCH信道發(fā)送上行數據給eNodeB,UE發(fā)送NPUSCH數據后的t5時間內,不監(jiān)聽NPDCCH信道,eNodeB接收NPUSCH信道并解碼出上行數據后,在滿足(10nf+ns2)modT=αoffset·T]的時刻,通過NPDCCH信道里面的新數據指示信息,通知UE發(fā)送新的上行數據或重傳上行數據。
NB-IoT的1次上行數據傳輸進程的持續(xù)時間為: T3=tNPDCCH+t4+tNPUSCH1+t5 (3) 式中: tNPDCCH——NPDCCH的傳輸時間 t4——NPDCCH結束傳輸到NPUSCH開始傳輸的間隔時間,占用8、16、32或64個下行子幀 tNPUSCH1——格式1的NPUSCH的傳輸時間,tNPUSCH1=NRepNRU t5——UE發(fā)送NPUSCH后不監(jiān)聽NPDCCH的間隔時間,固定為3個下行子幀,即3 ms NB-IoT的上行速率計算公式如下: NB-IoT的上行速率=TBS/T4 (4) 假設Rmax=1,G=8 ms,則T=Rmax×G=8 ms,上行傳輸塊取最大值,TBS=1 000 bit,此時NRU=4,則分配給UE不同的子載波數時NB-IoT的上行峰值速率如表1所示。 表1 NB-IoT上行峰值速率
2 NB-IoT容量規(guī)劃 NB-IoT業(yè)務的應用場景包括智能抄表、智能停車、智慧農業(yè)、海綿城市等,這些應用主要以傳輸上行數據為主,對傳輸下行數據無要求,因此本文的NB-IoT容量規(guī)劃主要考慮上行容量。 上行子載波帶寬有15和3.75 kHz 2種,參考文獻[10]建議上行子載波帶寬選擇15 kHz,本文按照上行子載波帶寬為15 kHz來計算上行容量,為了簡化起見,假定每個用戶只分配1個上行子載波。 2.1 NB-IoT用戶的業(yè)務模型 除了系統(tǒng)開銷外,NB-IoT的上行業(yè)務主要由兩部分組成,分別是MAR(Mobile Autonomous Reporting)例外報告、MAR周期性報告。 MAR例外報告的應用包括煙霧告警、智能儀表的電力中斷通知、非法修改通知等,該類應用基于事件報告機制,只有監(jiān)測到某個特定事件發(fā)生后才發(fā)送一次上行數據,該類事件通常是非常稀少的,幾個月或者數年才發(fā)生一次,因此流量很低,對NB-IoT網絡的容量規(guī)劃影響可以忽略不計,本文暫不考慮這部分流量。 MAR周期性報告的應用包括智能抄表(煤氣、水表、電表)、智慧農業(yè)、智能停車、智慧環(huán)境等,該類應用周期性的向應用服務器發(fā)送上行數據,發(fā)送周期為半小時、數小時或者數天,NB-IoT的上行流量以MAR周期性報告為主。 根據3GPP 45.820協(xié)議[9],MAR周期性報告的業(yè)務模型如下: 應用層的負荷:假定應用層的負荷的大小服從于帕累托分布,k=2.5,最小的應用層負荷xmin=20 B,最大的應用層負荷為200 B,負荷高于200 B時被認為是200 B,根據該模型,可知應用層負荷的平均值為xmin×k/(k-1)=34 B,95%的負荷低于64 B。 傳輸層的負荷:根據3GPP 36.321、36.322、36.323,MAC層的頭開銷是2 B、RLC層的頭開銷是4 B、PDCP層的頭開銷是1 B,IP頭采用壓縮模式的頭開銷是4 B,則傳輸層的負荷是64+2+4+1+4=75 B,折算為600 bit[5-7]。 上報周期:上報周期為1天的占比為40%,上報周期為2 h的占比為40%,上報周期為1 h的占比為15%,上報周期為30 min的占比為5%。 假設1個小區(qū)內的用戶數是NMS,則一天內產生的上行報告次數是: NReport=NMS×(40%×1+40%×12+15%×24+5%×48)=NMS×11.2 (5) 2.2 NB-IoT上行數據的報告流程 NB-IoT的業(yè)務以小的數據包為主,為了降低信令開銷,3GPP定義了2種信令優(yōu)化方案,分別是控制面(CP)CIoT EPS優(yōu)化方案和用戶面(UP)CIoT EPS優(yōu)化方案[4]。 采用CP CIoT EPS優(yōu)化方案時,NB-IoT的UE并不需要與eNodeB建立數據無線承載(DRB),只通過信令無線承載(SRB)即可以傳輸數據。 采用UP CIoT EPS優(yōu)化方案時,RRC連接釋放進入RRC IDLE態(tài)后,eNodeB和UE還會保留UE AS層的上下文信息,其中包括UE的能力信息;從RRC IDLE態(tài)到RRC CONNECTED態(tài),使用RRC connection resume流程,eNodeB和UE使用以前保留的AS上下文信息即可恢復RRC連接,因此省去了Attach請求、UE能力上報、鑒權和加密等過程,節(jié)省了信令開銷。 采用UP CIoT EPS優(yōu)化方案時,NB-IoT上行數據的報告流程如圖3所示。
圖3 NB-IoT上行數據的報告流程 UE需要發(fā)送上行數據給應用服務器時,首先通過NPRACH信道發(fā)送Random Access Preamble給eNodeB;eNodeB發(fā)送Random Access Response消息給UE,該消息包含了對NPUSCH信道的上行調度信息;UE發(fā)送RRC Connection Resume Request消息給eNodeB,該消息包含了Resume原因、Resume ID、shortResumeMAC-I等信息,請求恢復RRC連接;eNodeB發(fā)送RRC Connection Resume消息給UE,該消息包含了專用的無線資源配置信息;UE發(fā)送RRC Connection Resume Complet消息給eNodeB,該消息包含了可選的PLMN標識和可選的NAS數據;UE發(fā)送上行數據給eNodeB;eNodeB發(fā)送RRC Connection Release消息給UE,該消息屬于RLC AM模式,不需要UE反饋確認信息,至此,NB-IoT的一次上行數據報告流程結束。 NB-IoT的一次上行數據的報告流程包括5個NPDCCH調度周期,5個NPDCCH調度周期之和,即為一次上行數據報告的持續(xù)時間。 2.3 NB-IoT的上行容量 NB-IoT不支持測量報告,3GPP根據最小路徑損耗(MCL)的不同,定義了普通覆蓋、擴展覆蓋和極端覆蓋3個覆蓋等級,3個覆蓋等級對應的MCL分別是不高于144 dB、不高于154 dB和不高于164 dB,不同的覆蓋等級下,NPUSCH信道、NPDSCH信道、NPDCCH信道和NPRACH信道使用不同的MCS和/或重復次數。 在不同的覆蓋等級條件下,假設式(1)和式(3)中的各個參數取值如下: tNPDCCH、T:分別是NPDCCH的傳輸時間和NPDCCH的周期,在MCL為144、154、164 dB時,假設Rmax的取值分別是1、4、32,G的取值分別是8、8、4 ms,則對應的tNPDCCH分別是1、4、32 ms,對應的T=Rmax×G分別是8、32、128 ms。 tNPDSCH:NPDSCH的傳輸時間,占用NSF×NRep個下行子幀,假設NPDSCH的傳輸塊大小是20 B,折算為160 bit,對應的TBS尺寸是176 bit,在MCL為144、154、164 dB時,假設NSF取值分別是1、3、6,NRep取值分別是1、4、32;則在MCL為144、154、164 dB時,tNPDSCH分別是1、12、192 ms。 tNPDSCH1:格式1的NPUSCH的傳輸時間,該時間由NRepNRU 根據上行傳輸塊的大小,NRU取值分為2種情況,針對承載上行數據的NPUSCH信道,根據2.2節(jié),傳輸塊的大小是600 bit,在MCL為144、154、164 dB時,假設NRU的取值分別是3、6、10,對應的tNPUSCH1分別是24、192、2 560 ms;針對承載信令的NPUSCH信道,假設傳輸塊的大小是20 B,折算為160 bit,對應的TBS尺寸是176 bit,在MCL為144、154、164 dB時,假設NRU取值分別是1、3、6,對應的tNPUSCH1分別是8、96、1 536 ms。 tNPUSCH2:格式2的NPUSCH的傳輸時間,該時間由 t1:NPDCCH結束傳輸到NPDSCH開始傳輸的間隔時間,固定為4個下行子幀,即4 ms。 t2:NPDSCH結束到NPUSCH開始的間隔時間,在MCL為144、154、164 dB時,假設t2的取值均為12 ms。 t3、t5:UE發(fā)送NPUSCH后不監(jiān)聽NPDCCH的間隔時間,固定為3 ms。 t4:NPDCCH結束傳輸到NPUSCH開始傳輸的間隔時間,在MCL為144、154、164 dB時,假設t4的取值分別是8、16、32 ms。 根據上述條件,可以計算出在不同覆蓋等級下,NB-IoT UE發(fā)送1次上行數據的持續(xù)時間和1個子載波1天的上報次數如表2所示。 表2 NB-IoT在不同覆蓋等級下,1個子載波1天的上報次數
假設在MCL為144、154、164 dB時的用戶數的比例是4∶4∶2,則1個上行子載波(15 kHz)每天可以發(fā)送上行數據的次數為:675 000×40%+142 105×40%+ 12 500×20%=329 342次。 NB-IoT上行共計有12個帶寬為15 kHz的子載波,假設有3個子載波用于NPRACH信道,則用于NPUSCH信道的子載波數有9個;NPUSCH信道除了承載上行數據外,還要承載Attach請求、UE能力上報、鑒權和加密等信令開銷,假設業(yè)務和信令開銷的比例為8∶2;假設重傳率是10%,則1個小區(qū)1天可以發(fā)送上行數據的次數為:329 342×9×80%×(1-10%)=2 134 137次。 根據式(5),可知1個小區(qū)可以承載的用戶數為:2 134 137/11.2=190 548。 實際網絡的負荷不可能達到100%,網絡利用率為10%、25%、50%時,單小區(qū)可以承載的用戶數分別是19 055個、47 637個、95 274個。 3 結束語 由于目前處于NB-IoT網絡部署的初期階段,運營商還在持續(xù)的優(yōu)化NB-IoT網絡,上文給出的NB-IoT容量規(guī)劃的方法,很多參數是通過假設的方法得出的。隨著NB-IoT網絡的完善和用戶數的持續(xù)增長,運營商可以通過大數據手段收集NB-IoT用戶的上報頻率、安裝位置等數據,進而對重復次數等關鍵參數提出有針對性的優(yōu)化方案,再結合本文給出的容量規(guī)劃方法,可以更有效的指導NB-IoT網絡的容量規(guī)劃和網絡擴容。 參考文獻: [1] Physical Channels and Modulation:3GPP TS 36.211[S/OL]. [2017-12-22]. ftp://3gpp.org/Specs/. [2] Multiplexing and channel coding:3GPP TS 36.212[S/OL]. [2017-12-22]. ftp://3gpp.org/Specs/. [3] Physical layer procedures:3GPP TS 36.213[S/OL]. [2017-12-22]. ftp://3gpp.org/Specs/. [4] Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN);Overall description;Stage 2:3GPP TS 36.300[S/OL]. [2017-12-22]. ftp://3gpp.org/Specs/. [5] Evolved Universal Terrestrial Radio Access (E-UTRA);Medium Access Control (MAC) protocol specification:3GPP TS 36.321[S/OL]. [2017-12-22]. ftp://3gpp.org/Specs/. [6] Evolved Universal Terrestrial Radio Access (E-UTRA);Radio Link Control (RLC) protocol specification:3GPP TS 36.322[S/OL]. [2017-12-22]. ftp://3gpp.org/Specs/. [7] Evolved Universal Terrestrial Radio Access (E-UTRA);Packet Data Convergence Protocol (PDCP) specification:3GPP TS 36.323[S/OL]. [2017-12-22]. ftp://3gpp.org/Specs/. [8] Evolved Universal Terrestrial Radio Access (E-UTRA);Radio Resource Control (RRC);Protocol specification:3GPP TS 36.331[S/OL]. [2017-12-22]. ftp://3gpp.org/Specs/. [9] Technical Specification Group GSM/EDGE Radio Access Network;Cellular system support for ultra-low complexity and low throughput Internet of Things (CIoT):3GPP TR 45.820[S/OL]. [2017-12-22]. ftp://3gpp.org/Specs/. [10] 張建國. 中國移動NB-IoT部署策略研究[J]. 移動通信,2017,41(1):25-30. [11] 張建國,徐福永,楊東來. LTE-M關鍵技術研究[C]//面向5G的LTE網絡創(chuàng)新研討會(2016). 2016:163-167. [12] 戴博. 窄帶物聯(lián)網(NB-IoT)標準與關鍵技術[M]. 北京:人民郵電出版社,2016:53-54. [13] 5G Americas. LTE and 5G Technologies Enabling the Internet of Things.[EB/OL].[2017-12-22]. http://www.5gamericas.org/files/3514/8121/4832/Enabling_IoT_WP_12.8.16_FINAL.pdf [14] Evolved Universal Terrestrial Radio Access (E-UTRA);User Equipment (UE) procedures in idle mode:3GPP TS 36.304[S/OL]. [2017-12-22]. ftp://3gpp.org/Specs/. 作者簡介: 張建國,畢業(yè)于南京郵電學院,高級工程師,碩士,主要從事無線網絡的規(guī)劃和設計工作。 (中國集群通信網 | 責任編輯:李俊勇) |


個上行時隙,
為NPUSCH的重復次數,取值為1,2,4,8,16,32,64,128;






