5G的回傳帶寬該怎么算？

本文來源：無線深海

我們通過無線網(wǎng)絡(luò)上網(wǎng)時(shí)，手機(jī)發(fā)出的信號需要穿越基站，承載網(wǎng)，到達(dá)核心網(wǎng)，與此同時(shí)，核心網(wǎng)發(fā)出的數(shù)據(jù)也需要穿越承載網(wǎng)跟基站，才能到達(dá)手機(jī)，從而完成生命的大和諧。

那么，從服務(wù)于多個(gè)用戶的基站到核心網(wǎng)之間，到底需要多大的帶寬呢？這就涉及到回傳帶寬的估算問題。

其實(shí)原本回傳帶寬的算法并不區(qū)分4G和5G，但考慮到5G的架構(gòu)還包括前傳和中傳，因此在第一部分先做個(gè)總體

什么是回傳？

話說5G的網(wǎng)絡(luò)架構(gòu)，最廣為流傳的，莫過于下圖中的AAU，DU，CU加核心網(wǎng)的標(biāo)準(zhǔn)結(jié)構(gòu)了。

圖片來自公眾號“鮮棗課堂”

AAU：Active Antenna Unit，有源天線單元，是RRU跟天線的合體；

DU：Distributed Unit，分布式單元，原4G的BBU拆分出需要實(shí)時(shí)處理的部分，一般隨AAU一起在站點(diǎn)部署；

CU：Centralized Unit，集中式單元，原4G的BBU拆分出非實(shí)時(shí)處理的部分，一般認(rèn)為應(yīng)該集中式部署，可管理多個(gè)DU；

雖說架構(gòu)如此，在實(shí)際的5G網(wǎng)絡(luò)部署中，暫時(shí)沒有強(qiáng)烈的網(wǎng)元拆分的動(dòng)力，DU和CU基本都是合一部署的。這種情況下，DU加CU還是叫做BBU。

由于CU和DU合一部署為BBU，它們之間的傳輸就成為了內(nèi)部接口。因此大家最關(guān)注的，還是BBU與核心網(wǎng)之間的傳輸：回傳。

實(shí)現(xiàn)回傳網(wǎng)絡(luò)相關(guān)的技術(shù)都已經(jīng)非常成熟了。在一般的網(wǎng)絡(luò)規(guī)劃中，無線側(cè)必須要傳遞給承載一個(gè)關(guān)鍵數(shù)據(jù)：

5G站到底需要多大回傳帶寬？

回傳帶寬怎么算？

假設(shè)采用5ms單周期，100M帶寬的小區(qū)理論峰值速率可達(dá)7.2Gbps，一個(gè)站一般有3個(gè)小區(qū)。是否應(yīng)該給承載網(wǎng)傳遞如下信息：一個(gè)5G基站需要至少21.6Gbps的帶寬？

當(dāng)然，如果按照這個(gè)值來建網(wǎng)的話，網(wǎng)絡(luò)運(yùn)轉(zhuǎn)肯定是沒問題的，但想想還是有些浪費(fèi)：一個(gè)基站下的小區(qū)在每時(shí)每刻都能達(dá)到峰值嗎？除了凈荷之外，還有各種包頭，操作維護(hù)的開銷都考慮到了嗎？

其實(shí)，在真實(shí)網(wǎng)絡(luò)中，基站覆蓋一片區(qū)域，用戶有的近有的遠(yuǎn)，信號有的好有的壞，也并非所有用戶都在鉚足了勁下載，多數(shù)還是聊微信刷微博，所以達(dá)到小區(qū)峰值速率是不可能的，最終下來就是一個(gè)平均速率。

關(guān)于這個(gè)小區(qū)平均速率，需要通過仿真得出平均頻譜效率，再乘以實(shí)際的小區(qū)帶寬，就可以得出小區(qū)的平均速率。

比方說，如果我們?nèi)?G的平均頻譜效率為10比特每秒每赫茲，在100M帶寬下，一個(gè)小區(qū)的平均速率就是1Gbps。

綜上，平均速率再加上10%的開銷，一個(gè)三小區(qū)站點(diǎn)需要的平均回傳帶寬為3.3Gbps。

雖說平均速率一般可保證站點(diǎn)運(yùn)行無虞，但保不齊可能在某個(gè)時(shí)刻爆發(fā)，從而突破這個(gè)平均值。因此我們也還是需要考慮下峰值的。

因此，業(yè)界一般把（1x小區(qū)峰值 + 2x小區(qū)均值）x110%作為整個(gè)站點(diǎn)的峰值。俗稱“一峰加兩均”，其中的110%就是考慮了10%的開銷。

因此，一個(gè)三扇區(qū)的100M帶寬5G站點(diǎn)，所需的峰值回傳帶寬為（1x7.2Gbps + 2x1Gbps）x110% = 10.12Gbps。

在實(shí)際部署時(shí)，站點(diǎn)的回傳帶寬在必須要大于均值，按照峰值來設(shè)計(jì)峰值當(dāng)然最好。

C-RAN情況下呢？

按理說這個(gè)問題到此就該結(jié)束了，但由于5G網(wǎng)絡(luò)架構(gòu)的多樣性及演進(jìn)的考慮，一種叫做C-RAN的架構(gòu)經(jīng)?？梢砸姷健?

其實(shí)C-RAN的全稱是Centralized RAN，也就是BBU的集中式部署（因此也叫做BBU Pool），雖然這個(gè)縮寫也可被解讀為Cloud RAN，但目前距離無線網(wǎng)絡(luò)的云化尚有較遠(yuǎn)的路要走，我們還是按照BBU集中來假設(shè)。

在這種情況下，這些集中起來部署的BBU，到底需要多少帶寬的回傳資源呢？把各個(gè)BBU的帶寬加起來就行了！

跟前面的思路類似，可以每4個(gè)BBU作為一個(gè)組，其中1個(gè)BBU的回傳按照峰值算，另外3個(gè)BBU的回傳按照均值算。一個(gè)C-RAN站點(diǎn)需要的回傳帶寬，把多個(gè)這樣的組加起來就可以了。

如此一來，平均下來每個(gè)BBU能分到的帶寬稍多于其平均帶寬。如果有的站點(diǎn)話務(wù)突發(fā)怎么辦？因?yàn)樗蠦BU是共享總的傳輸帶寬的，話務(wù)有的高有的低，總體還是趨向于平均值。

綜上，建網(wǎng)是要考慮成本和收益的，回傳帶寬，夠用就行。

~END~

免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場，如有問題，請聯(lián)系我們，謝謝！