有線寬帶業(yè)務(wù)發(fā)展對(duì)運(yùn)營商IP承載網(wǎng)絡(luò)演進(jìn)的影響

唐利莉，聶明，張寧

（中國移動(dòng)通信集團(tuán)設(shè)計(jì)院有限公司，北京100080）

有線寬帶業(yè)務(wù)發(fā)展對(duì)運(yùn)營商IP承載網(wǎng)絡(luò)演進(jìn)的影響

唐利莉，聶明，張寧

（中國移動(dòng)通信集團(tuán)設(shè)計(jì)院有限公司，北京100080）

隨著有線寬帶業(yè)務(wù)的發(fā)展，以視頻為主的有線寬帶業(yè)務(wù)對(duì)網(wǎng)絡(luò)承載能力提出了新的要求。分析了有線寬帶業(yè)務(wù)流量疏導(dǎo)對(duì)帶寬和網(wǎng)絡(luò)質(zhì)量的需求，從多播技術(shù)應(yīng)用，BRAS、CDN部署方式，骨干網(wǎng)架構(gòu)演進(jìn)等多個(gè)角度，提出了可行的網(wǎng)絡(luò)演進(jìn)方案。

有線寬帶業(yè)務(wù)；視頻業(yè)務(wù)；網(wǎng)絡(luò)扁平化；多播技術(shù)；內(nèi)容源下沉

1 引言

隨著互聯(lián)網(wǎng)業(yè)務(wù)的進(jìn)一步發(fā)展，有線寬帶業(yè)務(wù)作為家庭數(shù)據(jù)化應(yīng)用的第一入口，各運(yùn)營商之間的競(jìng)爭(zhēng)越發(fā)激烈。同時(shí)，隨著Web 1.0向Web 2.0的發(fā)展，用戶行為發(fā)生變化，互聯(lián)網(wǎng)總流量中的在線視頻流量已經(jīng)超過70%；互聯(lián)網(wǎng)正在成為視頻的互聯(lián)網(wǎng)，視頻體驗(yàn)成為互聯(lián)網(wǎng)的主要體驗(yàn)。

為適應(yīng)有線寬帶用戶的業(yè)務(wù)發(fā)展需求，運(yùn)營商需要在接入網(wǎng)、骨干網(wǎng)、內(nèi)容源等方面采取相應(yīng)舉措。

1.1 寬帶用戶的網(wǎng)絡(luò)帶寬需求

隨著國家“三網(wǎng)融合”“寬帶中國”等戰(zhàn)略的實(shí)施，部分區(qū)域已經(jīng)出現(xiàn)了有線寬帶對(duì)有線電視業(yè)務(wù)的替代效應(yīng)。視頻直播、點(diǎn)播業(yè)務(wù)所占帶寬已成為用戶帶寬的主要部分。特別是在4K視頻發(fā)展方面，由于FTTH（fiber to the home，光纖到戶）的帶寬優(yōu)勢(shì)，網(wǎng)絡(luò)運(yùn)營商對(duì)此寄予了較高期望。根據(jù)IHS預(yù)測(cè)，截至2016年年底，中國4K電視滲透率接近10%，達(dá)到4 000萬臺(tái)，預(yù)計(jì)大量用戶將通過有線寬帶使用4K直播、4K點(diǎn)播業(yè)務(wù)，從而對(duì)運(yùn)營商網(wǎng)絡(luò)提出較高的網(wǎng)絡(luò)帶寬要求。

某運(yùn)營商預(yù)測(cè)有線寬帶用戶的平均使用速率將從目前的0.7 Mbit/s/用戶增長到5.5 Mbit/s/用戶，其中視頻直播業(yè)務(wù)所占帶寬將達(dá)到 1/2以上，具體預(yù)測(cè)過程見表1。

表1 某運(yùn)營商有線寬帶用戶平均速率預(yù)測(cè)

1.2 寬帶用戶的網(wǎng)絡(luò)質(zhì)量需求

在Web 1.0階段，用戶關(guān)注的主要是網(wǎng)頁首頁打開時(shí)間、下載速率等指標(biāo)。隨著Web 2.0的發(fā)展，視頻占互聯(lián)網(wǎng)流量的 70%以上，視頻業(yè)務(wù)質(zhì)量成為用戶直觀地評(píng)價(jià)網(wǎng)絡(luò)質(zhì)量的標(biāo)尺。

根據(jù)ITU-T Y.1541，承載在IP網(wǎng)絡(luò)上的視頻、交互類業(yè)務(wù)的服務(wù)質(zhì)量要求見表2。

表2 視頻、交互類業(yè)務(wù)服務(wù)質(zhì)量要求

同時(shí)，針對(duì)4K業(yè)務(wù)快速發(fā)展的新局面，經(jīng)過大量的調(diào)查分析發(fā)現(xiàn)，視頻源質(zhì)量、視頻加載速度、視頻觀看體驗(yàn)是影響客戶體驗(yàn)的關(guān)鍵因素。其中，視頻源質(zhì)量包括內(nèi)容的碼率（4K、高清、標(biāo)清），主要受網(wǎng)絡(luò)帶寬影響；視頻加載速度包括初始播放、頻道切換、快進(jìn)快退的響應(yīng)時(shí)間，受網(wǎng)絡(luò)時(shí)延、網(wǎng)絡(luò)帶寬影響；視頻觀看體驗(yàn)包括是否出現(xiàn)花屏、卡頓，受網(wǎng)絡(luò)分組丟失率、誤碼率影響。

根據(jù)研究，在4K視頻的環(huán)境下，為保障用戶體驗(yàn)，網(wǎng)絡(luò)需要滿足更高的要求，實(shí)現(xiàn)高帶寬、低時(shí)延、低分組丟失率，具體指標(biāo)為：端到端帶寬≥37.5 Mbit/s、時(shí)延≤20 ms、分組丟失率≤10-5。

2 多播技術(shù)的應(yīng)用

2.1 多播方式承載視頻直播業(yè)務(wù)

從寬帶用戶網(wǎng)絡(luò)帶寬需求的分析中可以發(fā)現(xiàn)，在預(yù)測(cè)的每用戶5.5 Mbit/s平均使用速率中，視頻直播業(yè)務(wù)所占帶寬達(dá)到了3 Mbit/s。如果使用單播點(diǎn)對(duì)點(diǎn)通信技術(shù)承載視頻直播業(yè)務(wù)，就意味著從播放節(jié)目源的直播平臺(tái)到用戶終端，均需獨(dú)占資源（包括每個(gè)用戶均需要占用直播平臺(tái)資源，省網(wǎng)、城域網(wǎng)均需為每個(gè)用戶提供帶寬保障），隨著用戶數(shù)量增長到十萬、百萬量級(jí)，運(yùn)營商將難以承受單播方式承載視頻直播業(yè)務(wù)所需帶寬的壓力。

如果采用多播技術(shù)，當(dāng)網(wǎng)絡(luò)中的某些用戶需要特定內(nèi)容（比如觀看某個(gè)直播頻道）時(shí)，多播源（即直播平臺(tái)）對(duì)每個(gè)復(fù)制點(diǎn)僅發(fā)送一份內(nèi)容，多播設(shè)備借助多播協(xié)議為多播數(shù)據(jù)分組建立樹型路由，被傳遞的內(nèi)容在盡可能靠近用戶側(cè)的分叉點(diǎn)（即多播復(fù)制點(diǎn)）進(jìn)行復(fù)制和分發(fā)。

視頻直播內(nèi)容從直播平臺(tái)到用戶，一般需要經(jīng)過路由器、BRAS（broadband remote access server，寬帶遠(yuǎn)程接入服務(wù)器）、OLT（optical line terminal，光線路終端）、ONU、電視機(jī)頂盒。以多播復(fù)制點(diǎn)設(shè)置在OLT為例，當(dāng)用戶收看4K視頻直播時(shí)，多播、單播方式對(duì)比如圖1所示。

圖1 多播、直播方式對(duì)比

由此可見，采用多播后，帶寬只與頻道數(shù)有關(guān)，而與用戶數(shù)無關(guān)，相比單播方式，采用多播承載視頻直播業(yè)務(wù)可大幅節(jié)省帶寬。

在采用多播承載視頻直播業(yè)務(wù)的情況下，各相關(guān)網(wǎng)元要求如下。

· 路由器和BRAS：支持PIM-SM（protocol independent multicast-sparse mode，協(xié)議無關(guān)多播路由協(xié)議?稀疏模式）。

· OLT：支持 IGMP（internet group management protocol，互聯(lián)網(wǎng)組管理協(xié)議）proxy，向上支持靜態(tài)多播組加入，向下支持動(dòng)態(tài)多播組，完成多播復(fù)制。

· ONU：支持 IGMP snooping，或 IGMP proxy。

· 電視機(jī)頂盒：支持IGMP、RTP（real-time transport protocol，實(shí)時(shí)傳輸協(xié)議）、RTCP（real-time transport control protocol，實(shí)時(shí)傳輸控制協(xié)議）、RTSP（real-time streaming protocol，實(shí)時(shí)流傳輸協(xié)議）、HLS（HTTP live streaming，HTTP直播流）。

因此，運(yùn)營商有線寬帶業(yè)務(wù)承載網(wǎng)絡(luò)中的路由器和 BRAS、OLT、ONU、電視機(jī)頂盒網(wǎng)元均應(yīng)支持以上協(xié)議，并根據(jù)視頻直播業(yè)務(wù)的開展進(jìn)度適時(shí)采用多播方式承載業(yè)務(wù)。

2.2 Wi-Fi組網(wǎng)方式

目前ONU基本具備Wi-Fi功能，考慮使用便捷等因素，家庭室內(nèi)一般采用 Wi-Fi方式組網(wǎng)。但是，以 Wi-Fi空口多播方式支持視頻直播業(yè)務(wù)的多播報(bào)文，會(huì)存在可靠性低、速率低、干擾大等問題，具體如下。

· Wi-Fi多播采用廣播方式，無法支持確認(rèn)應(yīng)答機(jī)制，不支持重傳，可靠性低。

· Wi-Fi多播需要考慮所有接入點(diǎn)，為確?？煽啃?，標(biāo)準(zhǔn)定義的報(bào)文速率遠(yuǎn)比單播方式小。

· Wi-Fi多播需要一對(duì)多，發(fā)送功率比點(diǎn)對(duì)點(diǎn)方式大，干擾更強(qiáng)。

因此，電視機(jī)頂盒與ONU之間應(yīng)優(yōu)選有線連接。對(duì)于受限于裝修等條件，僅能通過 Wi-Fi接入機(jī)頂盒的場(chǎng)景，建議以 Wi-Fi空口單播方式支持視頻直播業(yè)務(wù)。ONU應(yīng)采用智能網(wǎng)關(guān)設(shè)備，在Wi-Fi發(fā)送前將多播轉(zhuǎn)換成單播，利用Wi-Fi單播自有確認(rèn)機(jī)制提高可靠性，并規(guī)避 Wi-Fi多播速率低、干擾大等缺點(diǎn)。

因此，運(yùn)營商應(yīng)采用“智能網(wǎng)關(guān)”設(shè)備，并要求應(yīng)支持以上功能，以便在家庭 Wi-Fi環(huán)境下提供良好的視頻直播業(yè)務(wù)體驗(yàn)。

3 BRAS、CDN下沉

3.1 BRAS、CDN下沉的驅(qū)動(dòng)力

在分析用戶網(wǎng)絡(luò)質(zhì)量需求時(shí)可知，為提高視頻業(yè)務(wù)用戶體驗(yàn)，需要提供高帶寬、低時(shí)延、低分組丟失率的網(wǎng)絡(luò)。

實(shí)際上，目前視頻業(yè)務(wù)大多采用HTTP視頻，基于TCP承載由于TCP的傳輸特性，時(shí)延、分組丟失率除直接影響視頻體驗(yàn)外，還影響TCP連接的實(shí)際吞吐量。

根據(jù)TCP吞吐量的Mathis模型，可以得到：

其中，BW為網(wǎng)絡(luò)帶寬，WindowSize為滑動(dòng)窗口尺寸，RTT為往返時(shí)延，MSS為最大分段長度，ρ為分組丟失率。

（1）不考慮分組丟失率，分析往返時(shí)延與TCP吞吐量的關(guān)系

IP網(wǎng)絡(luò)正常情況下的往返時(shí)延主要受限于傳輸距離。當(dāng)傳輸距離分別為1 000 km以內(nèi)、2 000 km以內(nèi)、3 000 km以內(nèi)時(shí)，某運(yùn)營商網(wǎng)內(nèi)任意兩點(diǎn)間的往返時(shí)延分別為≤40 ms、≤60 ms、≤80 ms，網(wǎng)絡(luò)實(shí)測(cè)指標(biāo)優(yōu)于承諾指標(biāo)。

假設(shè)滑動(dòng)窗口為64 KB，根據(jù)以上指標(biāo)，并增加地市范圍內(nèi)往返時(shí)延≤10 ms的情形，代入式（1）計(jì)算可得各種往返時(shí)延情況下單 TCP連接的吞吐量，見表3。

表3 往返時(shí)延與TCP吞吐量關(guān)系

由表3可以看出，時(shí)延對(duì)吞吐量的影響很大，因而作為內(nèi)容源的CDN（content delivery network，內(nèi)容分發(fā)網(wǎng)絡(luò)）應(yīng)盡量下沉到地市，以減少時(shí)延、提高用戶實(shí)際使用速率。

（2）往返時(shí)延固定，分析分組丟失率與 TCP吞吐量的關(guān)系

假設(shè)往返時(shí)延為40 ms，報(bào)文凈荷1 460 byte，代入式（1）計(jì)算可得各分組丟失率情況下單TCP連接的吞吐量，見表4。

表4 分組丟失率與TCP吞吐量關(guān)系

同時(shí)，根據(jù)中國科學(xué)院計(jì)算技術(shù)研究所對(duì)TCP吞吐量和分組丟失率關(guān)系的研究，當(dāng)網(wǎng)絡(luò)分組丟失率超過1%時(shí)，吞吐量下降速度遠(yuǎn)大于理論計(jì)算值；即使在局域網(wǎng)時(shí)延極低的環(huán)境下，當(dāng)分組丟失率達(dá)到3%時(shí)，實(shí)測(cè)吞吐量已經(jīng)比理論值低了一個(gè)數(shù)量級(jí)；當(dāng)分組丟失率達(dá)到 10%時(shí)，網(wǎng)絡(luò)基本不可用。

由此可知，用戶與內(nèi)容源之間層級(jí)應(yīng)盡量少，并盡量減少容易造成沖突分組丟失的二層網(wǎng)絡(luò)。為實(shí)現(xiàn)以上目的，有線寬帶業(yè)務(wù)運(yùn)營商應(yīng)盡快推動(dòng)BRAS、CDN的下沉。

3.2 BRAS下沉方式

運(yùn)營商在介入有線通信領(lǐng)域初期，有線寬帶用戶數(shù)比較少，運(yùn)維力量、機(jī)房條件有所不足；在部分地區(qū)，為便于維護(hù)，BRAS集中部署在地市核心機(jī)房，通過匯聚交換機(jī)接入分布在城域網(wǎng)各級(jí)匯聚機(jī)房?jī)?nèi)的OLT設(shè)備。

這種BRAS集中部署、交換機(jī)匯聚的方式，不必要地?cái)U(kuò)大了二層網(wǎng)絡(luò)的范圍，且由于交換機(jī)設(shè)備端口緩存能力很弱，一旦出現(xiàn)擁塞，分組丟失率會(huì)快速上升。而三層網(wǎng)絡(luò)設(shè)備，由于端口緩存能力強(qiáng)，在一般擁塞情況下，首先是發(fā)生時(shí)延增加而不是分組丟失率增加，對(duì)用戶體驗(yàn)影響較小。

另一方面，在逐步取消匯聚交換機(jī)、OLT直聯(lián)BRAS的情況下，如果BRAS繼續(xù)采用集中部署，匯聚機(jī)房到核心機(jī)房之間的傳輸成本會(huì)快速增加。經(jīng)過測(cè)算，當(dāng)有線寬帶接入用戶數(shù)達(dá)到2萬戶及以上時(shí)，原則上應(yīng)將BRAS下沉到城域傳送網(wǎng)匯聚機(jī)房。

基于以上分析，綜合考慮設(shè)備成本、運(yùn)維成本以及網(wǎng)絡(luò)安全信息分級(jí)規(guī)范等管理規(guī)定，運(yùn)營商BRAS下沉可以考慮如下原則。

· 初期采用單BRAS下沉的方式，當(dāng)用戶增長到4萬戶及以上時(shí)，逐步實(shí)現(xiàn)同機(jī)房成對(duì)設(shè)置BRAS方式，單臺(tái)BRAS容量不應(yīng)超過4萬戶。

· BRAS最低下沉到縣區(qū)，當(dāng)用戶增長時(shí)應(yīng)采用在原機(jī)房擴(kuò)容BRAS的方式，而不是繼續(xù)下沉。

3.3 CDN下沉方式

為了滿足用戶的需求，運(yùn)營商應(yīng)通過多種手段進(jìn)行內(nèi)容建設(shè)，包括 IDC內(nèi)容源引入、CDN/緩存以及視頻平臺(tái)建設(shè)等，以期提高用戶的流量本網(wǎng)率。

針對(duì)視頻內(nèi)容，運(yùn)營商可以考慮建設(shè)融合CDN，由一套CDN對(duì)互聯(lián)網(wǎng)電視、大文件、小文件3類內(nèi)容采用不同的調(diào)度方式，提供視頻、下載、網(wǎng)頁等內(nèi)容的分發(fā)加速。

運(yùn)營商在制定融合CDN建設(shè)方案的過程中，需要綜合考慮CDN和傳輸?shù)脑靸r(jià)、建設(shè)維護(hù)、網(wǎng)間結(jié)算、管控成本等相關(guān)因素。根據(jù)目前的價(jià)格測(cè)算，按地市至省會(huì)平均距離為300 km，當(dāng)?shù)厥幸曨l用戶達(dá)到11.5萬戶時(shí)，CDN節(jié)點(diǎn)下沉的投資將低于地市至省會(huì)傳輸網(wǎng)絡(luò)的建設(shè)投資，由此CDN節(jié)點(diǎn)下沉可考慮如下原則。

· 面積大于2×105km2的省，地市至省會(huì)距離超過300 km，應(yīng)部署CDN節(jié)點(diǎn)。

· 面積小于2×105km2的省，地市視頻用戶超過11.5萬戶，應(yīng)部署CDN節(jié)點(diǎn)。

· 對(duì)部分業(yè)務(wù)重點(diǎn)區(qū)縣，部署CDN邊緣服務(wù)節(jié)點(diǎn)。

4 骨干網(wǎng)架構(gòu)演進(jìn)

隨著“國家寬帶”戰(zhàn)略以及“提速降費(fèi)”的不斷推進(jìn)，有線寬帶用戶數(shù)量還會(huì)持續(xù)攀升，接入帶寬也將進(jìn)一步提升；各類大帶寬的互聯(lián)視頻應(yīng)用推陳出新；網(wǎng)絡(luò)流量將會(huì)飛速上漲。雖然通過開啟多播、CDN下沉等方法，大量流量將在城域網(wǎng)、省網(wǎng)范圍內(nèi)終結(jié)，但由于各省內(nèi)容源引入和建設(shè)情況不同以及訪問國際、國內(nèi)網(wǎng)間內(nèi)容的需求，骨干網(wǎng)流量仍會(huì)持續(xù)增長，骨干網(wǎng)規(guī)模相應(yīng)持續(xù)增加，因此需要骨干網(wǎng)絡(luò)具備良好的可擴(kuò)展性。

實(shí)現(xiàn)網(wǎng)絡(luò)可擴(kuò)展性的兩大要素就是設(shè)備容量的擴(kuò)展和合理的網(wǎng)絡(luò)架構(gòu)，并且在網(wǎng)絡(luò)建設(shè)發(fā)展的過程中相依相佐，共同促進(jìn)網(wǎng)絡(luò)的演進(jìn)。

4.1 流量新平面構(gòu)建

運(yùn)營商一直在通過節(jié)點(diǎn)裂變、平行擴(kuò)容、推進(jìn)網(wǎng)絡(luò)結(jié)構(gòu)扁平化等平滑演進(jìn)思路來降低節(jié)點(diǎn)設(shè)備容量需求、實(shí)現(xiàn)網(wǎng)絡(luò)規(guī)模的持續(xù)擴(kuò)展，筆者在這里提出一種新的思路，即建設(shè)流量新平面，這是一種不平衡的結(jié)構(gòu)形式。

為解決已有設(shè)備平臺(tái)能力有限、擴(kuò)容潛力即將耗盡的問題，運(yùn)營商可考慮新建一個(gè)流量平面，流量新平面的覆蓋范圍可以根據(jù)節(jié)點(diǎn)的流量情況進(jìn)行選擇（選擇流量牽引效果大的節(jié)點(diǎn)），而不是像通常所用的全平面復(fù)制。同時(shí)，在新平面選擇使用最新型的路由器設(shè)備，采用高速鏈路組網(wǎng)；原有設(shè)備作為流量老平面，負(fù)責(zé)新平面未覆蓋節(jié)點(diǎn)的流量疏通以及所有出網(wǎng)流量（國際互聯(lián)、國內(nèi)互聯(lián)）。

新舊平面的近期演進(jìn)，可以首先實(shí)現(xiàn)兩個(gè)平面的業(yè)務(wù)區(qū)分，形成網(wǎng)間、網(wǎng)內(nèi)平面；新舊平面完全隔離，路由組織清晰；兩個(gè)平面的解耦既有利于原有平面的投資保護(hù)，又有利于新平面中新設(shè)備、新技術(shù)的引入；也可分別考慮兩個(gè)網(wǎng)絡(luò)平面的使用和架構(gòu)的演進(jìn)。

4.2 骨干網(wǎng)后續(xù)的演進(jìn)

通過新平面的建設(shè)，骨干網(wǎng)絡(luò)將有較長時(shí)期可以實(shí)現(xiàn)平滑擴(kuò)容，保持網(wǎng)絡(luò)架構(gòu)的相對(duì)穩(wěn)定。一方面，隨著IDC、CDN的建設(shè)以及內(nèi)容源的引入，網(wǎng)絡(luò)擴(kuò)容壓力將逐步向網(wǎng)絡(luò)邊緣遷移，流量大量終結(jié)于本省，骨干網(wǎng)擴(kuò)容壓力增長緩慢；另一方面，網(wǎng)絡(luò)設(shè)備能力仍保持快速增長，一定時(shí)期內(nèi)滿足網(wǎng)絡(luò)規(guī)模的擴(kuò)容需求。

當(dāng)未來更高容量的設(shè)備以及更高速率的帶寬出現(xiàn)時(shí)，仍然可以借鑒“構(gòu)建新平面”這一思路，確保網(wǎng)絡(luò)的良性可持續(xù)發(fā)展。構(gòu)建流量新平面擴(kuò)容示意如圖2所示。

圖2 構(gòu)建流量新平面擴(kuò)容示意

以網(wǎng)絡(luò)規(guī)模為基礎(chǔ)，骨干網(wǎng)后續(xù)演進(jìn)方向?qū)⒓性诰W(wǎng)絡(luò)架構(gòu)的持續(xù)優(yōu)化中。一是網(wǎng)絡(luò)核心節(jié)點(diǎn)和內(nèi)容核心節(jié)點(diǎn)的協(xié)同建設(shè)，滿足內(nèi)容分發(fā)需求；二是IP網(wǎng)絡(luò)中繼和傳輸資源協(xié)同管理，優(yōu)化時(shí)延，提升網(wǎng)絡(luò)頑健性；三是提升IP網(wǎng)絡(luò)智能化能力，引入SDN等新技術(shù)以賦予骨干網(wǎng)更高的智能，提供更精細(xì)化的客戶體驗(yàn)。

5 結(jié)束語

根據(jù)以上分析，為滿足有線寬帶用戶的帶寬需求、質(zhì)量需求，運(yùn)營商可采取以下主要應(yīng)對(duì)措施：視頻直播業(yè)務(wù)通過多播承載，減少帶寬占用；BRAS下沉、CDN下沉，用戶到網(wǎng)內(nèi)內(nèi)容之間經(jīng)過的網(wǎng)元盡量少，減小時(shí)延與分組丟失率；骨干網(wǎng)具備大容量擴(kuò)容能力，滿足用戶帶寬持續(xù)增長。

通過以上舉措，運(yùn)營商將為發(fā)力有線寬帶市場(chǎng)、迎接4K等視頻業(yè)務(wù)蓬勃發(fā)展做好IP承載網(wǎng)絡(luò)的基礎(chǔ)準(zhǔn)備，以便在后續(xù)業(yè)務(wù)發(fā)展的市場(chǎng)競(jìng)爭(zhēng)中取得有利地位。

[1] 黃孝建, 陶夢(mèng)華. IPTV關(guān)鍵技術(shù)詳解[M]. 北京: 北京郵電大學(xué)出版社, 2009. HUANG X J, TAO M H. IPTV key technology in detail[M]. Beijing: Beijing University of Posts and Telecommunications Press, 2009.

[2] 朱培棟, 張明杰, 盧錫城. TCP吞吐率模型及其應(yīng)用范例[J].計(jì)算機(jī)工程與科學(xué), 2005, 27(9): 1-3. ZHU P D, ZHANG M J, LU X C. The TCP throughput model and its applications[J]. Computer Engineering & Science, 2005, 27(9): 1-3.

[3] 吳起, 畢經(jīng)平, 李忠誠. 高帶寬低延遲下TCP吞吐量和包丟失率關(guān)系研究[C]//中國計(jì)算機(jī)學(xué)會(huì). 第七屆計(jì)算機(jī)科學(xué)與技術(shù)研究生學(xué)術(shù)討論會(huì)論文集. [S.l.:s.n.], 2002: 1-6. WU Q, BI J P, LI Z C. The relationship between TCP throughput and packet loss rate high bandwidth and low delay environment[C]//China Computer Federation. Proceedings of the7th Symposium on Computer Science and Technology Postgraduate. [S.l.:s.n.], 2002: 1-6.

[4] 周明天, 汪文勇. TCP/IP網(wǎng)絡(luò)原理與技術(shù)[M]. 北京: 清華大學(xué)出版社, 1993. ZHOU M T, WANG W Y. Principle and technology of TCP/IP network[J]. Beijing: Tsinghua University Press, 1993.

唐利莉（1973?），女，中國移動(dòng)通信集團(tuán)設(shè)計(jì)院有限公司高級(jí)工程師，主要從事IP承載網(wǎng)的設(shè)計(jì)工作。

聶明（1972?），男，中國移動(dòng)通信集團(tuán)設(shè)計(jì)院有限公司教授級(jí)高級(jí)工程師，主要從事 IP承載網(wǎng)、移動(dòng)互聯(lián)網(wǎng)業(yè)務(wù)平臺(tái)的設(shè)計(jì)工作。

張寧（1982?），男，中國移動(dòng)通信集團(tuán)設(shè)計(jì)院有限公司工程師，主要從事IP承載網(wǎng)的設(shè)計(jì)工作。

Impact of wired broadband services development on operators’ IP network evolution

TANG Lili, NIE Ming, ZHANG Ning
China Mobile Group Design Institute Co., Ltd., Beijing 100080, China

With the development of wired broadband services, new requirements on the carrying ability of network was put forward by video-dominated services. The demand on bandwidth and network quality of wired broadband traffic grooming was analyzed, and a feasible network evolution solution were presented from the perspective of multicast technology application, BRAS and CDN deployment, backbone network architecture evolution and other point of view.

wired broadband service, video service, network flattening, multicast technology, content closer to the user

TN915.41

A

10.11959/j.issn.1000?0801.2017090

2017-02-20；

2017-03-28