軟件定義企業(yè)級無線網絡平臺設計與實現(xiàn)

林世榮　姜守旭

摘要：本文在企業(yè)級無線網絡中引入軟件定義網絡協(xié)議并進行相應的采樣和控制設計，將網絡劃分為數(shù)據(jù)平面和邏輯平面，并在這兩個平面進行了相應的功能模塊設計與實現(xiàn)。在數(shù)據(jù)平面，本文實現(xiàn)了支持上層算法的實時數(shù)據(jù)采樣以及支持上層算法的控制動作。在邏輯平面，本文實現(xiàn)了實時的數(shù)據(jù)接收、預處理以及應用程序編程接口，為采用高級語言進行計算的優(yōu)化程序提供了支持。

關鍵詞：軟件定義企業(yè)無線網絡;數(shù)據(jù)采樣;網絡優(yōu)化

【Abstract】Thispaperintroducessoftware-definednetworkprotocolintoenterprisewirelessnetworkandcarriesoutcorrespondingsamplingandcontroldesign.Thenetworkisdividedintodataplaneandlogicplane，andcorrespondingfunctionalmoduledesignandimplementationarecarriedoutonthesetwoplanes.Inthedataplane，thispaperimplementsreal-timedatasamplingthatsupportsupper-layeralgorithmsandcontrolactionsthatsupportupper-layeralgorithms.Inthelogicplane，thispaperimplementsreal-timedatareception，preprocessingandapplicationprogramminginterface，andprovidessupportfortheoptimizationprogramthatuseshigh-levellanguagetoexecute.

【Keywords】softwaredefinedenterprisewirelessnetwork;datasampling;networkoptimization

作者簡介：林世榮（1985-），男，博士研究生，主要研究方向：軟件定義無線網絡、擁塞控制;姜守旭（1968-），男，博士，教授，博士生導師，主要研究方向：P2P網絡、數(shù)據(jù)庫、傳感器網絡。

0引言

WiFi無線網絡在生產生活實踐中已經起到了不可替代的作用，并正在呈現(xiàn)網絡規(guī)模、數(shù)據(jù)量的爆炸式增長。在無線設備方面，無線熱點的數(shù)量已從2017年的1.24*109即將增長到2022年的5.49*109規(guī)模;由此推知，來自于WiFi網絡數(shù)據(jù)的規(guī)模將在2022年超過所有IP數(shù)據(jù)量的51%。WiFi無線網絡中最重要的網絡組織形式是企業(yè)級無線網絡。企業(yè)級無線網絡指的是具有一個或者多個控制器、多個接入點的可配置可管理的無線局域網組織形式，常見的校園無線網絡、企事業(yè)單位無線網絡、公共場所無線網絡都是企業(yè)級無線網絡的常見形式。企業(yè)級無線網絡具有可中心配置管理、可軟件定義、計算能力強、網絡性能強、兼容性強等特點，尤為重要的是企業(yè)級無線網絡可以讓網絡管理人員和研究人員從設備的弱兼容性、計算能力不足等限制中解脫出來，專注于算法設計本身以提升網絡的傳輸性能。正因為如此，在軟件定義網絡協(xié)議[1]出現(xiàn)后，即迅速應用到企業(yè)級無線網絡的組織管理中心[2-5]。但是目前的企業(yè)級軟件定義無線網絡實現(xiàn)開發(fā)的出發(fā)點都是支撐各自的應用，在本文涉及的項目中，部分諸如鏈路調度、負載均衡的應用需要毫秒級的數(shù)據(jù)采樣支持、需要特有的控制動作支持、需要毫秒級的數(shù)據(jù)集研究數(shù)據(jù)傳輸擁塞與WiFi特征變量之間的關系，而這些支持從現(xiàn)有平臺中是無法得到的，所以本文開發(fā)了一個支持毫秒級數(shù)據(jù)傳輸優(yōu)化的平臺。

作為支撐優(yōu)化算法計算和執(zhí)行的平臺基礎，數(shù)據(jù)采樣一直是無線網絡中數(shù)據(jù)傳輸優(yōu)化研究的重點?？紤]到本文平臺與其他平臺之間的差距主要在于數(shù)據(jù)采樣，為此擬著重介紹無線網絡監(jiān)控方面的相關研究。在文獻[6]中，通過ping方法來獲取清華大學校園無線網絡中的數(shù)據(jù)傳輸時延，并從思科（該校網絡設備提供商）提供的簡單網絡管理協(xié)議（simplenetworkmanagementprotocol，SNMP）中提取粗粒度的網絡狀態(tài)統(tǒng)計信息，從而研究WiFi時延與網絡狀態(tài)之間的量化關系。在文獻[7-8]中，采用TCPdump（https：//www.tcpdump.org/manpages/tcpdump.1.html）獲取TCP通信的參數(shù)，收集系統(tǒng)信息syslog中的網絡狀態(tài)信息，使用SNMP獲取并反饋數(shù)據(jù)流的流量信息;在某些時間點或者采樣結束后，將數(shù)據(jù)收集到計算節(jié)點進行分析，從而得出典型網絡特征變量的特征以及數(shù)據(jù)傳輸?shù)囊恍┨卣?。在文獻[9]中，一個連接在康涅狄格大學網關路由器上的采樣設備對所有進入和流出根網關的數(shù)據(jù)包進行采樣，這些采樣涵蓋了應用層、傳輸層和網絡層的特征變量。該采樣用來研究校園網絡中的數(shù)據(jù)來源、吞吐量、延遲、丟包、同時運行的流數(shù)量、往返時間（Round-triptime，RTT）、應用反應時間等。文獻[10]中，研究了擁塞對網絡吞吐量、信道繁忙占比（最近1s內信道處于忙狀態(tài)的時間比率）、RTS-CTS機制、幀發(fā)送和接收以及接收延遲的影響。前述內容與本文的擁塞預測部分研究工作類似，但是其數(shù)據(jù)采集以及擁塞的定義存在問題：該研究受制于當時接入點（accesspoint，AP）性能的限制，其數(shù)據(jù)包信息是通過一個叫做tetheral的軟件進行采集的，而影響傳輸?shù)囊蛩厥褂靡慌_搭載sniffer（嗅探器）的IBMR32筆記本進行采集，這些相關參數(shù)包括發(fā)送速率、信道、信噪比和接收數(shù)據(jù)包量;但該研究并未嚴格區(qū)分擁塞丟包和非擁塞丟包，這也使得該研究的成果存在一定的爭議。

綜上的研究工作都具有一個特征：采樣頻率低，采樣不全面。本文旨在設計并實現(xiàn)了一個集細粒度且高頻采樣、實時預處理及優(yōu)化算法應用程序編程接口（API）輸入支持、速率控制為一體的軟件定義無線網絡平臺，以支撐毫秒級網絡優(yōu)化，支撐傳輸控制協(xié)議（TCP）對應的數(shù)據(jù)擁塞與WiFi特征變量之間的關系研究。本文研發(fā)設計的平臺旨在達到已有工作不能支撐的總體水平。

本文研究內容安排如下：第一部分給出平臺的整體架構及功能模塊;第二部分討論了平臺的數(shù)據(jù)采樣;第三部分介紹了本文設計平臺上的一個擁塞窗口回歸應用，第四部分總結全文。

1平臺架構

本節(jié)立足于研究本文企業(yè)級軟件定義無線網絡平臺的設計與實現(xiàn)，主要介紹平臺的設計思想、采樣模塊、數(shù)據(jù)處理模塊、以及相應的邏輯控制模塊。對此可做闡釋分述如下。

1.1平臺結構簡介

在軟件定義網絡協(xié)議（通常為OpenFlow）協(xié)議中，網絡被劃分為數(shù)據(jù)傳輸平面和邏輯控制平面兩個部分。其中，數(shù)據(jù)傳輸平面主要負責數(shù)據(jù)傳輸，而未能兼管邏輯相關的控制;邏輯平面主要負責邏輯的生成及管理。這是區(qū)別于傳統(tǒng)數(shù)據(jù)傳輸網絡的，在傳統(tǒng)通信網絡中并不區(qū)分邏輯平面與數(shù)據(jù)平面，不同廠家的數(shù)據(jù)設備設計并未形成統(tǒng)一的規(guī)范，各自算法固化在數(shù)據(jù)傳輸設備上，導致不同廠商的設備的協(xié)同工作調試極為困難，并且需要專業(yè)人員的配合參與。本文平臺按照軟件定義網絡協(xié)議的邏輯進行開發(fā)，設計結構如圖1所示。其中，無線接入點處于數(shù)據(jù)傳輸平面，與因特網連接，負責將用戶請求的數(shù)據(jù)下行傳輸?shù)揭苿釉O備上。無線接入點上運行的數(shù)據(jù)采樣平面將數(shù)據(jù)實時采集并傳送給控制器和數(shù)據(jù)采集器進行接收、存儲和運算。一般計算能力強的服務器充當控制器角色，控制器上完成數(shù)據(jù)接收、處理并通過應用程序編程接口的形式傳送給上層的優(yōu)化算法進行數(shù)據(jù)傳輸優(yōu)化計算，以提升數(shù)據(jù)傳輸?shù)难舆t和吞吐量性能。運行在控制器上的功能如數(shù)據(jù)傳輸性能與WiFi特征變量之間關系的研究、網絡優(yōu)化配置管理、負載均衡、鏈路調度以及傳輸協(xié)議優(yōu)化。

如上文所述，傳統(tǒng)數(shù)據(jù)通信網絡中并不區(qū)分數(shù)據(jù)傳輸平面和邏輯控制平面，傳輸控制邏輯直接固化在數(shù)據(jù)傳輸設備上，而軟件定義網絡中將數(shù)據(jù)傳輸邏輯剝離到控制器上運行，交換機只負責按照控制器生成的傳輸控制邏輯進行數(shù)據(jù)傳輸。所以構建軟件定義無線網絡的第一步是將無線接入點轉化成為虛擬交換機[11]。這一過程通常采用OpenvSwitch（www.openvswitch.org）來實現(xiàn)，OpenvSwitch是一個軟件定義網絡套件，通過接管數(shù)據(jù)傳輸并創(chuàng)建相應流表的方式將傳統(tǒng)網絡設備虛擬為交換機，使其像真正的軟件定義交換機一樣配合控制器工作。總地來說，在無線接入點上配合OpenvSwitch工作還需要OpenWRT，OpenWRT是一個為無線接入設備開發(fā)的Linux操作系統(tǒng)。OpenvSwitch可以通過編程成為用戶控件程序或者內核空間模塊的模式運行在OpenWRT上，完成數(shù)據(jù)的傳輸控制。在無線接入點被虛擬為交換機后，本文通過編寫內核模塊以及用戶空間程序的方式對企業(yè)級無線網絡的特征變量（網絡狀態(tài)變量）進行采樣、冗余消除和傳輸。并在控制器上實時接收處理的同時通過API的方式提供給網絡優(yōu)化算法使用。網絡優(yōu)化算法在數(shù)據(jù)采樣基礎上計算出網絡優(yōu)化策略后，通過編碼、且加載到本文開發(fā)的消息中傳輸給接入點，接入點按照接收到的控制指令并在本文開發(fā)的控制模塊的基礎上進行網絡優(yōu)化控制。這里將針對整個控制過程中涉及的采樣、數(shù)據(jù)接收及預處理、運算和控制等過程及對應的模塊做出研討論述如下。

1.2數(shù)據(jù)平面模塊設計

1.2.1數(shù)據(jù)采樣模塊

如前文介紹，數(shù)據(jù)采樣是本文區(qū)別于其他平臺的主要原因。通常軟件定義網絡平臺通過軟件定義網絡協(xié)議自帶的狀態(tài)消失進行數(shù)據(jù)采樣。但是這種方式采樣頻率低、采樣并不全面，不足以支撐數(shù)據(jù)傳輸優(yōu)化算法的研究。本文數(shù)據(jù)采樣的目的在于支撐毫秒級的鏈路調度研究以及TCP擁塞與WiFi特征變量之間的關系的研究。故本文在接入點內核開發(fā)了相應的模塊，采樣各種狀態(tài)信息，如：

（1）采樣WiFi接入點的狀態(tài)信息。如信道忙占比、信道接收占比、信道傳輸占比、信道掃描占比等，信道的狀態(tài)占比是在過去1s內處于該狀態(tài)的時間比率。比如信道忙占比為0.6，表示在過去的1s內，有600ms間信道處于工作狀態(tài)。

（2）鏈路狀態(tài)信息。如鏈路傳輸/接收的數(shù)據(jù)包數(shù)量、傳輸失敗、傳輸重試、鏈路信噪比等變量。

（3）拓撲信息。從Beacon信標中可以得到接入點接收到的信標信息，可以顯示鄰居接入點的數(shù)量及信號強度信息。

（4）隊列信息。隊列是數(shù)據(jù)傳輸過程中的一個重要結構體，數(shù)據(jù)進入設備后會被存儲在相應的隊列中等待被傳輸，TCP中的擁塞丟包就發(fā)生在數(shù)據(jù)隊列中，所以本文著重對接入點上的隊列信息進行了采樣。

（5）數(shù)據(jù)包信息。本文在OpenvSwitch的datapath中對數(shù)據(jù)包的TCP頭部、IP頭部信息進行了采集，得到數(shù)據(jù)傳輸?shù)亩丝?、IP地址、物理地址等。

本文采集的數(shù)據(jù)見表1。

表1中，出現(xiàn)的“_3”表示來自于隊列3的數(shù)據(jù)，下標為“_5”的數(shù)據(jù)項來自于隊列5的數(shù)據(jù)。這是因為OpenWRT在網件公司的NETGEARWNDR3800/4300無線路由器上會產生5個隊列，標記為1，…，5，但是通常數(shù)據(jù)采隊列3中被傳輸，當且僅當數(shù)據(jù)壓力大、數(shù)據(jù)突發(fā)產生的時候，部分數(shù)據(jù)才會在隊列5中被傳輸。其他數(shù)據(jù)的解釋說明已在表1中做出描述了，這些數(shù)據(jù)中如在擁塞丟包、非擁塞丟包、數(shù)據(jù)包數(shù)量等是在每個數(shù)據(jù)包都被采樣，連接終端數(shù)量是按照10Hz的頻率進行采樣，其他的數(shù)據(jù)則按照250Hz的頻率進行采樣。

公共場所以及辦公環(huán)境是企業(yè)級無線網絡的典型場所，為了使得采集的數(shù)據(jù)集具有代表性，本文選擇了H大學的圖書館來表征企業(yè)級無線網絡中的普通公共場所，并選擇H大學的實驗室作為典型的辦公場所代表。本文在H大學的圖書館布置了12個接入點，在該大學某實驗樓的4樓布置了8個接入點。這些接入點并不設置接入密碼，方便用戶接入。采樣持續(xù)了2個月，總共采集了1060.9GB（600.9GBTCP頭和460GB的跨層統(tǒng)計數(shù)據(jù)）原始數(shù)據(jù)，該數(shù)據(jù)集的規(guī)模是TB級別的，并在與標準的企業(yè)級無線網絡環(huán)境相同來采樣的情況下，能支撐典型的企業(yè)無線網絡中的優(yōu)化研究。

1.2.2負載監(jiān)控

網絡監(jiān)控的目的在于在提醒網絡管理員或者網絡優(yōu)化算法在合適的時候發(fā)起網絡優(yōu)化配置或者選出數(shù)據(jù)傳輸優(yōu)化算法以最大化網絡傳輸性能。在一個典型的企業(yè)級軟件定義無線網絡中，通常有一個或者多個控制器、多個接入點和多個無線終端，控制器通過無線接入點采集的實時數(shù)據(jù)，判定網絡當前所屬的狀態(tài)。當符合一定的特征的時刻發(fā)起網絡優(yōu)化算法。

1.2.3自定義消息和自定義動作

在軟件定義網絡協(xié)議（如OpenFlow）中，通常有一套專門的消息用于在交換機和控制器之間傳輸采樣消息和控制消息。比如在OpenFlow協(xié)議中，采用6553端口傳輸這些消息。但是因為系統(tǒng)實現(xiàn)的原因，這一消息機制并不能用于傳輸本文的采樣信息和控制信息。所以在OpenFlow中的Experimenter消息的框架下，本文開發(fā)了OpenvSwitch與控制器套件（RYU，https：//ryu-sdn.org/）之間的自定義消息。這樣在控制器RYU框架下計算出的控制消息可以通過用戶自定義消息傳送給交換機上的OpenvSwitch，后者在對應的用戶空間協(xié)議ofprotocol.c中進行接收和處理。因為數(shù)據(jù)傳輸優(yōu)化通常涉及到數(shù)據(jù)流之間的速率控制問題，同時要求數(shù)據(jù)傳輸?shù)乃俾士刂谱詈貌灰婕皝G包，因為丟包會造成額外的影響，所以本文開發(fā)了一種基于擁塞窗口的控制方式，其思路是通過修改ACK確認數(shù)據(jù)包中的廣告串口限制發(fā)送窗口的方式進行速率控制。本次研究中即在OpenvSwitch框架下開發(fā)了一個傳輸控制層動作set_window_to（x）用于改變當前數(shù)據(jù)傳輸數(shù)據(jù)流的速率，其中x是期望的網絡速率。

1.3邏輯平面模塊

邏輯控制在使用軟件定義網絡協(xié)議的數(shù)據(jù)傳輸網絡中扮演著“大腦”的角色，負責數(shù)據(jù)傳輸邏輯的生成和管理。如前文所述數(shù)據(jù)傳輸?shù)倪壿嫳粡臄?shù)據(jù)傳輸設備剝離到控制器上進行計算，本文的邏輯控制建立在數(shù)據(jù)采樣上層，負責對實時數(shù)據(jù)繼續(xù)接收和處理，以及控制邏輯的運算。其中，數(shù)據(jù)接收和處理是有難度的，因為企業(yè)級無線網絡中無論是設備規(guī)模、還是數(shù)據(jù)規(guī)模都是巨大的，但是只有對采樣數(shù)據(jù)進行統(tǒng)計后才能得到最終可用的數(shù)據(jù)。比如信道的各種狀態(tài)占比需要統(tǒng)計各個接入點在過去1s的數(shù)據(jù)信息。而處理后的統(tǒng)計數(shù)據(jù)也不能直接供給優(yōu)化算法使用，還要整合成應用程序編程接口的形式供優(yōu)化算法進行調用。為此，對數(shù)據(jù)的接收過程可做如下分析詳述。

1.3.1數(shù)據(jù)實時接收及預處理

數(shù)據(jù)接收預處理的作用在于實時地處理接收到的來自于不同無線接入點的采樣數(shù)據(jù)，并統(tǒng)計得到可以用于網絡優(yōu)化算法的輸入變量。因為企業(yè)級無線網絡中具有設備密度大、設備及數(shù)據(jù)規(guī)模大、設備與網絡設備之間的連接關系復雜（及鏈路動態(tài)變化）等特征。所以數(shù)據(jù)接收處理的難度較大。并且采樣到的元數(shù)據(jù)需要轉化成為統(tǒng)計數(shù)據(jù)才具有價值，如前文論述的信道狀態(tài)占比，以及隊列信息、鏈路信息等等都需要進行統(tǒng)計分析，所以應該在數(shù)據(jù)流之間維護大量的采樣數(shù)據(jù)緩存以計算網絡狀態(tài)變量的統(tǒng)計信息。在得到統(tǒng)計數(shù)據(jù)后，為了配合優(yōu)化算法的執(zhí)行，還要開發(fā)應用程序編程接口。所以本文采用C語言進行多線程編程以支持數(shù)據(jù)的接收，并且通過混合編程的方式開發(fā)應用程序編程接口來支撐網絡優(yōu)化算法的執(zhí)行。

仍需一提的是TCP窗口的獲取。因為歷史原因，嵌套在數(shù)據(jù)的TCP頭部的接收窗口并不是該數(shù)據(jù)流對應的真實接收窗口。接收窗口在數(shù)據(jù)傳輸?shù)倪^程中表示當前數(shù)據(jù)接收方的接收能力，也是數(shù)據(jù)發(fā)送方數(shù)據(jù)發(fā)送的上限，發(fā)送方的發(fā)送窗口應該小于擁塞窗口和接收窗口大小。因此可以通過修改接收窗口的方式來限制當前數(shù)據(jù)流的速率。但是TCP頭部中的窗口并不是當前數(shù)據(jù)流的真正窗口大小。這是因為在數(shù)據(jù)傳輸網絡的初期，網絡傳輸介質的能力相對較弱，此時采用8位大小就可以表征數(shù)據(jù)速率。但是隨著數(shù)據(jù)通信技術的發(fā)展，數(shù)據(jù)傳輸介質的能力得到了提升，傳統(tǒng)8位大小的接收窗口不足以支撐數(shù)據(jù)的高速率傳輸，隨后就在RFC1323（https：//tools.ietf.org/html/rfc1323）中提出了窗口放縮選項位，額外增加8位配合原有8位表征數(shù)據(jù)的接收窗口。但是該8位不在數(shù)據(jù)傳輸過程中發(fā)送，只在數(shù)據(jù)流的建立過程中相互通知。所以要得到一個數(shù)據(jù)流的接收窗口大小就要獲得該窗口放縮選項以及當前TCP頭部中的窗口大小。同時，本文設計中在接入點上的OpenvSwitch上為每個數(shù)據(jù)流建立了相應的狀態(tài)機，保存數(shù)據(jù)流建立過程中的各種協(xié)調信息。并在TCP數(shù)據(jù)流的各個生命過程中維護狀態(tài)機的狀態(tài)變化，從而獲取到數(shù)據(jù)流的當前窗口大小，配合存儲的窗口放縮選項，可以計算出當前數(shù)據(jù)流的接收窗口大小。

1.3.2負載均衡

負載均衡用來管理客戶端設備與無線接入點之間的連接關系，從而達到均衡網絡負載以最大化數(shù)據(jù)傳輸?shù)难舆t和吞吐量性能的目的。該功能是建立在數(shù)據(jù)采樣基礎上的，通?？梢詫⑵湫问交癁橐粋€混合整數(shù)規(guī)劃問題，求解并得到相應的連接關系，執(zhí)行該連接關系，負載均衡則得以實現(xiàn)。

1.3.3過載診斷

過載診斷通過研究網絡負載與網絡特征變量之間的關系，采用合適的回歸模型可以得到當前的網絡負載情況，也可以采用預測模型得到未來的網絡負載狀況，從而支撐各種網絡優(yōu)化算法的運行。

2企業(yè)級無線網絡中擁塞窗口回歸

在本節(jié)中，介紹本文支撐網絡優(yōu)化的一個典型應用：擁塞窗口回歸。擁塞窗口是TCP數(shù)據(jù)傳輸?shù)囊粋€重要參數(shù)，表示在未接收到下一個ACK的情況下最多可以注入網絡的數(shù)據(jù)包的數(shù)量。通常TCP的發(fā)送窗口控制著發(fā)送速率，但是TCP的發(fā)送窗口必須同時小于擁塞窗口和接收窗口。已有研究表明在一般情況下，接收窗口大于擁塞窗口，所以如果在TCP傳輸?shù)闹虚g節(jié)點上得到擁塞窗口，則可以通過此擁塞窗口來控制TCP的速率以規(guī)避不必要的擁塞產生。文獻[12]給出了一種通過未確認數(shù)據(jù)包量（unacknowledged，UNA）來進行擁塞窗口回歸的方法，據(jù)此測算，該方法在有線網絡中能夠達到0.9以上的精確度，只是同時在研究中也發(fā)現(xiàn)，僅僅使用UNA在企業(yè)級無線網絡中只能達到0.2911的準確度。

既然只采用UNA解決不了企業(yè)級無線網絡中的中間節(jié)點上的擁塞窗口回歸問題，那么在企業(yè)級無線網絡中，中間節(jié)點上的擁塞窗口回歸的性能極限到底是多少，應該采用什么樣的特征變量進行回歸？本文開展了相應的回歸研究。該回歸研究擬欲設計TCP的擁塞窗口，限于篇幅，這里將重點評述擁塞窗口的采樣工作。

為了采集作為回歸對象的擁塞窗口，本文在TCP發(fā)送端進行了相應的采樣實現(xiàn)，特開發(fā)了一個類似于Linux下“ss”命令的應用程序。該應用程序通過NetLink消息從內核獲取當前數(shù)據(jù)流的統(tǒng)計狀態(tài)信息，包括擁塞窗口、延遲等數(shù)據(jù)。同時再依據(jù)表1中的特征數(shù)據(jù)采樣，共同組成回歸所使用的數(shù)據(jù)集。研究中需特別關注的就是時間同步，本文在局域網內部架設專有的時間服務器以給采樣的設備提供共同的時間，從而統(tǒng)一了采樣點的時間，使得數(shù)據(jù)集具有共同的時鐘。

在采樣數(shù)據(jù)集的基礎上，研究了表1中的特征變量與擁塞窗口之間的關系，從而得出所選特征變量以及使用seaborn.heatmap計算的相關性見表2。由表2可知，其中的數(shù)據(jù)項與擁塞窗口有顯著的關系，即顯示了UNA、所有數(shù)據(jù)鏈路的數(shù)據(jù)速率、信道傳輸占比、信號強度、信道忙占比、重傳率以及噪聲與擁塞窗口具有顯著的關系。依據(jù)這些特征變量，本文采用標準的機器學習回歸方法研究了將其用于擁塞窗口的回歸精度，最終結果見表3。

回歸結果顯示，如果僅僅使用UNA進行回歸，最好也只能達到0.2911的精度，但是如果選用本文選擇的特征變量，該回歸精度可以提升到0.5374?；谶x擇的特征變量，本文采用回歸表現(xiàn)最好的XGBregressor算法對擁塞窗口進行回歸，并截取了部分回歸結果如圖2所示。圖2中，藍色是實際窗口，紅色是通過XGBregressor獲得的窗口。仿真結果顯示回歸窗口與實際窗口擬合程度可以接受。

3結束語

本文采用軟件定義網絡協(xié)議以及思想，設計并提出了企業(yè)級軟件定義無線網絡優(yōu)化管理平臺。分別在數(shù)據(jù)平面和邏輯平面設計了相應的網絡狀態(tài)采樣、數(shù)據(jù)接收處理、以及應用程序編程接口，最終實現(xiàn)了一個實時的擁塞窗口回歸應用，測試了平臺的可用性。

參考文獻

[1]MCKEOWNN，ANDERSONT，BALAKRISHNANH，etal.OpenFlow：Enablinginnovationincampusnetworks[J].ACMSIGCOMMComputerCommunicationReview，2008，38（2）：69-74.

[2]LUENGOE.Anopenflow-basedwirelessusermanagementsystem[D].Canada：UniversityofOntarioInstituteofTechnology，2016.

[3]SHALIMOVA，ZUIKOVD，ZIMARINAD，etal.AdvancedstudyofSDN/OpenFlowcontrollers[C]//CEE-SECR'13：Proceedingsofthe9thCentral&EasternEuropeanSoftwareEngineeringConferenceinRussia.Moscow，Russia：ACM，2013：1-6.

[4]SURESHL，SCHULZ-ZANDERJ，MERZR，etal.TowardsprogrammableenterpriseWLANSwithOdin[C]//ProceedingsofthefirstworkshoponHottopicsinsoftwaredefinednetworks.Helsinki，F(xiàn)inland：dblp，2012：115-120.

[5]CORONADOE，KHANSN，RIGGIOR，etal.5G-EmPOWER：Asoftware-definednetworkingplatformfor5Gradioaccessnetworks[J].IEEETransactionsonNetworkandServiceManagement，2019，16（2）：715-728.

[6]PEIChanghua，ZHAOYoujian，CHENGuo，etal.WiFicanbetheweakestlinkofroundtripnetworklatencyinthewild[C]//IEEEINFOCOM2016-The35thAnnualIEEEInternationalConferenceonComputerCommunications.SanFrancisco，CA，USA：IEEE，2016：1-9.

[7]MENGXiaoqiao，WONGSHY，YUANYuan，etal.Characterizingflowsinlargewirelessdatanetworks[C]//Proceedingsofthe10thannualinternationalconferenceonMobileComputingandNetworking.Philadelphia，PA，USA：ACM，2004：174-186.

[8]HENDERSONT，KOTZD，ABYZOVI.Thechangingusageofamaturecampus-widewirelessnetwork[C]//Proceedingsofthe10thannualinternationalconferenceonMobileComputingandNetworking.Philadelphia，PA，USA：ACM，2004：187-201.

[9]CHENX，JINR，SUHK，etal.NetworkperformanceofsmartmobilehandheldsinauniversitycampusWiFinetwork[C]//Proceedingsofthe2012InternetMeasurementConference.Boston，USA：ACM，2012：315-328.

[10]JARDOSHAP，RAMACHANDRANKN，ALMEROTHKC，etal.UnderstandingcongestioninIEEE802.11bwirelessnetworks[C]//Proceedingsofthe5thACMSIGCOMMconferenceonInternetMeasurement.Berkeley，CA，USA：Dblp，2005：279-292.

[11]YIAKOUMISY，BANSALM，COVINGTONA，etal.BeHop：AtestbedfordenseWiFinetworks[J].ACMSigmobileMobileComputingandCommunicationsReview，2015，18（3）：71-80.

[12]HAGOSDH，ENGELSTADPE，YAZIDIA，etal.AmachinelearningapproachtoTCPstatemonitoringfrompassivemeasurements[C]//2018WirelessDays（WD）.Dubai，UnitedArabEmirates：IEEE，2018：164-171.