主頁（http://www.by236.com）：NB-IoT容量規(guī)劃研究 0 引言 NB-IoT在幀結(jié)構(gòu)、時隙結(jié)構(gòu)、物理信道、數(shù)據(jù)傳輸過程等方面與傳統(tǒng)的LTE網(wǎng)絡(luò)都有較大的差別，為了增強下行和上行覆蓋，NB-IoT的NPDCCH、NPDSCH、NPUSCH、NPRACH等物理信道可以根據(jù)覆蓋等級進行多次傳輸，同時NPDCCH和NPDSCH在不同的子幀進行傳輸，NB-IoT需要采用與LTE完全不同的容量規(guī)劃方法。本文接下來分析NB-IoT的下行數(shù)據(jù)傳輸進程和下行峰值速率以及上行數(shù)據(jù)傳輸進程和上行峰值速率，然后分析NB-IoT用戶的業(yè)務(wù)模型和NB-IoT上行數(shù)據(jù)報告流程，最后給出NB-IoT容量規(guī)劃的方法。 1 NB-IoT數(shù)據(jù)傳輸進程 由于NB-IoT終端的成本低、處理能力弱，3GPP協(xié)議規(guī)定，NB-IoT的UE只能進行單進程傳輸，即某一個時刻只有1個進程傳輸下行數(shù)據(jù)或者上行數(shù)據(jù)。 1.1 NB-IoT下行數(shù)據(jù)傳輸進程 NB-IoT的下行數(shù)據(jù)傳輸進程如圖1所示，eNodeB通過NPDCCH信道發(fā)送DCI格式N1的調(diào)度消息給UE，通知UE接收下行數(shù)據(jù)，經(jīng)過t1時間后，eNodeB通過NPDSCH信道發(fā)送下行數(shù)據(jù)給UE，UE接收NPDSCH信道并解碼出下行數(shù)據(jù)后，經(jīng)過t2時間，UE通過格式2的NUPSCH信道發(fā)送UL A/N消息給eNodeB，通知eNodeB是否正確接收下行數(shù)據(jù)，UE發(fā)送UL A/N消息后的t3時間內(nèi)，UE不監(jiān)聽NPDCCH信道，同時下一個NPDCCH信道的發(fā)送時刻需滿足：
圖1 NB-IoT下行數(shù)據(jù)傳輸進程
NB-IoT的1次下行數(shù)據(jù)傳輸進程的持續(xù)時間為：
式中： tNPDCCH——NPDCCH的傳輸時間，NPDCCH最多使用Rmax個下行子幀，Rmax在1到2 048之間共有12個取值 t1——NPDCCH結(jié)束傳輸?shù)絅PDSCH開始傳輸?shù)拈g隔時間，固定為4個下行子幀，即4 ms tNPDSCH——NPDSCH的傳輸時間，占用NSF×NRep個下行子幀，其中NSF為1個NPDSCH（對應(yīng)1個下行傳輸塊）占用的下行子幀數(shù)，取值為1，2，3，4，5，6，8，10，NSF由傳輸?shù)臄?shù)據(jù)塊大小和調(diào)制方式共同決定，該值越大，信道編碼速率越低，編碼增益就越大；NRep為NPDSCH的重復(fù)次數(shù)，在1到2048之間共有16種取值 t2——NPDSCH傳輸結(jié)束到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］。 上述參數(shù)中的Rmax、NRep、 NB-IoT的下行速率計算公式如下： NB-IoT的下行速率=TBS/T2 （2） 假設(shè)Rmax=1，G=8 ms，則T=Rmax×G=8 ms，下行傳輸塊取最大值，TBS=680 bit，此時NSF=3，則式（1）中各個參數(shù)取值如下時，NB-IoT下行數(shù)據(jù)傳輸時間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開始時間應(yīng)大于25 ms，且為T=8 ms的整數(shù)倍，即T2=32 ms，因此可以計算出NB-IoT的下行峰值速率為680 bit/32 ms=21.25 kbit/s。 1.2 NB-IoT上行數(shù)據(jù)傳輸進程 NB-IoT的上行數(shù)據(jù)傳輸進程如圖2所示，eNodeB通過NPDCCH信道發(fā)送DCI格式N0的調(diào)度消息給UE，通知UE發(fā)送上行數(shù)據(jù)，經(jīng)過t4時間后，UE通過格式1的NPUSCH信道發(fā)送上行數(shù)據(jù)給eNodeB，UE發(fā)送NPUSCH數(shù)據(jù)后的t5時間內(nèi)，不監(jiān)聽NPDCCH信道，eNodeB接收NPUSCH信道并解碼出上行數(shù)據(jù)后，在滿足（10nf+ns2）modT=αoffset·T]的時刻，通過NPDCCH信道里面的新數(shù)據(jù)指示信息，通知UE發(fā)送新的上行數(shù)據(jù)或重傳上行數(shù)據(jù)。
NB-IoT的1次上行數(shù)據(jù)傳輸進程的持續(xù)時間為： T3=tNPDCCH+t4+tNPUSCH1+t5 （3） 式中： tNPDCCH——NPDCCH的傳輸時間 t4——NPDCCH結(jié)束傳輸?shù)絅PUSCH開始傳輸?shù)拈g隔時間，占用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） 假設(shè)Rmax=1，G=8 ms，則T=Rmax×G=8 ms，上行傳輸塊取最大值，TBS=1 000 bit，此時NRU=4，則分配給UE不同的子載波數(shù)時NB-IoT的上行峰值速率如表1所示。 表1 NB-IoT上行峰值速率
2 NB-IoT容量規(guī)劃 NB-IoT業(yè)務(wù)的應(yīng)用場景包括智能抄表、智能停車、智慧農(nóng)業(yè)、海綿城市等，這些應(yīng)用主要以傳輸上行數(shù)據(jù)為主，對傳輸下行數(shù)據(jù)無要求，因此本文的NB-IoT容量規(guī)劃主要考慮上行容量。 上行子載波帶寬有15和3.75 kHz 2種，參考文獻［10］建議上行子載波帶寬選擇15 kHz，本文按照上行子載波帶寬為15 kHz來計算上行容量，為了簡化起見，假定每個用戶只分配1個上行子載波。 2.1 NB-IoT用戶的業(yè)務(wù)模型 除了系統(tǒng)開銷外，NB-IoT的上行業(yè)務(wù)主要由兩部分組成，分別是MAR（Mobile Autonomous Reporting）例外報告、MAR周期性報告。 MAR例外報告的應(yīng)用包括煙霧告警、智能儀表的電力中斷通知、非法修改通知等，該類應(yīng)用基于事件報告機制，只有監(jiān)測到某個特定事件發(fā)生后才發(fā)送一次上行數(shù)據(jù)，該類事件通常是非常稀少的，幾個月或者數(shù)年才發(fā)生一次，因此流量很低，對NB-IoT網(wǎng)絡(luò)的容量規(guī)劃影響可以忽略不計，本文暫不考慮這部分流量。 MAR周期性報告的應(yīng)用包括智能抄表（煤氣、水表、電表）、智慧農(nóng)業(yè)、智能停車、智慧環(huán)境等，該類應(yīng)用周期性的向應(yīng)用服務(wù)器發(fā)送上行數(shù)據(jù)，發(fā)送周期為半小時、數(shù)小時或者數(shù)天，NB-IoT的上行流量以MAR周期性報告為主。 根據(jù)3GPP 45.820協(xié)議［9］，MAR周期性報告的業(yè)務(wù)模型如下： 應(yīng)用層的負(fù)荷：假定應(yīng)用層的負(fù)荷的大小服從于帕累托分布，k=2.5，最小的應(yīng)用層負(fù)荷xmin=20 B，最大的應(yīng)用層負(fù)荷為200 B，負(fù)荷高于200 B時被認(rèn)為是200 B，根據(jù)該模型，可知應(yīng)用層負(fù)荷的平均值為xmin×k/（k-1）=34 B，95%的負(fù)荷低于64 B。 傳輸層的負(fù)荷：根據(jù)3GPP 36.321、36.322、36.323，MAC層的頭開銷是2 B、RLC層的頭開銷是4 B、PDCP層的頭開銷是1 B，IP頭采用壓縮模式的頭開銷是4 B，則傳輸層的負(fù)荷是64+2+4+1+4=75 B，折算為600 bit［5-7］。 上報周期：上報周期為1天的占比為40%，上報周期為2 h的占比為40%，上報周期為1 h的占比為15%，上報周期為30 min的占比為5%。 假設(shè)1個小區(qū)內(nèi)的用戶數(shù)是NMS，則一天內(nèi)產(chǎn)生的上行報告次數(shù)是： NReport=NMS×（40%×1+40%×12+15%×24+5%×48）=NMS×11.2 （5） 2.2 NB-IoT上行數(shù)據(jù)的報告流程 NB-IoT的業(yè)務(wù)以小的數(shù)據(jù)包為主，為了降低信令開銷，3GPP定義了2種信令優(yōu)化方案，分別是控制面（CP）CIoT EPS優(yōu)化方案和用戶面（UP）CIoT EPS優(yōu)化方案［4］。 采用CP CIoT EPS優(yōu)化方案時，NB-IoT的UE并不需要與eNodeB建立數(shù)據(jù)無線承載（DRB），只通過信令無線承載（SRB）即可以傳輸數(shù)據(jù)。 采用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上下文信息即可恢復(fù)RRC連接，因此省去了Attach請求、UE能力上報、鑒權(quán)和加密等過程，節(jié)省了信令開銷。 采用UP CIoT EPS優(yōu)化方案時，NB-IoT上行數(shù)據(jù)的報告流程如圖3所示。
圖3 NB-IoT上行數(shù)據(jù)的報告流程 UE需要發(fā)送上行數(shù)據(jù)給應(yīng)用服務(wù)器時，首先通過NPRACH信道發(fā)送Random Access Preamble給eNodeB；eNodeB發(fā)送Random Access Response消息給UE，該消息包含了對NPUSCH信道的上行調(diào)度信息；UE發(fā)送RRC Connection Resume Request消息給eNodeB，該消息包含了Resume原因、Resume ID、shortResumeMAC-I等信息，請求恢復(fù)RRC連接；eNodeB發(fā)送RRC Connection Resume消息給UE，該消息包含了專用的無線資源配置信息；UE發(fā)送RRC Connection Resume Complet消息給eNodeB，該消息包含了可選的PLMN標(biāo)識和可選的NAS數(shù)據(jù)；UE發(fā)送上行數(shù)據(jù)給eNodeB；eNodeB發(fā)送RRC Connection Release消息給UE，該消息屬于RLC AM模式，不需要UE反饋確認(rèn)信息，至此，NB-IoT的一次上行數(shù)據(jù)報告流程結(jié)束。 NB-IoT的一次上行數(shù)據(jù)的報告流程包括5個NPDCCH調(diào)度周期，5個NPDCCH調(diào)度周期之和，即為一次上行數(shù)據(jù)報告的持續(xù)時間。 2.3 NB-IoT的上行容量 NB-IoT不支持測量報告，3GPP根據(jù)最小路徑損耗（MCL）的不同，定義了普通覆蓋、擴展覆蓋和極端覆蓋3個覆蓋等級，3個覆蓋等級對應(yīng)的MCL分別是不高于144 dB、不高于154 dB和不高于164 dB，不同的覆蓋等級下，NPUSCH信道、NPDSCH信道、NPDCCH信道和NPRACH信道使用不同的MCS和/或重復(fù)次數(shù)。 在不同的覆蓋等級條件下，假設(shè)式（1）和式（3）中的各個參數(shù)取值如下： tNPDCCH、T：分別是NPDCCH的傳輸時間和NPDCCH的周期，在MCL為144、154、164 dB時，假設(shè)Rmax的取值分別是1、4、32，G的取值分別是8、8、4 ms，則對應(yīng)的tNPDCCH分別是1、4、32 ms，對應(yīng)的T=Rmax×G分別是8、32、128 ms。 tNPDSCH：NPDSCH的傳輸時間，占用NSF×NRep個下行子幀，假設(shè)NPDSCH的傳輸塊大小是20 B，折算為160 bit，對應(yīng)的TBS尺寸是176 bit，在MCL為144、154、164 dB時，假設(shè)NSF取值分別是1、3、6，NRep取值分別是1、4、32；則在MCL為144、154、164 dB時，tNPDSCH分別是1、12、192 ms。 tNPDSCH1：格式1的NPUSCH的傳輸時間，該時間由NRepNRU 根據(jù)上行傳輸塊的大小，NRU取值分為2種情況，針對承載上行數(shù)據(jù)的NPUSCH信道，根據(jù)2.2節(jié)，傳輸塊的大小是600 bit，在MCL為144、154、164 dB時，假設(shè)NRU的取值分別是3、6、10，對應(yīng)的tNPUSCH1分別是24、192、2 560 ms；針對承載信令的NPUSCH信道，假設(shè)傳輸塊的大小是20 B，折算為160 bit，對應(yīng)的TBS尺寸是176 bit，在MCL為144、154、164 dB時，假設(shè)NRU取值分別是1、3、6，對應(yīng)的tNPUSCH1分別是8、96、1 536 ms。 tNPUSCH2：格式2的NPUSCH的傳輸時間，該時間由 t1：NPDCCH結(jié)束傳輸?shù)絅PDSCH開始傳輸?shù)拈g隔時間，固定為4個下行子幀，即4 ms。 t2：NPDSCH結(jié)束到NPUSCH開始的間隔時間，在MCL為144、154、164 dB時，假設(shè)t2的取值均為12 ms。 t3、t5：UE發(fā)送NPUSCH后不監(jiān)聽NPDCCH的間隔時間，固定為3 ms。 t4：NPDCCH結(jié)束傳輸?shù)絅PUSCH開始傳輸?shù)拈g隔時間，在MCL為144、154、164 dB時，假設(shè)t4的取值分別是8、16、32 ms。 根據(jù)上述條件，可以計算出在不同覆蓋等級下，NB-IoT UE發(fā)送1次上行數(shù)據(jù)的持續(xù)時間和1個子載波1天的上報次數(shù)如表2所示。 表2 NB-IoT在不同覆蓋等級下，1個子載波1天的上報次數(shù)
假設(shè)在MCL為144、154、164 dB時的用戶數(shù)的比例是4∶4∶2，則1個上行子載波（15 kHz）每天可以發(fā)送上行數(shù)據(jù)的次數(shù)為：675 000×40%+142 105×40%+ 12 500×20%=329 342次。 NB-IoT上行共計有12個帶寬為15 kHz的子載波，假設(shè)有3個子載波用于NPRACH信道，則用于NPUSCH信道的子載波數(shù)有9個；NPUSCH信道除了承載上行數(shù)據(jù)外，還要承載Attach請求、UE能力上報、鑒權(quán)和加密等信令開銷，假設(shè)業(yè)務(wù)和信令開銷的比例為8∶2；假設(shè)重傳率是10%，則1個小區(qū)1天可以發(fā)送上行數(shù)據(jù)的次數(shù)為：329 342×9×80%×（1-10%）=2 134 137次。 根據(jù)式（5），可知1個小區(qū)可以承載的用戶數(shù)為：2 134 137/11.2=190 548。 實際網(wǎng)絡(luò)的負(fù)荷不可能達到100%，網(wǎng)絡(luò)利用率為10%、25%、50%時，單小區(qū)可以承載的用戶數(shù)分別是19 055個、47 637個、95 274個。 3 結(jié)束語 由于目前處于NB-IoT網(wǎng)絡(luò)部署的初期階段，運營商還在持續(xù)的優(yōu)化NB-IoT網(wǎng)絡(luò)，上文給出的NB-IoT容量規(guī)劃的方法，很多參數(shù)是通過假設(shè)的方法得出的。隨著NB-IoT網(wǎng)絡(luò)的完善和用戶數(shù)的持續(xù)增長，運營商可以通過大數(shù)據(jù)手段收集NB-IoT用戶的上報頻率、安裝位置等數(shù)據(jù)，進而對重復(fù)次數(shù)等關(guān)鍵參數(shù)提出有針對性的優(yōu)化方案，再結(jié)合本文給出的容量規(guī)劃方法，可以更有效的指導(dǎo)NB-IoT網(wǎng)絡(luò)的容量規(guī)劃和網(wǎng)絡(luò)擴容。 參考文獻： ［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關(guān)鍵技術(shù)研究［C］//面向5G的LTE網(wǎng)絡(luò)創(chuàng)新研討會（2016）. 2016：163-167. ［12］ 戴博. 窄帶物聯(lián)網(wǎng)（NB-IoT）標(biāo)準(zhǔn)與關(guān)鍵技術(shù)［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è)于南京郵電學(xué)院，高級工程師，碩士，主要從事無線網(wǎng)絡(luò)的規(guī)劃和設(shè)計工作。 (中國集群通信網(wǎng) | 責(zé)任編輯：李俊勇) |
（1）
個上行時隙，
為NPUSCH的重復(fù)次數(shù)，取值為1，2，4，8，16，32，64，128；
為上行資源單元（RU）占用的時隙數(shù)，取值為4，上行子載波帶寬為15 kHz時，上行時隙長為0.5 ms，
