一、概述
當(dāng)空口全部采用共享信道來并發(fā)承載業(yè)務(wù)時,信道已不是一份固定的物理資源,并且不同業(yè)務(wù)也會互相搶占資源。容量不是一個固定的取值,也無法直接與接入用戶數(shù)和阻塞率用顯性表達式來描述,不變的是業(yè)務(wù)層對QoS的要求,變化的是承載能力。本文擬對VoLTE的業(yè)務(wù)帶寬計算及其空口承載能力做一個較為系統(tǒng)性的闡述。
二、語音帶寬計算
1、業(yè)務(wù)層帶寬
語音采用AMR編碼(幀格式)在網(wǎng)絡(luò)中傳輸,規(guī)范定義兩種類型的幀格式:AMR IF1 和 AMR IF2,由于IF2相比IF1減少了重復(fù)的Frame Quality Indicator, Mode Indication, Mode Request 和CRC 校驗,因此ITU-T的H系列建議中通常使用IF2,3GPP則在TS 26.201和TS 26.101進一步明確了AMR-WB和AMR-NB在無線網(wǎng)絡(luò)中的使用要求。

注*:為語音數(shù)據(jù),即Class A/B/C比特數(shù),如477bit=23.85kbps*20ms。
注**:AMR幀中數(shù)據(jù)的長度并不是字節(jié)(8bit)的整數(shù)倍,所以在有些幀的末尾需要增加bit填充,以使整個幀的長度達到字節(jié)的整數(shù)倍。
2、IP層帶寬

表2 AMR帶寬計算
*:上述單位均為bit或kbps。
說明1:語音包大小=N*8;IP+UDP+RTP頭共60Byte,RoHC壓縮為4Byte(PDCP和RLC層SN大小分別為12bit和10bit,若采用7bit和5bit可壓縮為3Byte),假設(shè)語音靜默比為0.5,PDCP+RLC+MAC頭共6Byte。
說明2:上表應(yīng)用到的計算公式。
單個語音業(yè)務(wù)占用帶寬 = (1秒內(nèi)的靜默幀bit數(shù)+1秒內(nèi)的語音幀比特數(shù))/1024 kbps
1秒內(nèi)的靜默幀比特數(shù)=(靜默幀大小+IP/UDP/RTP頭)*1秒的最大靜默幀個數(shù)*靜默比*8
1秒內(nèi)的語音幀比特數(shù)=(語音幀大小+IP/UDP/RTP頭)*1秒的最大語音幀個數(shù)*(1-靜默比)*8
1秒的最大靜默幀個數(shù) =1000ms/160ms 其中160ms為靜默幀的周期
1秒的最大語音幀個數(shù) =1000ms/20ms 其中20ms為語音幀的周期
說明3:從上表也能看到RoHC的壓縮效率可達50%以上,因此在VoLTE網(wǎng)絡(luò)中開啟RoHC功能具有非常積極的意義。
從表2可以看到,AMR-WB23.85的最大IP層RTP帶寬為47.27kbps,AMR-WB12.65的最大IP層RTP帶寬為36.33kbps,在實際參數(shù)(b=AS)配置時通常取整數(shù)值48kbps和37kbps。
而在配置專用承載(DBR)的帶寬時,還要考慮RTCP的帶寬,即DRB GBR =RTP帶寬+RTCP帶寬,其中RTP帶寬由“m=audio”下的“b=AS”參數(shù)得到,而RTCP帶寬計算略微復(fù)雜,具體如下:
· 如果b=RS和b=RR參數(shù)存在,那么UL和DL的RTCP帶寬 = (bRS +bRR)/1000。
· 如果沒有b=RS或者b=RR參數(shù),那么UL和DL的RTCP帶寬 =MAX[0.05*bAS, bRS/1000或者bRR/1000]。
· 如果b=RS或者b=RR都不存在,那么UL和DL的RTCP帶寬 = 0.05*bAS。
表3 專載帶寬計算

3、MAC層帶寬
語音IP包要在空口傳輸還需要經(jīng)過層二DPCP層、RLC和MAC層的SDU和PDU的轉(zhuǎn)換,增加了約6Byte的包頭開銷。

表4 Type0下傳輸效率計算
上表假設(shè)PRB數(shù)總為4個,采用不同的MCS等級來提供不同的TB塊,可以看到包頭壓縮即使在多個分段之后,也能提供較高的數(shù)據(jù)傳輸效率,但在RLC分段數(shù)超過4個,傳輸效率有一個明顯的下跳,故而在網(wǎng)絡(luò)中應(yīng)該控制RLC分段數(shù)在4個以內(nèi),以保證較好的傳輸效率。
當(dāng)信道質(zhì)量嚴重惡化,如SINR低于-3dB時,CQI約為3,采用的MCS Index為1,對應(yīng)的TBS Index為1。對于AMR-WB23.85當(dāng)未采用RoHC時,為傳輸TBS=1016bit的MAC層傳輸塊(TB),需要占用不低于29個PRB的資源,即需要32個PRB。而同等情況下,采用RoHC時,僅需要16個PRB。那么考慮UL1:DL3配置時的上行鏈路,一個10ms無線幀僅能提供176個PRB,未采用RoHC時,當(dāng)接入用戶數(shù)超過10個時,RTP時延將開始增大,語音MOS開始變差。
三、視頻帶寬計算
視頻的東西太復(fù)雜也比較亂,反正就是各種不兼容,要講清楚不容易。這里談一談帶寬相關(guān)的問題,聚焦于視頻的傳輸格式。
H.264是ISO和ITU在MPEG-4技術(shù)的基礎(chǔ)之上共同提出的數(shù)字視頻編碼標準,又稱為MPEG-4 AVC,具有高圖像質(zhì)量和高壓縮效率的特點。
為滿足不同應(yīng)用對圖像質(zhì)量和計算復(fù)雜度的不同要求,H.264定義了21 套的能力,被稱為配置文件(Profile),表5是常用的4種Profile,每個profile支持一組特定的算法特征和限制的子集,任何遵守某個profile 的解碼器都應(yīng)該支持與其相應(yīng)的子集。

表5 常用的視頻配置文件

為進一步說明給定profile下,對解碼器的處理能力和內(nèi)存容量的要求,定義了等級(Level)的概念對應(yīng)到一組參數(shù)(如取樣速率、圖像尺寸、編碼比特率等),標準中采用語法成員(syntax element)來描述各種參數(shù)值的限制。

表6 常見的視頻等級
· 如何根據(jù)分辨率計算幀率和等級
以720p視頻為例,
(1)協(xié)議規(guī)定宏塊尺寸是16x16bit => 水平宏塊數(shù)=1280/16=80,垂直宏塊數(shù)=720/16=45
(2)每幀宏塊數(shù)=80*45=3600
(3)若幀率為30,每秒最大宏塊數(shù)=3600*30=108000
(4)參考表6,等級3.1可提供該能力。
· 如何計算最大存儲幀數(shù)
· 協(xié)議定義了在不同的級別(Level)下,最大的解碼圖片緩存區(qū)宏塊數(shù)(MaxDpbMbs),以等級為3.1的720p視頻為例,最大的解碼圖片緩存區(qū)宏塊數(shù)為18000,最大存儲幀數(shù)為5(見表6最后一列的括號中取值)。計算公式如下:
· 最大存儲幀數(shù)=min(floor(MaxDpbMbs/ (水平宏塊數(shù) * 垂直宏塊數(shù))), 16)

表7 常見視頻格式的主要參數(shù)和帶寬
假設(shè)網(wǎng)絡(luò)配置為UL1:DL3, PUCCH占用12個PRB,對于720p視頻而言,上行每TTI傳輸?shù)?/span>TBS=10880,當(dāng)MCS低于8時將無法承載,對應(yīng)要求下行的SINR應(yīng)當(dāng)高于3dB,因此對于TDD網(wǎng)絡(luò)而言很難承載720p視頻業(yè)務(wù)。
下面我們來看一個實例
m=video 60010 RTP/AVP 113 114
b=AS:882
b=RS:8000
b=RR:6000
a=rtpmap:113 H264/90000
a=fmtp:113profile-level-id=42C016;packetization-mode=1;sar-understood=16;sar-supported=1;sprop-parameter-sets=Z0LAFtoHgUaAbQoTUA==,aM4G4g==
這是一個采用H264的視頻媒體,時鐘頻率為90000,RTP帶寬為882kbps,RTCP帶寬為14kbps。
· packetization-mode=1
表示支持的封包模式.
當(dāng) packetization-mode 的值為 0 時或不存在時, 必須使用單一 NALU 單元模式.
當(dāng) packetization-mode 的值為 1 時必須使用非交錯(non-interleaved)封包模式.
當(dāng) packetization-mode 的值為 2 時必須使用交錯(interleaved)封包模式.
· profile-level-id=42C016
[PROFILE IDC]=0x42,即為BP的畫質(zhì)。注:0x42=BP,0x4D=MP,0x64=HP
[PROFILE IOP]=0xC0,即編碼器的NALU執(zhí)行BP、EP和MP所有約束
[LEVEL IDC]=0x16,即level=2.2
四、總結(jié)
對于語音業(yè)務(wù),IP層的GBR帶寬設(shè)置分別為51kbps@AMR-WB23.85和39kbps@AMR-WB12.65,RoHC的使用可以顯著提高傳輸?shù)男,即使?/span>RLC層做小于4個的分段,也能保證高于50%的傳輸效率。由于分段個數(shù)與資源數(shù)量和無線環(huán)境有關(guān),同樣的語音業(yè)務(wù)表現(xiàn)在MAC層上的速率將是一個變化值。在網(wǎng)絡(luò)運維中,可以通過統(tǒng)計每DPCP層包的bit數(shù)是否超過1000來判斷上下行是否開啟RoHC。
對于視頻業(yè)務(wù),最重要的參數(shù)有配置和級別,尤其是級別所定義的參數(shù)與視頻的帶寬密切相關(guān)。對于目前TDD網(wǎng)絡(luò)的配置而言,難以承載720p業(yè)務(wù),建議承載Level值為2.2的VGA業(yè)務(wù)。