黃 旭，成夢虹，成芝言

(中國移動通信集團設計院有限公司，北京 100080)

0 引 言

網(wǎng)絡質(zhì)量一直是運營商重點關注的指標，主要影響因素包括網(wǎng)絡鏈路擁塞、時延和丟包等。目前常采用因特網(wǎng)包探索器(Packet Internet Groper，PING)、路由追蹤(Traceroute)和遠程包探索(Remote Packet Internet Groper，RPING)等方法完成網(wǎng)絡質(zhì)量的主動探測[1]，利用簡單網(wǎng)絡管理協(xié)議(Simple Network Management Protocol，SNMP)采集鏈路流量實現(xiàn)鏈路擁塞監(jiān)控。但現(xiàn)有主動發(fā)起的探測及監(jiān)控方法都不具備時效性，往往是故障或質(zhì)差發(fā)生后的問題查詢手段。

隨著用戶業(yè)務的多元化、網(wǎng)絡架構(gòu)的復雜化和邊緣化[2]，現(xiàn)有探測方法和監(jiān)控手段已無法滿足運營商對網(wǎng)絡質(zhì)量提升的要求，更無法支撐行業(yè)重點客戶的服務級別協(xié)議(Service Level Agreement，SLA)保障需求?，F(xiàn)有網(wǎng)絡目前沒有一套完整的、有效的網(wǎng)絡整體質(zhì)量和用戶業(yè)務質(zhì)量監(jiān)測方案。為解決這一問題，本文結(jié)合隨流檢測(In-situ Flow Information Telemetry，IFIT)、雙向測量(Twamp)、高速采集(Telemetry)和數(shù)據(jù)流分析(Flow)等技術，提出了基于IP網(wǎng)絡質(zhì)量的監(jiān)測方案設計，采用統(tǒng)一架構(gòu)實現(xiàn)網(wǎng)際互連協(xié)議(Internet Protocol，IP)網(wǎng)絡不同維度的質(zhì)量監(jiān)測。最終，結(jié)合不同場景的人工智能(Artificial Intelligence，AI)預測完成整體網(wǎng)絡及客戶業(yè)務的質(zhì)差預警，利用運維方法及流程設計實現(xiàn)網(wǎng)絡質(zhì)量提升的目標。

1 研究思路

1.1 架構(gòu)設計

以設備層、協(xié)議層、采集層、應用層和分析層設計方案架構(gòu)，統(tǒng)一部署Twamp、IFIT和Netflow等協(xié)議/技術，完成網(wǎng)絡設備時延和丟包等性能數(shù)據(jù)封包。利用Telemetry+SNMP完成性能和流量等數(shù)據(jù)的采集，結(jié)合網(wǎng)絡時延、丟包率和鏈路利用率等質(zhì)差分析方法及AI預測方法，最終完成網(wǎng)絡整體質(zhì)量及行業(yè)重點客戶的端到端業(yè)務質(zhì)量提升。

1.2 應用思路

(1)網(wǎng)絡整體質(zhì)量監(jiān)測：采用Twamp技術代替現(xiàn)有PING和Traceroute等技術，完成網(wǎng)絡全鏈路質(zhì)量監(jiān)測，實現(xiàn)全網(wǎng)質(zhì)量透明化。

(2)大客戶業(yè)務質(zhì)量監(jiān)測：利用IFIT+Flow技術完成用戶的業(yè)務質(zhì)量保障，實現(xiàn)特定業(yè)務的端到端故障定界，填補時效性業(yè)務監(jiān)測能力的空白。

(3)采用Telemetry技術協(xié)同SNMP共同完成流量采集與統(tǒng)計，針對時效性強的性能數(shù)據(jù)通過Telemetry完成亞秒級采集，傳統(tǒng)流量數(shù)據(jù)采用SNMP分鐘粒度采集，完成流量擁塞統(tǒng)計，支撐網(wǎng)絡運維。

圖1所示為網(wǎng)絡質(zhì)量監(jiān)測方案架構(gòu)及應用。質(zhì)量監(jiān)測方案通過不同技術的結(jié)合應用部署，采用整體架構(gòu)設計完成網(wǎng)絡整體質(zhì)量和大客戶業(yè)務質(zhì)量的監(jiān)測，結(jié)合AI預測實現(xiàn)鏈路和業(yè)務質(zhì)差預警，從而達到網(wǎng)絡質(zhì)量監(jiān)測自動化和智能化的目的，最終網(wǎng)絡質(zhì)量提升。

圖1 網(wǎng)絡質(zhì)量監(jiān)測方案架構(gòu)及應用

2 技術優(yōu)勢及應用部署

2.1 網(wǎng)絡整體質(zhì)量監(jiān)測

2.1.1 Twamp網(wǎng)絡監(jiān)測能力

Twamp是一種用于IP鏈路的性能測量技術，可以在正反兩個方向統(tǒng)計網(wǎng)絡雙向時延和抖動[3]。Twamp屬于主動探測技術，能較好地反映網(wǎng)絡質(zhì)量整體情況，如亞秒級反饋鏈路雙向時延、丟包和抖動等質(zhì)量數(shù)據(jù)。相比傳統(tǒng)以及現(xiàn)在常用的傳輸控制協(xié)議(Transmission Control Protocol，TCP)/網(wǎng)際IP提供的PING和Traceroute等服務，Twamp更具時效性和準確性。

2.1.2 應用部署

圖2所示為Twamp與現(xiàn)有技術應用對比。選取已部署探針監(jiān)測的城域網(wǎng)絡進行Twamp現(xiàn)網(wǎng)部署[4]，實測并對比兩種技術應用下寬帶接入服務器(Broadband Remote Access Server，BRAS)至城域網(wǎng)絡核心層設備(Metropolis Backbone，MB)之間的鏈路質(zhì)量數(shù)據(jù)。

圖2 Twamp與現(xiàn)有技術應用對比

(1) Twamp應用：只需設備開啟相關服務，數(shù)據(jù)將自動上報。

數(shù)據(jù)包訪問路徑：BRAS1或BRAS2至MB(雙向)。

時延計算：舉例BRAS1和MB鏈路時延。設BRAS1發(fā)包時間戳為T1，MB收包時間戳為T2，MB發(fā)包時間戳為T3，BRAS1收報時間戳為T4,則單向時延=T2-T1和T4-T3，雙向(往返)時延=(T4-T1)-(T3-T2)。

丟包率計算：丟包率=(收到的返回包數(shù)目)/(發(fā)出的包數(shù)目)。

(2) 現(xiàn)有探針應用：需路由器設備下掛探針服務器，Sever下發(fā)PING和Trace等指令后探針執(zhí)行。

數(shù)據(jù)包訪問路徑：Sever下發(fā)指令至探針，探針發(fā)出檢測報文至BRAS，BRAS發(fā)包至MB(雙向)。

時延計算：舉例：BRAS1和MB鏈路時延。設Sever指令下發(fā)時間為T1，探針讀取指令時間為T2，探針執(zhí)行指令并發(fā)包至BRAS1時間為T3，BRAS1發(fā)包至MB時間為T4，探針只支持雙向時延計算，雙向(往返)時延=2(T1+T2+T3+T4)。

丟包率計算：丟包率=(收到的返回包數(shù)目)/(發(fā)出的包數(shù)目)。

表1所示為Twamp與傳統(tǒng)探針監(jiān)測數(shù)據(jù)對比。數(shù)據(jù)結(jié)果說明Twamp網(wǎng)絡性能質(zhì)量探測比探針更精準，避免了探針系統(tǒng)自身的指令下發(fā)時間和讀取時間，以及Sever、探針和BRAS間的鏈路性能數(shù)據(jù)疊加。從為期一周的性能測試結(jié)果來看，Twamp亞秒級監(jiān)測的平均時延為1.0 ms，探針分鐘級監(jiān)測平均時延為1.5 ms，相差0.5 ms，可以判定，多出的時延是探針網(wǎng)絡的自身時延。探針系統(tǒng)的實際網(wǎng)絡性能監(jiān)測結(jié)果=網(wǎng)絡性能質(zhì)量+探針系統(tǒng)質(zhì)量，且圖2中探針的丟包數(shù)據(jù)是探針本身宕機導致，因此數(shù)據(jù)真實度較低。而Twamp監(jiān)測時延及丟包以數(shù)據(jù)報文的時間戳和實際報文數(shù)量為準，數(shù)據(jù)真實度較高，能實時保障鏈路真實質(zhì)量。同時，在部署上更具靈活性，除分析服務器外，無需額外部署服務器，減少了成本投入及維護投入。

表1 Twamp與傳統(tǒng)探針監(jiān)測數(shù)據(jù)對比(監(jiān)控時間：2021/5/4-2021/5/11)

2.2 大客戶業(yè)務質(zhì)量監(jiān)測

針對行業(yè)大客戶的業(yè)務保障，現(xiàn)有網(wǎng)絡多采用服務質(zhì)量(Quality of Service，Qos)、隧道綁定和網(wǎng)絡策略等方法[5]，但諸多應用也只停留在業(yè)務保障層，無法做到業(yè)務質(zhì)量精準監(jiān)測。

現(xiàn)有手段根據(jù)業(yè)務穿越的網(wǎng)元節(jié)點逐跳PING測，但無法保證業(yè)務質(zhì)量的時效性和準確性，多數(shù)都是問題排障時的查詢和復現(xiàn)手段。因此可采用IFIT逐流監(jiān)測技術完成大客戶業(yè)務端到端的質(zhì)量監(jiān)測，實現(xiàn)SLA等級較高業(yè)務的保障支撐及故障定界。

2.2.1 IFIT業(yè)務隨流監(jiān)測

IFIT是一種基于真實業(yè)務流的隨路測量技術，具備真實業(yè)務流的端到端及逐跳SLA(丟包、流量、時延和抖動等)測量能力，可快速感知網(wǎng)絡相關故障，并進行精準定界和排障。IFIT屬于被動監(jiān)測技術，可做到業(yè)務質(zhì)量隨流精準測量，其基于RFC 8321，是一種對實際業(yè)務流進行特征標記(染色)的隨流監(jiān)測技術，支持丟包及時延染色，可測量獲得包數(shù)、字節(jié)數(shù)和時戳3個原始數(shù)據(jù)[6]。因此，其在保證丟包數(shù)量真實性的同時，根據(jù)包中的時間戳也保證了時延數(shù)據(jù)準確性，IFIT當前支持的監(jiān)測周期有10 s、30 s、1 min和5 min。

圖3所示為報文染色，進入端(Ingress)按照一定周期i對被監(jiān)測流的標記字段進行交替染色，統(tǒng)計本周期的染色報文數(shù)量Tx；出端(Egress)按照Ingress相同的周期，統(tǒng)計本周期特征業(yè)務流染色報文數(shù)量Rx。同時，在Ingress和Egress進行時延染色，記錄報文入口時間戳T1和T3，報文出口時間戳T2和T4。計算業(yè)務流在周期i的丟包數(shù)及雙向時延分別為

IFIT主要通過報文頭部的染色封裝，根據(jù)同一個數(shù)據(jù)包隨業(yè)務流進出設備后的染色報文統(tǒng)計完成時延和丟包的精準計算。

圖3 報文染色[6]

2.2.2 應用部署

選取某省網(wǎng)、城域網(wǎng)和省內(nèi)互聯(lián)網(wǎng)數(shù)據(jù)中心(Internet Data Center，IDC)聯(lián)合部署測試，流量訪問路徑：訪問用戶→BRAS→MB→省網(wǎng)絡核心層(Province Backbone，PB)→IDC內(nèi)部服務器，在BRAS、MB和PB設備上開啟IFIT服務及逐跳監(jiān)測功能。模擬兩個訪問用戶為SLA保障專線，并通過網(wǎng)絡策略劃分兩個用戶的訪問路徑。對比不同鏈路相同業(yè)務的數(shù)據(jù)監(jiān)測結(jié)果，驗證IFIT端到端業(yè)務監(jiān)測能力。

圖4所示為IFIT應用部署。兩條SLA專線以不同路徑同時完成網(wǎng)絡測速和視頻文件訪問。

圖4 IFIT應用部署

表2 所示為用戶性能監(jiān)控數(shù)據(jù)對比。用戶1端到端訪問總時延為15.083 ms，丟包率為1.92%；用戶2端到端訪問總時延為10.187 ms，丟包率為0。經(jīng)過對比，用戶1訪問視頻文件首幀訪問時間較長，卡頓率較高，視頻播放成功率較低，業(yè)務感知較差。通過IFIT業(yè)務逐跳監(jiān)測數(shù)據(jù)，可短時間內(nèi)判斷影響業(yè)務質(zhì)量的故障發(fā)生在2021/5/11 08∶56∶01的BRAS節(jié)點至MB1節(jié)點。登錄BRAS設備查詢與MB1互聯(lián)端口，發(fā)現(xiàn)互聯(lián)端口循環(huán)冗余校驗(Cyclic Redundancy Check，CRC)誤碼率增長較快，MB1設備無異常。經(jīng)查詢故障是由BRAS與MB1之間的光傳送網(wǎng)(Optical Transport Network，OTN)鏈路光衰導致，OTN更換業(yè)務波道后業(yè)務質(zhì)量恢復。

表2 用戶性能監(jiān)控數(shù)據(jù)對比(選取時間：2021/5/11 08∶56∶01～09∶13∶44)

目前現(xiàn)有網(wǎng)絡沒有客戶業(yè)務實時監(jiān)測技術，只限于Qos等質(zhì)量保障，無法真實反饋用戶業(yè)務質(zhì)量。同時，網(wǎng)絡結(jié)構(gòu)復雜也導致用戶質(zhì)差時無法快速定界問題。因此可通過IFIT部署及應用實現(xiàn)行業(yè)為大客戶業(yè)務的質(zhì)量分析和故障定界，有效支撐大客戶業(yè)務運營及運維工作。

3 Telemetry+SNMP采集

方案中提出的Twamp和IFIT等技術對時效性要求較高，采集粒度較小，因此細粒度的數(shù)據(jù)采集通過Telemetry完成高效采集，保障整體網(wǎng)絡及業(yè)務質(zhì)量時效性。傳統(tǒng)SNMP技術部署在網(wǎng)絡整體流量采集中，用于鏈路擁塞管控。

兩種采集方式聯(lián)合部署可實現(xiàn)大客戶業(yè)務的實時質(zhì)量監(jiān)測和全網(wǎng)鏈路擁塞質(zhì)量監(jiān)控，通過Telemetry+SNMP兩種采集方式的結(jié)合部署完成網(wǎng)絡整體到具體用戶業(yè)務的雙重質(zhì)量保障。

4 網(wǎng)絡質(zhì)量優(yōu)化

4.1 質(zhì)量優(yōu)化支撐-Netflow

設備開啟Netflow功能完成鏈路中明細路由、流量大小及流量方向等數(shù)據(jù)獲取，實現(xiàn)流量精細化調(diào)度[7]，快速恢復質(zhì)差業(yè)務，提升網(wǎng)絡質(zhì)量優(yōu)化效率。以方案中提出的網(wǎng)絡整體質(zhì)量監(jiān)測和大客戶業(yè)務質(zhì)量監(jiān)測結(jié)果為調(diào)度觸發(fā)事件，結(jié)合鏈路流量擁塞占比和鏈路性能指標完成質(zhì)差業(yè)務調(diào)度，實現(xiàn)業(yè)務質(zhì)量優(yōu)化。

4.2 應用部署及質(zhì)量提升

圖5所示為網(wǎng)絡質(zhì)量提升方案部署。網(wǎng)絡在部署Twamp和IFIT后實時監(jiān)測網(wǎng)絡及業(yè)務質(zhì)量，發(fā)現(xiàn)被監(jiān)測網(wǎng)絡視頻業(yè)務的IFIT時延偏大并伴隨丟包，同時Twamp鏈路監(jiān)測時延和丟包數(shù)據(jù)也出現(xiàn)劣化。開啟Netflow流量明細分析，進行流量調(diào)度，優(yōu)先保障網(wǎng)絡視頻高價值業(yè)務質(zhì)量。

圖5 網(wǎng)絡質(zhì)量提升方案部署

網(wǎng)絡質(zhì)量優(yōu)化流程：

(1) IFIT監(jiān)測大客戶業(yè)務質(zhì)量，Twamp監(jiān)測網(wǎng)絡鏈路質(zhì)量；

(2) 分析網(wǎng)絡整體鏈路質(zhì)量及端到端業(yè)務質(zhì)量監(jiān)測數(shù)據(jù)，完成故障定界；

(3) 開啟Netflow流量分析，獲取鏈路中各業(yè)務明細路由，按Flow比例還原SLA保障用戶流量大?。?/p>

(4) 評估流量調(diào)度后是否會對現(xiàn)有鏈路造成流量擁塞；

(5) 下發(fā)策略，完成調(diào)度；

(6) Netflow分析調(diào)度后的鏈路，通過流量明細、流量大小驗證調(diào)度是否成功；

(7) IFIT、Twamp繼續(xù)監(jiān)測網(wǎng)絡及業(yè)務質(zhì)量，保障網(wǎng)絡質(zhì)量，支撐網(wǎng)路運維。

通過以上調(diào)度流程，成功地將鏈路1中的網(wǎng)絡視頻業(yè)務流量調(diào)度至鏈路2，調(diào)度成功后業(yè)務監(jiān)測顯示數(shù)據(jù)時延降低，丟包率為0，業(yè)務質(zhì)量恢復，業(yè)務調(diào)度前后數(shù)據(jù)對比如表3所示。

表3 業(yè)務調(diào)度前后數(shù)據(jù)對比

5 AI預警

網(wǎng)絡質(zhì)量監(jiān)測目的是降低網(wǎng)絡故障發(fā)生率及用戶投訴數(shù)量，從而提升網(wǎng)絡及業(yè)務質(zhì)量。因此，AI預警從故障和業(yè)務投訴出發(fā)，設定觸發(fā)條件為時延、丟包和流量擁塞。

5.1 場景設定

(1)故障類場景：鏈路down、端口閃斷、CRC誤碼率高和端口光衰等。

(2)業(yè)務類場景：業(yè)務訪問緩沖問題、業(yè)務卡頓問題和業(yè)務掉線問題等。

5.2 預測周期

考慮包粒度的質(zhì)量數(shù)據(jù)量級較大，采用短周期預測方法，結(jié)合10周歷史數(shù)據(jù)計算結(jié)果完成預測。

5.3 數(shù)據(jù)建模

(1) 故障類建模：獲取告警信息/設備告警日志，通過相同時間和相同節(jié)點的鏈路/端口大量網(wǎng)絡質(zhì)量數(shù)據(jù)完成計算建模，輸出各類故障對應的不同條件基線值，如某一時間點鏈路down，查詢此時間點前后鏈路時延/丟包率，完成基線值計算。

(2) 業(yè)務類建模：獲取不同業(yè)務投訴時間，通過時間段內(nèi)網(wǎng)絡質(zhì)量數(shù)據(jù)完成建模計算，輸出各類業(yè)務質(zhì)差投訴對應的不同條件基線值，如晚忙時用戶投訴業(yè)務卡頓，查詢該時段網(wǎng)元端口流量擁塞情況/時延，完成基線計算。

通過觸發(fā)故障和業(yè)務投訴的各類條件基線計算實現(xiàn)網(wǎng)絡質(zhì)差預警功能[8]，部署后結(jié)合運維手段，實現(xiàn)網(wǎng)絡質(zhì)差自動發(fā)現(xiàn)自動處理的能力。

6 方案整體應用效果

為驗證監(jiān)測方案的整體應用效果，選取具備傳統(tǒng)探針的省內(nèi)網(wǎng)絡環(huán)境，部署本文的監(jiān)測方案。設備監(jiān)控范圍包括PB路由器2臺，MB路由器2臺，BRAS接入服務器8臺。BRAS與MB互聯(lián)采用10 Gbit/s端口4上聯(lián)，MB與PB互聯(lián)采用100 Gbit/s端口4上聯(lián)，MB與MB、PB與PB間均采用100 Gbit/s端口雙互聯(lián)。如圖6所示，本方案服務器部署在省核心設備PB處，通過堆疊交換機完成采集、存儲和分析等監(jiān)測服務器主備接入；傳統(tǒng)探針服務器下掛在BRAS接入服務器下，與用戶接入網(wǎng)同層級。

圖6 方案部署拓撲

6.1 網(wǎng)絡性能質(zhì)量監(jiān)測數(shù)據(jù)對比

表4所示為網(wǎng)絡性能監(jiān)控粒度對比，表中的數(shù)據(jù)是本方案與傳統(tǒng)探針部署在相同網(wǎng)絡環(huán)境中各指標的監(jiān)測粒度對比，由表可知，本文方案部署后，網(wǎng)絡監(jiān)測粒度變的更小、更精準。其中，監(jiān)測周期最小粒度為秒級，比傳統(tǒng)監(jiān)控周期縮小一個量級，可實時感知網(wǎng)絡變化情況。同時，傳統(tǒng)的聚合鏈路監(jiān)測基于固定的Hash算法做選路，相同流量大概率通過固定端口/鏈路轉(zhuǎn)發(fā)，導致監(jiān)測結(jié)果與網(wǎng)絡實際質(zhì)量情況不符。通過本方案監(jiān)控可實現(xiàn)網(wǎng)絡鏈路最小集監(jiān)控，共計44條全量物理鏈路，遠超傳統(tǒng)探針的10條聚合鏈路監(jiān)控數(shù)量。路徑監(jiān)測也由傳統(tǒng)的點到點演進為所有節(jié)點間逐跳監(jiān)測的形式，可滿足網(wǎng)絡全鏈路監(jiān)控需求及網(wǎng)絡自動駕駛演進要求。

表4 網(wǎng)絡性能監(jiān)控粒度對比

表5所示為網(wǎng)絡性能指標監(jiān)測數(shù)據(jù)對比情況(天)，表中監(jiān)測數(shù)據(jù)最小更新粒度是傳統(tǒng)探針的1/60，由于探針本身需要處理時延，因此時延的監(jiān)測數(shù)據(jù)往往大于本方案的時延監(jiān)測結(jié)果，天粒度的平均時延對比相差0.5～0.7 ms。由丟包數(shù)據(jù)對比也可發(fā)現(xiàn)，探針的監(jiān)測周期粒度較大，加上服務器相關命令處理時長，導致網(wǎng)絡丟包時探針無法及時監(jiān)控此部分間隔數(shù)據(jù)。抽取某天丟包數(shù)據(jù)對比，BRAS-MB鏈路傳統(tǒng)探針少監(jiān)控丟包數(shù)67個，MB-PB鏈路傳統(tǒng)探針少監(jiān)控丟包數(shù)38個。因此，傳統(tǒng)探針監(jiān)測數(shù)據(jù)中時延增加和丟包數(shù)量較小情況多為數(shù)據(jù)不真實導致，此類不符合業(yè)務邏輯的現(xiàn)象也為網(wǎng)絡故障處理增加了難度。

表5 網(wǎng)絡性能指標監(jiān)測數(shù)據(jù)對比情況(天)

6.2 大客戶業(yè)務質(zhì)量監(jiān)測

方案部署前本省網(wǎng)不具備大客戶業(yè)務質(zhì)量精準監(jiān)測能力，傳統(tǒng)的監(jiān)測手段均為模擬監(jiān)測，在探針系統(tǒng)預置客戶經(jīng)常訪問的目的地址，設定監(jiān)測時間間隔，完成粗粒度的業(yè)務質(zhì)量監(jiān)測。此方案只能模擬監(jiān)測用戶到目的地址端到端間長鏈路數(shù)據(jù)質(zhì)量，無法根據(jù)網(wǎng)絡情況判定省內(nèi)節(jié)點設備間的業(yè)務質(zhì)量情況。因此，傳統(tǒng)監(jiān)測方式中業(yè)務的路徑、時效性和質(zhì)量情況等都不足以支撐用戶業(yè)務質(zhì)量精準分析。

表6所示為大客戶業(yè)務質(zhì)量監(jiān)測能力對比(周)，表中數(shù)據(jù)是針對159條互聯(lián)網(wǎng)專線客戶業(yè)務的監(jiān)測數(shù)據(jù)統(tǒng)計。數(shù)據(jù)結(jié)果不僅包括BRAS-MB和MB-PB鏈路間的業(yè)務性能指標評估，同時具備節(jié)點設備間不同業(yè)務路徑逐跳質(zhì)量監(jiān)測能力，可實時反饋用戶業(yè)務質(zhì)量變化情況，解決方案部署前省內(nèi)網(wǎng)絡無法精準監(jiān)測大客戶業(yè)務質(zhì)量的難題。

表6 大客戶業(yè)務質(zhì)量監(jiān)測能力對比(周)

方案部署后，某BRAS-MB鏈路上的客戶視訊專線出現(xiàn)監(jiān)測預警，詳情如表7所示，3條鏈路中承載4個大客戶業(yè)務，客戶C的BRAS-MB業(yè)務鏈路時延為13.70 ms，明顯高于其他客戶業(yè)務，同時伴隨業(yè)務丟包，丟包率達5%。而MB-PB上行鏈路數(shù)據(jù)無異常，因此判定故障出現(xiàn)在BRAS與MB互聯(lián)端口或互聯(lián)鏈路上。手動開啟質(zhì)量優(yōu)化功能，自動計算業(yè)務流量、業(yè)務明細及鏈路流量占比，選擇流量占比小且調(diào)度后不超限的鏈路下發(fā)調(diào)度策略，客戶專線業(yè)務最終調(diào)度至BRAS的GE1/0/2后業(yè)務質(zhì)量恢復正常。運維人員登錄BRAS和MB兩臺設備，發(fā)現(xiàn)BRAS的GE1/0/1端口光衰導致客戶業(yè)務時延突增且出現(xiàn)丟包，現(xiàn)場更換光模塊后網(wǎng)絡質(zhì)量恢復。

表7 大客戶業(yè)務質(zhì)量波動情況

正常情況下，業(yè)務丟包率達5%以上大概率是因為整體鏈路質(zhì)差導致，但未收到相關預警。因此，查看Twamp整體鏈路質(zhì)量監(jiān)測模塊，發(fā)現(xiàn)此條鏈路也有質(zhì)差數(shù)據(jù)出現(xiàn)，但未超過閾值，因此未上報鏈路質(zhì)差消息。專家分析此客戶業(yè)務屬于視訊專業(yè)業(yè)務，碼流較大丟包較明顯，考慮網(wǎng)絡整體質(zhì)量，為防止再次出現(xiàn)類似現(xiàn)象，將全網(wǎng)整體Twamp質(zhì)差上報閾值調(diào)低。

6.3 工單投訴比

圖7所示為互聯(lián)網(wǎng)質(zhì)量投訴工單前后對比。投訴工單部署后每月平均投訴量減少349單，投訴量環(huán)比下降57.5%。通過整套方案的應用及部署，本省的省網(wǎng)及多個城域網(wǎng)在兩個月內(nèi)通過Twamp監(jiān)測功能優(yōu)化質(zhì)差鏈路67條(其中AI智能預警44條)、IFIT監(jiān)測保障SLA級別專線375條、Netflow支撐流量調(diào)度10.2 G/天，初步統(tǒng)計近兩個月節(jié)約人工成本300人天。

圖7 互聯(lián)網(wǎng)質(zhì)量投訴工單前后對比

7 結(jié)束語

與傳統(tǒng)監(jiān)測方案不同，IP網(wǎng)絡質(zhì)量監(jiān)測方案將Twamp、IFIT、Telemetry和Netflow等技術做整合，在統(tǒng)一框架下利用不同技術的部署、采集和應用，共同完成網(wǎng)絡整體性能質(zhì)量和行業(yè)大客戶端到端業(yè)務性能質(zhì)量的監(jiān)測。結(jié)合AI預警完成網(wǎng)絡整體鏈路質(zhì)量、用戶業(yè)務質(zhì)量和流量擁塞占比等多維度質(zhì)量預測，最終實現(xiàn)網(wǎng)絡精細化管理及質(zhì)量提升。本文設計的質(zhì)量監(jiān)測方案在數(shù)據(jù)時效性、真實性和可靠性等方面均具備較強能力，可逐步替代現(xiàn)有探針監(jiān)測技術。同時，隨著云網(wǎng)融合發(fā)展，本文提出的重點業(yè)務實時監(jiān)測能力優(yōu)勢將更加突出。