利用NS-3平臺分析802.11無線網絡協議性能

李珊娜，安志強

(北京交通大學 信息中心，北京 100044)

0 引 言

IEEE 802.11協議是一種無線局域網協議，主要包括兩種類型，即獨立型網絡(以下簡稱ad hoc網絡)和基礎型網絡(以下簡稱Sta-AP網絡)。ad hoc網至少由兩個工作站直接通信組成，其中一個工作站負責接入點AP的工作，工作站間彼此可以直接通信，兩者間的距離必須在可以直接通信的范圍內[1]；Sta-AP網至少包含一個接入點AP和一個工作站，接入點負責基礎型網絡所有的傳輸[2]。

該文主要介紹利用NS-3平臺仿真不同的網絡拓撲結構，通過調整AP數量、節點之間的距離、節點移動速度等參數設置不同的網絡環境。實驗主要設計模擬三個節點拓撲結構、五個節點拓撲結構、五個節點遠距離拓撲結構、六個節點兩個AP拓撲結構的網絡環境，在每一種拓撲結構下對比Sta-AP網絡和ad hoc網絡的性能參數，得出一系列結論為現實網絡環境搭建提供輔助決策。

實驗中利用Wireshark和NS3的FlowMonitor功能作為網絡性能分析手段，在網絡發送端節點上加載NS-3的OnOff應用，產生發送數據包流量，在網絡接收端節點上加載NS-3的PacketSinkHelper應用模擬接收數據包應用。當節點安裝ad hoc協議時，通過加載不同的路由協議和設置節點移動參數比較其網絡性能差異情況，也驗證了路由協議的部分特性，發現Wireshark和NS-3的FlowMonitor在特定情況下獲取網絡流量的區別，最終得出結論為FlowMonitor方法本身的局限性導致這樣的現象。

1 NS-3仿真平臺

NS-3是為網絡研究和教育而開發的網絡仿真平臺，它提供了一個分組數據網絡如何工作和運行的模型，也為用戶提供了一個用于仿真實驗的仿真引擎。NS-3使用經典的Unix語言作為環境工具，在GNU/Linux平臺下開發，用C++語言實現，兼容時下流行的Python[3]。

NS-3仿真流程主要通過編寫網絡仿真腳本實現，根據實際仿真對象和仿真場景選擇相應的仿真模塊，主要包括以下內容：

(1)生成網絡節點[4]：NS-3中網絡節點是基本計算設備的抽象，節點由C++類中的Node類來描述，Node類提供了管理計算設備所需的各種方法，如網卡、應用程序、協議棧等[5]。

(2)安裝網絡設備：不同的網絡類型有不同的網絡設備，網絡設備由C++中的NetDevice類來描述，NetDevice類提供管理連接節點和信道的各種方法，如CsmaNetDevice、WiFiNetDevice和PointToPointNetDe-vice等。

(3)安裝協議棧：NS-3網絡中一般是TCP/IP協議棧，依據網絡選擇具體協議棧，如是UDP還是TCP，選擇具體的路由協議(OLSR、AODV和Global等)，并為其配置相應的IP地址。

(4)安裝應用層協議：C++中用Application類來描述被仿真的應用程序，這個類提供了管理仿真時用戶層應用的各種方法。依據選擇的傳輸層協議選擇相應的應用層協議[6]。

通過以上網絡仿真腳本的編寫，完成網絡場景配置。由此可見，搭建NS-3網絡仿真場景和搭建實際網絡類似。實驗中各種網絡拓撲結構的模擬都將采用上述過程和方法，熟練使用NS-3仿真流程尤為重要，可以參考官網的方法和實例。

2 性能分析工具

2.1 Wireshark

Wireshark是一個網絡封包分析軟件。網絡封包分析軟件的功能是擷取網絡封包，并顯示出最為詳細的網絡封包資料。Wireshark使用WinPCAP作為接口，直接與網卡進行數據報文交換。使用Wireshark將得到大量的冗余數據包列表，使用捕捉過濾器和顯示過濾器會有助于在大量的數據中迅速定位所需信息。實驗中著重分析Wireshark產生的pcap文件，它反映了網絡真實的交互過程及性能數據[7]。

2.2 FlowMonitor

FlowMonitor是為NS-3設計的網絡監控功能，它自動檢測網絡中所有的流，可以方便地收集存儲NS-3生成的網絡性能數據。NS-3提供了FlowMonitor-Help類，可以方便地創建FlowMonitor。它使用安裝在網絡節點中的探針來跟蹤節點交換的數據包，并進行測量一些參數。數據包根據它們所屬的流進行劃分，其中每個流根據探測器的特征定義，即包含協議、源地址、源端口、目的地址、目的端口的五元組。收集每個流的統計信息可以以XML格式導出，也可以直接訪問探針以請求關于每個流的特定統計數據。

3 仿真內容與結果分析

在客戶端安裝相同的應用產生網絡流量[8]，通過Wireshark和FlowMonitor來監控服務器端每秒接收網絡包的數量。下面將分別介紹不同網絡拓撲結構下的實驗結論。

3.1 三個節點網絡拓撲

三個節點組成等邊三角形的拓撲結構，如圖1所示，每個網絡節點都將同時安裝Sta-AP和ad hoc協議。其中n0作為發送端節點，n2為接收端節點，n0節點上安裝由OnOffHelper類生成的OnOff應用，通過監測n0至n2的網絡流量得出實驗結論。

圖1 三個節點拓撲結構

當n0和n2之間的距離小于294米時，從圖2中得出結論ad hoc性能更好一些；當n0和n2之間的距離等于294米時，三角形高度等于255米時，模擬ad hoc和Sta-AP協議，n2每秒接收的數據包都為0；當距離不變，三角形高度調整為50米時，Sta-AP協議下n2每秒接收的數據包為107個，而ad hoc協議下n2每秒接收的數據包仍為0個。由此可見，當超過一定距離范圍時，Sta-AP表現的更好。

圖2 不同距離時每秒接收包的數量

既然超過一定距離時Sta-AP表現更好，嘗試在當n0和n2之間的距離等于294米時，三角形高度等于50米時加載路由協議，可以發現加載AODV協議[9]時ad hoc表現的更好，加載OLSR協議時[10]，Sta-AP表現更好。

3.2 五個節點網絡拓撲

五個節點可以互相通信，每個網絡節點都將安裝Sta-AP或ad hoc協議，當節點安裝ad hoc協議時，同時也加載路由協議。結構如圖3所示。實驗中兩條鏈路將產生網絡傳輸流量，第一條為n0作為發送端節點，n2為接收端節點；第二條為n3作為發送端節點，n4為接收端節點。n0、n3節點上安裝由OnOffHelper類生成的OnOff應用，通過監測兩條鏈路的網絡流量得出實驗結論。

圖3 五個節點拓撲結構

從圖4、圖5的實驗結果可以發現，無論AP節點是靜止還是移動，ad hoc模式下接收包的數量總是Sta-AP模式的兩倍。

通過分析Wireshark產生的pcap抓包文件可以解釋上述結論的原因。通過比較Sta-AP和ad hoc模式下一個包的傳輸時間，發現ad hoc模式下n0到n2用時0.004 449 s，Sta-AP模式下n0到n2用時0.008 898 s，所以ad hoc模式下接收包的數量總是Sta-AP模式的兩倍。Sta-AP模式下n0節點要先連接n1(AP節點)傳輸用時0.004 449 s，然后n1再連接到n2傳輸用時0.004 449 s，所以累計就是0.008 898 s。因此，這也是這種網絡拓撲結構下ad hoc模式比Sta-AP模式性能更勝一籌的原因。

圖4 AP靜止時每秒接收包的數量

圖5 AP移動時每秒接收包的數量

3.3 五個節點遠距離的網絡拓撲

通過設置n0到n2之間、n3到n4之間不同的遠距離長度如600米、1 500米、3 000米，比較ad hoc模式和Sta-AP模式的性能，如圖6所示。每個網絡節點都將安裝Sta-AP或ad hoc協議，當節點安裝ad hoc協議時，同時也加載路由協議。

圖6 節點速度變化后的性能

實驗中設置除了n1節點外的節點一直都在移動，比較n1節點靜止和移動狀態下，兩個協議的性能。

實驗結果發現不管中間節點n1靜止還是移動，ad hoc模式都比Sta-AP模式性能更好。隨著距離的增加，增加節點的移動速度時，無論是ad hoc模式還是Sta-AP模式，服務端收到的包都在增加。

3.4 六個節點兩個AP的網絡拓撲

這個場景選取n0、n1為兩個AP節點，n2、n3為客戶端節點，負責發送數據包，n4和n5為服務端節點，用于接收數據包。左側的n2、n3連接n0即AP1(SSID=wifi1)，右側n4、n5連接n1即AP2(SSID=wifi2)，AP1和AP2之間用有線連接起來，每個網絡節點都將安裝Sta-AP或ad hoc協議。實驗中兩條鏈路產生網絡傳輸流量，第一條flow1為n3作為發送端節點，n5為接收端節點，第二條flow2為n2作為發送端節點，n4為接收端節點。拓撲結構如圖7所示。

圖7 六個節點兩個AP的網絡拓撲

//創建使用P2P鏈路的兩個節點n0和n1，每一個節點安裝點到點的網絡設備，在它們之間有一個點到點的信道。兩個設備被配置在一個有2 ms傳輸延時的信道上，以5 Mbps的速率傳輸數據[11]。

NodeContainer p2pNodes;

p2pNodes.Create (2);

PointToPointHelper pointToPoint;

pointToPoint.SetDeviceAttribute("DataRate",StringValue ("5Mbps"));

pointToPoint.SetChannelAttribute("Delay",StringValue ("2ms"));

NetDeviceContainer p2pDevices;

p2pDevices = pointToPoint.Install (p2pNodes);

//創建左側無線自組網節點n2和n3，并將n0作為AP1節點。AP1是個雙模節點，安裝有Sta-AP和PointToPoint兩個網絡設備。

NodeContainer leftAdhocNodes;

leftAdhocNodes.Create(2);

leftAdhocNodes.Add(p2pNodes.Get(0));

//創建右側無線自組網節點n4和n5，并將n1作為AP2節點。AP2是個雙模節點，安裝有Sta-AP和PointToPoint兩個網絡設備。

NodeContainer rightAdhocNodes;

rightAdhocNodes.Create(2);

rightAdhocNodes.Add(p2pNodes.Get(1));

//NS3缺省的設置是802.11a采用的頻段，實驗中設置為802.11b協議。

WifiHelper wifi;

wifi.SetStandard(WIFI_PHY_STANDARD_80211b);

//初始化WIFI信道和物理層

YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();

//設置傳輸損耗模型[12]

wifiPhy.Set("EnergyDetectionThreshold",DoubleValue(-80));

wifiPhy.Set("CcaMode1Threshold",DoubleValue(-81));

YansWifiChannelHelper wifiChannel;[13]

wifiChannel.SetPropagationDelay("ns3::ConstantSpeedPropagationDelayModel");

wifiChannel.AddPropagationLoss("ns3::FriisPropagationLossModel");

wifiPhy.SetChannel (wifiChannel.Create ());

//分別為左側和右側節點裝載Wifi協議

WifiMacHelper wifiMac;

wifiMac.SetType ("ns3::AdhocWifiMac");

NetDeviceContainer leftdevices = wifi.Install (wifiPhy,wifiMac,leftAdhocNodes);

NetDeviceContainer rightdevices = wifi.Install (wifiPhy,wifiMac,rightAdhocNodes);

//設置移動模型，讓節點n2、n3、n4、n5移動起來[14]

mobility.SetMobilityModel ("ns3::RandomWaypointMobilityModel","Speed",StringValue(speedConstantRandom VariableStream.str ()),

"Pause",StringValue (pauseConstantRandomVariableStream.str ()), "PositionAllocator", PointerValue (taPositionAlloc));

mobility.SetPositionAllocator (taPositionAlloc);

mobility.Install(leftAdhocNodes.Get(0));

mobility.Install(leftAdhocNodes.Get(1));

mobility.Install(rightAdhocNodes.Get(0));

mobility.Install(rightAdhocNodes.Get(1));

//設置移動模型，讓節點n0、n1移動起來

Ptr positionAlloc =

CreateObject ();

positionAlloc ->Add(Vector(200,100, 0));

positionAlloc ->Add(Vector(2800,100, 0));

mobility.SetPositionAllocator(positionAlloc);

mobility.SetMobilityModel("ns3::ConstantPositionMobilityModel");

mobility.Install(p2pNodes);

//實驗中使用OnOff模式模擬產生流量，設置n2向n4節點發送流量，設置On狀態下的速率和發包大小

OnOffHelper onoff1("ns3::UdpSocketFactory", InetSocketAddress (rightAdhocInterfaces.GetAddress(0),45));

onoff1.SetAttribute ("PacketSize", UintegerValue (packetSize));

onoff1.SetAttribute ("DataRate", StringValue ("3000000bps"));

onoff1.SetAttribute("OnTime",StringValue("ns3::ConstantRandomVariable[Constant=1]"));

onoff1.SetAttribute("OffTime",StringValue("ns3::ConstantRandomVariable[Constant=0]"));

//將n2設置為發送數據包節點

ApplicationContainer app1=onoff1.Install(leftAdhocNodes.Get(0));

app1.Start(Seconds (var->GetValue (m_dataStart, m_dataStart + 1)));

app1.Stop (Seconds (800.0))

//實驗中使用PacketSinkHelper模擬接收數據包，將n4設置為接收數據包節點。

PacketSinkHelper sink2 ("ns3::UdpSocketFactory", InetSocketAddress (rightAdhocInterfaces.GetAddress(0),45));

ApplicationContainer app2=sink2.Install(rightAdhocNodes.Get(0));

app2.Start(Seconds (var->GetValue (m_dataStart, m_dataStart + 1)));

app2.Stop (Seconds (800.0));

//實驗中使用 FlowMonitorHelper監控各個節點的流量

FlowMonitorHelper flowmon;

Ptr monitor=flowmon.Install(allNodes);

NS_LOG_INFO ("Run Simulation.");

Simulator::Stop(Seconds(800.0));

Simulator::Run ();

monitor->CheckForLostPackets();

Ptr classifier = DynamicCast (flowmon.GetClassifier());

std::map stats=monitor->GetFlowStats();

//監控各個節點的流量并輸出

for (std::map::const_iterator i=stats.begin();i!=stats.end();++i)

{

Ipv4FlowClassifier::FiveTuplet=classifier->FindFlow(i->first);

//監控flow1的流量并輸出發送包和接收包的數量

if ((t.sourceAddress == "10.1.2.2" && t.destinationAddress == "10.1.3.2" && t.destinationPort==45))

{

std::cout<<"Flow"<first<<"protocol"<

ess<<"->"<

std::cout<<"Ap1-Sta1 transmitted packets:"<second.txPackets<<" ";

std::cout<<"Ap2-Sta1 received packets:"<second.rxPackets<<" ";

}

//監控flow2的流量并輸出發送包和接收包的數量[15]

else if ((t.sourceAddress == "10.1.2.1" && t.destinationAddress == "10.1.3.1" && t.destinationPort==45))

{

std::cout<<"Flow "<first<<" protocol"<"<

std::cout<<"Ap1-Sta2 transmitted packets:"<second.txPackets<<" ";

std::cout<<"Ap2-Sta2 received packets:"<second.rxPackets<<" ";

}

實驗結果表明(見圖8)，如果客戶端節點不安裝任何路由協議，將不會發送任何數據包，安裝路由協議后，將有數據流量產生。當所有節點都靜止時，ad hoc模式比Sta-AP模式性能更好，當除了兩個AP節點靜止其他所有節點都移動時，尤其是遠距離時，Sta-AP模式性能更好。當兩個AP共用一個信道時，彼此有干擾發生。

圖8 不同信道數量的傳輸性能

3.5 FlowMonitor和Wireshark的區別

當選擇六個節點兩個AP的拓撲結構，選擇 802.11b協議模擬時，通過FlowMonitor和Wireshark監測流量的差距很大。起初分析是由于FlowMonitor的參數MaxPerHopDelay引起的，這個參數設置每一跳的最大延時，缺省值為10秒，如果超過最大延時將被認為丟包。但當分析Wireshark的pcap抓包文件，發現每一跳的延時都沒有超過10秒。

圖9 802.11a協議下的FlowMonitor流量監測

將802.11b協議換作802.11a協議重復模擬上述現象時，發現通過FlowMonitor和Wireshark監測流量的差距很小，如圖9所示。使用Wireshark監測flow1接收包數為217個，flow2接收包數為4 479個；使用FlowMonitor監測flow1接收包數為158個，flow2接收包數為4 476個。由此推斷FlowMonitor方法本身的局限性導致這樣的現象。

4 結束語

該文主要研究了通過NS-3平臺仿真不同網絡拓撲結構，充分比較ad hoc模式和Sta-AP模式性能情況。利用Wireshark和FlowMonitor監測分析數據包，得出一系列實驗結果，為搭建真實網絡環境提供依據。Ad hoc模式提供有限的無線傳輸范圍，傳輸速度是Sta-AP模式的兩倍。Sta-AP模式必須要連接有線網，可以拓展無線網的范圍，但是傳輸速度也減少一半，因為它需要花費時間傳輸信號到AP而不是直接發送到目的節點。FlowMonitor方法本身的局限性導致。