- 1 -
PROJECTE FINAL DE MÀSTER
Dynamic Buffer Size Allocation in Wireless Networks for Non-
Elastic Traffic
Estudis: Màster en Enginyeria Telemàtica
Autor: Rubén Rumipamba Z.
Director: Luis J. de la Cruz, PhD
Enero 2014
- 2 -
- 3 -
Content
Agradecimiento y Dedicatoria ....................................................................................... 5
Resum ....................................................................................................................... 7
Resumen ................................................................................................................... 8
Abstract .................................................................................................................... 9
1. Introduction ................................................................................................... 11
2. MAC Protocol IEEE 802.11 .............................................................................. 13
2.1 CSMA/CA Description ........................................................................................... 13
2.2 802.11e Description ............................................................................................... 17
2.2.1 Performance Analysis of EDCA in WMN .............................................................. 20
2.3 802.11s Description ............................................................................................... 21
2.3.1 Mesh Creation ................................................................................................ 23
2.3.2 Internetworking with IEEE 802.11s ..................................................................... 24
2.3.3 Path Selection Mechanism ................................................................................ 25
2.3.3.1 Hybrid Wireless Mesh Protocol ..................................................................... 25
2.3.3.2 Airtime Link Metric .................................................................................... 28
3. Buffer Sizing ................................................................................................... 30
3.1 Packets in the system and packets seen by arrivals and departures ................................ 30
3.2 The computation of probabilities: a maximum entropy approach ..................................... 33
3.2.1 Infinite buffer size............................................................................................ 33
3.2.2 Finite buffer size ............................................................................................. 35
3.3 Application to the buffer sizing for the G/G/1/K queuing system................................... 36
3.4 Numerical and simulation results .............................................................................. 38
4. Wi-Fi and Mesh Modules Description in Ns-3 ...................................................... 44
4.1 Wi-fi Module in Ns-3 ............................................................................................. 44
4.2 Mesh IEEE 802.11s Module in Ns-3 .......................................................................... 46
4.2.1 Supported Features ......................................................................................... 47
4.2.2 Unsupported Features...................................................................................... 47
4.2.3 Module Implementation in ns-3 .......................................................................... 48
5. Simulation and Obtained Results ........................................................................ 51
5.1 Dynamic Buffer Size Allocation in WLAN ................................................................... 51
5.1.1 Memory utilization efficiency ............................................................................. 55
5.1.2 Time Delays Analysis ....................................................................................... 59
5.2 Dynamic Buffer Size Allocation in WMN ............................................................ 66
5.2.1 Scenario-2: Chain Mesh Network Topology ......................................................... 66
5.2.1.1 Dynamic Mechanism with Finite Buffer Size .................................................... 87
5.2.2 Scenario-3: Wireless Mesh Topology .................................................................. 92
- 4 -
5.2.2.1 Reactive (On Demand) Mode ........................................................................ 95
5.2.2.2 Proactive Mode ......................................................................................... 104
5.3 Implementation Issues ..................................................................................... 108
6. Conclusions and Future Works ........................................................................ 110
Appendix A ............................................................................................................ 112
Appendix B ............................................................................................................. 145
References .............................................................................................................. 147
List of Figures ......................................................................................................... 151
List of Tables .......................................................................................................... 154
- 5 -
Agradecimiento y Dedicatoria
A Dios que con su ayuda me ha permitido cumplir uno más de mis objetivos de adquirir nuevos
conocimientos más allá de las fronteras de mi país y acompañarme a lo largo de esta travesía.
A mi hijo Matías E. Quien es mi motivación, la razón de mi esfuerzo constante y mi gran
alegría.
A mis padres, familia cercana y amigos, que han estado a mi lado respaldándome y confiando
en mí en todo momento aún a la distancia.
Al Prof. Luis J. de la Cruz por su guía académica importante en la realización de este trabajo.
A la Secretaría Nacional de Ciencia y Tecnología (SENESCYT) y Gobierno de la República del
Ecuador por todo el apoyo y respaldo económico recibido para la culminación de mis estudios de
cuarto nivel, y su acertada inversión en la Educación Superior.
- 6 -
- 7 -
Resum
El dimensionament de buffers en els equips de comunicació (routers i switches) és un aspecte
important a tenir en compte doncs afecta directament a diversos paràmetres de prestacions de
les xarxes com la probabilitat de pèrdua de paquets, el temps d'extrem a extrem, així com a la
utilització dels canals de transmissió, etc. La solució a l'assignació òptima de memòria és el
dimensionament de buffers basat en la màxima entropia. Aquest mecanisme proposa que els
dispositius siguin capaços d'auto-configurar dinàmicament la seva grandària de buffer garantint
una probabilitat de pèrdua de paquets amb el mínim d'espai de memòria. Amb l'aplicació
d'aquesta solució, s'evita el fenomen conegut com bufferbloat que introdueix retards excessius
als usuaris provocats per un sobre-dimensionament de l'espai de buffer. A més, s'optimitza la
utilització de la memòria, la qual cosa podria ser molt beneficiós en equips de xarxa amb
múltiples interfícies. Aquest treball implementa la solució del dimensionament de buffers basat en
la màxima entropia en canals compartits com són les xarxes sense fils Wi-Fi i les Wireless Mesh
Networks (WMN). Es demostra l'operació eficient de l'algorisme a través de diversos paràmetres
de mesurament d'acompliment i operació. A les xarxes WLAN i WMN, l'algorisme ha estat
avaluat amb els mecanismes d'accés al mitjà per defecte: DCF (Distributed Coordination
Function) i EDCAF (Enhanced Distributed Channel Access Function) respectivament. Per
EDCAF s'ha realitzat l'anàlisi amb dues classes de servei.
Paraules clau: dimensionament de buffers, xarxes sense fils, pèrdua de paquets, màxima entropia,
sistemes de cues
- 8 -
Resumen
El dimensionamiento de buffers en los equipos de comunicación (routers y switches) es un
aspecto importante a tener en cuenta pues afecta directamente a varios parámetros de
desempeño de las redes como la probabilidad de pérdida de paquetes, tiempos de extremo a
extremo, así como a la utilización de los canales de transmisión, etc. La solución a la asignación
óptima de memoria es el dimensionamiento de buffers basado en la máxima entropía. Este
mecanismo propone que los dispositivos sean capaces de auto-configurar dinámicamente su
tamaño de buffer garantizando una probabilidad de pérdida de paquetes con el mínimo de espacio
de memoria. Con la aplicación de esta solución, se evita el fenómeno conocido como bufferbloat
que introduce retardos excesivos a los usuarios provocados por un sobre-dimensionamiento del
espacio de buffer. Además, se optimiza la utilización de la memoria, lo que podría ser muy
beneficioso en equipos de red con múltiples interfaces. Este trabajo implementa la solución del
dimensionamiento de buffers basado en la máxima entropía en canales compartidos como son las
redes inalámbricas Wi-Fi y Wireless Mesh Networks (WMN). Se demuestra la operación eficiente
del algoritmo a través de varios parámetros de medición de desempeño y operación. En las
redes WLAN y WMN, el algoritmo ha sido evaluado con los mecanismos de acceso al medio por
defecto: DCF (Distributed Coordination Function) y EDCAF (Enhanced Distributed Channel
Access Function) respectivamente. Para EDCAF se ha realizado el análisis con dos clases de
Servicio.
Palabras clave: dimensionamiento de buffers, redes inalámbricas, pérdida de paquetes, máxima
entropía, sistemas de colas.
- 9 -
Abstract
The dimensioning of the buffers in communication devices (routers and switches) is an
important aspect to take into account since it affects some parameters of network performance
such as: loss probability, end-to-end delay as well as transmission channels utilization, etc. The
properly solution to dynamic buffer size allocation is based on maximum entropy. This
mechanism proposes the network devices become able to dynamically self-configure their buffer
sizes guaranteeing a specific packet loss probability with the minimum buffer size. With this
solution, the bufferbloat effect is minimizing, which introduces unnecessary excessive delays to
the users caused by the over-dimensioning of the buffer size. Also, it allows optimizing the
memory utilization, which could be very beneficial in network devices with multiple interfaces.
This work implements the dynamic buffer size allocation solution based on maximum entropy in
shared channels such as the Wireless LAN (WLAN) and Wireless Mesh Networks (WMN). It is
demonstrated the efficient operation of the dynamic mechanism through measured performance
and operation parameters. In the networks WLAN and WMN, the algorithm has been evaluated
with default mechanisms for medium access channel: DCF (Distributed Coordination Function)
and EDCAF (Enhanced Distributed Channel Access Function) respectively. For EDCAF, two
classes of service have been taking into account.
Keywords: Buffer sizing, wireless networks, packet loss, maximum entropy, queuing systems.
- 10 -
- 11 -
1. Introduction
For telecom operators it is very important to offer data transmissions with Quality of Service
(QoS) especially when sensible and critical data are sent by the network. The parameters to
guarantee are: bandwidth, loss packets, delay and jitter. Each application demands an specific
requirement depending on its Grade of Service (GoS). The communication devices that know
about these requirements assign the necessary resources to guarantee always the offered quality
of service. The network resources can be bandwidth and buffer space in the communication
devices. The requirement of each packet is specified in its header with the different
encapsulation protocols of Layer 3 (IP) and Layer 2 (MPLS, IEEE 802.3, IEEE 802.11, Frame
Relay, ATM, etc). The packet flows are grouped in queues and the more sensible data (those
that demand more resources) have the highest priority. Generally, the queues with highest
priority packets are those that belong to network control traffic, after those the transmission
applications in real time over UDP (non-elastic traffic), then specific application can be
processed in an intermediate queue. On the other hand, the applications without QoS
requirements will be processed in a Best Effort queue. Finally, the applications which are
transmitted in background can be allocated in a lowest priority queue.
Referent to buffer space resource it has been demonstrated by some studies that it is
convenient to have a memory allocation according to the network traffic load in order to avoid
the bufferbloat effect [13] and cause delay in the packet transmissions. In this sense, it has
been developed the algorithm purposed in [12] which provides the buffer auto-sizing in network
devices based in maximum entropy. The algorithm guarantees a specific packet loss probability
for non-elastic flows but avoiding unnecessary processor overloading. Furthermore, the
algorithm operates efficiently in dedicated channels [12] as well as in shared channels, like
Wireless Local Area Networks (LAN) and Wireless Mesh Networks (WMN), as it is demonstrated
in the present work.
A small buffer size is extremely value in all-optical packet switching routers design and
construction. Nevertheless, too small buffers increase the packet losses and reduce the link
utilization when TCP-alike protocols are used. Dimensioning routers’ buffer size is therefore not
an easy task and is an active research topic above all for wired routers. Wireless devices become
increasingly part of the edge access networks. However, less attention has been provided to
sizing buffers in such wireless devices where new challenging issues arise [11].
On the other hand, the growth in the use of mobile devices and their increasing computational
capacity, together with the user ubiquitous access expectations, make wireless networking
- 12 -
technologies, (like wireless local area networks (WLAN), mobile ad-hoc networks (MANETs),
wireless mesh networks (WMNs), etc.) become increasingly demanded. When dealing with the
task of buffer sizing for wireless devices new problems arise. This is due to the fact that the node
transmission state does not depend only on itself, but also on the state of the other nodes inside
the same collision domain. In this work we also extend the method for wireless devices working
over shared channels and to be used during the network operation period. We provide to these
devices the capability of dynamically self-configure its buffer sizes according to the traffic load
variation and keeping bounded the packet loss probability. Extensive simulations have been done
to verify the proper performance of the proposal. We evaluate different scenarios varying the
network topology and load conditions. We analyze two kinds of load variations: firstly, when the
variations are due to changes in the traffic generated by a specific node; and secondly, when the
load fluctuation is due to activation or deactivation of different nodes inside the network.
In summary, the purpose of this work is to provide to devices which transmit over shared
channels a straightforward method, based on easily measured parameters, to self-configure and
efficiently manage their available memory. This is achieved by dynamically adapting their buffer
sizes according to the traffic load variation during the network operation. The method is based
on the application of the maximum entropy principle.
The rest of this work is organized as follows. In chapter 2 it is described the fundamentals of
IEEE 802.11 standard and its enhancements 802.11e and 802.11s. The proposed mechanism to
dynamically allocate the buffer size via maximum entropy is presented in chapter 3. Chapter 4
presents the Wi-fi and Mesh models implemented in network simulator ns-3. The evaluation
results are shown and explained in the Chapter 5. Finally, in the chapter 6 the conclusions of
this work are summarized.
- 13 -
2. MAC Protocol IEEE 802.11
The MAC Layer of IEEE 802.11 standard [11] has the function to offer channel access to
different stations which transmit in infrastructure (Basic Service Set - BSS) or non-infrastructure
mode (Independent Basic Service Set -BSS). The MAC layer also offers support to the upper
layers and provides services such as: fragmentation, encapsulation, frame error control, etc. In
this study, a set of simulations were executed with infrastructure mode in the case of Wireless
LAN and non-infrastructure in the case of Wireless Mesh Networks (WMN). The fundamentals of
the medium access channel are described in the following sections.
2.1 CSMA/CA Description
The IEEE 802.11 standard defines three main functions for the channel access: Distributed
Coordination Function (DCF), Point Coordination Function (PCF) and Hybrid Coordination
Function (HCF). The first one has to be enabled mandatorily in the stations and it was used in
the simulations. This function uses the Carrier Sense Multiple Access protocol with Collision
Avoidance (CSMA/CA). At difference of Ethernet in IEEE 802.11 it is not possible to detect
collisions because the stations cannot sense the medium while they are transmitting. Figure 1
shows the flow chart of the CSMA/CA procedure.
Fig.1. Flow chart for CSMA/CA
- 14 -
The procedure of CSMA/CA is the following: when a station wants to send a frame, first the
station senses the medium to detect if another one is transmitting. If the channel is free during
an Inter Frame Space (IFS) the station starts to transmit. The duration of this period of time
varies; the one used just before starting a transmission in normal condition is called DIFS (DCF
Inter Frame Space). To avoid a station can capture the channel for long times, random backoff
times are introduced. If the channel is busy the station waits until the channel is free for DIFS
period, after that the station waits for random backoff period of time and transmits if the medium
continues free. The backoff period is selected based in a contention window (CW). The initial
value is a random value between (0,CWmin). The value of backoff timer is decremented in each
fixed slot time until it becomes 0 when the frame is transmitted; otherwise if the channel
becomes busy again, the backoff timer is freeze and it is resumed when the channel is free after
another DIFS period.
When a station transmits a unicast frame it has to receive a successful reception confirmation.
So, after the destination node receives the frame successfully waits for SIFS (Short Inter Frame
Space) period and sends the confirmation (ACK) to the sender. SIFS is shorter than DIFS to give
priority to ACK packets. If one station transmits a frame and it does not receive an ACK after
specific time (timeout) the frame is assumed was lost and the station starts to retransmit the
frame. To reduce the probability of having a new collision in each retransmission the contention
window is doubled until a maximum value (CWmax) defined by the standard, with this the
objective is to have in average backoff times higher in each retransmission. This process is
repeating until seven times (by default), if after seven attempts the frame cannot be transmitted
successfully it is discarded. Figure 2 shows an example of DCF or CSMA/CA process and table
1 summarizes the default values of Inter Frame Spaces and Contention Window for different
IEEE 802.11 transmission techniques in the physical layer.
Fig.2. CSMA/CA Example
- 15 -
TABLE 1 . RELEVANT PARAMETERS FOR IEEE 802.11 CSMA/CA
Parameter DSSS FHSS IR
Slot Time 20 µs 50µs 6µs
SIFS 10 µs 28 µs 7 µs
DIFS 50 µs 128 µs 19 µs
ACCAtime <=15 µs 27 µs 5 µs
MSDUmax Size 2312 b 2312 b 2312 b
RxTxArTime 10 µs 19 µs 0 µs
Phy Preambule 192 b 122 b 92-112 b
It is also important to mention the relation between different Inter Frame Space (IFS), which is
SIFS < PIFS < DIFS. PIFS is used in Point Coordination Function. Being more precise:
PIFS := SIFS + 1 · SlotTime
DIFS := SIFS + 2 · SlotTime
There are two different carrier sensing mechanisms used by 802.11: physical carrier sense
(P-CS) and virtual carrier sense (V-CS). A physical carrier sense indication is raised when
another signal is detected on the medium. However, this signal detection is rather difficult
because most wireless modulation schemes are only distinguishable from noise if the receiver is
properly synchronized and has the capabilities required to decode the signal. The different PHYs
in 802.11 require individual carrier sensing mechanisms and the standard leaves device
manufacturers great flexibility in designing these mechanisms. When two distant station wants to
transmit to the same destination can occur the “hidden terminal” problem because none of both
sense the transmission and the frames collide in the intersection of both coverage. This problem
can be resolved with RTS/CTS mechanism or virtual carrier sense. The procedure is the
following: when a station wants to transmit a frame sends a RTS (Request to Send) message with
the duration of the frame to be transmitted. The intermediate node reply with CTS (Clear to
Send) message which now is captured by the destination node and through this mechanism the
destination node knows that it does not have to transmit by the entire duration of the frame
transmission. So, this medium reservation is called Network Reservation Vector (NAV). On the
other hand, this mechanism is activated when specific and configurable threshold is reached in
the packet length. Figures 3 and figure 4 show the procedure of the RTS/CTS mechanism in a
flow chart and an example of the transmission using this mechanism respectively.
- 16 -
Fig.3. Flow chart for CSMA/CA with RTS/CTS
Fig.4. CSMA with RTS/CTS Example
The MAC level of IEEE 802.11 provides also fragmentation mechanism to increase the
probability of success transmission. Each fragment has to be confirmed by acknowledge (ACK)
and is retransmitted individually in case of unsuccessful transmission. The sender node can
decide apply fragmentation if the channel does not have properly conditions. Figure 5 shows an
example of IEEE 802.11 transmission with fragmentation.
Fig.5. Example of Fragmentation using CSMA with RTS/CTS
- 17 -
Another aspect to mention is the delay in the successful transmission packet with and without
RTS/CTS, which has implication in the service time of the wireless nodes.
pTXTXsuccessTX 2.t(ack)TSIFS(packet)TDIFS(CSMA/CA)T
pTXTXsuccessTX 4.t(ack)TSIFS(packet)TSIFSCTSSIFSRTSDIFS(RTS/CTS)T
Where pt is the propagation time.
2.2 802.11e Description
802.11 Distributed Coordination Function (DCF) provides only best effort services. All traffic
types compete in the same way for channel access. Real-time intolerant applications (e.g.: voice
over IP, video conferences) need quality of service to guarantee certain bandwidth, delay and
jitter.
Enhanced Distributed Channel Access (EDCA) 802.11e is the mandatory MAC scheme for
Wireless Mesh Networks (unique channel access method implemented in NS-3 simulator) and
provides service differentiation and priorities to four classes of services including: voice, video,
best effort and background. The different traffic classes are called Access Categories (AC) and
each of them has a specific priority and queue. Every AC has 4 important system parameters,
which are: CWmin (the minimum Contention Window), CWmax (the maximum Contention
Window), AIFS (Arbitration inter-frame space) and TXOP (Transmission Opportunity). These
parameters are different in terms of different ACs. CWmin and CWmax define the backoff timer
used after occurring collision. In the EDCA scheme, CW will be reset to CWmin immediately
once the station sends packets successfully. If a collision happens, CW will be doubled until
reaches CWmax. The maximum allowed transmission time is defined by TXOP limit, once a
station accesses to the medium it can transmit one or more frames during TXOP. To achieve
differentiation in EDCA, instead of using fixed DIFS, Arbitrary IFS (AIFS) is applied, where the
AIFS for given AC is determined by the following equation:
aSlotTimeACAIFSNSIFSACAIFS *][][
AIFSN is the AIFS number determined by the AC and physical settings. The highest priority
will be given to the AC with smallest AIFS. Table 2 shows the default parameters for the
different ACs:
- 18 -
TABLE 2. STANDARD EDCA PARAMETERS [6]
AC CWmin CWmax AIFSN TXOP Limit
AC_VO 7 15 2 1504us
AC_VI 15 31 2 3008us
AC_BE 31 1023 3 0
AC_BK 31 1023 7 0
When the backoff counter reaches zero, the AC is granted an EDCA-TXOP. This TXOP has
a maximum duration specified by the parameter TXOPLimit[AC]. A TXOPLimit = 0 allows a
single frame at any data rate and an addition RTS/CTS exchange if desired. Note that the TXOP
is granted to the AC, not to the station.
If we analyze equation (2.3), we can determine that the minimum possible value of AIFS (for
voice and video) is equal to DIFS period. AIFS for Access Categories: AC_BE and AC_BK are
higher than DIFS. The relation between different IFS is represented in the figure 6.
Fig.6. Interframe Space (IFS) [32]
A QoS-enabled station holds four EDCAFs (Enhanced Distributed Channel Access Function),
so it can occur that two or more backoff counters reach zero simultaneously. This is called an
“internal collision” and is resolved by granting access only to the EDCAF with highest priority.
The other EDCAF must initiate the usual backoff procedure just as if an “external” collision on
the medium is detected. Figure 7 shows different ACs and queues after mapping User Priority
(UP) to Access Category.
- 19 -
Fig.7. EDCA Queues [32]
More specifically, seven traffic types are identified and differentiated, given the potential
applications and their requirements; these are, in order of priority: (1) Network control, which
includes packets that support network infrastructure and that must be delivered as quickly as
possible; (2) Voice and (3) Video, which principal requirement is bounded delay and loss; (4)
Controlled load, which (similarly to AF) includes traffic from important business applications, (5)
Excellent and (6) Best Effort, which consists of LAN and Internet traffic as we know it today.
Finally, (7) Background traffic belongs to activities which should not impact the use of the
network by other users (e.g. backups). Accordingly, the standard specifies up to eight levels of
priority (also referred as traffic classes), and recommends an appropriate mapping between the
seven traffic types and the available traffic classes [16]. Table 3 shows the summary of different
traffic classes and traffic types.
TABLE 3. SUGGESTED MAPPING OF THE TRAFFIC TYPES TO AVAILABLE TRAFFIC CLASSES IN IEEE 802.1D
Priority
Traffic
Classes
802.1D
Priority
802.1D
Traffic Types
Access
Category
802.11e
802.11e
Description
Lowest 1 Background AC_BK Background
... 2 ... AC_BK Background
… 0 Best Effort AC_BE Best Effort
... 3 Excellent Effort AC_BE Best Effort
... 4 Controlled Load AC_VI Video
... 5 Video AC_VI Video
... 6 Voice AC_VO Voice
Highest 7 Network Control AC_VO Voice
- 20 -
2.2.1 Performance Analysis of EDCA in WMN
Due to the fact that EDCA 802.11e was designed for wireless single-hop networks, it has
some problems in multi-hops WMNs which are described below: Inefficient Medium Usage
RTS/CTS (to avoid hidden station problem) messages have a negative effect on the
performance in WMN [1][2]. Conservative Energy Detection (ED) and Physical-Carrier Sense
(P-CS) threshold settings prevents almost any occurrences of hidden station problem in 802.11
[2][33]. Measurements results in large wireless networks affirm RTS/CTS absence [34]. Also,
studies show that usage of RTS/CTS has almost no impact on the network performance [7].
Accordingly, [8], [9] conclude that it only adds overhead [2].
As the sensitivity level of P-CS in 802.11 is low, the CS range is extremely large. As a
consequence of range of ED and CS one problem occurs when large amount Mesh Points (MPs)
refrain from medium access since they are blocked even though the medium is idle. Therefore,
the capacity of the wireless medium cannot be exploited. Figure 6 illustrates this problem,
station D does not detect the transmission of station A to B because is outside ED range (A), so
station D start to transmit a frame to station F, but station F is blocked (F is inside ED range
(A)) to transmit and it does not respond to station D.
Fig.6. Inefficient medium usage problem with Energy Detection (ED) range [2].
Unaware station Problem
This problem is derived from the previous one, distant stations who does not detect P-CS can
initiate a transmission with a block station and they will not receive a reply. As EDCA has been
developed for single-hop Wireless Local Area Network (WLAN), stations interpret the absence
of a response frame (ACK to data, CTS to RTS etc.) as a transmission failure. So, they double
their Contention Window; increase a frame’s retry counter and perform an additional back off to
- 21 -
resend the frame. Moreover, depending on the duration of active transmission (EDCA’s TXOP
duration) the frames of distant stations can start several retransmissions until they finally discard
the frames.
No transmission prioritization of Mesh STA over legacy STA
The current 802.11 MAC has been designed for wireless single-hop networks. EDCA consider
local BSS only. Its opportunistic approach leads to selfish behavior. When MP receives a frame,
it stores in its local queue and handles it as any other frame [1]. Thus, the mesh network does
not treat fairly the frames that have already traversed several hops. MPs have no means to
prioritize packets from other mesh routers over packets from STA nodes (legacy stations): In the
MP+AP (Mesh AP), Mesh STA and STA need to compete on the wireless medium. The local
single hop link from a station to its AP can easily congest the Mesh Network.
The three problems above-mentioned are counteracted with another access mechanism called
Mesh Deterministic Access (MDA) [2]. Besides, MCCA and eMCCA [3] face these problems but
they are out of the scope of this work (They are no implemented in ns-3 simulator).
2.3 802.11s Description
Wireless Networks have been widely extended in the last years. IEEE 802.11 standard for
Wireless LAN are based mainly in infrastructure mode and some amendments have been
proposed to improve speed, coverage and Quality of Service. However, the demands of networks
with higher capacity, coverage and lower cost have motivated the apparition of infrastructure-
less wireless networks. IEEE 802.11s amendment is a Wireless Mesh Network (WMN) standard
which builds a multi-hop network topology without infrastructure (Access Point).
Some Medium Access Control mechanisms have been proposed. Enhanced Distributed
Channel Access (EDCA) 802.11e has been adopted as mandatory medium access mechanism for
IEEE 802.11s. Another known optional mechanism is Mesh Coordinated Channel Access
(MCCA). Both mechanisms have suffered some modifications to improve specially Quality of
Service, fairness and delay-constraints for critical applications.
To understand MAC process in WMN is important to consider the different type of nodes that
compose WMNs. Figure 7, shows the typical architecture of WMN, there are four types of nodes:
Client or Stations (STA) that request a service but do not forward frames, MP (Mesh Point) or
Mesh STA that participates in the information and operation of the mesh cloud, Portal is MP
- 22 -
with additional functionality of acting as a gateway between mesh cloud and external networks,
MP+AP (Mesh AP) is MP attached an Access Point (AP) to provide service to STA clients. STA
are common Wi-fi nodes and they do not know anything about WMN parameters including the
MAC mechanisms, they just run DCF or its improvement EDCA.
Fig.7. Typical architecture of the IEEE 802.11s WMN [3]
A WMN is basically a collection of fixed nodes (relatively small up to 32 hops)[10], most of the
times consisting of regular wireless routers running adapted software. Its main goal is to provide
an inexpensive and easily deployable wireless backhaul that will connect distant LANs or WLANs
as it is shown in the figure 8.
Fig.8. WMN routers provide a wireless backhaul that interconnects wired and wireless stations [10]
Some differences between MANET and WMN are those one related with the following aspects:
- 23 -
Mobility: In Mesh networks the topology is relatively static and mesh routers are often
stationary.
Power Consumption: Less of an issue with mesh networks.
New MAC and routing protocols have been proposed for wireless mesh networks.
For mesh networks other issues are more important, robustness and reliability, including
rerouting packets when one or more mesh nodes or links have failed are important. Management
of interference between nearby wireless links is a critical challenge. This may involve two phases:
(1) deployment and (2) operations. Various choices can have a significant impact on system
capacity, robustness and reliability, including the following choices:
Placements of gateways.
Load balancing algorithms in gateways.
Placement of mesh routers.
Channel allocation of 802.11 channels between mesh routers.
Channel switching-synchronization.
2.3.1 Mesh Creation
At difference of SSID in infrastructure wireless networks, WMN use Mesh ID to create the
network. Similarly to 802.11, beacon frames are used to announce a Mesh ID and Mesh STA
broadcast beacons with the SSID set to wildcard value in order to avoid confusion with Mesh ID
in non-mesh station. To form the mesh cloud, all nodes must share the same profile, which has
three elements: Mesh ID, path selection protocol and path selection metric. The mesh STA
nodes may support different profiles but at the same time is recommended the mesh network
shall not use more than one profile in order to avoid complexity in renegotiation profiles
procedure in simple mesh nodes. The IEEE 802.11s standard defines HWMP as the path
discovery mechanism and the Air Link metric as the path selection metric, which are explained
in subsection 2.3.3.
A mesh network is formed as Mesh STAs find neighbors to share the same profile. In order to
achieve this, regular (802.11) beacon frames and probe response frames are extended to include
mesh related fields. Moreover, the IEEE 802.11s draft not only introduces new frames but also
extend pre-existent ones.
Another important aspect to be mentioned is the establishment of the Peer Links. A Mesh
STA shall create and maintain peer links to its neighbors that share its active profile. Once a
neighbor candidate is found through active or passive scanning, a Mesh STA uses the Mesh Peer
Link Management Protocol to open a mesh peer link. A mesh peer link is univocally identified
- 24 -
by the MAC addresses of both participants and a pair of link identifiers. To establish a peer link,
both Mesh STAs exchange Peer Link Open and Peer Link Confirm frames as depicted in figure 9.
Whenever a Mesh STA wants to close a peer link it should send a Peer Link Close frame to the
peer Mesh STA.
Fig. 9. The establishment of a peer link in 802.11s [10]
2.3.2 Internetworking with IEEE 802.11s
This aspect is referred as the capability of mesh network to connect to other networks. The
means for connecting to external networks like the Internet is the Portal nodes (as it was
mentioned in 802.11s description) and they act as a gateways. This capability of Portal nodes
has to be announced for other mesh STAs to benefit from its connectivity. Thus, once
configured as a Portal, a node spreads the news sending a Portal Announcements (PANN) frame.
A mesh STA that receives a PANN frame registers the Portal MAC address and the associated
path metric and then broadcasts the PANN frame again. Each mesh point in the cloud keeps a
list of available Portals and is able to choose among them when it needs to send traffic outside
the mesh network limits. Figure 10 shows two scenarios when Portal node acts in (a) as Bridge
between wired and wireless nodes because all nodes are in the same network (b) as a Gateway
between nodes in different subnets.
- 25 -
Fig.10. IEEE 802.11s internetworking scenarios [10]
2.3.3 Path Selection Mechanism
In this section it is explained how the mesh network create the route between specific sender
and destination nodes. There are two elements: routing protocol and its metric. In this sense,
IEEE 802.11s proposes a mandatory selection path protocol hybrid (proactive/reactive) protocol
named Hybrid Wireless Mesh Protocol (HWMP) which is inspired in AODV protocol [10]; on the
other hand the mandatory metric is Airtime Link Metric (ALM). Both of them parameters are
exchanged in beacon frames, Peer Link Open and Peer Link Confirm frames. It is important to
mention that at difference of traditional routing protocols, HWMP does path selection at the
MAC Layer instead of doing at Layer 3.
2.3.3.1 Hybrid Wireless Mesh Protocol
HWMP can be configured to operate in two modes: On-demand (Reactive) or tree-based
approach (Proactive). The real hybrid is the fact that both modes may be used concurrently. In
some situations one will be better than other. In the proactive mechanism is necessary to choose
a root node in the tree logical topology. The entire traffic pass through root, which in some
- 26 -
circumstances can be not optimal and add delay in transmission, but when the traffic has the
tendency to be transmitted to a specific common node, for example Mesh Portal, the use of
proactive mode can improve path selection efficiency. In this case Portal would act as a root of
the tree.
Independently of the operating mode (proactive or reactive mode), HWMP functions are
carried on by management frames with the following set of information elements:
Path Request (PREQ): It is transmitted in broadcast by a source Mesh STA that wants
to discover a path to a destination Mesh STA.
Path Reply (PREP): It is transmitted in unicast from destination Mesh STA back to the
source Mesh STA. Occasionally, PREP elements can be sent from intermediate nodes
that already know the path to the destination Mesh STA.
Path Error (PERR): It is transmitted to notify that a path is not available anymore.
Root Announcement (RANN): It is flooded into network in one of the proactive operations
modes.
On-demand (Reactive Mode)
In this case when node wants to start a transmission sends a PREQ message and the
intermediate nodes can respond or not with PREP message. To control the behavior of
intermediate nodes there are two flags: DO (“Destination Only”) and RF (“Reply and Forward”).
The valid possible combinations are the following:
DO=1: Is the default configuration where RF bit value does not care. In this case only
destination node can respond a PREQ frame with PREP. When the intermediate nodes
receive a frame PREQ with bit DO set to “1” broadcast the frame until reaches
destination.
DO=0, RF=1: In this case the intermediate nodes can respond with PREP frames if they
know the path to the destination mesh STA. Moreover, since bit RF is set to “1” the
intermediate node can also broadcast the PREQ frame.
DO=0, RF=0: In this case the intermediate nodes can respond with PREP frame if they
know the path to the destination mesh STA but they cannot forward the PREQ frames.
Figure 11 shows the route path discovery procedure in on-demand mode.
- 27 -
Fig. 11. HWMP on-demand route discovery.
Proactive Mode
In this mode the paths to destination mesh STA nodes are discover before they are required.
HWMP provides two different mechanisms for proactively building a forwarding table: Proactive
PREQ and Proactive RANN mechanisms.
In the “Proactive PREQ mechanism”, when configured to work as a root, a node broadcasts a
PREQ frame with DO and RF flags set to “1”. This PREQ is sent periodically and every
receiving Mesh STAs updates the PREQ frame (decreasing the time to live and updating the path
metric) and broadcasts the PREQ again, which eventually reaches all nodes in the mesh cloud.
Whether or not a node answers with a PREP frame upon receipt of a proactive PREQ depends
in part on the setting of another flag, the “Proactive PREP". If the root sets it on, all receiving
nodes shall send a proactive PREP back to it. A node may send a PREP frame back if it has data
to send to the root node and if it wants to establish a bidirectional link, even if the Proactive
PREP is not set. Figure 12 shows path discovery mechanism using Proactive PREQ mechanism.
The proactive PREQ mechanism is clearly chatty, particularly in its proactive PREP version.
An alternative method is presented by the “Proactive RANN mechanism”. Here, instead of
sending PREQs out, a root node can flood the mesh with Root Announcement (RANN) frames.
Nodes willing to form a path to the root answer with a PREQ frame. This PREQ is sent in unicast
mode to the root, through the node by which the RANN frame was received, and is processed by
intermediate nodes with the same rules applied to PREQ broadcasts in the reactive mode.
The root node answers each of the received PREQs with a respective PREP, thus forming a
forward path from each Mesh STA to the root. At the end, the RANN mechanism introduces one
additional step and may be advantageous if compared to the PREQ mechanism only if a small
subset of Mesh STAs wants to establish paths with the root node.
- 28 -
After a path is formed, whenever a frame cannot be forwarded by an intermediate node this
fact should be informed to the previous nodes in the path. The PERR frames are used for such
purpose, announcing a broken link in the path. The PERR will be sent to all traffic sources that
have an active path over this broken link. Each sender that still needs to use the path will then
start a new path discovery cycle.
Fig. 12. HWMP proactive route discovery using “Proactive PREQ” mechanism [10].
2.3.3.2 Airtime Link Metric
Airtime metric (ALM) is a radio-aware metric which is meant to measure the amount of
consumed channel resources when transmitting a frame over a particular wireless link. This
metric is computed according to the following equation:
f
tpcaa
er
BOOC
1
1
Where caO is the channel access overhead and pO the protocol overhead that varies
according to the PHY layer implementation, tB is the test frame size (1024 bytes), r is the
date rate in Mbps at which mesh STA would transmit the test frame and fe is the measured test
frame error rate. As it can be seen the airtime metric accounts the amount of time consumed to
transmit test frame taking into account the probability of retransmission. The draft does not
specify how to calculate the frame loss probability, leaving this choice to the implementation.
The metric prevents longer transmissions at low data rates and transmission with higher frame
- 29 -
error probability can capture the medium for long times. Table show the typical values of the
constants caO , pO and tB .
TABLE 4. AIRTIME LINK METRIC CONSTANTS
Parameter 802.11a 802.11b Description
caO 75 µs 335 µs Channel access overhead
caO 110 µs 364 µs Protocol overhead
tB 8224 8224 # bits in test frame
- 30 -
3. Buffer Sizing
This section presents the method for the solution of the G/G/1 and G/G/1/K queues via
maximum entropy in an easy and comprehensive way. The derivation is rather elementary and
intuitive. First of all, a vision of the system’s dynamic is presented. Computations of state
probabilities via maximum entropy in both the infinite and finite buffer size cases are described.
Finally, it is presented different methods to find the buffer size for a given target loss probability
and also it is shown some experimental results.
3.1 Packets in the system and packets seen by arrivals and
departures
Consider a transmission system in which packets arrive and depart one at a time. In steady
state, such a system evolves through periods of activity and idleness as represented in figure 13.
When the system is continuously observed over a long enough time span comprising many of
those cycles, obst (observing time), the probability of having i packets in the system, p(i), can be
computed as:
obs
t ip i
t
Where t(i) is the total amount of time the system has sojourned in state i (during obst ).
Similarly, the probability that the system is busy, ρ , is given by:
B
obs
t
t
Where Bt is the total duration of the activity periods, i.e.:
1
B
i
t t i
- 31 -
Fig. 13. Pictorial definition of t(i) and Bt .
Fig. 14. Pictorial definition of na(i) and nd(i).
To evaluate the probability of packets found in the system by an arrival, a(i), one has to
proceed differently, since now measurements are only taken at precise time instants. If there are
na arrivals in obst , and na(i) of those see the system in state i, a(i) can be estimated as (see figure
14):
Note that now we are dealing with discrete quantities, as opposed to the continuous values
used to estimate p(i). Therefore, it should not be surprising that, in general, p(i) and a(i) differ.
Analogously, denoting by d(i) the probability of leaving behind i packets at service completion,
we can write:
cycle 1
tobs
time1
Number of packets in the system
cycle 2
t(1)
t(2)
t(0)
2
3
0
cycle M
tB
.
.
.
cycle 1
tobs
time1
Number of packets in the system
cycle 2
t(1)
t(2)
t(0)
2
3
0
cycle M
tB
.
.
.
.
.
.
a
a
n ia i
n
- 32 -
Where dn and )(ind are, respectively, the total number of departures and the number of those
departures that leave i packets in the system. From figure 2, it is apparent that ad nn and
)()( inin ad . (Observe that these equalities hold also true for every cycle). Therefore, we also
have d(i)= a(i).
The probabilities p(i) and a(i) are related through arrival and departure rates, defined
respectively as follows:
1
a
d
n ii
t i
n ii
t i
The global arrival rate, λ, is:
0 1
0 1
...
...
a a a
obs
n n n
t t t
Similarly, the global departure ratio, µ, is:
0 1
1 2
...
...
d d d
B
n n n
t t t
From all the above, we readily obtain the following relationships which will be useful in the sequel.
, 0,1, 2...
obs
a
a
n ia i
n
i t i ip i i
t
( 1)1 , 0,1,2,...
d
obs a
n it ip i a i i
t n i i
and from both, we finally have:
1 , 0,1, 2,...
i ip i p i p i i
i i
d
d
n id i
n
- 33 -
3.2 The computation of probabilities: a maximum entropy approach
We will distinguish two cases, corresponding to infinite or finite buffer size.
3.2.1 Infinite buffer size
As anticipated in the introduction, the problem we address in this section is the following.
Suppose that the average number of packets in a transmission system (buffer and server) and the
server occupancy have both been measured. As explained before, such measurements may yield
different values depending on the way they are taken: at arrival times or by continuously
monitoring the system. Both ways of proceeding are used in engineering practice. Time averages
are very useful for operators, for instance, since they clearly indicate the utilization of network
resources. The knowledge of these values is pertinent to many aspects of paramount importance
like economic revenues, equipment heating and, in general, subject matters related to network
exploitation. On the other hand, users are more concerned with a different set of parameters,
like packet losses, delays, etc., that, in the usual parlance of traffic engineering are grouped
under the heading of Quality of Service. In this article we focus on buffer dimensioning to
achieve a given packet loss probability, LP . Obviously, a packet is lost when, upon its arrival to
the transmission system, no storage space is left in the buffering element. Therefore, to evaluate
LP measurements should be taken at arrival times. Since LP is normally a very small number, its
reliable estimation is a lengthy process that needs many packets. To avoid excessive burden on
the measuring mechanism, and to make the adjustments more dynamic, our model requires the
collection of only two values, namely: the server occupancy, a , and the average number of
packets in the system, aN , both of them seen by arrivals. Note that a and aN are several
orders of magnitude larger than LP , and therefore they can be estimated much faster, using for
instance moving averages. Then, the problem is to evaluate the probabilities of packets seen by
an arrival, a(i), having at our disposal only the knowledge of those two quantities. If the a(i) were
given, a and aN would follow readily. Our aim is just the opposite, i.e.: to obtain the a(i) from
the sole knowledge of a a and aN . Observe that by producing a(i) we are providing more
information than we have available. We should, therefore, be as “ambiguous” as possible, but
always in compliance with the observed data. Since the pioneering work of C. Shannon [17], the
uncertainty of a random variable (rv) is measured by a quantity known as entropy. Focusing in
our case of interest, if a rv takes on the values x1, x2, x3, … with probabilities p1, p2, p3, ...
the entropy of this rv is given by the expression [18]:
- 34 -
1
1ln
i
i i
pp
The base of logarithms can be arbitrary and, by convenience, in the above expression, we have
chosen natural logarithms.
Going back to our case, since aa 1)0( is known, the problem can be stated as follows:
Compute a(1), a(2), a(3), … to maximize:
1
1ln
i
a ia i
Subject to the conditions:
1
1
a
i
a
i
a i
ia i N
Using the approach routinely employed to solve constrained optimization problems of this sort,
we form the Lagrangean function [19]:
1 1 1
1 , 2 , lna a
i i i
F a a a i a i A a i B ia i N
K
and equal its partial derivatives to 0, as follows:
ln 1 0, 1, 2, ...F
a i A Bi ia i
Therefore
1, 1, 2,...
A Bi ia i e i
where
1,
A Be e
To compute α and β we use the known conditions:
1 1 1
i
a
i i
a i
which implies:
1
a
Also
- 35 -
2
1 1 11
i a
a
i i
N ia i i
Then,
1a
aN
and therefore, from Eq. (3.20):
21
1
a
aa
a
N
N
Once α and β have been determined, the values of a(i) are given by the expressions:
12
0 1
1 , 1, 2, ...
a
i
a a
a a
a
a i iN N
Proceeding similarly with p(i), we can write:
12
0 1
1 , 1, 2, ...
i
p
p i iN N
Where ρ and N are, respectively, the server occupancy and the average number of packets
obtained by continuously monitoring the system.
3.2.2 Finite buffer size
Let Q be the buffer size. Similarly to before, we have:
0 1
, 1, 2,..., 1
aQ
i
Q
a
a i i Q
Where )(iaQ denotes the probability seen by an arrival when the buffer size is Q. The
parameters α and β are now obtained from a and aN as indicated below.
From
1 1
1 1
Q Q
i
a
i i
Qa i
We obtain:
1
1 1
1a Q
- 36 -
The computation of Na yields:
11 1
1
1 1
1 2 1
1 1
QQ Q
i a
a Q
i i
Q
Q QN ia i i
Observe that when Q increases to infinity we reobtain (3.20) and (3.21). Eq. (3.29) can be
rewritten as:
a
aQ
Nf
where
1
1
1 1 2 1
1 1
Q
Q Qf
is an increasing function of βand 1)0( Qf (see figure 15). Therefore, since ( aN / a )>1, Eq.
(3.31) can be easily solved for β, and α readily follows from Eq. (28).
Fig. 15. Calculation of β.
3.3 Application to the buffer sizing for the G/G/1/K queuing system
Buffer overflow in data networks causes packet losses and, consequently, it should be
evaluated and properly controlled to guarantee the desired level of service performance.
Obviously, a packet is lost when, upon its arrival to the transmission system, no storage space is
left in the buffering element. Therefore, as said before, to evaluate this parameter, the use of the
probabilities of packets found in the system by an arrival (and not the probability of packets in
Na/a
fQ
- 37 -
the system) is in order. Based on the previous formulas, we propose and compare three different
methods. For the first method we use the finite buffer model presented in Section 3.2.2, whereas
for methods 2 and 3 we employ Eq. (24) derived in Section 3.2.1.
Method 1. The probability of packet loss, LP , can be evaluated as the probability of
being in the state K, that is, Q + 1.
11
Q
L QP a Q
Where α and β are computed as indicated in Section 3.2.2.
PL can also be calculated using the probabilities a(i) obtained in Section 3.2.1 for the infinite
buffer size. Here, we present two methods, akin to the ones used to compute blocking
probabilities for voice circuits.
Method 2. Define:
1
0
( )
( ), 1
( )
0, 1
Q
n
a i
a ii Q
a n
i Q
%
Then, PL can be computed as follows:
2
1
2
1
11
1 ( ) 1 1
Q
a
aaL Q
aa
an Q
a
a QNa Q
PN
a nN
%
Observe that this method of truncation is similar to the Erlang_B approach to compute blocking
probabilities for voice circuits (truncating, in that case, a Poisson distribution).
Method 3. We now parallel Molina’s [20] way of computing blocking probabilities.
Therefore, we set:
1
2
1 1
1 1
i Q
a a aL a
i Q i Q a a a
P a iN N N
With this method Q can be expressed in closed-form as:
- 38 -
ln
int
ln 1
L
a
a
a
P
Q
N
where int(·) is the integer function.
As shown later, Eqs. (3.32) and (3.34) give similar results for the value of the needed buffer
size. The value of Q provided by Eq. (3.36) is however larger than necessary, but the advantage
is that Q can be expressed in closed-form.
In the next section we comment on the numerical results obtained using different traffic
aggregations.
3.4 Numerical and simulation results
In this section we give a few representative figures obtained by simulation and using the
procedure and methods described in sections 3.2 and 3.3. Although the main interest of this
paper is the computation of buffer overflow using to that end the probabilities seen by arrivals,
we have also indicated how to evaluate the probabilities of packets in the system, and pointed
out the differences between the two of them. To more visually highlight those differences, in Fig.
4 we have shown the values of p(i) and a(i) for infinite buffers and two specific distribution of
interarrival and service times. More specifically, we have chosen a Gamma(α,ν) distribution for
the interarrival times and a Pareto (k, mx ) for packet lengths.
The probability density function for the Gamma(α,ν) is given by:
1
( ) , 0x
xf x e x
Where α > 0, ν > 0 and ґ(ν) is the gamma function. Its average value is να.
The density function for the Pareto (k, mx ) is:
m
1( ) , 0
k
k
xf x k x
x
Where mx > 0 and k > 1. Its average value is )1/( kkxm .
Observe that one of the distributions considered for the packet lengths is the Pareto
distribution, which takes into account the “heavy-tailed” effect present in the self-similar traffic
[21][22]. Anyway, although self-similarity property appears in many real traffics [23][24], it
- 39 -
should be noted that its influence in some environments or with certain services (for instance,
real time services with small buffers) is not determinant[25][26].
The parameters chosen to compute the model and run the simulations are shown in Table 5.
TABLE 5. TRAFFIC CONFIGURATION PARAMETERS
Function Parameters
Interarrival Time (Gamma) α= 0.001 s ν= 2
Packet length (Pareto) xm = 800 bits k = 3
For a 1 Mbps channel, this produces a load of 0.6. Obviously, many other parameters and
distributions could have been chosen and the results are similar. Observe how, as expected, the
probabilities p(i) and a(i) differ, but the values provided by the model agree accurately with the
results of the simulation runs.
Fig. 16. Probabilities of packets in the system, p(i), and probabilities seen by arrivals, a(i), with infinite queue size.
Since we are interested in buffer overflow, for the rest of the computations and figures we are
only concerned with the value of the probabilities seen by arrivals. To more realistically mimic
the actual traffic in any network, we have considered a traffic resulting from the aggregation of
four different mixes with quite different interarrival times and packet lengths. Besides the gamma
distribution, already mentioned, the other distributions we have used are the following:
Truncated Exponential:
max
max( ) , 01
x
xf x e x x
e
Truncated Pareto:
- 40 -
minmin max1
min
max
( ) ,
1
k
k k
k xf x x x x
xx
x
Uniform:
min max
max min
1( ) ,f x x x x
x x
Deterministic:
0( )f x x x
Where () is the Dirac’s delta function.
Moreover, to fully explore the behavior under different loads, we have compared three loads:
ρ= 0.4, ρ=0.6 and ρ= 0.8. Table 6 shows the packet length distributions and table 7 the
distributions of the interarrival times for the three different loads. The channel capacity is set to
1 Gbps. The analytic computations are carried out using method 1 presented in Section 3.3.
Fig. 5 represents the values (model and simulations) of )(iaQ for a buffer size of 11. It can be
observed a good agreement for the whole spectrum of loads. Figure 18 shows the packet loss
probability as a function of the buffer size and for the three different load conditions. As usual,
the values obtained with the model and by means of simulation are compared. Finally, figure 19,
although similar to figure 18, shows more conveniently for a practical implementation the Q
needed for a given LP for the three loads. As can be seen, the agreement is again very good.
Finally, figures 20 and 21 show the results obtained using the three methods mentioned in
Section 3.3. Not to clutter the figure, we have selected only one load: ρ= 0.6. From those
graphs, we see the agreement of methods 1 and 2 and that, as expected, method 3 allocates
more buffer than necessary.
- 41 -
TABLE 6. TRAFFIC STREAMS (PACKET LENGTH)
Traffic number Packet length
1 Truncated Pareto
k = 1.5
xmin = 368 bits
xmax = 12000 bits
2 Gamma
= 500 bits
= 3
3 Uniform
xmin = 1000 bits
xmax = 9000 bits
4 Truncated Pareto
k = 1.5
xmin = 368 bits
xmax = 18000 bits
TABLE 7. TRAFFIC STREAMS (INTERARRIVAL TIME)
Traffic
number
Interarrival
time (=0.4)
Interarrival
time (=0.6)
Interarrival
time (=0.8)
1 Trunc. Exponential
= 9·10-6 s
xmax = 1.2·10-4 s
Trunc. Exponential
= 6·10-6 s
xmax = 1.2·10-4 s
Trunc. Exponential
= 4.5·10-6 s
xmax = 1.2·10-4 s
2 Uniform
xmin = 0 s
xmax = 3·10-5 s
Uniform
xmin = 0 s
xmax = 2·10-5 s
Uniform
xmin = 0 s
xmax = 1.5·10-5 s
3 Deterministic
x0 = 5·10-5 s
Deterministic
x0 = 3.333·10-5 s
Deterministic
x0 = 2.5·10-5 s
4 Gamma
= 2.37·10-6 s
k = 4
Gamma
= 1.58·10-6 s
k = 4
Gamma
= 1.18·10-6 s
k = 4
Fig. 17. Probabilities seen by arrivals, aQ(i), with finite queue size (Q = 11).
- 42 -
Fig. 18. Packet loss probability vs. buffer size.
Fig. 19. Buffer size vs. packet loss probability.
- 43 -
Fig. 20. Packet loss probability vs. buffer size using the three models ( = 0.6).
Fig. 21. Buffer size vs. packet loss probability using the three models (= 0.6).
- 44 -
4. Wi-Fi and Mesh Modules Description in Ns-3
Network simulator ns-3[30] was used to test different scenarios with dynamic buffer size,
allocation. This is open source and discrete-event based simulator. Ns-3 uses object oriented-
programming in C++ or Python. The method to do simulations is to create devices and mount
over them the interfaces. One of advantages of this simulator is that it uses a powerful trace
module that allows flow analysis as well as data frame by frame. Figure 22 show ns-3 node
architecture. Also in sections 4.1 and 4.2 are described Wi-fi and Mesh modules respectively in
ns-3.
Fig. 22. Ns-3 node architecture [27]
4.1 Wi-fi Module in Ns-3
The WifiNetDevice models implement a wireless network interface controller based on the IEEE
802.11 standard. Ns-3 provides models for these aspects of 802.11:
Basic 802.11 DCF with infrastructure and adhoc modes
802.11a, 802.11b and 802.11g physical layers
QoS-based EDCA and queueing extensions of 802.11e
Various propagation loss models including Nakagami, Rayleigh, Friis, LogDistance,
FixedRss, Random.
Two propagation delay models, a distance-based and random model.
Various rate control algorithms including Aarf, Arf, Cara, Onoe, Rraa, ConstantRate, and
Minstrel
802.11s (mesh)
The set of 802.11 models provided in ns-3 attempts to provide an accurate MAC-level
- 45 -
implementation of the 802.11 specification and to provide a not-so-slow PHY-level model of the
802.11a specification.
The implementation is modular and provides roughly four levels of models:
The PHY layer models
The so-called MAC low models: they implement DCF and EDCAF
The so-called MAC high models: they implement the MAC-level beacon generation,
probing, and association state machines, and
A set of Rate control algorithms used by the MAC low models
There are presently three MAC high models that provide for the three Wi-Fi topological
elements (non-mesh):
Access Point (AP) (implemented in class ns3::ApWifiMac)
non-AP Station (STA) (ns3::StaWifiMac), and
STA in an Independent Basic Service Set (IBSS - also commonly referred to as an ad hoc
network (Ns-3::AdhocWifiMac).
The mesh equivalent (ns3::MeshWifiInterface), which is a sibling of these with common
parent ns3::RegularWifiMac, is discussed in section 4.2. The simplest of these is
ns3::AdhocWifiMac, which implements a Wi-Fi MAC that does not perform any kind of beacon
generation, probing, or association. The ns3::StaWifiMac class implements an active probing
and association state machine that handles automatic re-association whenever too many beacons
are missed. Finally, ns3::ApWifiMac implements an AP that generates periodic beacons, and that
accepts every attempt to associate.
These three MAC high models share a common parent in ns3::RegularWifiMac, which exposes,
among other MAC configuration, an attribute QosSupported that allows configuration of
802.11e/WMM-style QoS support.
With QoS-enabled MAC models it is possible to work with traffic belonging to four different
Access Categories (ACs):
AC_VO for voice traffic
AC_VI for video traffic,
AC_BE for best-effort traffic and
AC_BK for background traffic.
In order for the MAC to determine the appropriate AC for an MSDU (Mac Service Data Unit),
packets forwarded down to these MAC layers should be marked using ns3::QosTag in order to
set a TID (traffic id) for that packet otherwise it will be considered belonging to AC_BE.
The MAC low layer is split into three components:
- 46 -
1. ns3::MacLow which takes care of RTS/CTS/DATA/ACK transactions.
2. ns3::DcfManager and ns3::DcfState which implements the DCF and EDCAF functions.
3. ns3::DcaTxop and ns3::EdcaTxopN which handle the packet queue, packet fragmentation,
and packet retransmissions if they are needed. The ns3::DcaTxop object is used high MACs that
are not QoS-enabled, and for transmission of frames (e.g., Management frames) that the
standard says should access the medium using the DCF. ns3::EdcaTxopN is used by QoS-
enabled high MACs and also performs QoS operations like 802.11n-style MSDU aggregation.
There are also several rate control algorithms that can be used by the Mac low layer:
OnoeWifiManager
IdealWifiManager
AarfcdWifiManager
AarfWifiManager
ArfWifiManager
AmrrWifiManager
ConstantRateWifiManager
MinstrelWifiManager
CaraWifiManager
RraaWifiManager
On the other hand, the PHY layer implements a single model in the ns3::WifiPhy class.
In ns-3, nodes can have multiple WifiNetDevices on separate channels, and the WifiNetDevice
can coexist with other device types; this removes an architectural limitation found in ns-2.
Presently, however, there is no model for crosschannel interference or coupling.
The wifi component of ns-3 contains a lot of modules and subclasses. A very condensed
summary of the wifi NetDevice architecture of ns-3 is shown in figure 23. The WifiNetDevice is
built up of a number of classes coordinating packet transmission and reception. The path a
packet takes when traveling through 802.11 device and channel is marked by the solid lines with
arrows. Other dashed lines indicate functional class relationships; however, many dependencies
and class associations are omitted.
4.2 Mesh IEEE 802.11s Module in Ns-3
Wireless Software R&D Group of IITP RAS [35][15] designed and implemented a runtime
configurable multi-interface and multi-protocol Mesh STA architecture in ns-3.
- 47 -
In the next subsections, the supported and unsupported features are presented according to
the description of the draft presented in chapter 2 and section 2.3.
Fig 23. Wi-fi NetDevice Architecture [28]
4.2.1 Supported Features
The most important features supported are the implementation of the Peering Management
Protocol, the HWMP and the ALM (AirTime Link Metric).
A part from the functionality described in section 2.3, the PMP includes link close heuristics
and beacon collision avoidance. HWMP includes proactive and on-demand modes,
unicast/broadcast propagation of management traffic and, as an extra functionality not specified
yet in the draft, multi-radio extensions. However, actually for proactive HWMP mode, the
RANN mechanism is implemented but there is no support, so only the PREQ mechanism can be
used.
4.2.2 Unsupported Features
The most important feature not implemented is Mesh Coordinated Channel Access (MCCA)
mentioned in section 2.3. Internetworking using a Mesh Access Point or a Portal node is not
- 48 -
implemented neither, but this functionality is not needed to evaluate the performance in the
creation of mesh networks [15].
As other less relevant features not implemented we can point out the security and although
multi-radio operation is supported, no channel assignment protocol is proposed [29].
4.2.3 Module Implementation in ns-3
Figure 24 show the UML diagram of core classes in ns-3 mesh implementation. The main
classes are related with the draft features described in section 2.3:
Peer-Link
PeerLink Management Protocol (PMP)
HWMP
AirTime Link Metric (ALM)
Fig. 24. UML diagram of core mesh classes [15]
- 49 -
The MAC High function that manages mesh STA nodes in ns-3 is ns3::MeshWifiMacInterface,
which is part of four elements under ns3::RegularWifiMac parent class. These four elements
include all net devices in IEEE 802.11 wireless transmission (adhoc, STA, AP, mesh STA).
Figure 25 shows this scheme in a simplified and summarized version of caller graph for 802.11
classes. Mac High: RegularWifiMac class with the four classes below it and Mac Low are
encapsulated in one ns3::WifiMac class [31].
Fig. 25. Caller graph for MAC IEEE 802.11 classes in ns-3
Moreover, it is important to mention how data packets and management frames are transmitted
in ns-3 mesh implementation. Beacons which are used to maintain peer links are sent used
Distributed Control Function (DCF). The rest of the frames are transmitted using EDCAF, more
specifically: Unicast management frames (PREP) uses AC_VO queue, broadcast management
frames uses AC_BK queue and data frames are mapped according to TID (if the packet has no
802.11D tag will be served using AC_BE queue). Figure 26 shows the caller graph for different
methods of STA and mesh STA nodes, which summarizes the functions that use either DCF or
EDCAF channel access methods.
ns3::StaWifiMac
ns3::RegularWifiMac
ns3::AdHocWifiMac ns3::ApWifiMac ns3::MeshWifiMac
Interface
ns3::DcaTxop
ns3::EdcaTxopN
ns3::MacLow
ns3:WifiMac
“Mac High”
ns3::DcfManager
“Mac Low”
- 50 -
Fig. 26. Caller graph for STA and mesh STA functions that use DCF and EDCAF.
WifiMacQueue::
Enqueue ()
DcaTxop::
Queue ()
EdcaTxopN::
Queue ()
MeshWifiInterface::
SendBeacon ()
StaWifiMac::
Enqueue ()
MeshWifiInterface::ForwardDown()
MeshWifiInterface::
SendManagementFrame()
StaWifiMac::
Enqueue()
- 51 -
5. Simulation and Obtained Results
In this section is implemented the dynamic buffer size mechanism in Wireless devices like
STA nodes in WLAN and Mesh STA nodes in WMN. First, in section 5.1 it will be explained
the results obtained in infrastructure WLAN and in section 5.2 the results in WMN.
5.1 Dynamic Buffer Size Allocation in WLAN
Studies carried out after [12] describes the extension of dynamic mechanism in WLAN devices
and evaluates the results. This section reproduces some experiment results of these studies and
contributes them with the analysis of different delay sources (waiting time, service time and
transfer time) under dynamic and static buffer size. For this, it has repeated all simulations with
the obtained appropriated input parameters (w, Threshold up, Threshold down) explained in [12]
adding new traces in ns-3 simulation in order to track the packets and compute different time
delays.
Figure 27 shows the used ns-3 simulation topology. It consists of two infrastructure-based
WiFi networks with five stations associated with each AP. Additionally, a special node (N0)
equipped with two network interface cards (IF1 and IF2) and associated to both WiFi networks
has been considered and subjected to deeper analysis. The APs are connected to the wired hosts
(H1 and H2) through 500 Mbps links. Static routing has been configured in the nodes for
connectivity purposes. Wireless nodes in WLAN1 (WLAN2) transmit UDP packets to H1 (H2)
through AP1 (AP2). Node N0 belongs to both networks. For all the simulations under this
scenario it transmits UDP packets through its two interfaces during the entire simulation time.
The other nodes transmit UDP packets according to the activation pattern shown in figure 28.
- 52 -
H1
H2
WLAN 1
WLAN 2
IF1
N4
N1
N7
N10
N2
N6
N5
N9
N3
N8
IF2N0
AP2
AP1
Fig. 27. Scenario-1 ns-3 simulation topology
The ON state means that a station is transmitting UDP traffic to its respective wired host at
that time instant. The figure also shows the total number of active nodes in each WLAN at any
time. As it can be seen, the length of the simulations in this scenario is 5000 seconds. Table 8
shows the data used in the simulations and the MAC/PHY configuration parameters are shown in
Table 9.
TABLE 8. DATA USED IN SIMULATION FOR CHAIN MESH TOPOLOGY AND STATIC BUFFER SIZE
Fig. 28. Activation pattern for scenario 2 nodes.
0 1000
2000
3000
4000
5000 t [s]
N1
ON/OFF
1 2 3
1 2 3
ON
ON
ON
ON
ON
N2 N3 N4 N5
N6 N7 N8 N9 N10
Total No. of transmitting Nodes in WLAN2
ON
ON
ON
ON
ON
Total No. of transmitting Nodes in WLAN1
- 53 -
SIMULATION DATA
Mean Packet Length 200B
Mean packet arrival rate 1paq/2.5ms
Mean Tx bit rate 640kbps
Qinit (Initial Queue Size) 100 pkts
Simulation Time 5000s
TABLE 9. NS-3 MAC/PHY PARAMETERS USED IN SIMULATIONS
Parameter Value
AP Beacon Interval 10 s
STA Probe Request Timeout 50 ms
STA Assoc. Request Timeout 500 ms
STA Max Missed Beacons 10
STA Active Probing No
CTS Timeout 75 s
AckTimeout 75 s
Basic Block Ack Timeout 281 s
Compressed Block Ack Timeout 99 s
SIFS 16 s
DIFS 34 s
Slot duration 9 s
Max. Propagation delay 3.333 s
Propagation loss model
Log distance
Exponent: 3
Ref. Distance: 1m
Ref. Loss: 46.677 dB
Data/Control OFDM Rate 6 Mbps
Max No. of retransmission attempts
for RTS/Data packets 7
RTS/CTS/Fragmentation threshold 2346
Random number generator MRG32k3a
This experimentation shows the mechanism works for the case that the channel occupancy and
the traffic variations are due to the activation or deactivation of different network nodes. Fig.
shows the average channel occupancy measured in both WLANs. Here it can be observed that
each node in the network is able to correctly capture the average channel occupancy during its
corresponding activity periods. Due to the fact that the N0 node is transmitting by its two
interfaces during all the simulation time, the first graph in figure 29a and 29b, which corresponds
to each interface of the N0 node, shows the complete evolution of the average channel
occupancy for each of the two WLANs (Observe the correspondence with the total number of
active nodes for each WLAN in figure 28).
With this information, every node is able to autonomously and dynamically adapt its buffer size
according to the traffic and channel states. As described in section 3, this is done with the
constraint of a given target packet loss probability. Figure 30 shows the buffer size evolution of
each N0 interface for three different target packet loss probabilities. This confirms the proper
- 54 -
functioning of the algorithm for bigger topologies where different nodes are contending for
channel access.
(a)
(b)
Fig. 29. Average Channel Occupancy for scenario 3 nodes. (a) WLAN1 nodes; (b) WLAN2 nodes.
0 1 2 3 4 50
0.2
0.4
0.6
0.8
1
Time [x 1000 s]
Avera
ge C
hannel O
ccupancy
N0 Interface 1
0 1 2 3 4 50
0.2
0.4
0.6
0.8
1
Time [x 1000 s]
Avera
ge C
hannel O
ccupancy
N1
0 1 2 3 4 50
0.2
0.4
0.6
0.8
1
Time [x 1000 s]
Avera
ge C
hannel O
ccupancy
N2
0 1 2 3 4 50
0.2
0.4
0.6
0.8
1
Time [x 1000 s]
Avera
ge C
hannel O
ccupancy
N3
0 1 2 3 4 50
0.2
0.4
0.6
0.8
1
Time [x 1000 s]
Avera
ge C
hannel O
ccupancy
N4
0 1 2 3 4 50
0.2
0.4
0.6
0.8
1
Time [x 1000 s]A
vera
ge C
hannel O
ccupancy
N5
0 1 2 3 4 50
0.2
0.4
0.6
0.8
1
Time [x 1000 s]
Avera
ge C
hannel O
ccupancy
N0 Interface 2
0 1 2 3 4 50
0.2
0.4
0.6
0.8
1
Time [x 1000 s]
Avera
ge C
hannel O
ccupancy
N6
0 1 2 3 4 50
0.2
0.4
0.6
0.8
1
Time [x 1000 s]
Avera
ge C
hannel O
ccupancy
N7
0 1 2 3 4 50
0.2
0.4
0.6
0.8
1
Time [x 1000 s]
Avera
ge C
hannel O
ccupancy
N8
0 1 2 3 4 50
0.2
0.4
0.6
0.8
1
Time [x 1000 s]
Avera
ge C
hannel O
ccupancy
N9
0 1 2 3 4 50
0.2
0.4
0.6
0.8
1
Time [x 1000 s]
Avera
ge C
hannel O
ccupancy
N10
- 55 -
Fig. 30. Buffer size for the N0 node configured with three different PL target values.
5.1.1 Memory utilization efficiency
To illustrate and quantify the improvements achieved with the dynamic buffer sizing mechanism,
the concept of memory utilization efficiency has been defined as the ratio between the area
under the buffer occupancy curve (current number of packets waiting in the buffer) and the area
under the buffer size curve (maximum number of packets allowed in the buffer). Figure 31 shows
these two curves, for the interface 2 of the N0 node, and for a target PL of 1E-3. For the sake of
clarity, a ‘zoomed’ version is also provided. It can be seen that this memory utilization
efficiency is expected to be very low due to the fact that the nodes, working under normal traffic
load conditions, expend long time with empty buffers.
0 1000 2000 3000 4000 50000
10
20
30
40
Time [s]
Buffer
Siz
e Q
[pkts
]
0 1000 2000 3000 4000 50000
10
20
30
40
Time [s]
Buffer
Siz
e Q
[pkts
]
N0 INTERFACE 2
PL=1.0E-5
PL=1.0E-4
PL=1.0E-3
PL=1.0E-5
PL=1.0E-4
PL=1.0E-3
N0 INTERFACE 1
- 56 -
Fig. 31. Buffer Size vs. Buffer Occupancy for the Interface 2 of the N0 node with target PL=1E-3.
A round of simulations has been carried out to compare the value of with the dynamic buffer
sizing algorithm against the resulting when the nodes are configured with a static buffer size.
To do this comparison in the correct terms, the buffer size selected with the static allocation has
been the one that produces the same loss probability than the dynamic allocation. That is, if we
run the dynamic algorithm with a target PL equal to 1E-3, we must compare it with a static
buffer size that results in the same PL. For the scenario under study, the correspondences are:
10 packets for PL = 1E-3, 16 for PL = 1E-4 and 22 for PL= 1E-5. These static buffer size values
have also been determined by simulation.
Table 10 summarizes the simulation results for the two interfaces-node. From here, it can be
verified that the proposed mechanism achieves more efficient memory utilization for all the
simulated conditions and for both node interfaces. The efficiency improvement achieved is
around the 50% for the interface 1 and around 81% for the interface 2. It can be also noticed that
0 1000 2000 3000 4000 50000
2
4
6
8
10
12
Time [s]
[pkts
]
Buffer Size
Buffer Occupancy
1090.3 1090.4 1090.5 1090.6 1090.7 1090.8 1090.9
0
1
2
3
4
5
Time [s]
[pkts
]
Buffer Size
Buffer Occupancy
- 57 -
in both, static and dynamic buffer sizing schemes, the memory utilization efficiency is lesser
when the target PL value is more stringent. This is because greater buffer sizes are required to
reach this value and so the probability of underutilization increases.
TABLE 10. MEMORY EFFICIENCY COMPARISON FOR THE TWO INTERFACES-NODE CONFIGURED WITH STATIC VS. DYNAMIC
BUFFER SIZE
Q for
Static
[pkts]
STATIC_Q DYNAMIC_Q % Improvement
Interface 1
10 0.03984 0.05728 43.77%
16 0.02669 0.03961 48.41%
22 0.01976 0.03114 57.59%
Interface 2
10 0.02772 0.04424 59.56%
16 0.01780 0.03234 81.69%
22 0.01313 0.02649 101.85%
Memory utilization efficiency provides a global vision of the performance achieved with the
dynamic buffer sizing mechanism. On the other hand, it is interesting the study of a more
instantaneous measure, such us the difference d between the allocated buffer size Q and the
current buffer occupancy nw (that is, the number of packets waiting in the buffer), both computed
at packet transition times. This measure will be another systems’ discrete random variable
defined by:
wd Q n
(5.1)
The behavior of this random variable has also been studied in the previous simulations. Its pmf
is shown in figure 32 for the static buffer allocation, and in figure 33 for the dynamic one. As it
can be observed, for the static buffer configuration the random variable d is almost all the time
with a value closer to the maximum assigned buffer. This means that the buffer is almost all the
time at the maximum underutilization level. Meanwhile, with the dynamic buffer sizing this
variable is distributed among lesser values, and hence the underutilization level is considerably
lesser.
- 58 -
Fig. 32. pmf for random variable d computed in the N0 node with static buffer allocation.
Fig. 33. pmf for random variable d computed in the N0 node with dynamic buffer allocation.
0 5 10 15 200
0.1
0.2
0.3
0.4
0.5
d
pm
f
IF1 Static Q=10
0 5 10 15 200
0.1
0.2
0.3
0.4
0.5
d
pm
f
IF2 Static Q=10
0 5 10 15 200
0.1
0.2
0.3
0.4
0.5
d
pm
fIF1 Static Q=16
0 5 10 15 200
0.1
0.2
0.3
0.4
0.5
d
pm
f
IF2 Static Q=16
0 5 10 15 200
0.1
0.2
0.3
0.4
0.5
d
pm
f
IF1 Static Q=22
0 5 10 15 200
0.1
0.2
0.3
0.4
0.5
d
pm
f
IF2 Static Q=22
0 5 10 15 20 25 300
0.05
0.1
0.15
0.2
d
pm
f
IF1 DynQ-PL=1.0E-3
0 5 10 15 20 25 300
0.05
0.1
0.15
0.2
d
pm
f
IF2 DynQ-PL=1.0E-3
0 5 10 15 20 25 300
0.05
0.1
0.15
0.2
d
pm
f
IF1 DynQ-PL=1.0E-4
0 5 10 15 20 25 300
0.05
0.1
0.15
0.2
d
pm
f
IF2 DynQ-PL=1.0E-4
0 5 10 15 20 25 300
0.05
0.1
0.15
0.2
d
pm
f
IF1 DynQ-PL=1.0E-5
0 5 10 15 20 25 300
0.05
0.1
0.15
0.2
d
pm
f
IF2 DynQ-PL=1.0E-5
- 59 -
The mean value (D) of the random variable d is also important since it gives a global idea of
the buffer overprovisioning. Table 11 summarizes the obtained values. Once again, a better
performance is obtained with the dynamic buffer sizing algorithm, since this measured memory
waste is lesser than the values produced by a static buffer assignment under equivalent PL values.
Specifically, for the two interfaces-node a reduction of around 35% for the interface 1 and 47% for
the interface 2 has been achieved. This means also that to reach an equivalent packet loss
probability the node configured with the dynamic buffer sizing algorithm requires less amount of
memory.
TABLE 11. MEAN DIFFERENCE BETWEEN THE BUFFER SIZE AND THE BUFFER OCCUPANCY
Q for
Static
[pkts]
D for
Static
D for
Dynamic
Achieved
Reduction %
Interface 1
10 9.1122 6.1063 32.99%
16 15.0777 9.8235 34.85%
22 21.0668 12.9595 38.48%
Interface 2
10 9.2252 5.5350 40.00%
16 15.2156 8.0546 47.06%
22 21.2115 10.0159 52.78%
5.1.2 Time Delays Analysis
To compute different time delays (waiting, service and transfer time) per packet it was used
ns-3 traces generated for some specific events. Figure 34 shows the flow chart of methods
invoked for each data transmitted packet from it arrives to MAC layer until successfully or
failure transmission notification is received. Each shown method is associated with some specific
trace, which was captured tagging the time when it occur. It is worth of remember, that
broadcast frames (such as: arp request, some management and network control frames) are not
confirmed, so they have to be identified and separated from statistics. To track each packet
understand this process and know trace accessing were very useful. In the diagram of the figure
34, WifiMacQueue::Drop() method really is a sub-process of WifiMacQueue::Enqueue() method,
but it was put there only for illustration purposes.
The ns-3 traced sequence for transmitted packets is:
1. Trace accessing for enqueue events (adapted ns3::WifiMacQueue): /NodeList/[i]/DeviceList/[i]/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Enqueue
/NodeList/[i]/DeviceList/[i]/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/[AC]_EdcaTxopN/Queue/Enqueue
2. Trace accessing for dequeue events (adapted ns3::WifiMacQueue):
/NodeList/[i]/DeviceList/[i]/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Dequeue
/NodeList/[i]/DeviceList/[i]/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/[AC]_EdcaTxopN/Queue/Dequeue
- 60 -
3. Trace accessing for physical transmission (ns3::WifiPhy):
/NodeList/[i]/DeviceList/[i]/$ns3::WifiNetDevice/Phy/PhyTxBegin
4. Trace accessing for successful transmission notification (ns3::RegularWifiMac)
/NodeList/[i]/DeviceList/[i]/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/TxOkHeader
Or:
5. Trace accessing for failure transmission notification (ns3::RegularWifiMac)
/NodeList/[i]/DeviceList/[i]/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/TxErrHeader
With this traces it was obtained directly the waiting time ( wt ) and the transfer time ( t ) per
packet. The service time was deduced from:
sw ttt (5.2)
Figures from 35 to 40 show the p.d.f. of different time delays and its exponential distribution
of mean waiting, service and transfer time for Node 4 interface 1 with dynamic and static queue
size.
- 61 -
Fig. 34.Flow chart of packet transmission in 802.11 ns-3 implementation
- 62 -
Fig 35. Delay p.d.f. for Dynamic Queue Size - Node 4 Interface 1 with target
LP =1E-3
Fig 36. Delay p.d.f. for Static Queue Size - Node 4 Interface 1 with target
LP =1E-3
Fig 37. Delay p.d.f. for Dynamic Queue Size - Node 4 Interface 1 with target
LP =1E-4
- 63 -
Fig. 38. Delay p.d.f. for Static Queue Size - Node 4 Interface 1 with target
LP =1E-4
Fig. 39. Delay p.d.f. for Dynamic Queue Size - Node 4 Interface 1 with target
LP =1E-5
Fig 40. Delay p.d.f. for Static Queue Size - Node 4 Interface 1 with target
LP =1E-5
Table 12 shows the summary of different mean delays (waiting, service and transfer time) for
dynamic and static queue size with different target packet loss probabilities. These results show
- 64 -
that the time delays are independent of the target packet loss probability and they are
practically equal either for dynamic or static buffer size. It is important to remember that the
delay just depends on the packet priority and scheduler used [12].
TABLE 12. DIFFERENT TIME DELAYS FOR DYNAMIC AND STATIC BUFFER SIZE IN SCENARIO-1
Target PL
Dynamic Static
Tw
[ms]
Ts
[ms]
T
[ms]
Tw
[ms]
Ts
[ms]
T
[ms]
1E-3 0.3374 0.4673 0.8048 0.3403 0.4685 0.8088
1E-4 0.3354 0.4683 0.8037 0.3403 0.4685 0.8088
1E-5 0.3357 0.4669 0.8026 0.3357 0.4669 0.8026
As it was mention before together with the p.d.f. it was graph the exponential distribution of
different time delays for comparison purposes (highlighted in light blue).
To explain theoretically the results shown in the previous figures it is going to present the
function analysis.
The mean service time can be expressed as follows:
colcolsuccesss .TNTT (5.3)
Where successT is the mean successful transmission time, colN is the mean number of collisions
and colT the mean time elapsed of one collision.
The minimum elapsed time in successful transmission according to different source time delays
in IEEE 802.11 is defined as:
ptxacktxpktsuccess 2.tTSIFSTDIFSmin)(totalT (5.4)
For CSMA/CA
ptxacktxpktsuccess 4.tTSIFSTSIFSCTSSIFSRTSDIFSmin)(totalT (5.5)
With RTS/CTS
On the other hand packet transmission time is given by:
C
LTtxpkt (5.6)
The packet arrival rate and packet length used in simulation have an exponential distribution.
More specifically packet length has a truncated exponential distribution from 12 to 1500B.
Moreover, the measured mean number of collisions per transmitted packet is too much lower,
- 65 -
so the eq. (5.3) can be reduced to:
successs TT
If we observe the p.d.f of service time from figure 35 to 40, it is approximately equal to the
exponential distribution, which shows the transmission packet time predominates over other
delay sources. Hence, in this scenario the network devices can be modeling as M/M/1 queuing
system. The probability density functions of different time delays of M/M/1 queuing system are
shown below:
t/TeT
1)( tf t (5.7)
st/T
s
eT
1)(
tf
st (5.8)
t/Te
T
1)()1()(
ttf
wt (5.9)
Where T is the mean transfer time, sT mean service time and ρ the utilization factor.
More specifically:
(5.10)
C
LTs (5.11)
sw TT
1 (5.12)
sTT
1
1 (5.13)
The )(tfwt
function described in eq. (5.9) is the waiting time p.d.f. and it is the sum of the
functions of packets that do not wait and those that wait in the buffer before being served. Both
multiplied by their probabilities (1-ρ) and ρ respectively. For comparison purposes between
obtained p.d.f. of waiting time and its exponential distribution, it was extracted zero waiting time
registers (or the served packets that do not wait in the buffer).
- 66 -
5.2 Dynamic Buffer Size Allocation in WMN
After testing the correct operation of dynamic buffer size allocation in WLAN networks the
following subsections show the operation of dynamic mechanism in Wireless Mesh Networks
(WMN).
5.2.1 Scenario-2: Chain Mesh Network Topology
In the scenario-2 (figure 41) first it was doing several simulations for static buffer size in order
to determine the needed traffic load conditions to work in stable conditions. Also, these
simulations allow observing the effect of increasing the network diameter in the packet loss ratio.
The chosen topology is a simple chain topology with equal distance between nodes (80m) in
order to facilitate the addition of nodes without having many variables that could affect the
stability of the network operation. Table 13 shows data used in the simulation.
Fig. 41. Scenario-2: Mesh Chain Topology
TABLE 13. DATA USED IN SIMULATION FOR CHAIN MESH TOPOLOGY AND STATIC BUFFER SIZE
SIMULATION DATA
Mean Packet Length 200B
Mean packet arrival rate
Flow 1: 1paq/5ms
Flow 2: 1paq/6ms
Flow 3: 1paq/7ms
Mean Tx bit rate
Flow 1: 320kbps
Flow 1: 266kbps
Flow 1: 228kbps
Qstatic 3
Simulation Time 5000s
The offered load o can be seen in the figure 42, the network load fluctuation is not only due
to generated traffic by source mesh STA node, but also due to activation or deactivation of
intermediate nodes that retransmit the packets to destination mesh STA node.
- 67 -
Fig. 42. Offered Load Diagram
The following tables from 14 to 19 show the packet loss per node, end-to-end packet loss and
the average packet loss per node as the number of hops increases. The end-to-end packet loss
is approximated equal to the sum of each node packet loss (as it can be seen in the simple
following demonstration):
If there are n nodes in the network and N packets are transmitted from node 1, the second
one receives 1
1 LPN packets, third one 21
11 LL PPN and so on. So, the cN (Number of
carried packets) can be generalized as the following equation:
)NP)...(1P)(1P(1N1-n21
LLLc (5.14)
The Packet Loss Ratio (PLR) is:
N
N1PLR c (5.15)
1L2-nL1LLL1LLL1LLL
c
LLLc
PP...P...PPP...PPP...PP1N
N
)P)...(1P)(1P(1N
N
322121
1-n21
nnnn
(5.16)
If the loss probabilities are too much lower all terms which are products are approximately
equal to 0, so the eq. (5.16) can be expressed as:
1L2LL
c P...PP1N
N1
n
(5.17)
and PLR would be:
- 68 -
1LLL P...PPPLR21
n
(5.18)
TABLE 14 . STATIC_Q: MEASURED LP FOR 1X2 MESH TOPOLY
Topology Node Measured LP
1x2
N0 → N1 0 2.04E-5
Accumulated LP 2.04E-5
TABLE 15. STATIC_Q: MEASURED PL FOR 1X3 MESH TOPOLY
Topology Node Measured LP
1x3
N0 → N2
0 1.89E-4
1 7.07E-5
Accumulated LP 2.60E-4
Avg. LP /Node 1.3E-4
TABLE 16 . STATIC_Q: MEASURED PL FOR 1X4 MESH TOPOLY
Topology Node Measured LP
1x4
N0 → N3
0 7.5E-4
1 3.5E-4
2 1.32E-5
Accumulated LP 1.11E-3
Avg. LP /Node 3.7E-4
TABLE 17. STATIC_Q : MEASURED PL FOR 1X5 MESH TOPOLY
Topology Node Measured LP
1x5
N0 → N3
0 1.6E-3
1 1.12E-3
2 7.79E-5
3 3.60E-6
Accumulated LP 2.80E-3
Avg. LP /Node 7.0E-4
TABLE 18. STATIC_Q: MEASURED LP FOR 1X6 MESH TOPOLY
Topology Node Measured LP
1x6
N0 → N5
0 1.43E-3
1 2.17E-3
2 6.21E-4
3 1.69E-5
4 0.0
Accumulated LP 4.24E-3
Avg. LP /Node 8.48E-4
- 69 -
TABLE 19. STATIC_Q: MEASURED LP FOR 1X7 MESH TOPOLY
Topology Node Measured LP
1x7
N0 → N6
0 1.82E-3
1 2.1E-3
2 2.02E-3
3 2.83E-4
4 6.02E-6
5 0.0
Accumulated LP 6.23E-3
Avg. LP /Node 1.04E-3
Table 20 summarizes the results obtained in the different simulations where it can be observed
the end-to-end packet loss and the average Packet Loss per hop.
TABLE 20. STATIC_Q: SUMMARY OF MEASURED END-TO-END LP FOR CHAIN MESH TOPOLY
Topology No. Hops Measured LP
Σ LP Avg. LP /Hop
1x2 1 2.04E-5 2.04E-5
1x3 2 2.60E-4 1.3E-4
1x4 3 1.11E-3 3.7E-4
1x5 4 2.80E-3 7.0E-4
1x6 5 4.24E-3 8.48E-4
1x7 6 6.23E-3 1.04E-3
The results show that the packet loss is higher in the first Mesh STA node of the chain
topology and it decreases in the nodes as the packets traverse the network from source to
destination. This is because of the number of contentions increases with the size of the network,
and also because of packet loss produced along the path transmission. Moreover, the more
number of hops, the more packet loss per node and PLR. Consequently, it is important to
consider the network size since the higher network diameter the less traffic will be supported by
the network.
The packet losses obtained with static buffer size are in the range of target packet loss
probabilities solicited by the dynamic mechanism in WLAN simulations (section 5.1). In the case
of WMN the results obtained with this traffic load conditions give us a margin of target packet
loss probabilities to be guaranteed (between 1E-4 and 1E-3). Figure 43 shows the relation
between Packet Loss Ratio (PLR) and number of hops.
On the other hand, the generated data traffic or transmission bit rate is low, to have a margin
to increase the number of hops in stability conditions (without overloading the network) and to
- 70 -
have more resolution1 in the results as it is increased the network diameter.
Fig. 43. PLR vs Number of hops in static queue size.
After obtaining the traffic load conditions in static buffer size simulations, this section shows
the results of the dynamic mechanism implementation in Wireless Mesh Networks. Table 21
shows data used in simulation and table 22 shows MAC and PHY parameters.
TABLE 21. DATA USED IN SIMULATION FOR CHAIN MESH TOPOLOGY AND DYNAMIC BUFFER SIZE
SIMULATION DATA
Mean Packet Length 200B
Mean packet arrival
rate
Flow 1: 1paq/5ms
Flow 2: 1paq/6ms
Flow 3: 1paq/7ms
Mean Tx bit rate
Flow 1: 320kbps
Flow 1: 266kbps
Flow 1: 228kbps
Qinit 100
Simulation Time 5000s
1 Resolution: To have more valid results in the figures as the number of hops increases.
- 71 -
TABLE 22. NS-3: MAC(IEEE 802.11S)/PHY PARAMETERS USED IN SIMULATION
Parameter Value
CTS Timeout 75us
AckTimeout 75us
BasicBlockAckTimeout 281us
CompressedBlockAckTimeout 107us
Sifs 16us
MaxPropagationDelay 333us
Slot 9us
Max No. of retransmission
attempts for RTS/Data packets
7
RTS/CTS Threshold 2346B
Fragmentation Threshold 2346B
Mesh 802.11s
BeaconGeneration true
BeaconInterval 0.5s
Peer Management Protocol
MaxNumberOfPeerLinks 32
Peer Link
MaxRetries 4
MaxBeaconLoss 5
MaxPacketFailure 5
HWMP Protocol
Mode On-demand
Max Queue Size 255
Reactive Path Timeout 5100s
Max Path Request Retries 3
MaxTtl 32
DO flag 0
RF flag 1
PHY
Data/Control OFDM Rate 6Mbps
Propagation Loss Model
Log distance
Exponent: 3
ReferenceDistance: 1m
ReferenceLoss: 46.67dB
One relevant parameter of IEEE 802.11 is RTS/CTS threshold. As it was mentioned in section
2.2 is better to deactivate RTS/CTS (for WMN) mechanism because it just adds overhead. So,
this threshold has the default configured value for ns-3 simulator (2346B) taking into account
that the generated packets are from 12 to 1500B.
The simulations were done using two access categories or traffic classes (AC_VO and AC_BE).
However, the dynamic mechanism can be activated in any of 4 EDCA queues. In the case of
AC_VO it is important to mention that as it was explained in chapter 4 the Management HWMP
frames PREP are also transmitted using AC_VO queue. So, data traffic competes with
management frames and therefore it is produced a considerable queue occupation and the
probability of packet loss increases. By default, an established path is used for 5 seconds and
then path request – reply procedure is repeated to try to find a better path. Note that the path
discovery procedure is used even for direct neighbors known by Peering Management Protocol
[14]. In these simulations due to network topology of scenario-2, where there is not alternative
- 72 -
paths it was configured that the path discovery mechanism occurs once in all simulation in order
to optimize the performance of the system in this situation.
On the other hand, the dynamic mechanism was activated in all nodes with two target packet
loss probabilities: 1E-3 and 1E-4, range values obtained in static buffer size simulations. It is
worth mentioning, that the target packet loss probability is guaranteed per node not end-to-end
packet loss. Tables from 23 to 38 show the packet loss and transfer time obtained per node in
different chain topologies increasing number of hops until 6. Also end-to-end packet loss ratio
was obtained as well as end-to-end delay.
AC=BE TABLE 23 . DYNAMIC_Q: MEASURED L
P AND T FOR 1X2 MESH TOPOLY
Topology Node
Target LP
1E-3
Target LP
1E-4
LP Ti[ms] L
P Ti[ms]
1x2
N0 → N1
1Hops
0 2.85E-4 0.49851 1.92E-5 0.49902
Accumulated LP 2.85E-4 1.92E-5
Avg. LP /Hop 2.85E-4 1.92E-5
TEE[ms] 0.49851 0.49902
AC=VO TABLE 24. DYNAMIC_Q: MEASURED L
P AND T FOR 1X2 MESH TOPOLY
Topology Node
Target LP
1E-3
Target LP
1E-4
LP Ti[ms] LP Ti[ms]
1x2
N0 → N1
1Hops
0 2.21E-4 0.49592 1.56E-5 0.49604
Accumulated LP 2.21E-4 1.56E-5
Avg. LP /Hop 2.21E-4 1.56E-5
TEE[ms] 0.49592 0.49604
AC=BE TABLE 25. DYNAMIC_Q: MEASURED L
P AND T FOR 1X3 MESH TOPOLY
Topology Node
Target L
P
1E-3
Target L
P
1E-4
LP Ti[ms] L
P Ti[ms]
1x3
N0 → N2
2Hops
0 1.69E-4 0.58369 1.44E-5 0.58432
1 1.20E-6 0.68935 0.0 0.68925
Accumulated LP 1.70E-4 1.44E-5
Avg. LP /Hop 8.51E-5 7.2E-6
TEE[ms] 1.273 1.273
- 73 -
AC=VO TABLE 26. DYNAMIC_Q: MEASURED LP AND T FOR 1X3 MESH TOPOLY
Topology Node
Target LP
1E-3
Target LP
1E-4
LP Ti[ms] LP Ti[ms]
1x3
N0 → N2
2Hops
0 1.50E-4 0.58491 1.80E-5 0.58506
1 0.0 0.61091 0.0 0.61072
Accumulated LP 1.50E-4 1.80E-5
Avg. LP /Hop 7.5E-5 9E-6
TEE[ms] 1.19582 1.1958
AC=BE TABLE 27. DYNAMIC_Q: MEASURED LP AND T FOR 1X4 MESH TOPOLY
Topology Node
Target LP
1E-3
Target LP
1E-4
LP Ti[ms] LP Ti[ms]
1x4
N0 → N3
3Hops
0 1.97E-4 0.70654 1.20E-5 0.70959
1 0.0 0.75281 0.0 0.74937
2 0.0 0.6974 0.0 0.69652
Accumulated LP 1.97E-4 1.20E-5
Avg. LP /Hop 6.56E-5 4.0E-6
TEE[ms] 2.1568 2.1555
AC=VO TABLE 28. DYNAMIC_Q: MEASURED LP AND T FOR 1X4 MESH TOPOLY
Topology Node
Target LP
1E-3
Target LP
1E-4
LP Ti[ms] LP Ti[ms]
1x4
N0 → N3
3Hops
0 3.48E-4 0.71243 2.64E-5 0.71676
1 0.0 0.66459 0.0 0.66046
2 2.40E-6 0.59662 0.0 0.5961
Accumulated LP 3.504E-4 2.64E-5
Avg. LP /Hop 1.17E-4 8.8E-6
TEE[ms] 1.9736 1.9733
- 74 -
AC=BE TABLE 29. DYNAMIC_Q: MEASURED L
P AND T FOR 1X5 MESH TOPOLY
Topology Node
Target L
P
1E-3
Target L
P
1E-4
LP Ti[ms] L
P Ti[ms]
1x5
N0 → N4
4Hops
0 2.55E-4 0.88634 3.35E-5 0.88348
1 3.59E-6 0.83958 0.0 0.84201
2 0.0 0.74035 0.0 0.73967
3 0.0 0.67872 0.0 0.67587
Accumulated LP 2.59E-4 3.35E-5
Avg. LP /Hop 6.46E-5 8.38E-6
TEE[ms] 3.1450 3.1410
AC=VO TABLE 30. DYNAMIC_Q: MEASURED LP AND T FOR 1X5 MESH TOPOLY
Topology Node
Target LP
1E-3
Target LP
1E-4
LP Ti[ms] LP Ti[ms]
1x5
N0 → N4
4Hops
0 3.64E-4 0.94802 4.66E-5 0.94268
1 2.04E-5 0.72659 0.0 0.72346
2 2.39E-6 0.6213 0.0 0.62104
3 0.0 0.59033 0.0 0.59041
Accumulated LP 3.87E-4 4.66E-5
Avg. LP /Hop 9.67E-5 1.17E-5
TEE[ms] 2.8862 2.8776
AC= BE TABLE 31. DYNAMIC_Q: MEASURED LP AND T FOR 1X6 MESH TOPOLY
Topology Node
Target LP
1E-3
Target LP
1E-4
LP Ti[ms] LP Ti[ms]
1x6
N0 → N5
5Hops
0 2.60E-4 0.87485 4.07E-5 0.87339
1 2.28E-5 0.94793 0.0 0.94297
2 8.39E-6 0.81943 0.0 0.8233
3 0.0 0.70806 0.0 0.70766
4 0.0 0.66301 0.0 0.66492
Accumulated LP 2.91E-4 4.07E-5
Avg. LP /Hop 5.82E-5 8.14E-6
TEE[ms] 4.0133 4.0123
- 75 -
AC= VO TABLE 32. DYNAMIC_Q: MEASURED LP AND T FOR 1X6 MESH TOPOLY
Topology Node
Target LP
1E-3
Target LP
1E-4
LP Ti[s] LP Ti[s]
1x6
N0 → N5
5Hops
0 9.60E-4 0.9266 2.31E-4 0.92745
1 3.24E-5 0.87026 1.08E-5 0.87591
2 2.40E-6 0.67189 0.0 0.67656
3 1.20E-6 0.60409 0.0 0.60391
4 3.60E-6 0.58357 0.0 0.58417
Accumulated LP 9.99E-4 2.42E-4
Avg. LP /Hop 1.99E-4 4.84E-5
TEE[ms] 3.6564 3.668
AC= BE TABLE 33. DYNAMIC_Q: MEASURED LP AND T FOR 1X7 MESH TOPOLY
Topology Node
Target LP
1E-3
Target LP
1E-4
LP Ti[ms] LP Ti[ms]
1x7
N0 → N6
6Hops
0 9.17E-4 0.86972 6.57E-4 0.87636
1 5.28E-5 0.9461 3.47E-5 0.94654
2 3.84E-5 0.96662 1.20E-6 0.96711
3 2.40E-6 0.78029 0.0 0.78336
4 0.0 0.69096 0.0 0.69237
5 0.0 0.65721 0.0 0.66044
Accumulated LP 1.01E-3 6.93E-4
Avg. LP /Hop 1.68E-4 1.15E-4
TEE[ms] 4.911 4.9262
AC= VO TABLE 34. DYNAMIC_Q: MEASURED LP AND T FOR 1X7 MESH TOPOLY
Topology Node
Target
1E-3
Target
1E-4
LP Ti[ms] L
P Ti[ms]
1x7
N0 → N6
6Hops
0 7.71E-4 0.93152 3.46E-4 0.93056
1 3.72E-5 0.86983 8.38E-6 0.87775
2 1.68E-5 0.82855 0.0 0.83414
3 4.80E-6 0.64975 0.0 0.64859
4 1.20E-6 0.59868 0.0 0.59868
5 8.39E-6 0.5854 0.0 0.58467
Accumulated LP 8.39E-4 3.54E-4
Avg. LP /Hop 1.4E-4 5.90E-5
TEE[ms] 4.4637 4.4744
- 76 -
AC= BE TABLE 35. DYNAMIC_Q: MEASURED
LP
FOR 1X8 MESH TOPOLY
Topology Node Target L
P
1E-3 1E-4
1x8
N0 → N6
7Hops
0 8.29E-4 3.43E-4
1 3.36E-5 0.0
2 3.00E-5 1.20E-6
3 1.20E-6 1.20E-6
4 6.0E-6 0.0
5 0.0 0.0
6 0.0 0.0
Accumulated LP 8.998E-4 3.454E-4
Avg. LP /Hop
AC= VO TABLE 36. DYNAMIC_Q: MEASURED L
P
FOR 1X8 MESH TOPOLY
Topology Node Target
1E-3 1E-4
1x8
N0 → N7
7Hops
0 6.77E-4 6.57E-4
1 2.76E-5 2.40E-5
2 3.48E-5 0.0
3 8.40E-6 1.20E-6
4 5.99E-6 0.0
5 3.60E-6 0.0
6 3.60E-6 0.0
Accumulated LP 7.61E-4 6.83E-4
Avg. LP /Hop 1.087E-4 9.76E-5
- 77 -
AC= BE TABLE 37. DYNAMIC_Q: MEASURED
LP FOR 1X9 MESH TOPOLY
Topology Node Target LP
1E-3 1E-4
1x9
N0 → N8
8Hops
0 1.1E-3 3.19E-4
1 3.48E-5 2.40E-6
2 3.96E-5 1.08E-5
3 3.60E-5 0.0
4 1.68E-5 0.0
5 4.80E-6 0.0
6 0.0 0.0
7 0.0 0.0
Accumulated LP 1.23E-3 3.31E-4
Avg. LP /Hop 1.54E-4 4.14E-5
AC= VO TABLE 38. DYNAMIC_Q: MEASURED
LP
FOR 1X9 MESH TOPOLY
Topology Node
Target LP
1E-4
1E-3 1E-4
1x9
N0 → N6
8Hops
0 1.75E-3 5.42E-4
1 4.56E-5 5.31E-5
2 2.76E-5 2.95E-5
3 1.08E-5 0.0
4 8.41E-6 0.0
5 1.20E-6 0.0
6 7.21E-6 0.0
7 6E-6 0.0
Accumulated LP 1.86E-3 6.25E-4
Avg. LP /Hop 2.33E-4 7.81E-5
Table 39 and 40 summarize the results obtained in the different simulations where it can be
observed the end-to-end packet loss, end-to-end delay and average Packet Loss per hop for
AC_BE and AC_VO.
- 78 -
AC=BE TABLE 39 . DYNAMIC_Q: SUMMARY OF MEASURED END-TO-END
LP
AND TEE FOR CHAIN MESH TOPOLY
Topology No.
Hops
Target LP
1E-3
Target LP
1E-4
Σ L
P TEE
[ms] Σ
LP TEE
[ms]
1x2 1 2.85E-4 0.49592 1.92E-5 0.49604
1x3 2 1.70E-4 1.273 1.44E-5 1.273
1x4 3 1.97E-4 2.1568 1.20E-5 2.1555
1x5 4 2.59E-4 3.1450 3.35E-5 3.1410
1x6 5 2.91E-4 4.0133 4.07E-5 4.0123
1x7 6 1.01E-3 4.911 6.93E-4 4.9262
1x8 7 8.99E-4 3.45E-4
1x9 8 1.23E-3 3.31E-4
AC=VO TABLE 40. DYNAMIC_Q: SUMMARY OF MEASURED END-TO-END
LP
AND TEE FOR CHAIN MESH TOPOLY
Topology No.
Hops
Target LP
1E-3
Target LP
1E-4
Σ L
P TEE
[ms] Σ
LP TEE
[ms]
1x2 1 2.21E-4 0.49592 1.56E-5 0.49604
1x3 2 1.50E-4 1.19582 1.80E-5 1.1958
1x4 3 3.50E-4 1.97364 2.64E-5 1.9733
1x5 4 3.87E-4 2.8862 4.66E-5 2.8776
1x6 5 9.99E-4 3.6564 2.42E-4 3.668
1x7 6 8.39E-4 4.4637 3.54E-4 4.4744
1x8 7 7.61E-4 6.83E-4
1x9 8 1.86E-3 6.25E-4
As it can be seen in the results show in the previous tables 39 and 40, there is a specific
number of hops for the current traffic load conditions (highlighted in red), from which the target
packet loss probabilities are not achieved. For these simulations: in AC_BE and AC_VO the
target 31 EPL is not achieved from 8 hops forward, for AC_BE the target 41 EPL is not
achieved from 6 hops forward and for AC_VO the target 41 EPL is not achieved from 5 hops
forward.
Moreover, similar to static buffer size behavior mentioned in section 5.2, in dynamic buffer
size allocation we expect not only packet loss is higher in the first node and decreases as the
packets traverse from source to destination mesh STA node, but also the more number of hops,
the higher end-to-end packet loss.
- 79 -
In all simulations was obtained the transfer time (t) and end-to-end delay ( EEt ) per packet and
in above tables also it has been included the mean transfer time (T) per channel and mean end-
to-end delay ( EET ), which can be evidenced are not affected by target packet loss probability
guaranteed by dynamic mechanism, their values are approximately equal either with 31 EPL
or 41 EPL . So, again it can be said that the transfer time is independent of target packet loss.
Similar to packet loss per node, we expect the delay in the channels decreases as the packets
traverse the network from source to destination. Also, it is logic, the more number of hops, the
more end-to-end delay. The figures 44 and 45 show the Packet Loss Ratio and end-to-end
delay versus number of hops.
Fig. 44. End-to-end packet loss versus number of hops.
Fig. 45. End-to-end delay versus number of hops.
The relation between PLR and number hops shows in the figure 44 differs from what expected
because there are some exceptions where can be evidenced variable increases or decreases in
packet loss, as number of hops increases. This case will be discussed later in subsection 5.2.1.
On the other hand, as we expect end-to-end delay increases with the number hops, the
- 80 -
relation between both parameters is not totally linear. Depending on traffic class or access
category there is a difference in channel access which is controlled by EDCA (IEEE 802.11e).
The access category AC_VO has lower service time than AC_BE and therefore transfer time and
end-to-end delay is also lower.
As it can be seen in figure 45 the mean transfer time (T) per channel starts to stabilize or
maintains its value after certain number of hops. For example, in channel 1, the transfer time is
almost equal from 4 hops forward. Moreover, for few hops (e.g. lower than 3 hops) the end-to-
end delay are not so much different between traffic classes, but from 4 hops forward the delay is
each time lower for access category AC_VO than AC_BE. Also, it can be evidenced that the
mean transfer time per channel for AC_BE and AC_VO are practically equal in first and second
channel; however, from third channel forward the transfer time is lower for AC_VO and lower the
end-to-end delay as number of hops increases. The delay in the channels for both access
categories AC_BE and AC_VO decreases as the packets traverse the network from source to
destination reaching to stabilize in 0.65ms and 0.59ms respectively.
In the following figures it is shown the average channel utilization and buffer size for different
hops and traffic classes. The buffer size and its utilization for different target packet loss
probability are also shown.
BEST EFFORT TRAFFIC CLASS
Fig. 46. Average Channel utilization for different number of hops and Target
LP =1E-3.
- 81 -
Fig. 47. Buffer Size for different number of hops and Target
LP =1E-3.
It can be seen that the average channel occupancy as well as queue size increase with the
number of hops with the same traffic conditions due to transmissions of intermediate nodes that
use the channel and therefore the increase of contention medium access.
Fig. 48.Buffer Size for 1x4 chain topology and different target
LP .
Also, like in the infrastructure Wireless LAN (WLAN) the queue size calculated by the
dynamic mechanism is higher as lower is target packet loss probability solicited as it can be seen
in the figure 48.
- 82 -
Fig. 49.Buffer Size utilization for 1x4 chain topology and different target
LP .
In figure 49 it can be seen that queue size follows the shape of number of packets that are in
the queue. While higher is the queue occupation better the performance of the mechanism
because it is taking advantage of the buffer memory. Memory utilization efficiency is analyzed in
subsection 5.2.2.1.
VOICE TRAFFIC CLASS
Fig. 50.Average Channel utilization for different number of hops and Target LP =1E-3.
- 83 -
Fig. 51.Buffer Size for different number of hops and Target
LP =1E-3.
Fig. 52.Buffer Size for 1x4 chain topology and different targetLP .
Fig. 53.Buffer Size utilization for 1x4 chain topology and different targetLP .
- 84 -
The following figures show probability density function (p.d.f) of different time delays (waiting,
service and transfer time) in sender mesh STA node (Node 0) for 5 hops network topology and
two access categories.
Fig. 54.Node 0 Delay p.d.f. with Dynamic Queue Size for BE traffic and target LP =1E-3
Fig. 55.Node 0 Delay p.d.f. with Dynamic Queue Size for VO traffic and target LP =1E-3
The mean service time can be expressed as follows:
colcolsuccesss .TNTT (5.19)
Where successT , is the mean successful transmission time or mean transmission time in the first
attempt, colN is the mean number of collisions and colT is the mean elapsed time of one
collision.
Due to channel conditions and simulated parameters the mean number of retransmissions per
packet is too much lower in all last simulations (or what is the same the mean number of
- 85 -
collisions per packet is too much lower) and therefore the service time per packet is in average
the successful transmission time, which for EDCA is expressed by:
ptxacktxpktsuccess 2tTSIFSTAIFSmintotalT (5.20)
For CSMA/CA.
ptxacktxpktsuccess 4tTSIFSTSIFSCTSSIFSRTSAIFSmintotalT (5.21)
With RTS/CTS
On the other hand, the transmission time per packet is:
C
LTtxpkt (5.22)
The transmission time per packet follows an exponential distribution because of packet length.
Figure 54 and 55 show that the p.d.f. of service time versus the exponential function of its
average are approximately equal, which show that packet transmission time per packet
predominates. This gives us as result that the waiting time ( wt ) in queue is also very
approximated to exponential distribution. Remember for M/M/1 case Tw is:
sw Tρ1
ρT
(5.23)
In the waiting time p.d.f. shown in the figure 54 and 55 as in section 5.1 it has been extracted
zero values in order to graph only the delay corresponding to packets that wait in queue to be
served.
Also it is important to mention, that for Voice traffic class there are failures transmitted
packets that do not occur for Best Effort traffic class. This is due to not only the contention
window is lower for Access Category AC_VO but also due to the Transmission Opportunity Time
(TxOP) is higher (see Table 2). Therefore, the collision probability for AC_VO is higher than
AC_BE. However, the packets that have not been transmitted are excluded and for the effective
transmitted packets the mean number of retransmissions per flow is too much lower. It is
important to remember, that the target packet loss probability that guarantee the dynamic buffer
size allocation mechanism is only referent to buffer overflow.
However, to observe the impact in time delay when more retransmissions occur in the network,
- 86 -
it were done a set of simulations to add variable loss in the transmission channel in order to
obtain in average more than one attempt of transmission per packet. Figure 56 shows the service
time p.d.f. for Voice traffic and 4 hops network topology (1x5 Wireless Mesh Network) where
mean transmission attempts per served packet is 1.3602 and figure 57 shows the service time
p.d.f. for the same traffic and topology but with higher (3.3406) mean transmission attempts.
TABLE 41 . DELAY AND MEAN NO. OF TRANSMISSIONS FOR 1X5 MESH TOPOLY AND AC_VO WITH TARGET L
P =1E-3
Network
Topology
(Voice Traffic)
Tw
[ms]
Ts
[ms]
T
[ms]
Mean TX
attempts
N
1x5 0.3866 0.7055 1.0921 1.3602
Fig. 56.Service Time p.d.f. with N=1.3602 for 1x5 Mesh Topology and VO traffic
TABLE 42. DELAY AND MEAN NO. OF TRANSMISSIONS FOR 1X5 MESH TOPOLY AND AC_VO WITH TARGET L
P =1E-3
Network
Topology
(Voice Traffic)
Tw
[ms]
Ts
[ms]
T
[ms]
Mean TX
attempts
N
1x5 1.1971 1.4131 2.6102 3.3406
- 87 -
Fig. 57.Service Time p.d.f. with N=3.3406 for 1x5 Mesh Topology and VO traffic.
The figures show that when the mean number of collisions is too much lower the service time
closely follows an exponential distribution, while when the mean number of collisions is higher
the service time follows a different distribution. In the figure 57, for comparison effects it has
been included a gamma distribution over the service time p.d.f.
5.2.1.1 Dynamic Mechanism with Finite Buffer Size
The variable behavior of end-to-end packet loss shown in the figure 44 is analyzed in this
subsection. First, it was noted that there are some abrupt changes in ρ and Q in some
simulations, like those pointed out with arrows in figures 58, 60, 63 and 65. So, a set of
simulations were carried out with finite buffer size to avoid abrupt changes and to observe the
achieved packet loss for 31 EPL target packet loss probability. For 1x6 and 1x7 topologies
(AC_VO) the maximum queue size in both cases is 5, from this value occurs the abrupt change in
queue size (see figures 60 and 65). The tables 43 and 44 show the measured packet loss per
node for chain topology with 5 and 6 hops with infinite and finite buffer size.
- 88 -
TABLE 43. MEASURED L
P FOR AC_VO WITH INFINITE AND FINITE BUFFER SIZE
Without Buffer
Limit
With Finite Buffer
Qmax=5
Topology Node
Target LP
1E-3
Target LP
1E-3
LP
LP
1x6
N0 → N5
5Hops
0 9.60E-4 3.68E-4
1 3.24E-5 1.51E-4
2 2.40E-6 3.6E-6
3 1.20E-6 0.0
4 3.60E-6 3.99E-6
Accumulated LP 9.99E-4 5.31E-4
Avg. LP /Hop 1.99E-4 1.06E-4
TABLE 44. MEASURED PL FOR AC_VO WITH INFINITE AND FINITE BUFFER SIZE
Without Buffer
Limit
With Finite Buffer
Qmax=5
Topology Node Target L
P
1E-3
Target L
P
1E-3
LP
LP
1x7
N0 → N5
6Hops
0 7.71E-4 5.91E-4
1 3.72E-5 1.53E-4
2 1.68E-5 7.67E-5
3 4.80E-6 2.40E-6
4 1.20E-6 1.20E-6
5 8.39E-6 7.20E-6
Accumulated LP 8.39E-4 8.32E-4
Avg. LP /Hop 1.4E-4 1.39E-4
AC= VO TABLE 45. SUMMARY OF MEASURED EN-TO-END
LP
FOR AC_VO WITH INFINITE AND FINITE BUFFER SIZE
Topology Without Buffer Limit
Buffer Limit
Qmax=5
Σ L
P Σ L
P
1x6 9.99E-4 5.31E-4
1x7 8.39E-4 8.32E-4
When the finite buffer is configured, the buffer utilization is also limited and therefore the
abrupt updates are avoided. The end-to-end packet loss with finite buffer size decreases
referent to the same topology with infinite buffer size as it is shown in the table 45, where it was
analyzed two topologies with 5 and 6 hops. It can be understood that, if there are high changes
- 89 -
in average channel utilization like those shown in figure 58 and 63, and there is the memory
capacity to increase the buffer size, this will cause the loss probability remains under target
solicited value and vice versa. In any case, if the data traffic is regular we expect the channel
utilization behaves in the same way. Moreover, as it is explained in section 5.1 the memory
utilization efficiency η is computed as: ratio between utilization queue area ( aN - current
number of packet units waiting in the buffer) and allocated buffer size area. When abrupt changes
occur, the memory efficiency will decrease due to short queue size areas not occupied by aN
(see figure 61 –zoom buffer size utilization-).
Hence, it is recommended to analyze the behavior of the functions of the dynamic mechanism
for alfa, beta, aN and Q computations (see the functions of buffer sizing via maximum entropy in
chapter 3). Also, it is important to remember, that ρ and aN measured values are the average
of the current values with past values through exponentially weighted moving average [12] (w)
with purpose of smoothing the values and avoiding oscillations that prevent the desired work [12].
The weight (w) given to the current or past value depends on fixed initial value that it has been
calibrated previously. It may be recommended that w could be dynamic and adapted to network
traffic conditions. Figures 59 and 64 show the average channel utilization with finite buffer size;
and on the other hand, figures 62 and 66 show the buffer utilization where it can be evidenced
the buffer limit (Qmax=5) configured.
Fig. 58.Average Channel utilization for 1x6 mesh topology, VO traffic, and Target
LP =1E-3 with Infinite Buffer Size.
- 90 -
Fig. 59.Average Channel utilization for 1x6 mesh topology, VO traffic, and Target
LP =1E-3 with Finite Buffer Size Qmax=5.
Fig. 60.Buffer utilization for 1x6 mesh topology, VO traffic, and Target
LP =1E-3 with Infinite Buffer Size.
Fig. 61.Buffer utilization for 1x6 mesh topology, VO traffic, and Target L
P =1E-3 with Infinite Buffer Size (zoom version).
- 91 -
Fig. 62.Buffer utilization for 1x6 mesh topology, VO traffic, and Target
LP =1E-3 Finite Buffer Size Qmax=5.
Fig. 63.Average Channel utilization for 1x7 mesh topology, VO traffic, and Target
LP =1E-3 with Infinite Buffer Size.
Fig. 64.Average Channel utilization for 1x7 mesh topology, VO traffic, and Target
LP =1E-3 with Finite Buffer Size Qmax=5.
- 92 -
Fig. 65.Buffer utilization for 1x7 mesh topology, VO traffic, and Target
LP =1E-3 with Infinite Buffer Size.
Fig. 66.Buffer utilization for 1x7 mesh topology, VO traffic, and Target
LP =1E-3 Finite Buffer Size Qmax=5.
According to the tests that have been carried out, the variable behavior of the end-to-end
packet loss shown in the figure 44 can be attributed to the tuning required in the functions of
the dynamic mechanism, which can be the objective of study in future works.
5.2.2 Scenario-3: Wireless Mesh Topology
In this section it is simulated other WMN scenario where there is a central node (which can
acts as Portal Mesh STA node or Gateway) and it communicates with peripheral mesh STA nodes.
The network topology is shown in the figure 67, where it is also shown the peer-link established
between mesh STA nodes. In normal conditions, when all links are up the Gateway node (N4) will
communicate with peripheral STA mesh nodes in two hops according to HWMP path selection
mechanism. The nodes are distributed in different positions and distances between them in order
- 93 -
to do not overlap coverage areas. The links highlighted in blue are peer-links established
between nodes.
Fig. 67.Mesh network topology for scenario-3.
Table 46 shows the data used in simulation where it is shown the different data flows between
GW and destination nodes. Table 47 shows MAC and PHY parameters of the mesh nodes. Figure
68 shows the traffic pattern generated from gateway node and the activation pattern of
intermediate nodes (N1,N3,N5,N7) according to each flow. This figure also shows the total
number of transmitting nodes trying to obtain channel access at the same time. Therefore, in
this scenario again the load traffic variation is not only due to traffic generated by gateway node,
but also due to activation or deactivation of intermediate nodes.
TABLE 46. DATA USED IN SIMULATION FOR CHAIN MESH TOPOLOGY AND DYNAMIC BUFFER SIZE.
SIMULATION DATA
Flows
Flow 1: N4 → N0
Flow 2: N4 → N2
Flow 3: N4 → N6
Flow 4: N4 → N8
Mean Packet Length
200B
Mean packet arrival
rate
1paq/6ms
Mean Tx bit rate 267kbps
Qinit 100
Simulation Time 5000s
- 94 -
Fig. 68.GW Traffic pattern and Activation/Deactivation pattern of intermediate nodes
TABLE 47. NS-3: MAC(IEEE 802.11S)/PHY PARAMETERS USED IN SIMULATION
Parameter Value
CTS Timeout 75us
AckTimeout 75us
BasicBlockAckTimeout 281us
CompressedBlockAckTimeout 107us
Sifs 16us
MaxPropagationDelay 333us
Slot 9us
Max No. of retransmission
attempts for RTS/Data packets
7
RTS/CTS Threshold 2346B
Fragmentation Threshold 2346B
Mesh 802.11s
BeaconGeneration true
BeaconInterval 0.5s
Peer Management Protocol
MaxNumberOfPeerLinks 32
Peer Link
MaxRetries 4
MaxBeaconLoss 5
MaxPacketFailure 5
HWMP Protocol
Max Queue Size 255
Reactive Path Timeout 5.12s
Max Path Request Retries 3
MaxTtl 32
DO flag 0
RF flag 1
PHY
Data/Control OFDM Rate 6Mbps
Propagation Loss Model
Log distance
Exponent: 3
ReferenceDistance: 1m
ReferenceLoss: 46.67dB
- 95 -
5.2.2.1 Reactive (On Demand) Mode
First it was simulated with on-demand HWMP mode with traffic classes: AC_VO and AC_BE,
two target loss probabilities values per node: 1E-3 and 1E-4. Tables from 48 to 51 shown below
are organized by flows. There are 4 flows, one from gateway node to each destination mesh STA
node. Packet Loss Ratio (PLR) and mean delay for each flow are shown. Both results are
obtained from statistics of udp server and client ns-3 applications. The UDP generated traffic
from gateway node is equally distributed to 4 destination mesh STA nodes, so the end-to-end
network delay is ¼ of the sum of the end-to-end delay per flow. Moreover, as in this scenario
there are more than one alternative path for each destination mesh STA node, it was doing the
simulation with default life time value for reactive routing information (5.12s) in the mesh module
implemented in ns-3.
BE=Best Effort.
TABLE 48. MEASURED L
P AND MEAN END-TO-END DELAY FOR AC_BE AND TARGET L
P =1E-3
Target
LP
1E-3
Flow Path
TX L
P
GW L
P N1 LP
N3
LP
N5
LP
N7
No.
Hops
PLR
(%)
Mean
Delay
(EET )
1 4-1-0
4.18E-4
0.0 --- --- --- 2 0.0805 T40=T1+T2
1.5ms
2 4-3-2 --- 0.0 --- --- 2 0.0651 T42=T3+T4
1.5ms
3 4-5-6 --- --- 5.83E-6 --- 2 0.0424 T46=T5+T6
1.4ms
4 4-7-8 --- --- --- 0.0 2 0.05195 T48=T7+T8
1.4ms
Network 0.0599 EET
1.45ms
Totaltx[packets]= 1333183
Totalrx[packets]= 1332384
x100ts]Totaltx[pk
ts]Totalrx[pk1PLR NET
(5.24)
The end-to-end delay ( EET ) is computed as follows:
- 96 -
4845424048454240EE TTTT4
1T
4
1T
4
1T
4
1T
4
1T (5.25)
Other form to compute EET is to obtain the mean transfer time per link and multiply by mean
number of hops (N):
NxTT
,TTT
EE
sw
(5.26)
As traffic generated per flow is equally distributed and propagation delay is approximately
equal between nodes, can be interesting compute the transfer of any link and multiply by mean
number of hops, which is 2 when all links are up.
So,
T= 0.3066+0.4708= 0.7775[ms], in node 3 or link 4.
EET 2xT=2x0.7775 = 1.55[ms]
As we expect, both computing values obtained from eq. (5.25) and (5.26) are not so much
different.
VO=Voice
TABLE 49 . MEASURED L
P AND MEAN END-TO-END DELAY FOR AC_VO AND TARGET L
P =1E-3
Target
LP
1E-3
Flow Path TX L
P
GW
LP
N1
LP
N3
LP
N5
LP
N7
No.
Hops PLR (%)
Mean Delay
(EET )
1 4-1-0
3.35E-4
0.0 --- --- --- 2 0.0664 T40=T1+T2
1.4ms
2 4-3-2 --- 2.94E-6 --- --- 2 0.0645 T42=T3+T4
1.4ms
3 4-5-6 --- --- 5.91E-6 --- 2 0.0455 T46=T5+T6
1.3ms
4 4-7-8 --- --- --- 0.0 2 0.0333 T48=T7+T8
1.3ms
Network 0.0524 EET
1.35ms
Totaltx[packets]= 1333183
Totalrx[packets]= 1332484
x100ts]Totaltx[pk
ts]Totalrx[pk1PLR NET
- 97 -
It is worth mentioning, for voice traffic the measured packet loss is taken into account that the
data and management PREP frames are in the same queue and compete for medium access.
BE=Best Effort
TABLE 50. MEASURED L
P AND MEAN END-TO-END DELAY FOR AC_BE AND TARGET L
P =1E-4
Target L
P
1E-4
Flow Path TX L
P
GW
LP
N1
LP
N3
LP
N5
LP
N7
No.
Hops
PLR
(%)
Mean Delay
(EET )
1 4-1-0
1.73E-4
0.0 --- --- --- 2 0.0423 T40=T1+T2
1.5ms
2 4-3-2 --- 0.0 --- --- 2 0.0507 T42=T3+T4
1.5ms
3 4-5-6 --- --- 0.0 --- 2 0.0335 T46=T5+T6
1.4ms
4 4-7-8 --- --- --- 0.0 2 0.0195 T48=T7+T8
1.4ms
Network 0.0365 EET
1.45ms
Totaltx[packets]= 1333183
Totalrx[packets]= 1332696
x100ts]Totaltx[pk
ts]Totalrx[pk1PLR NET
- 98 -
VO=Voice
TABLE 51. MEASURED L
P AND MEAN END-TO-END DELAY FOR AC_VO AND TARGET L
P =1E-4
Target
LP
1E-4
Flow Path TX L
P
GW
LP
N1
LP
N3
LP
N5
LP
N7
No.
Hops
PLR
(%)
Mean Delay
(EET )
1 4-1-0
1.29E-4
0.0 --- --- --- 2 0.0462 T40=T1+T2
1.4ms
2 4-3-2 --- 0.0 --- --- 2 0.0399 T42=T3+T4
1.4ms
3 4-5-6 --- --- 0.0 --- 2 0.0192 T46=T5+T6
1.3ms
4 4-7-8 --- --- --- 0.0 2 0.0198 T48=T7+T8
1.3ms
Network 0.0313 EET
1.35ms
Totaltx[packets]= 1333183
Totalrx[packets]= 1332766
x100ts]Totaltx[pk
ts]Totalrx[pk1PLR NET
Table 50 and 51 show that for target packet loss probability LP =1E-4 is not achieved in the
gateway node (for AC_BE and AC_VO) due to the network traffic load conditions and the medium
access contention. So, after comparing this scenario-3 with scenario-2, it can be noted that, the
more destination nodes, the more channel utilization as consequence of contention. For this case,
although the network topology in normal operation has only two hops to each destination node,
the packet loss is lower than what were achieved in scenario-2.
Tables 52 and 53 show the mean waiting (Tw), service (Ts) and transfer time (T) in gateway
and intermediate nodes for Dynamic Mechanism (with LP =1E-3 target packet loss probability)
and Static Queue Size (which gives the same target packet loss probability)
- 99 -
AC=BE TABLE 52. MEASURED MEAN TRANSFER TIME FOR AC_BE AND TARGET L
P =1E-3
Dynamic_Q Static
Q=5
Node Tw
[ms]
Ts
[ms]
T
[ms]
Tw
[ms]
Ts
[ms]
T
[ms]
GW(4) 0.3726 0.4843 0.8569 0.4078 0.4888 0.8965
1 0.3189 0.4807 0.7996 0.3296 0.4844 0.8139
3 0.3066 0.4708 0.7775 0.3360 0.4849 0.8209
5 0.3181 0.4786 0.7967 0.3248 0.4790 0.8038
7 0.2488 0.4716 0.7204 0.2482 0.4702 0.7185
AC=VO TABLE 53. MEASURED MEAN TRANSFER TIME FOR AC_VO AND TARGET
LP =1E-3
Dynamic
Static
Q=5
Node Tw
[ms]
Ts
[ms]
T
[ms]
Tw
[ms]
Ts
[ms]
T
[ms]
GW(4) 0.3308 0.5291 0.8599 0.3282 0.5288 0.8570
1 0.1908 0.5017 0.6926 0.1886 0.5023 0.6910
3 0.1921 0.4821 0.6742 0.1913 0.4825 0.6738
5 0.1943 0.4977 0.6920 0.1976 0.4988 0.6964
7 0.1476 0.4784 0.6260 0.1490 0.4790 0.6280
The results show that, as in the scenario-1 (infrastructure Wireless LAN), the different time
delays are approximately equal in both dynamic and static queue sizes for the same target packet
loss probability. The figures 69 and 70 show delay p.d.f. for Best Effort and Voice traffic with
both dynamic and static queue sizes. In the graphs was introduced the exponential distribution
of mean waiting, service and transfer time. Again, due to average number of collisions are zero
and the transmission packet time predominates, the results are approximately equal to M/M/1
queuing system.
- 100 -
Best Effort
(a)
(b)
(a) Fig. 69.Node GW Delay p.d.f. with Dynamic Queue Size for AC_BE traffic and target L
P =1E-3
(b) Fig. 69.Node GW Delay p.d.f. with Static Queue Size for AC_BE traffic and target L
P =1E-3
Voice
(a)
- 101 -
(b)
(a) Fig. 70.Node GW Delay p.d.f. with Dynamic Queue Size for AC_VO traffic and target L
P =1E-3
(b) Fig. 70.Node GW Delay p.d.f. with Static Queue Size for AC_VO traffic and target L
P =1E-3
The following figures show the channel utilization, queue size and number of packets in queue
for AC_BE and AC_VO access categories and different target packet loss probabilities.
Fig. 71.Average Channel utilization in scenario-3 for AC_BE and AC_VO and Target
LP =1E-3.
Fig. 72.Buffer Size in scenario-3 for different Target
LP and AC_BE
- 102 -
Fig. 73.Buffer Size utilization in scenario-3 for Target
LP =1E-3 and AC_BE
Fig. 74.Buffer Size utilization in scenario-3 for Target L
P =1E-3 and AC_BE (zoomed version)
Fig. 75.Buffer Size in scenario-3 for different Target
LP and AC_VO
- 103 -
Fig. 76.Buffer Size utilization in scenario-3 for Target
LP =1E-3 and AC_VO
Memory Utilization Efficiency
In the previous section was obtained the queue sizes that in static buffer size allocation cause
the same target packet loss probability. In general, the access category AC_VO demands in
average smaller buffer size than AC_BE due to the fact that the AC_VO has lower channel
access time than AC_BE, and therefore it also has lower service time. This reduces the
probability of queue congestion with arriving packets. Moreover, the memory utilization
efficiency was defined in section 5.1, which relates the areas occupied by dynamic buffer size
versus static buffer size. The memory utilization efficiency represents the percentage of memory
that the dynamic mechanism optimizes, and also it shows the wasted memory (difference between
queue allocated size and number of packets in queue), which has to be lower in dynamic buffer
sizing.
On the other hand, as it can be seen in the previous figures the average channel utilization in
the scenario-3 is moderated (lower than 45%), which causes the allocated queue size is not so
demanding (lower than 9 or 8 units in the case of highest network load and target packet loss
probability). This gives a lower margin of released memory by dynamic buffer size allocation to
evaluate the system, or what is the same the static and dynamic buffer size areas differ each time
less as lower network load. Furthermore, the difference between allocated queue size and
number of packets in queue is each time smaller.
Other factor that affects the memory utilization efficiency metric is the abrupt changes
occurred in ρ and Q size as it was explained in subsection 5.2.1.1. This effect decreases the
memory utilization efficiency ηsince there are short queue size areas not used by aN (Number
of packet units waiting in the buffer).
Tables 51 and 52 show the obtained results for memory utilization efficiency and the mean
- 104 -
difference between queue size and the number of packets in queue respectively, where can be
seen that efficiency improvement achieved is higher than 9% for AC_BE or AC_VO and the
achieved memory reduction for this scenario and simulations is lower than 12%.
TABLE 54. MEMORY EFFICIENCY COMPARISON FOR THE TWO AC CONFIGURED WITH STATIC VS. DYNAMIC BUFFER SIZE
AC Q for Static
[pkts] η_static_Q η_dynamic_Q % Improvement
BE
LP =1E-3
0.01655 0.01829 10.51% 5
LP =1E-4
0.01188 0.01364 14.81% 7
VO
LP =1E-3
0.01499 0.01699 13.34% 5
LP =1E-4
0.01193 0.01298 8.80% 6
TABLE 55. MEAN DIFFERENCE BETWEEN THE BUFFER SIZE AND THE BUFFER UTILIZATION
AC Q for Static
[pkts] D for Static D for Dynamic
Achieved
Reduction %
BE
LP =1E-3
4.4026 4.2226 4.09% 5
LP =1E-4
6.4013 5.9075 7.71% 7
VO
LP =1E-3
4.4122 3.8765 12.14% 5
LP =1E-4
5.4155 5.2806 2.49% 6
5.2.2.2 Proactive Mode
In this part proactive HWMP mode was evaluated in the same scenario-3 and traffic conditions.
For AC_BE two target packet loss probabilities has been solicited (1E-3 and 1E-4) per node and
they were achieved at difference of the reactive mode simulation (where LP =1E-4 was not
obtained in gateway node). It is important to remember, that in this mode the routes are
previously established before they are needed between a root node and each destination mesh
STA node. The root node, as it is recommended for the standard, is the gateway because all the
traffic coming and going from it. However, as default configuration of the network simulator ns-
3 the routes are refreshed every 5.12s in order to determine if there is a better route to each
destination.
- 105 -
Tables 56 and 57 show the obtained results per flow and node, where can be seen that
obtained packet loss is lower than target packet loss probability. However, the mean delay in
proactive mode per flow is slightly greater than in reactive mode.
BE=Best Effort
TABLE 56. MEASURED L
P AND MEAN END-TO-END DELAY FOR AC_BE AND TARGET L
P =1E-3
Target L
P
1E-3
Flow Path
TX L
P
GW
LP
N1
LP
N3
LP
N5
LP
N7
No.
Hops
PLR
(%)
Mean Delay
(TEE)
1 4-1-0
2.16E-4
1.12E-5 --- --- --- 2 0.0195 1.5ms
2 4-3-2 --- 1.45E-5 --- --- 2 0.0303 1.6ms
3 4-5-6 --- --- 0.0 --- 2 0.0248 1.5ms
4 4-7-8 --- --- --- 2.96E-6 2 0.0150 1.4ms
Network 0.0224 1.5ms
Totaltx[packets]= 1333184
Totalrx[packets]= 1332885
TABLE 57. MEASURED L
P AND MEAN END-TO-END DELAY FOR AC_BE AND TARGET L
P =1E-4
Target L
P
1E-4
Flow Path
TX L
P
GW
LP
N1
LP
N3
LP
N5
LP
N7
No.
Hops
PLR
(%)
Mean Delay
(Tee)
1 4-1-0
2.33E-5
0.0 2 0.0021 1.5ms
2 4-3-2 8.73E-6 2 0.0057 1.6ms
3 4-5-6 0.0 2 0.0024 1.5ms
4 4-7-8 5.86E-6 2 0.0015 1.4ms
Network 0.0029 1.5ms
Totaltx[packets]= 1333183
Totalrx[packets]= 1333144
Table 58 show the obtained results for different time delays in gateway and intermediate nodes
of scenario-3 for LP =1E-3 target packet loss probability in static and dynamic buffer size
allocation. Again, different delays are approximately equal in both cases. Furthermore, p.d.f of
different delays (in gateway node) is shown in figure 77 as well as different parameters of dynamic
mechanism are shown in figures from 78 to 80.
- 106 -
AC=BE TABLE 58. MEASURED MEAN TRANSFER TIME FOR AC_BE AND
TARGET L
P =1E-3
Dynamic_Q Static
Q=5
Node Tw
[ms]
Ts
[ms]
TT
[ms]
Tw
[ms]
Ts
[ms]
T
[ms]
GW(4) 0.4129 0.4892 0.9021 0.3946 0.4871 0.8817
1 0.3664 0.4964 0.8627 0.3763 0.5005 0.8769
3 0.3337 0.4829 0.8165 0.3273 0.4761 0.8034
5 0.3429 0.4804 0.8233 0.3367 0.4805 0.8173
7 0.2622 0.4784 0.7406 0.2668 0.4820 0.7488
(a)
(b)
(a) Fig. 77.Node GW Delay p.d.f. with Dynamic Queue Size for AC_BE traffic and target L
P =1E-3
(b) Fig. 77.Node GW Delay p.d.f. with Static Queue Size for AC_BE traffic and target L
P =1E-3
- 107 -
Fig. 78.Average Channel utilization in scenario-3 for AC_BE and Target L
P =1E-3.
Fig. 79.Buffer Size in scenario-3 for different Target L
P and AC_BE
Fig. 80.Buffer Size utilization in scenario-3 for Target
LP =1E-3 and AC_BE
- 108 -
5.3 Implementation Issues
ARP packets: In some mesh networks scenarios can occur that different arp request arrives to
intermediate node at the same time due to symmetric distances. Ns-3 simulator does not
prevent this situation when occur collisions between arp request frames. Remember that arp
request are broadcast frames without ACK. In this case, to avoid this problem the bugs reported
to Ns-3 errors support (https://www.nsnam.org/bugzilla/) purposes two solutions: 1) modify the
backoff procedure for this situation or 2) add processing delays in order to do not cause losses in
arp request frames. The patch for bug 1363 provides the solution to modify the backoff
procedure and it resolves sometimes the problem. However, in the scenerio3, the problem still
continues where there is not full-connectivity between some nodes, so it was decide to create
static arp tables and avoid also problems of “internal collisions” between AC_VO (Voice traffic)
and AC_BE (for ARP frames) transmissions.
Peer links closed: Initially some losses problems occurred with default configuration values of
peer-link for Peer Management Protocol caused by closed peer links. IEEE 802.11s standard
does not define the way of closing peer link, ns-3 implemented two ways of doing this. The first
one is to close link due to beacon loss. Every beacon contains beacon interval, and beacons are
sent strictly periodically by each station. So, at every moment for every link we exactly know,
how many beacons were lost since last successfully received one. If beacon loss counter has
exceeded a configurable threshold value MaxBeaconLoss link shall be closed. Default value for
MaxBeaconLoss is 2. Note, that at least 1.0 s is needed to detect link failure this way using
default beacon interval of 0.5 s. The second heuristic for link failure detection applies when link
is used for data transmission. If the number of successive frames were failed to transmit to a
given neighbor (transmission failure is an event, when MAC refuses to transmit frame due to
retry threshold), exceeds a threshold value MaxPacket- Failure, link shall be closed. It is worth
to mention, that a single transmission failure may occur because station has many neighbors and
frame was failed to transmit due to collisions. The default value for MaxPacket-Failure parameter
is also 2 [15]. For our simulations it was modified this default values in order to avoid flapping
links and routes. The chosen threshold values for both cases were 5 as in simulations carried out
in [15]. In any case, there should be a trade-off between fast failure detection and link stability.
Many variables to manage: Initially to simulate WMN in ns-3 we found some different variables
to be managed in order to obtain stability and be able to cause changes in channel utilization and
- 109 -
see the behavior of the dynamic mechanism. The first problem encountered was the lack of full-
connectivity, closed-links or instability, have to decide work in reactive or proactive HWMP
mode, contention of Managed PREP frames with traffic of access category AC_VO, use RTS/CTS
mode or not; and on the other hand select appropriate input parameters of dynamic mechanism:
thresholds and exponentially weighted moving average (EWMA). So, the solutions were test a lot
of simulations changing parameter by parameter and observe the effect in the dynamic
mechanism parameters, especially in the average channel utilization.
To select the properly parameters, it is recommended be carefully in the network planning of
wireless mesh nodes. It should start with conservatives traffic polices to estimate the traffic load
that the network could support in stable conditions (without congestion or saturation). An initial
test is to review that the established peer links are consistent and stables when there is no
traffic in the network. After that, it could modify the own and configurable IEEE 802.11s
parameters as well as dynamic mechanism parameters. Finally, it should observe that ρ, N, Q
follow the function of the offered load. This procedure could be repeated several times until
obtain the desired results.
Processing Time in Python Script: In order to obtain different delays per packets it was
developed a python script. Initially, we use different loops to track each packet from it is
enqueued until it is received the ACK. This cause the output simulation file must start to be
read a lot times as number of packet are generated. We have to tag the position of the last
tracked packet. If only loops and temporal variables are used cause considerable processing time
in python script. So, the solution adopted was use the python functions: tell() and seek() to save
the current position (in Bytes) of the last served packet and to recover the desired position
inside the output simulation file.
- 110 -
6. Conclusions and Future Works
The application of maximum entropy mechanism in the dynamic buffer size allocation is a valid
solution for memory optimization, which uses two measurable network parameters, such as:
server utilization and the mean number of packets in the transmission system (both seen by an
arriving packet).
It has been demonstrated that, the dynamic buffer size allocation mechanism can be applied in
networks with shared channels, such as: WLAN and WMN guaranteeing always in stable network
conditions a target packet loss probability. Furthermore, through properly settings of the
algorithm parameters, the processor overloading can be reduced.
The WLAN devices as well as WMN are able to self-configure their buffer sizes through
dynamic mechanism implementation. They capture the network load fluctuation, which is caused
not only for the traffic variation of the nodes, but also for activation/deactivation of other
devices that share the transmission medium.
For WMN the dynamic mechanism can be applied to different class of services, each one with
different target packet loss probabilities. Also, in the WMN it has to be considered more
operation parameters in the implementation of the dynamic mechanism; however, a properly
network planning allows the successful auto-buffer sizing keeping bounded the packet loss ratio.
It was observed that, the dynamic mechanism implementation in some particular cases can
cause abrupt changes in the buffer size allocation, which affects the measured packet losses and
the memory utilization efficiency. For this reason, it is convenient to study in detail the
behavior of the algorithm functions as well as its operation parameters.
The advantage of dynamic buffer size allocation versus static allocation is the memory
optimization, which is beneficial in network devices with multiple interfaces as well as in resource
constraint devices like wireless sensor nodes. Furthermore, the better memory utilization could
also facilitate the design and use of all-optical routers where small buffers are much appreciated.
Further work is the study and analysis of the behavior of the dynamic mechanism functions and
review which fixed operation parameters can be adapting to the network traffic load evolution.
The implementation and evaluation of the dynamic mechanism in WMN in other simulators using
different channel access mechanisms can be valuable. Moreover, the evaluation of the algorithm
for TCP and a mix of TCP and UDP flows are also considered as well as the evaluation in sensor
nodes. Furthermore, guarantee another parameter like transfer time (T) based in different
priorities and scheduler together with a target packet loss probability can be also valuable. The
first simulations carried out in [12] show that it is possible to work with both separately, which is
very useful to facilitate the auto configuration of network devices.
- 111 -
- 112 -
Appendix A
NS-3 Scripts
A.1 Scenario-1
/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */
/*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation;
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include "ns3/core-module.h"
#include "ns3/point-to-point-module.h"
#include "ns3/network-module.h"
#include "ns3/applications-module.h"
#include "ns3/wifi-module.h"
#include "ns3/mobility-module.h"
#include "ns3/csma-module.h"
#include "ns3/internet-module.h"
using namespace ns3;
NS_LOG_COMPONENT_DEFINE ("scenario-3");
//begin added callback traces
void
PhyTxBeginCallback (std::string context, Ptr<const Packet> packet)
{
std::ostringstream oss;
packet->Print (oss);
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << packet->GetUid() <<
"\t"<< packet->GetSize() << "\t" << oss.str() << endl;
}
void
MacTxCallback (std::string context, Ptr<const Packet> packet)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << packet->GetUid() <<
"\t" << packet->GetSize() << endl;
}
void
PhyRxEndCallback (std::string context, Ptr<const Packet> packet)
{
std::ostringstream oss;
packet->Print (oss);
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << packet->GetUid() <<
"\t" << packet->GetSize() << "\t" << oss.str() << endl;
}
void
RxOkCallback (std::string context, Ptr<const Packet> packet, double snr, WifiMode mode, enum
WifiPreamble prem)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << packet->GetUid() <<
endl;
}
void
TxOkHeaderCallback (std::string context, const WifiMacHeader &_wmh)
{
- 113 -
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _wmh << endl;
}
void
TxErrHeaderCallback (std::string context,const WifiMacHeader &_wmh)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _wmh << endl;
}
void
AssocCallback (std::string context, Mac48Address _ad)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _ad << endl;
}
void
EnqueueCallback (std::string context,Ptr<const Packet> _p,uint32_t _size,uint32_t _maxSize)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _p->GetUid() << "\t"
<< _p->GetSize() << "\t" << _size << "\t" << _maxSize << "\n";
}
void
DequeueCallback (std::string context,Ptr<const Packet> _p,uint32_t _size,uint32_t _maxSize)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _p->GetUid() << "\t"
<< _p->GetSize() << "\t" << _size << "\t" << _maxSize << "\n";
}
void
DropCallback (std::string context, Ptr<const Packet> _p,uint32_t _size,uint32_t _maxSize)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _p->GetUid() << "\t"
<< _p->GetSize() << "\t" << _size << "\t" << _maxSize << "\n";
}
void
GenerateCallback (std::string context, double _d, uint32_t _ui)
{
std::cout << _d << "\t" << _ui << endl;
}
void
QueueSizeUpdated_1Callback (std::string context, uint32_t _r,uint32_t _n,double _ar,double
_an,double _y,double _b,double _newN,uint32_t _newQ)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _r << "\t" << _n <<
"\t" << _ar << "\t" << _an << "\t" << _y << "\t" << _b << "\t" << _newN << "\t" << _newQ << endl;
}
void
QueueSizeUpdated_2Callback (std::string context, double _y,double _b,double _newN, uint32_t _newQ,
uint32_t _GS, uint32_t _neededQ)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _y << "\t" << _b <<
"\t" << _newN << "\t" << _newQ << "\t" << _GS << "\t" << _neededQ << endl;
}
void
QueueSizeUpdated_3Callback (std::string context, uint32_t _prevQ,uint32_t _neededQ,int32_t
_dif,uint32_t _prevAvailable, uint32_t _newQ,uint32_t _available)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _prevQ << "\t" <<
_neededQ << "\t" << _dif << "\t" << _prevAvailable << "\t" << _newQ << "\t" << _available << endl;
}
//end
int
main (int argc, char *argv[])
{
uint32_t nWifi_1 = 5;
uint32_t nWifi_2 = 5;
double a=100.0;
bool managed=false;
double pl=0.00001;
- 114 -
double w=0.001;
double tu=0.01;
double td=0.1;
int qInit=22;
int runNumber=1;
CommandLine cmd;
cmd.AddValue ("managed", "Is buffer size managed?", managed);
cmd.AddValue ("pl", "Loss probability", pl);
cmd.AddValue ("w", "Moving average weight", w);
cmd.AddValue ("tu", "Up threshold", tu);
cmd.AddValue ("td", "Down threshold", td);
cmd.AddValue ("qInit", "Initial value for queue size", qInit);
cmd.AddValue ("runNumber", "Run Number", runNumber);
cmd.Parse (argc,argv);
SeedManager::SetRun(runNumber);
Packet::EnablePrinting ();
NodeContainer p2pNodes_1;
NodeContainer p2pNodes_2;
p2pNodes_1.Create(2);
p2pNodes_2.Create(2);
PointToPointHelper pointToPoint_1;
pointToPoint_1.SetDeviceAttribute ("DataRate", StringValue ("500Mbps"));
pointToPoint_1.SetChannelAttribute ("Delay", StringValue ("0ms"));
NetDeviceContainer p2pDevices_1;
p2pDevices_1 = pointToPoint_1.Install (p2pNodes_1);
PointToPointHelper pointToPoint_2;
pointToPoint_2.SetDeviceAttribute ("DataRate", StringValue ("500Mbps"));
pointToPoint_2.SetChannelAttribute ("Delay", StringValue ("0ms"));
NetDeviceContainer p2pDevices_2;
p2pDevices_2 = pointToPoint_2.Install (p2pNodes_2);
NodeContainer wifiApNodes;
wifiApNodes.Add(p2pNodes_1.Get (0));
wifiApNodes.Add(p2pNodes_2.Get (0));
NodeContainer wifiStaNodes_1;
wifiStaNodes_1.Create (nWifi_1+1);
NodeContainer wifiStaNodes_2;
wifiStaNodes_2.Add(wifiStaNodes_1.Get (0));
wifiStaNodes_2.Create (nWifi_2);
uint32_t i=0;
NodeContainer wifiStaNodes;
for (i=0;i<=nWifi_1; i++) {
wifiStaNodes.Add(wifiStaNodes_1.Get (i));
}
for (i=1;i<=nWifi_2; i++) {
wifiStaNodes.Add(wifiStaNodes_2.Get (i));
}
YansWifiChannelHelper channel_1 = YansWifiChannelHelper::Default ();
YansWifiPhyHelper phy_1 = YansWifiPhyHelper::Default ();
phy_1.SetChannel (channel_1.Create ());
WifiHelper wifi_1 = WifiHelper::Default ();
wifi_1.SetRemoteStationManager ("ns3::ConstantRateWifiManager");
NqosWifiMacHelper mac_1 = NqosWifiMacHelper::Default ();
Ssid ssid_1 = Ssid ("ns-3-ssid-1");
mac_1.SetType ("ns3::StaWifiMac",
"Ssid", SsidValue (ssid_1),
"ActiveProbing", BooleanValue (false));
NetDeviceContainer staDevices_1;
staDevices_1 = wifi_1.Install (phy_1, mac_1, wifiStaNodes_1);
mac_1.SetType ("ns3::ApWifiMac",
"Ssid", SsidValue (ssid_1),
- 115 -
"BeaconGeneration", BooleanValue (true),
"BeaconInterval", TimeValue (Seconds (10)));
NetDeviceContainer apDevices_1;
apDevices_1 = wifi_1.Install (phy_1, mac_1, wifiApNodes.Get(0));
YansWifiChannelHelper channel_2 = YansWifiChannelHelper::Default ();
YansWifiPhyHelper phy_2 = YansWifiPhyHelper::Default ();
phy_2.SetChannel (channel_2.Create ());
WifiHelper wifi_2 = WifiHelper::Default ();
wifi_2.SetRemoteStationManager ("ns3::ConstantRateWifiManager");
NqosWifiMacHelper mac_2 = NqosWifiMacHelper::Default ();
Ssid ssid_2 = Ssid ("ns-3-ssid-2");
mac_2.SetType ("ns3::StaWifiMac",
"Ssid", SsidValue (ssid_2),
"ActiveProbing", BooleanValue (false));
NetDeviceContainer staDevices_2;
staDevices_2 = wifi_2.Install (phy_2, mac_2, wifiStaNodes_2);
mac_2.SetType ("ns3::ApWifiMac",
"Ssid", SsidValue (ssid_2),
"BeaconGeneration", BooleanValue (true),
"BeaconInterval", TimeValue (Seconds (10)));
NetDeviceContainer apDevices_2;
apDevices_2 = wifi_2.Install (phy_2, mac_2, wifiApNodes.Get(1));
MobilityHelper mobility;
mobility.SetPositionAllocator ("ns3::GridPositionAllocator",
"MinX", DoubleValue (0.0),
"MinY", DoubleValue (0.0),
"DeltaX", DoubleValue (5.0),
"DeltaY", DoubleValue (10.0),
"GridWidth", UintegerValue (3),
"LayoutType", StringValue ("RowFirst"));
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (wifiStaNodes);
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (wifiApNodes);
InternetStackHelper stack;
stack.Install (wifiApNodes);
stack.Install (wifiStaNodes);
NodeContainer sinkNodes; //Auxiliar solo para instalar la pila IP
sinkNodes.Add(p2pNodes_1.Get (1));
sinkNodes.Add(p2pNodes_2.Get (1));
stack.Install (sinkNodes);
Ipv4AddressHelper address;
address.SetBase ("192.168.1.0", "255.255.255.0");
address.Assign (apDevices_1);
address.Assign (staDevices_1);
address.SetBase ("192.168.2.0", "255.255.255.0");
address.Assign (apDevices_2);
address.Assign (staDevices_2);
address.SetBase ("192.168.10.0", "255.255.255.0");
Ipv4InterfaceContainer p2pInterfaces_1;
p2pInterfaces_1 = address.Assign (p2pDevices_1);
address.SetBase ("192.168.20.0", "255.255.255.0");
Ipv4InterfaceContainer p2pInterfaces_2;
p2pInterfaces_2 = address.Assign (p2pDevices_2);
/////////////////////////////////////////////////////////////////////////////////
// ENCAMINAMIENTO ESTATICO
//Rutas por defecto en wifiStaNodes_1
for (i=1;i<=nWifi_1;i++) {
Ptr<Node> node=wifiStaNodes_1.Get(i);
- 116 -
Ptr<Ipv4L3Protocol> ipv4 = node->GetObject<Ipv4L3Protocol>();
Ptr<Ipv4RoutingProtocol> ipRP = ipv4->GetRoutingProtocol();
Ptr<Ipv4ListRouting> ipLR = DynamicCast<Ipv4ListRouting> (ipRP);
int16_t priority;
Ptr<Ipv4RoutingProtocol> ipRP2 = ipLR->GetRoutingProtocol(0,priority);
Ptr<Ipv4StaticRouting> ipSR = DynamicCast<Ipv4StaticRouting> (ipRP2);
ipSR->SetDefaultRoute (Ipv4Address("192.168.1.1"), 1);
}
//Rutas por defecto en wifiStaNodes_2
for (i=1;i<=nWifi_2;i++) {
Ptr<Node> node=wifiStaNodes_2.Get(i);
Ptr<Ipv4L3Protocol> ipv4 = node->GetObject<Ipv4L3Protocol>();
Ptr<Ipv4RoutingProtocol> ipRP = ipv4->GetRoutingProtocol();
Ptr<Ipv4ListRouting> ipLR = DynamicCast<Ipv4ListRouting> (ipRP);
int16_t priority;
Ptr<Ipv4RoutingProtocol> ipRP2 = ipLR->GetRoutingProtocol(0,priority);
Ptr<Ipv4StaticRouting> ipSR = DynamicCast<Ipv4StaticRouting> (ipRP2);
ipSR->SetDefaultRoute (Ipv4Address("192.168.2.1"), 1);
}
//Rutas en estación inalámbrica con acceso a las dos WLANs (no tiene ruta por defecto)
Ptr<Node> n4=wifiStaNodes.Get(0);
Ptr<Ipv4L3Protocol> ipv4_4 = n4->GetObject<Ipv4L3Protocol>();
Ptr<Ipv4RoutingProtocol> ipRP_4 = ipv4_4->GetRoutingProtocol();
Ptr<Ipv4ListRouting> ipLR_4 = DynamicCast<Ipv4ListRouting> (ipRP_4);
int16_t priority;
Ptr<Ipv4RoutingProtocol> ipRP2_4 = ipLR_4->GetRoutingProtocol(0,priority);
Ptr<Ipv4StaticRouting> ipSR_4 = DynamicCast<Ipv4StaticRouting> (ipRP2_4);
ipSR_4->AddNetworkRouteTo (Ipv4Address ("192.168.10.0"),
Ipv4Mask("255.255.255.0"),Ipv4Address("192.168.1.1"),1);
ipSR_4->AddNetworkRouteTo (Ipv4Address ("192.168.20.0"),
Ipv4Mask("255.255.255.0"),Ipv4Address("192.168.2.1"),2);
//Rutas por defecto en los sinks
Ptr<Node> n1=sinkNodes.Get(0);
Ptr<Node> n3=sinkNodes.Get(1);
Ptr<Ipv4L3Protocol> ipv4_1 = n1->GetObject<Ipv4L3Protocol>();
Ptr<Ipv4L3Protocol> ipv4_3 = n3->GetObject<Ipv4L3Protocol>();
Ptr<Ipv4RoutingProtocol> ipRP_1 = ipv4_1->GetRoutingProtocol();
Ptr<Ipv4RoutingProtocol> ipRP_3 = ipv4_3->GetRoutingProtocol();
Ptr<Ipv4ListRouting> ipLR_1 = DynamicCast<Ipv4ListRouting> (ipRP_1);
Ptr<Ipv4ListRouting> ipLR_3 = DynamicCast<Ipv4ListRouting> (ipRP_3);
Ptr<Ipv4RoutingProtocol> ipRP2_1 = ipLR_1->GetRoutingProtocol(0,priority);
Ptr<Ipv4RoutingProtocol> ipRP2_3 = ipLR_3->GetRoutingProtocol(0,priority);
Ptr<Ipv4StaticRouting> ipSR_1 = DynamicCast<Ipv4StaticRouting> (ipRP2_1);
Ptr<Ipv4StaticRouting> ipSR_3 = DynamicCast<Ipv4StaticRouting> (ipRP2_3);
ipSR_1->SetDefaultRoute (Ipv4Address("192.168.10.1"), 1);
ipSR_3->SetDefaultRoute (Ipv4Address("192.168.20.1"), 1);
/////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
// UDP SIN ECHO APPLICATION
//Estaciones en WLAN1
UdpClientHelper udpClient_1 (p2pInterfaces_1.GetAddress(1), 9);
udpClient_1.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_1.SetAttribute ("Interval", TimeValue (Seconds (0.0025)));
udpClient_1.SetAttribute ("PacketSize", UintegerValue (200));
ApplicationContainer udpClientApps_1_1_1 =
udpClient_1.Install (wifiStaNodes_1.Get(1));
udpClientApps_1_1_1.Start (Seconds (0.0*a));
udpClientApps_1_1_1.Stop (Seconds (1.0*a));
ApplicationContainer udpClientApps_1_1_2 =
udpClient_1.Install (wifiStaNodes_1.Get(1));
udpClientApps_1_1_2.Start (Seconds (3.0*a));
udpClientApps_1_1_2.Stop (Seconds (4.0*a));
ApplicationContainer udpClientApps_1_1_3 =
udpClient_1.Install (wifiStaNodes_1.Get(1));
udpClientApps_1_1_3.Start (Seconds (6.0*a));
udpClientApps_1_1_3.Stop (Seconds (7.0*a));
ApplicationContainer udpClientApps_1_1_4 =
udpClient_1.Install (wifiStaNodes_1.Get(1));
udpClientApps_1_1_4.Start (Seconds (12.0*a));
udpClientApps_1_1_4.Stop (Seconds (15.0*a));
ApplicationContainer udpClientApps_1_1_5 =
udpClient_1.Install (wifiStaNodes_1.Get(1));
- 117 -
udpClientApps_1_1_5.Start (Seconds (26.0*a));
udpClientApps_1_1_5.Stop (Seconds (28.0*a));
ApplicationContainer udpClientApps_1_1_6 =
udpClient_1.Install (wifiStaNodes_1.Get(1));
udpClientApps_1_1_6.Start (Seconds (30.0*a));
udpClientApps_1_1_6.Stop (Seconds (32.0*a));
ApplicationContainer udpClientApps_1_1_7 =
udpClient_1.Install (wifiStaNodes_1.Get(1));
udpClientApps_1_1_7.Start (Seconds (33.0*a));
udpClientApps_1_1_7.Stop (Seconds (37.0*a));
ApplicationContainer udpClientApps_1_1_8 =
udpClient_1.Install (wifiStaNodes_1.Get(1));
udpClientApps_1_1_8.Start (Seconds (45.0*a));
udpClientApps_1_1_8.Stop (Seconds (48.0*a));
ApplicationContainer udpClientApps_1_2_1 =
udpClient_1.Install (wifiStaNodes_1.Get(2));
udpClientApps_1_2_1.Start (Seconds (1.0*a));
udpClientApps_1_2_1.Stop (Seconds (2.0*a));
ApplicationContainer udpClientApps_1_2_2 =
udpClient_1.Install (wifiStaNodes_1.Get(2));
udpClientApps_1_2_2.Start (Seconds (3.0*a));
udpClientApps_1_2_2.Stop (Seconds (6.0*a));
ApplicationContainer udpClientApps_1_2_3 =
udpClient_1.Install (wifiStaNodes_1.Get(2));
udpClientApps_1_2_3.Start (Seconds (7.0*a));
udpClientApps_1_2_3.Stop (Seconds (9.0*a));
ApplicationContainer udpClientApps_1_2_4 =
udpClient_1.Install (wifiStaNodes_1.Get(2));
udpClientApps_1_2_4.Start (Seconds (12.0*a));
udpClientApps_1_2_4.Stop (Seconds (17.0*a));
ApplicationContainer udpClientApps_1_2_5 =
udpClient_1.Install (wifiStaNodes_1.Get(2));
udpClientApps_1_2_5.Start (Seconds (28.0*a));
udpClientApps_1_2_5.Stop (Seconds (30.0*a));
ApplicationContainer udpClientApps_1_2_6 =
udpClient_1.Install (wifiStaNodes_1.Get(2));
udpClientApps_1_2_6.Start (Seconds (31.0*a));
udpClientApps_1_2_6.Stop (Seconds (33.0*a));
ApplicationContainer udpClientApps_1_2_7 =
udpClient_1.Install (wifiStaNodes_1.Get(2));
udpClientApps_1_2_7.Start (Seconds (40.0*a));
udpClientApps_1_2_7.Stop (Seconds (45.0*a));
ApplicationContainer udpClientApps_1_3_1 =
udpClient_1.Install (wifiStaNodes_1.Get(3));
udpClientApps_1_3_1.Start (Seconds (2.0*a));
udpClientApps_1_3_1.Stop (Seconds (3.0*a));
ApplicationContainer udpClientApps_1_3_2 =
udpClient_1.Install (wifiStaNodes_1.Get(3));
udpClientApps_1_3_2.Start (Seconds (4.0*a));
udpClientApps_1_3_2.Stop (Seconds (11.0*a));
ApplicationContainer udpClientApps_1_3_3 =
udpClient_1.Install (wifiStaNodes_1.Get(3));
udpClientApps_1_3_3.Start (Seconds (14.0*a));
udpClientApps_1_3_3.Stop (Seconds (21.0*a));
ApplicationContainer udpClientApps_1_3_4 =
udpClient_1.Install (wifiStaNodes_1.Get(3));
udpClientApps_1_3_4.Start (Seconds (30.0*a));
udpClientApps_1_3_4.Stop (Seconds (35.0*a));
ApplicationContainer udpClientApps_1_3_5 =
udpClient_1.Install (wifiStaNodes_1.Get(3));
udpClientApps_1_3_5.Start (Seconds (42.0*a));
- 118 -
udpClientApps_1_3_5.Stop (Seconds (47.0*a));
ApplicationContainer udpClientApps_1_4_1 =
udpClient_1.Install (wifiStaNodes_1.Get(4));
udpClientApps_1_4_1.Start (Seconds (2.0*a));
udpClientApps_1_4_1.Stop (Seconds (3.0*a));
ApplicationContainer udpClientApps_1_4_2 =
udpClient_1.Install (wifiStaNodes_1.Get(4));
udpClientApps_1_4_2.Start (Seconds (8.0*a));
udpClientApps_1_4_2.Stop (Seconds (12.0*a));
ApplicationContainer udpClientApps_1_4_3 =
udpClient_1.Install (wifiStaNodes_1.Get(4));
udpClientApps_1_4_3.Start (Seconds (17.0*a));
udpClientApps_1_4_3.Stop (Seconds (19.0*a));
ApplicationContainer udpClientApps_1_4_4 =
udpClient_1.Install (wifiStaNodes_1.Get(4));
udpClientApps_1_4_4.Start (Seconds (30.0*a));
udpClientApps_1_4_4.Stop (Seconds (31.0*a));
ApplicationContainer udpClientApps_1_4_5 =
udpClient_1.Install (wifiStaNodes_1.Get(4));
udpClientApps_1_4_5.Start (Seconds (37.0*a));
udpClientApps_1_4_5.Stop (Seconds (40.0*a));
ApplicationContainer udpClientApps_1_4_6 =
udpClient_1.Install (wifiStaNodes_1.Get(4));
udpClientApps_1_4_6.Start (Seconds (44.0*a));
udpClientApps_1_4_6.Stop (Seconds (46.0*a));
ApplicationContainer udpClientApps_1_5_1 =
udpClient_1.Install (wifiStaNodes_1.Get(5));
udpClientApps_1_5_1.Start (Seconds (1.0*a));
udpClientApps_1_5_1.Stop (Seconds (3.0*a));
ApplicationContainer udpClientApps_1_5_2 =
udpClient_1.Install (wifiStaNodes_1.Get(5));
udpClientApps_1_5_2.Start (Seconds (4.0*a));
udpClientApps_1_5_2.Stop (Seconds (8.0*a));
ApplicationContainer udpClientApps_1_5_3 =
udpClient_1.Install (wifiStaNodes_1.Get(5));
udpClientApps_1_5_3.Start (Seconds (12.0*a));
udpClientApps_1_5_3.Stop (Seconds (14.0*a));
ApplicationContainer udpClientApps_1_5_4 =
udpClient_1.Install (wifiStaNodes_1.Get(5));
udpClientApps_1_5_4.Start (Seconds (25.0*a));
udpClientApps_1_5_4.Stop (Seconds (30.0*a));
ApplicationContainer udpClientApps_1_5_5 =
udpClient_1.Install (wifiStaNodes_1.Get(5));
udpClientApps_1_5_5.Start (Seconds (32.0*a));
udpClientApps_1_5_5.Stop (Seconds (33.0*a));
ApplicationContainer udpClientApps_1_5_6 =
udpClient_1.Install (wifiStaNodes_1.Get(5));
udpClientApps_1_5_6.Start (Seconds (39.0*a));
udpClientApps_1_5_6.Stop (Seconds (44.0*a));
//Estaciones en WLAN2
UdpClientHelper udpClient_2 (p2pInterfaces_2.GetAddress(1), 9);
udpClient_2.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_2.SetAttribute ("Interval", TimeValue (Seconds (0.0025)));
udpClient_2.SetAttribute ("PacketSize", UintegerValue (200));
ApplicationContainer udpClientApps_2_1_1 =
udpClient_2.Install (wifiStaNodes_2.Get(1));
udpClientApps_2_1_1.Start (Seconds (1.0*a));
udpClientApps_2_1_1.Stop (Seconds (2.0*a));
ApplicationContainer udpClientApps_2_1_2 =
- 119 -
udpClient_2.Install (wifiStaNodes_2.Get(1));
udpClientApps_2_1_2.Start (Seconds (9.0*a));
udpClientApps_2_1_2.Stop (Seconds (11.0*a));
ApplicationContainer udpClientApps_2_1_3 =
udpClient_2.Install (wifiStaNodes_2.Get(1));
udpClientApps_2_1_3.Start (Seconds (17.0*a));
udpClientApps_2_1_3.Stop (Seconds (23.0*a));
ApplicationContainer udpClientApps_2_1_4 =
udpClient_2.Install (wifiStaNodes_2.Get(1));
udpClientApps_2_1_4.Start (Seconds (31.0*a));
udpClientApps_2_1_4.Stop (Seconds (32.0*a));
ApplicationContainer udpClientApps_2_1_5 =
udpClient_2.Install (wifiStaNodes_2.Get(1));
udpClientApps_2_1_5.Start (Seconds (45.0*a));
udpClientApps_2_1_5.Stop (Seconds (50.0*a));
ApplicationContainer udpClientApps_2_2_2 =
udpClient_2.Install (wifiStaNodes_2.Get(2));
udpClientApps_2_2_2.Start (Seconds (2.0*a));
udpClientApps_2_2_2.Stop (Seconds (3.0*a));
ApplicationContainer udpClientApps_2_2_3 =
udpClient_2.Install (wifiStaNodes_2.Get(2));
udpClientApps_2_2_3.Start (Seconds (11.0*a));
udpClientApps_2_2_3.Stop (Seconds (13.0*a));
ApplicationContainer udpClientApps_2_2_4 =
udpClient_2.Install (wifiStaNodes_2.Get(2));
udpClientApps_2_2_4.Start (Seconds (16.0*a));
udpClientApps_2_2_4.Stop (Seconds (17.0*a));
ApplicationContainer udpClientApps_2_2_5 =
udpClient_2.Install (wifiStaNodes_2.Get(2));
udpClientApps_2_2_5.Start (Seconds (18.0*a));
udpClientApps_2_2_5.Stop (Seconds (25.0*a));
ApplicationContainer udpClientApps_2_2_6 =
udpClient_2.Install (wifiStaNodes_2.Get(2));
udpClientApps_2_2_6.Start (Seconds (33.0*a));
udpClientApps_2_2_6.Stop (Seconds (34.0*a));
ApplicationContainer udpClientApps_2_2_7 =
udpClient_2.Install (wifiStaNodes_2.Get(2));
udpClientApps_2_2_7.Start (Seconds (47.0*a));
udpClientApps_2_2_7.Stop (Seconds (48.0*a));
ApplicationContainer udpClientApps_2_3_1 =
udpClient_2.Install (wifiStaNodes_2.Get(3));
udpClientApps_2_3_1.Start (Seconds (0.0*a));
udpClientApps_2_3_1.Stop (Seconds (4.0*a));
ApplicationContainer udpClientApps_2_3_2 =
udpClient_2.Install (wifiStaNodes_2.Get(3));
udpClientApps_2_3_2.Start (Seconds (13.0*a));
udpClientApps_2_3_2.Stop (Seconds (15.0*a));
ApplicationContainer udpClientApps_2_3_3 =
udpClient_2.Install (wifiStaNodes_2.Get(3));
udpClientApps_2_3_3.Start (Seconds (16.0*a));
udpClientApps_2_3_3.Stop (Seconds (20.0*a));
ApplicationContainer udpClientApps_2_3_4 =
udpClient_2.Install (wifiStaNodes_2.Get(3));
udpClientApps_2_3_4.Start (Seconds (27.0*a));
udpClientApps_2_3_4.Stop (Seconds (30.0*a));
ApplicationContainer udpClientApps_2_3_5 =
udpClient_2.Install (wifiStaNodes_2.Get(3));
udpClientApps_2_3_5.Start (Seconds (32.0*a));
udpClientApps_2_3_5.Stop (Seconds (38.0*a));
ApplicationContainer udpClientApps_2_3_6 =
udpClient_2.Install (wifiStaNodes_2.Get(3));
udpClientApps_2_3_6.Start (Seconds (48.0*a));
udpClientApps_2_3_6.Stop (Seconds (49.0*a));
- 120 -
ApplicationContainer udpClientApps_2_4_2 =
udpClient_2.Install (wifiStaNodes_2.Get(4));
udpClientApps_2_4_2.Start (Seconds (3.0*a));
udpClientApps_2_4_2.Stop (Seconds (4.0*a));
ApplicationContainer udpClientApps_2_4_3 =
udpClient_2.Install (wifiStaNodes_2.Get(4));
udpClientApps_2_4_3.Start (Seconds (15.0*a));
udpClientApps_2_4_3.Stop (Seconds (18.0*a));
ApplicationContainer udpClientApps_2_4_4 =
udpClient_2.Install (wifiStaNodes_2.Get(4));
udpClientApps_2_4_4.Start (Seconds (23.0*a));
udpClientApps_2_4_4.Stop (Seconds (29.0*a));
ApplicationContainer udpClientApps_2_4_5 =
udpClient_2.Install (wifiStaNodes_2.Get(4));
udpClientApps_2_4_5.Start (Seconds (34.0*a));
udpClientApps_2_4_5.Stop (Seconds (40.0*a));
ApplicationContainer udpClientApps_2_5_2 =
udpClient_2.Install (wifiStaNodes_2.Get(5));
udpClientApps_2_5_2.Start (Seconds (4.0*a));
udpClientApps_2_5_2.Stop (Seconds (5.0*a));
ApplicationContainer udpClientApps_2_5_3 =
udpClient_2.Install (wifiStaNodes_2.Get(5));
udpClientApps_2_5_3.Start (Seconds (13.0*a));
udpClientApps_2_5_3.Stop (Seconds (16.0*a));
ApplicationContainer udpClientApps_2_5_4 =
udpClient_2.Install (wifiStaNodes_2.Get(5));
udpClientApps_2_5_4.Start (Seconds (20.0*a));
udpClientApps_2_5_4.Stop (Seconds (27.0*a));
ApplicationContainer udpClientApps_2_5_5 =
udpClient_2.Install (wifiStaNodes_2.Get(5));
udpClientApps_2_5_5.Start (Seconds (29.0*a));
udpClientApps_2_5_5.Stop (Seconds (31.0*a));
ApplicationContainer udpClientApps_2_5_6 =
udpClient_2.Install (wifiStaNodes_2.Get(5));
udpClientApps_2_5_6.Start (Seconds (36.0*a));
udpClientApps_2_5_6.Stop (Seconds (39.0*a));
ApplicationContainer udpClientApps_2_5_7 =
udpClient_2.Install (wifiStaNodes_2.Get(5));
udpClientApps_2_5_7.Start (Seconds (49.0*a));
udpClientApps_2_5_7.Stop (Seconds (50.0*a));
//Estacion en ambas WLANs
UdpClientHelper udpClient_0_1 (p2pInterfaces_1.GetAddress(1), 9);
udpClient_0_1.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_0_1.SetAttribute ("Interval", TimeValue (Seconds (0.0025)));
udpClient_0_1.SetAttribute ("PacketSize", UintegerValue (200));
UdpClientHelper udpClient_0_2 (p2pInterfaces_2.GetAddress(1), 9);
udpClient_0_2.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_0_2.SetAttribute ("Interval", TimeValue (Seconds (0.0025)));
udpClient_0_2.SetAttribute ("PacketSize", UintegerValue (200));
ApplicationContainer udpClientApps_0_1 =
udpClient_0_1.Install (wifiStaNodes_1.Get(0));
udpClientApps_0_1.Start (Seconds (0.0*a));
udpClientApps_0_1.Stop (Seconds (50.0*a));
ApplicationContainer udpClientApps_0_2 =
udpClient_0_2.Install (wifiStaNodes_2.Get(0));
udpClientApps_0_2.Start (Seconds (0.0*a));
udpClientApps_0_2.Stop (Seconds (50.0*a));
// Packet sinks
PacketSinkHelper sink_1 ("ns3::UdpSocketFactory",
Address (InetSocketAddress (Ipv4Address::GetAny (), 9)));
ApplicationContainer serverApps_1 = sink_1.Install (p2pNodes_1.Get(1));
- 121 -
serverApps_1.Start (Seconds (0.0));
PacketSinkHelper sink_2 ("ns3::UdpSocketFactory",
Address (InetSocketAddress (Ipv4Address::GetAny (), 9)));
ApplicationContainer serverApps_2 = sink_2.Install (p2pNodes_2.Get(1));
serverApps_2.Start (Seconds (0.0));
//serverApps_2.Stop (Seconds (50.0*a));
/////////////////////////////////////////////////////////////////////////////////
std::ostringstream oss;
std::ostringstream oss2;
std::ofstream ofile;
for (i=5;i<=5+nWifi_1-1;i++) {
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/DataMode";
Config::Set (oss.str(), StringValue("OfdmRate6Mbps"));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/ControlMode";
Config::Set (oss.str(), StringValue("OfdmRate6Mbps"));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Enqueue";
Config::Connect (oss.str(), MakeCallback (&EnqueueCallback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Dequeue";
Config::Connect (oss.str(), MakeCallback (&DequeueCallback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Drop";
Config::Connect (oss.str(), MakeCallback (&DropCallback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/IsQueueSizeManaged";
Config::Set (oss.str(), BooleanValue(managed));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/LossProbability";
Config::Set (oss.str(), DoubleValue(pl));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Weight";
Config::Set (oss.str(), DoubleValue(w));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/ThresholdUp";
Config::Set (oss.str(), DoubleValue(tu));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/ThresholdDown";
Config::Set (oss.str(), DoubleValue(td));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/MaxPacketNumber";
Config::Set (oss.str(), UintegerValue(qInit));
oss.str("");
oss2.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/AvailableMemoryFile";
oss2 << "availableMemory_" << i << ".txt";
ofile.open((oss2.str()).c_str());
ofile << "0" << "\n";
ofile.close();
Config::Set (oss.str(), StringValue(oss2.str()));
oss.str("");
- 122 -
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/QueueSizeUpdated_1";
Config::Connect (oss.str(), MakeCallback(&QueueSizeUpdated_1Callback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/QueueSizeUpdated_2";
Config::Connect (oss.str(), MakeCallback(&QueueSizeUpdated_2Callback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/QueueSizeUpdated_3";
Config::Connect (oss.str(), MakeCallback(&QueueSizeUpdated_3Callback));
}
for (i=5+nWifi_1;i<=5+nWifi_1+nWifi_2-1;i++) {
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/DataMode";
Config::Set (oss.str(), StringValue("OfdmRate6Mbps"));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/ControlMode";
Config::Set (oss.str(), StringValue("OfdmRate6Mbps"));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Enqueue";
Config::Connect (oss.str(), MakeCallback (&EnqueueCallback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Dequeue";
Config::Connect (oss.str(), MakeCallback (&DequeueCallback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Drop";
Config::Connect (oss.str(), MakeCallback (&DropCallback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/IsQueueSizeManaged";
Config::Set (oss.str(), BooleanValue(managed));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/LossProbability";
Config::Set (oss.str(), DoubleValue(pl));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Weight";
Config::Set (oss.str(), DoubleValue(w));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/ThresholdUp";
Config::Set (oss.str(), DoubleValue(tu));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/ThresholdDown";
Config::Set (oss.str(), DoubleValue(td));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/MaxPacketNumber";
Config::Set (oss.str(), UintegerValue(qInit));
oss.str("");
oss2.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/AvailableMemoryFile";
oss2 << "availableMemory_" << i << ".txt";
ofile.open((oss2.str()).c_str());
ofile << "0" << "\n";
ofile.close();
- 123 -
Config::Set (oss.str(), StringValue(oss2.str()));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/QueueSizeUpdated_1";
Config::Connect (oss.str(), MakeCallback(&QueueSizeUpdated_1Callback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/QueueSizeUpdated_2";
Config::Connect (oss.str(), MakeCallback(&QueueSizeUpdated_2Callback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/QueueSizeUpdated_3";
Config::Connect (oss.str(), MakeCallback(&QueueSizeUpdated_3Callback));
}
//Trazas en APs
Config::Set
("/NodeList/0/DeviceList/1/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/Da
taMode", StringValue("OfdmRate6Mbps"));
Config::Set
("/NodeList/0/DeviceList/1/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/Co
ntrolMode", StringValue("OfdmRate6Mbps"));
Config::Set
("/NodeList/2/DeviceList/1/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/Da
taMode", StringValue("OfdmRate6Mbps"));
Config::Set
("/NodeList/2/DeviceList/1/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/Co
ntrolMode", StringValue("OfdmRate6Mbps"));
//Trazas en estacion muestra
Config::Set
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/Da
taMode", StringValue("OfdmRate6Mbps"));
Config::Set
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/Co
ntrolMode", StringValue("OfdmRate6Mbps"));
Config::Set
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/Da
taMode", StringValue("OfdmRate6Mbps"));
Config::Set
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/Co
ntrolMode", StringValue("OfdmRate6Mbps"));
Config::Connect
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Enqueue",
MakeCallback (&EnqueueCallback));
Config::Connect
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Dequeue",
MakeCallback (&DequeueCallback));
Config::Connect
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Drop",
MakeCallback (&DropCallback));
Config::Connect
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Enqueue",
MakeCallback (&EnqueueCallback));
Config::Connect
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Dequeue",
MakeCallback (&DequeueCallback));
Config::Connect
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/Drop",
MakeCallback (&DropCallback));
Config::Set
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/MaxPacketNumbe
r", UintegerValue(qInit));
Config::Set
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Queue/MaxPacketNumbe
r", UintegerValue(qInit));
Config::Set
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/IsQueueSizeManaged",
BooleanValue(managed));
Config::Set
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/LossProbability",
DoubleValue(pl));
Config::Set
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Weight",
DoubleValue(w));
- 124 -
Config::Set
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/ThresholdUp",
DoubleValue(tu));
Config::Set
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/ThresholdDown",
DoubleValue(td));
Config::Set
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/AvailableMemoryFile"
, StringValue("availableMemory_4.txt"));
Config::Connect
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/QueueSizeUpdated_1",
MakeCallback(&QueueSizeUpdated_1Callback));
Config::Connect
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/QueueSizeUpdated_2",
MakeCallback(&QueueSizeUpdated_2Callback));
Config::Connect
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/QueueSizeUpdated_3",
MakeCallback(&QueueSizeUpdated_3Callback));
Config::Connect
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/TxOkHeader",
MakeCallback(&TxOkHeaderCallback));
Config::Connect
("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/TxErrHeader",
MakeCallback(&TxErrHeaderCallback));
Config::Connect ("/NodeList/4/DeviceList/0/$ns3::WifiNetDevice/Phy/PhyTxBegin", MakeCallback
(&PhyTxBeginCallback));
Config::Set
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/IsQueueSizeManaged",
BooleanValue(managed));
Config::Set
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/LossProbability",
DoubleValue(pl));
Config::Set
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/Weight",
DoubleValue(w));
Config::Set
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/ThresholdUp",
DoubleValue(tu));
Config::Set
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/ThresholdDown",
DoubleValue(td));
Config::Set
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/AvailableMemoryFile"
, StringValue("availableMemory_4.txt"));
Config::Connect
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/QueueSizeUpdated_1",
MakeCallback(&QueueSizeUpdated_1Callback));
Config::Connect
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/QueueSizeUpdated_2",
MakeCallback(&QueueSizeUpdated_2Callback));
Config::Connect
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/DcaTxop/QueueSizeUpdated_3",
MakeCallback(&QueueSizeUpdated_3Callback));
Config::Connect
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/TxOkHeader",
MakeCallback(&TxOkHeaderCallback));
Config::Connect
("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/TxErrHeader",
MakeCallback(&TxErrHeaderCallback));
Config::Connect ("/NodeList/4/DeviceList/1/$ns3::WifiNetDevice/Phy/PhyTxBegin", MakeCallback
(&PhyTxBeginCallback));
//end
//Valor inicial para el total de memoria disponible en el nodo
ofile.open("availableMemory_4.txt");
ofile << "0" << "\n";
ofile.close();
//Simulator::Stop(Seconds(10000));
Simulator::Stop(Seconds(50*a));
Simulator::Run ();
Simulator::Destroy ();
return 0;
}
- 125 -
A.2 Scenario-2
/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */
/*
*
*
* This program was adapted by Rubén Rumipamba:
*
*
*student from Universitat Poltècnica de Catalunya) from code orignally created by: Kirill Andreev
*
*To implement dynamic buffer size allocation in WMN
*
*
* By default this script creates m_xSize * m_ySize square grid topology with
* IEEE802.11s stack installed at each node with peering management
* and HWMP protocol.
* The side of the square cell is defined by m_step parameter.
* When topology is created, UDP ping is installed to opposite corners
* by diagonals. packet size of the UDP ping and interval between two
* successive packets is configurable.
*
* m_xSize * step
* |<--------->|
* step
* |<--->|
* * --- * --- * <---Ping sink _
* | \ | / | ^
* | \ | / | |
* * --- * --- * m_ySize * step |
* | / | \ | |
* | / | \ | |
* * --- * --- * _
* ^ Ping source
*
* See also MeshTest::Configure to read more about configurable
* parameters.
*/
#include "ns3/core-module.h"
#include "ns3/internet-module.h"
#include "ns3/network-module.h"
#include "ns3/applications-module.h"
#include "ns3/wifi-module.h"
#include "ns3/mesh-module.h"
#include "ns3/mobility-module.h"
#include "ns3/mesh-helper.h"
#include "ns3/netanim-module.h"
#include "ns3/qos-tag.h" //RR
#include "ns3/flow-monitor-helper.h" //RR
#include <iostream>
#include <sstream>
#include <fstream>
using namespace ns3;
NS_LOG_COMPONENT_DEFINE ("TestMeshScript");
//begin added callback traces
void
PhyTxBeginCallback (std::string context, Ptr<const Packet> packet)
{
std::ostringstream oss;
packet->PrintPacketTags (oss);
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << packet->GetUid() <<
"\t"<< packet->GetSize() << "\t" << oss.str() << endl;
}
void
MacTxCallback (std::string context, Ptr<const Packet> const_packet)
- 126 -
{
//Set TID=6 a todos los paquetes sin tag=AC_BE
Ptr<Packet> packet = const_packet->Copy ();
QosTag qos;
if (!(packet->RemovePacketTag (qos)))
{
qos.SetTid(6); //TID=6 AC_VO
const_packet->AddPacketTag(qos);
}
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << const_packet-
>GetUid() << "\t" << const_packet->GetSize() << endl;
}
void
PhyRxEndCallback (std::string context, Ptr<const Packet> packet)
{
std::ostringstream oss;
packet->Print (oss);
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << packet->GetUid() <<
"\t" << packet->GetSize() << "\t" << oss.str() << endl;
}
void
RxOkCallback (std::string context, Ptr<const Packet> packet, double snr, WifiMode mode, enum
WifiPreamble prem)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << packet->GetUid() <<
endl;
}
void
TxOkHeaderCallback (std::string context, const WifiMacHeader &_wmh)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _wmh << endl;
}
void
TxErrHeaderCallback (std::string context,const WifiMacHeader &_wmh)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _wmh << endl;
}
void
EnqueueCallback (std::string context,Ptr<const Packet> _p,uint32_t _size,uint32_t _maxSize)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _p->GetUid() << "\t"
<< _p->GetSize() << "\t" << _size << "\t" << _maxSize << endl;
}
void
DequeueCallback (std::string context,Ptr<const Packet> _p,uint32_t _size,uint32_t _maxSize)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _p->GetUid() << "\t"
<< _p->GetSize() << "\t" << _size << "\t" << _maxSize << endl;
}
void
DropCallback (std::string context, Ptr<const Packet> _p,uint32_t _size,uint32_t _maxSize)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _p->GetUid() << "\t"
<< _p->GetSize() << "\t" << _size << "\t" << _maxSize << endl;
}
void
QueueSizeUpdated_1Callback (std::string context, uint32_t _r,uint32_t _n,double _ar,double
_an,double _y,double _b,double _newN,uint32_t _newQ)
{
- 127 -
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _r << "\t" << _n <<
"\t" << _ar << "\t" << _an << "\t" << _y << "\t" << _b << "\t" << _newN << "\t" << _newQ << endl;
}
void
QueueSizeUpdated_2Callback (std::string context, double _y,double _b,double _newN, uint32_t _newQ,
uint32_t _GS, uint32_t _neededQ)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _y << "\t" << _b <<
"\t" << _newN << "\t" << _newQ << "\t" << _GS << "\t" << _neededQ << endl;
}
void
QueueSizeUpdated_3Callback (std::string context, uint32_t _prevQ,uint32_t _neededQ,int32_t
_dif,uint32_t _prevAvailable, uint32_t _newQ,uint32_t _available)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _prevQ << "\t" <<
_neededQ << "\t" << _dif << "\t" << _prevAvailable << "\t" << _newQ << "\t" << _available << endl;
}
//end
class MeshTest
{
public:
/// Init test
MeshTest ();
/// Configure test from command line arguments
void Configure (int argc, char ** argv);
/// Run test
int Run ();
private:
int m_xSize;
int m_ySize;
int m_qInit;
double m_step;
double m_randomStart;
double a;
double m_packetInterval;
uint16_t m_packetSize;
uint32_t m_nIfaces;
bool m_chan;
bool m_pcap;
bool m_managed;
std::string m_stack;
std::string m_root;
std::string m_ac;
std::string nameflow;
uint32_t m_gwnode;
uint32_t m_dst;
int m_runNumber;
double m_pl;
/// List of network nodes
NodeContainer nodes;
/// List of all mesh point devices
NetDeviceContainer meshDevices;
//Addresses of interfaces:
Ipv4InterfaceContainer interfaces;
// MeshHelper. Report is not static methods
MeshHelper mesh;
private:
/// Create nodes and setup their mobility
void CreateNodes ();
/// Install internet m_stack on nodes
void InstallInternetStack ();
/// Install applications
void InstallApplication ();
/// Print mesh devices diagnostics
void Report ();
//Populate ARP Cache Table - Add by RUBEN
void PopulateArpCache ();
};
MeshTest::MeshTest () :
m_xSize (5),
m_ySize (1),
m_qInit (100),
m_step (80.0),
m_randomStart (0.1),
- 128 -
a (100.0),
m_packetSize (1024),
m_nIfaces (1),
m_chan (true),
m_pcap (false),
m_managed (false),
m_stack ("ns3::Dot11sStack"),
m_root ("ff:ff:ff:ff:ff:ff"),
m_ac("BE"),
m_gwnode(0),
m_runNumber(1),
m_pl(0.001)
{
}
void
MeshTest::Configure (int argc, char *argv[])
{
CommandLine cmd;
cmd.AddValue ("x-size", "Number of nodes in a row grid. [6]", m_xSize);
cmd.AddValue ("y-size", "Number of rows in a grid. [6]", m_ySize);
cmd.AddValue ("step", "Size of edge in our grid, meters. [100 m]", m_step);
/*
* As soon as starting node means that it sends a beacon,
* simultaneous start is not good.
*/
cmd.AddValue ("start", "Maximum random start delay, seconds. [0.1 s]", m_randomStart);
cmd.AddValue ("time", "Simulation time, seconds [100 s]", a);
cmd.AddValue ("packet-interval", "Interval between packets in UDP ping, seconds [0.001 s]",
m_packetInterval);
cmd.AddValue ("packet-size", "Size of packets in UDP ping", m_packetSize);
cmd.AddValue ("interfaces", "Number of radio interfaces used by each mesh point. [1]", m_nIfaces);
cmd.AddValue ("channels", "Use different frequency channels for different interfaces. [0]",
m_chan);
cmd.AddValue ("pcap", "Enable PCAP traces on interfaces. [0]", m_pcap);
cmd.AddValue ("stack", "Type of protocol stack. ns3::Dot11sStack by default", m_stack);
cmd.AddValue ("managed", "Enable Dynamic Buffer Size Allocation Algorithm", m_managed);
cmd.AddValue ("root", "Mac address of root mesh point in HWMP", m_root);
cmd.AddValue ("pl", "Loss Probability for Dynamic Buffer Size Allocation Algorithm", m_pl);
cmd.AddValue ("ac", "Access Category of the TX Packets", m_ac);
cmd.AddValue ("qInit", "Queue Initial Size", m_qInit);
cmd.AddValue ("runNumber", "Run Number for Simulation", m_runNumber);
cmd.Parse (argc, argv);
NS_LOG_DEBUG ("Grid:" << m_xSize << "*" << m_ySize);
NS_LOG_DEBUG ("Simulation time: " << a << " s");
}
void
MeshTest::CreateNodes ()
{
/*
* Create m_ySize*m_xSize stations to form a grid topology
*/
nodes.Create (m_ySize*m_xSize);
// Configure YansWifiChannel
YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();
YansWifiChannelHelper wifiChannel = YansWifiChannelHelper::Default ();
//add Losses
//wifiChannel.AddPropagationLoss("ns3::RandomPropagationLossModel","Variable",RandomVariableValue(Un
iformVariable (5.5,5.5)));
//
wifiPhy.SetChannel (wifiChannel.Create ());
//Begin: Configure the parameters of the Peer Link
Config::SetDefault ("ns3::dot11s::PeerLink::MaxBeaconLoss", UintegerValue (5));
Config::SetDefault ("ns3::dot11s::PeerLink::MaxRetries", UintegerValue (4));
Config::SetDefault ("ns3::dot11s::PeerLink::MaxPacketFailure", UintegerValue (5));
//end: Peer-link configuration
// Begin: Configure the parameters of the HWMP
Config::SetDefault ("ns3::dot11s::HwmpProtocol::DoFlag", BooleanValue (false));
Config::SetDefault ("ns3::dot11s::HwmpProtocol::RfFlag", BooleanValue (true));
Config::SetDefault ("ns3::dot11s::HwmpProtocol::Dot11MeshHWMPactivePathTimeout",TimeValue (Seconds
(5100))); //ask for Path Request (PREQ) once in entire simulation time.
- 129 -
// end: HWMP configuration
/*
* Create mesh helper and set stack installer to it
* Stack installer creates all needed protocols and install them to
* mesh point device
*/
mesh = MeshHelper::Default ();
if (!Mac48Address (m_root.c_str ()).IsBroadcast ())
{
mesh.SetStackInstaller (m_stack, "Root", Mac48AddressValue (Mac48Address (m_root.c_str ())));
}
else
{
//If root is not set, we do not use "Root" attribute, because it
//is specified only for 11s
mesh.SetStackInstaller (m_stack);
}
if (m_chan)
{
mesh.SetSpreadInterfaceChannels (MeshHelper::SPREAD_CHANNELS);
}
else
{
mesh.SetSpreadInterfaceChannels (MeshHelper::ZERO_CHANNEL);
}
mesh.SetStandard (WIFI_PHY_STANDARD_80211a);
mesh.SetRemoteStationManager( "ns3::ConstantRateWifiManager",
"DataMode", StringValue("OfdmRate6Mbps"),
"ControlMode",StringValue("OfdmRate6Mbps"));
//begin - QoS STA supported
mesh.SetMacType("QosSupported",BooleanValue(true));
//end configuration
mesh.SetMacType ("RandomStart", TimeValue (Seconds (m_randomStart)));
// Set number of interfaces - default is single-interface mesh point
mesh.SetNumberOfInterfaces (m_nIfaces);
// Install protocols and return container if MeshPointDevices
meshDevices = mesh.Install (wifiPhy, nodes);
// Setup mobility - static grid topology
MobilityHelper mobility;
mobility.SetPositionAllocator ("ns3::GridPositionAllocator",
"MinX", DoubleValue (0.0),
"MinY", DoubleValue (0.0),
"DeltaX", DoubleValue (m_step),
"DeltaY", DoubleValue (m_step),
"GridWidth", UintegerValue (m_xSize),
"LayoutType", StringValue ("RowFirst"));
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (nodes);
if (m_pcap)
wifiPhy.EnablePcapAll (std::string ("mp-"));
}
void
MeshTest::InstallInternetStack ()
{
InternetStackHelper internetStack;
internetStack.Install (nodes);
Ipv4AddressHelper address;
address.SetBase ("10.1.1.0", "255.255.255.0");
interfaces = address.Assign (meshDevices);
}
void
MeshTest::InstallApplication ()
{
m_dst=nodes.GetN()-1;
UdpClientHelper udpClient_0 (interfaces.GetAddress (m_dst), 9);
udpClient_0.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_0.SetAttribute ("Interval", TimeValue (Seconds (0.007)));
udpClient_0.SetAttribute ("PacketSize", UintegerValue (200));
ApplicationContainer udpClientApps_0_1 =
- 130 -
udpClient_0.Install (nodes.Get(m_gwnode));
udpClientApps_0_1.Start (Seconds (1.0*a));
udpClientApps_0_1.Stop (Seconds (6.0*a));
UdpClientHelper udpClient_1 (interfaces.GetAddress (m_dst), 9);
udpClient_1.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_1.SetAttribute ("Interval", TimeValue (Seconds (0.006)));
udpClient_1.SetAttribute ("PacketSize", UintegerValue (200));
ApplicationContainer udpClientApps_0_2 =
udpClient_1.Install (nodes.Get(m_gwnode));
udpClientApps_0_2.Start (Seconds (6.0*a));
udpClientApps_0_2.Stop (Seconds (11.0*a));
UdpClientHelper udpClient_2 (interfaces.GetAddress (m_dst), 9);
udpClient_2.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_2.SetAttribute ("Interval", TimeValue (Seconds (0.007)));
udpClient_2.SetAttribute ("PacketSize", UintegerValue (200));
ApplicationContainer udpClientApps_0_3 =
udpClient_2.Install (nodes.Get(m_gwnode));
udpClientApps_0_3.Start (Seconds (11.0*a));
udpClientApps_0_3.Stop (Seconds (16.0*a));
UdpClientHelper udpClient_3 (interfaces.GetAddress (m_dst), 9);
udpClient_3.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_3.SetAttribute ("Interval", TimeValue (Seconds (0.006)));
udpClient_3.SetAttribute ("PacketSize", UintegerValue (200));
ApplicationContainer udpClientApps_0_4 =
udpClient_3.Install (nodes.Get(m_gwnode));
udpClientApps_0_4.Start (Seconds (16.0*a));
udpClientApps_0_4.Stop (Seconds (21.0*a));
UdpClientHelper udpClient_4 (interfaces.GetAddress (m_dst), 9);
udpClient_4.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_4.SetAttribute ("Interval", TimeValue (Seconds (0.0049)));
udpClient_4.SetAttribute ("PacketSize", UintegerValue (200));
ApplicationContainer udpClientApps_0_5 =
udpClient_4.Install (nodes.Get(m_gwnode));
udpClientApps_0_5.Start (Seconds (21.0*a));
udpClientApps_0_5.Stop (Seconds (26.0*a));
UdpClientHelper udpClient_5 (interfaces.GetAddress (m_dst), 9);
udpClient_5.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_5.SetAttribute ("Interval", TimeValue (Seconds (0.006)));
udpClient_5.SetAttribute ("PacketSize", UintegerValue (200));
ApplicationContainer udpClientApps_0_6 =
udpClient_5.Install (nodes.Get(m_gwnode));
udpClientApps_0_6.Start (Seconds (26.0*a));
udpClientApps_0_6.Stop (Seconds (31.0*a));
UdpClientHelper udpClient_6 (interfaces.GetAddress (m_dst), 9);
udpClient_6.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_6.SetAttribute ("Interval", TimeValue (Seconds (0.007)));
udpClient_6.SetAttribute ("PacketSize", UintegerValue (200));
ApplicationContainer udpClientApps_0_7 =
udpClient_6.Install (nodes.Get(m_gwnode));
udpClientApps_0_7.Start (Seconds (31.0*a));
udpClientApps_0_7.Stop (Seconds (36.0*a));
UdpClientHelper udpClient_7 (interfaces.GetAddress (m_dst), 9);
udpClient_7.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_7.SetAttribute ("Interval", TimeValue (Seconds (0.006)));
udpClient_7.SetAttribute ("PacketSize", UintegerValue (200));
ApplicationContainer udpClientApps_0_8 =
udpClient_7.Install (nodes.Get(m_gwnode));
udpClientApps_0_8.Start (Seconds (36.0*a));
udpClientApps_0_8.Stop (Seconds (41.0*a));
UdpClientHelper udpClient_8 (interfaces.GetAddress (m_dst), 9);
udpClient_8.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_8.SetAttribute ("Interval", TimeValue (Seconds (0.0049)));
- 131 -
udpClient_8.SetAttribute ("PacketSize", UintegerValue (200));
ApplicationContainer udpClientApps_0_9 =
udpClient_8.Install (nodes.Get(m_gwnode));
udpClientApps_0_9.Start (Seconds (41.0*a));
udpClientApps_0_9.Stop (Seconds (46.0*a));
UdpClientHelper udpClient_9 (interfaces.GetAddress (m_dst), 9);
udpClient_9.SetAttribute ("MaxPackets", UintegerValue (10000000));
udpClient_9.SetAttribute ("Interval", TimeValue (Seconds (0.006)));
udpClient_9.SetAttribute ("PacketSize", UintegerValue (200));
ApplicationContainer udpClientApps_0_10 =
udpClient_9.Install (nodes.Get(m_gwnode));
udpClientApps_0_10.Start (Seconds (46.0*a));
udpClientApps_0_10.Stop (Seconds (51.0*a));
// Packet sinks
PacketSinkHelper sink_1 ("ns3::UdpSocketFactory",
Address (InetSocketAddress (Ipv4Address::GetAny (), 9)));
ApplicationContainer serverApps_1 = sink_1.Install (nodes.Get(m_dst));
serverApps_1.Start (Seconds (1.0*a));
serverApps_1.Stop (Seconds (51.0*a));
}
int
MeshTest::Run ()
{
SeedManager::SetRun(m_runNumber);
CreateNodes ();
InstallInternetStack ();
PopulateArpCache ();
InstallApplication ();
Simulator::Schedule (Seconds (51*a), &MeshTest::Report, this);
std::ostringstream oss;
std::ostringstream oss2;
std::ofstream ofile;
//begin: Parameters for dynamic mechanism
double w=0.001;
double tu=0.01;
double td=0.1;
//end
// ALL MESH NODES //
for (uint32_t i=0;i<=((uint32_t)nodes.GetN())-1;i++) {
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/MacTx";
Config::Connect (oss.str(), MakeCallback(&MacTxCallback));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac <<"_EdcaTxopN/Queue/Enqueue";
Config::Connect (oss.str(), MakeCallback(&EnqueueCallback));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac <<"_EdcaTxopN/Queue/Dequeue";
Config::Connect (oss.str(), MakeCallback(&DequeueCallback));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac <<"_EdcaTxopN/Queue/Drop";
Config::Connect (oss.str(), MakeCallback(&DropCallback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/TxOkHeader";
Config::Connect (oss.str(), MakeCallback(&TxOkHeaderCallback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/TxErrHeader";
Config::Connect (oss.str(), MakeCallback(&TxErrHeaderCallback));
- 132 -
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Phy/PhyTxBegin";
Config::Connect (oss.str(), MakeCallback(&PhyTxBeginCallback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/1/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/DataMode";
Config::Set (oss.str(), StringValue("OfdmRate6Mbps"));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac <<"_EdcaTxopN/IsQueueSizeManaged";
Config::Set (oss.str(), BooleanValue(m_managed));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/LossProbability";
Config::Set (oss.str(), DoubleValue(m_pl));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/Weight";
Config::Set (oss.str(), DoubleValue(w));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/ThresholdUp";
Config::Set (oss.str(), DoubleValue(tu));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/ThresholdDown";
Config::Set (oss.str(), DoubleValue(td));
oss.str("");
oss2.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac <<"_EdcaTxopN/AvailableMemoryFile";
oss2 << "MavailableMemory_" << i << ".txt";
ofile.open((oss2.str()).c_str());
ofile << "0" << "\n";
ofile.close();
Config::Set (oss.str(), StringValue(oss2.str()));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/Queue/MaxPacketNumber";
Config::Set (oss.str(), UintegerValue(m_qInit));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/QueueSizeUpdated_1";
Config::Connect (oss.str(), MakeCallback(&QueueSizeUpdated_1Callback));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/QueueSizeUpdated_2";
Config::Connect (oss.str(), MakeCallback(&QueueSizeUpdated_2Callback));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/QueueSizeUpdated_3";
Config::Connect (oss.str(), MakeCallback(&QueueSizeUpdated_3Callback));
}
//begin FlowMonitor configuration
Ptr<FlowMonitor> flowMon;
FlowMonitorHelper flowMonHelper;
flowMon = flowMonHelper.InstallAll();
//end configuration
Simulator::Stop (Seconds (51*a));//5000 sec
Simulator::Run ();
//begin for save different flow monitor
stringstream x;
x << m_xSize;
- 133 -
string xstr = x.str();
stringstream y;
y << m_ySize;
string ystr = y.str();
stringstream pl;
pl << m_pl;
string plstr = pl.str();
nameflow="Cadena_Flow_"+ xstr +"x"+ ystr+m_ac+plstr+".xml";
flowMon->SerializeToXmlFile(nameflow, true, true);
//end configuration
Simulator::Destroy ();
return 0;
}
void
MeshTest::Report ()
{
unsigned n (0);
for (NetDeviceContainer::Iterator i = meshDevices.Begin (); i != meshDevices.End (); ++i, ++n)
{
std::ostringstream os;
os << "mp-report-" << n << ".xml";
std::cerr << "Printing mesh point device #" << n << " diagnostics to " << os.str () << "\n";
std::ofstream of;
of.open (os.str ().c_str ());
if (!of.is_open ())
{
std::cerr << "Error: Can't open file " << os.str () << "\n";
return;
}
mesh.Report (*i, of);
of.close ();
}
}
//begin_code for pre-polulate ARP cache (From google groups Pavel Boyko)
void
MeshTest::PopulateArpCache ()
{
Ptr<ArpCache> arp = CreateObject<ArpCache> ();
arp->SetAliveTimeout (Seconds(3600 * 24 * 365));
for (NodeList::Iterator i = NodeList::Begin(); i != NodeList::End(); ++i)
{
Ptr<Ipv4L3Protocol> ip = (*i)->GetObject<Ipv4L3Protocol> ();
NS_ASSERT(ip !=0);
ObjectVectorValue ifcs;
ip->GetAttribute("InterfaceList", ifcs);
for(ObjectVectorValue::Iterator j = ifcs.Begin(); j != ifcs.End (); j ++)
{
Ptr<Ipv4Interface> ipIface = (*j)->GetObject<Ipv4Interface> ();
NS_ASSERT(ipIface != 0);
Ptr<NetDevice> device = ipIface->GetDevice();
NS_ASSERT(device != 0);
Mac48Address addr = Mac48Address::ConvertFrom(device->GetAddress ());
for(uint32_t k = 0; k < ipIface->GetNAddresses (); k ++)
{
Ipv4Address ipAddr = ipIface->GetAddress (k).GetLocal();
if(ipAddr == Ipv4Address::GetLoopback())
continue;
ArpCache::Entry * entry = arp->Add(ipAddr);
entry->MarkWaitReply(0);
entry->MarkAlive(addr);
}
}
}
for (NodeList::Iterator i = NodeList::Begin(); i != NodeList::End(); ++i)
{
Ptr<Ipv4L3Protocol> ip = (*i)->GetObject<Ipv4L3Protocol> ();
NS_ASSERT(ip !=0);
ObjectVectorValue interfaces;
ip->GetAttribute("InterfaceList", interfaces);
for(ObjectVectorValue::Iterator j = interfaces.Begin(); j != interfaces.End (); j ++)
{
Ptr<Ipv4Interface> ipIface = (*j)->GetObject<Ipv4Interface> ();
ipIface->SetAttribute("ArpCache", PointerValue(arp));
}
}
- 134 -
}
int
main (int argc, char *argv[])
{
MeshTest t;
t.Configure (argc, argv);
return t.Run ();
}
- 135 -
A.3 Scenario-3
/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */
/*
*
*
* This program was adapted by Rubén Rumipamba:
*
*
*student from Universitat Poltècnica de Catalunya) from code orignally created by: Kirill Andreev
*
*To implement dynamic buffer size allocation in WMN
*
*
* By default this script creates m_xSize * m_ySize square grid topology with
* IEEE802.11s stack installed at each node with peering management
* and HWMP protocol.
* The side of the square cell is defined by m_step parameter.
* When topology is created, UDP ping is installed to opposite corners
* by diagonals. packet size of the UDP ping and interval between two
* successive packets is configurable.
*
* m_xSize * step
* |<--------->|
* step
* |<--->|
* * --- * --- * <---Ping sink _
* | \ | / | ^
* | \ | / | |
* * --- * --- * m_ySize * step |
* | / | \ | |
* | / | \ | |
* * --- * --- * _
* ^ Ping source
*
* See also MeshTest::Configure to read more about configurable
* parameters.
*/
#include "ns3/core-module.h"
#include "ns3/internet-module.h"
#include "ns3/network-module.h"
#include "ns3/applications-module.h"
#include "ns3/wifi-module.h"
#include "ns3/mesh-module.h"
#include "ns3/mobility-module.h"
#include "ns3/mesh-helper.h"
#include "ns3/netanim-module.h"
#include "ns3/qos-tag.h"
#include "ns3/flow-monitor-helper.h"
#include <iostream>
#include <sstream>
#include <fstream>
using namespace ns3;
NS_LOG_COMPONENT_DEFINE ("TestMeshScript");
//begin added callback traces
void
PhyTxBeginCallback (std::string context, Ptr<const Packet> packet)
{
std::ostringstream oss;
packet->PrintPacketTags (oss);
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << packet->GetUid() <<
"\t"<< packet->GetSize() << "\t" << oss.str() << endl;
}
void
MacTxCallback (std::string context, Ptr<const Packet> const_packet)
{
- 136 -
//-AC_VO : voice, tid = 6,7 ^ -AC_VI : video, tid = 4,5 | -AC_BE : best-effort, tid = 0,3 |
priority -AC_BK : background, tid = 1,2 |
//Set TID=6 a todos los paquetes sin tag=AC_BE
Ptr<Packet> packet = const_packet->Copy ();
QosTag qos;
if (!(packet->RemovePacketTag (qos)))
{
qos.SetTid(6); //TID=6 AC_VO
const_packet->AddPacketTag(qos);
}
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << const_packet-
>GetUid() << "\t" << const_packet->GetSize() << endl;
}
void
PhyRxEndCallback (std::string context, Ptr<const Packet> packet)
{
std::ostringstream oss;
packet->Print (oss);
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << packet->GetUid() <<
"\t" << packet->GetSize() << "\t" << oss.str() << endl;
}
void
RxOkCallback (std::string context, Ptr<const Packet> packet, double snr, WifiMode mode, enum
WifiPreamble prem)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << packet->GetUid() <<
endl;
}
void
TxOkHeaderCallback (std::string context, const WifiMacHeader &_wmh)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _wmh << endl;
}
void
TxErrHeaderCallback (std::string context,const WifiMacHeader &_wmh)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _wmh << endl;
}
void
AssocCallback (std::string context, Mac48Address _ad)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _ad << endl;
}
void
EnqueueCallback (std::string context,Ptr<const Packet> _p,uint32_t _size,uint32_t _maxSize)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _p->GetUid() << "\t"
<< _p->GetSize() << "\t" << _size << "\t" << _maxSize << "\n";
}
void
DequeueCallback (std::string context,Ptr<const Packet> _p,uint32_t _size,uint32_t _maxSize)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _p->GetUid() << "\t"
<< _p->GetSize() << "\t" << _size << "\t" << _maxSize << "\n";
}
void
DropCallback (std::string context, Ptr<const Packet> _p,uint32_t _size,uint32_t _maxSize)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _p->GetUid() << "\t"
<< _p->GetSize() << "\t" << _size << "\t" << _maxSize << "\n";
}
- 137 -
void
GenerateCallback (std::string context, double _d, uint32_t _ui)
{
std::cout << _d << "\t" << _ui << endl;
}
void
QueueSizeUpdated_1Callback (std::string context, uint32_t _r,uint32_t _n,double _ar,double
_an,double _y,double _b,double _newN,uint32_t _newQ)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _r << "\t" << _n <<
"\t" << _ar << "\t" << _an << "\t" << _y << "\t" << _b << "\t" << _newN << "\t" << _newQ << endl;
}
void
QueueSizeUpdated_2Callback (std::string context, double _y,double _b,double _newN, uint32_t _newQ,
uint32_t _GS, uint32_t _neededQ)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _y << "\t" << _b <<
"\t" << _newN << "\t" << _newQ << "\t" << _GS << "\t" << _neededQ << endl;
}
void
QueueSizeUpdated_3Callback (std::string context, uint32_t _prevQ,uint32_t _neededQ,int32_t
_dif,uint32_t _prevAvailable, uint32_t _newQ,uint32_t _available)
{
std::cout << Simulator::Now ().GetNanoSeconds() << "\t" << context << "\t" << _prevQ << "\t" <<
_neededQ << "\t" << _dif << "\t" << _prevAvailable << "\t" << _newQ << "\t" << _available << endl;
}
//end
class MeshTest
{
public:
/// Init test
MeshTest ();
/// Configure test from command line arguments
void Configure (int argc, char ** argv);
/// Run test
int Run ();
private:
int m_xSize;
int m_ySize;
int m_qInit;
double m_step;
double m_randomStart;
double a;
double m_packetInterval;
double m_pl;
uint16_t m_packetSize;
uint32_t m_nIfaces;
bool m_chan;
bool m_pcap;
bool m_managed;
std::string m_stack;
std::string m_root;
std::string m_ac;
std::string nameflow;
uint32_t m_gwnode;
/// List of network nodes
NodeContainer nodes;
/// List of all mesh point devices
NetDeviceContainer meshDevices;
//Addresses of interfaces:
Ipv4InterfaceContainer interfaces;
// MeshHelper. Report is not static methods
MeshHelper mesh;
private:
/// Create nodes and setup their mobility
void CreateNodes ();
/// Install internet m_stack on nodes
void InstallInternetStack ();
/// Install applications
void InstallApplication ();
/// Print mesh devices diagnostics
void Report ();
- 138 -
//Populate ARP Cache Table - Add by RUBEN
void PopulateArpCache ();
};
MeshTest::MeshTest () :
m_xSize (9),
m_ySize (1),
m_qInit (100),
m_step (10.0),
m_randomStart (0.1),
a (100.0),
m_packetInterval (0.006),
m_pl(0.001),
m_packetSize (200),
m_nIfaces (1),
m_chan (true),
m_pcap (false),
m_managed (false),
m_stack ("ns3::Dot11sStack"),
m_root ("00:00:00:00:00:05"),
m_ac("BE"),
m_gwnode(4)
{
}
void
MeshTest::Configure (int argc, char *argv[])
{
CommandLine cmd;
cmd.AddValue ("x-size", "Number of nodes in a row grid. [6]", m_xSize);
cmd.AddValue ("y-size", "Number of rows in a grid. [6]", m_ySize);
cmd.AddValue ("step", "Size of edge in our grid, meters. [100 m]", m_step);
/*
* As soon as starting node means that it sends a beacon,
* simultaneous start is not good.
*/
cmd.AddValue ("start", "Maximum random start delay, seconds. [0.1 s]", m_randomStart);
cmd.AddValue ("time", "Simulation time, seconds [100 s]", a);
cmd.AddValue ("packet-interval", "Interval between packets in UDP ping, seconds [0.001 s]",
m_packetInterval);
cmd.AddValue ("packet-size", "Size of packets in UDP ping", m_packetSize);
cmd.AddValue ("interfaces", "Number of radio interfaces used by each mesh point. [1]", m_nIfaces);
cmd.AddValue ("channels", "Use different frequency channels for different interfaces. [0]",
m_chan);
cmd.AddValue ("pcap", "Enable PCAP traces on interfaces. [0]", m_pcap);
cmd.AddValue ("stack", "Type of protocol stack. ns3::Dot11sStack by default", m_stack);
cmd.AddValue ("managed", "Enable Dynamic Buffer Size Allocation Algorithm", m_managed);
cmd.AddValue ("root", "Mac address of root mesh point in HWMP", m_root);
cmd.AddValue ("pl", "Loss Probability for Dynamic Buffer Size Allocation Algorithm", m_pl);
cmd.AddValue ("ac", "Access Category of the TX Packets", m_ac);
cmd.AddValue ("qInit", "Queue Initial Size", m_qInit);
cmd.Parse (argc, argv);
NS_LOG_DEBUG ("Grid:" << m_xSize << "*" << m_ySize);
NS_LOG_DEBUG ("Simulation time: " << a << " s");
}
void
MeshTest::CreateNodes ()
{
/*
* Create m_ySize*m_xSize stations to form a grid topology
*/
nodes.Create (m_ySize*m_xSize);
// Configure YansWifiChannel
YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();
YansWifiChannelHelper wifiChannel = YansWifiChannelHelper::Default ();
wifiPhy.SetChannel (wifiChannel.Create ());
// Begin: Configure the parameters of the Peer Link
Config::SetDefault ("ns3::dot11s::PeerLink::MaxBeaconLoss", UintegerValue (5));//OJO
Config::SetDefault ("ns3::dot11s::PeerLink::MaxRetries", UintegerValue (4));
Config::SetDefault ("ns3::dot11s::PeerLink::MaxPacketFailure", UintegerValue (5));
// end: Peer-link configuration
// Begin: Configure the parameters of the HWMP
Config::SetDefault ("ns3::dot11s::HwmpProtocol::DoFlag", BooleanValue (false));
Config::SetDefault ("ns3::dot11s::HwmpProtocol::RfFlag", BooleanValue (true));
// end: HWMP configuration
/*
- 139 -
* Create mesh helper and set stack installer to it
* Stack installer creates all needed protocols and install them to
* mesh point device
*/
mesh = MeshHelper::Default ();
if (!Mac48Address (m_root.c_str ()).IsBroadcast ())
{
mesh.SetStackInstaller (m_stack, "Root", Mac48AddressValue (Mac48Address (m_root.c_str ())));
}
else
{
//If root is not set, we do not use "Root" attribute, because it
//is specified only for 11s
mesh.SetStackInstaller (m_stack);
}
if (m_chan)
{
mesh.SetSpreadInterfaceChannels (MeshHelper::SPREAD_CHANNELS);
}
else
{
mesh.SetSpreadInterfaceChannels (MeshHelper::ZERO_CHANNEL);
}
mesh.SetStandard (WIFI_PHY_STANDARD_80211a);
mesh.SetRemoteStationManager( "ns3::ConstantRateWifiManager",
"DataMode", StringValue("OfdmRate6Mbps"),
"ControlMode",StringValue("OfdmRate6Mbps"));
//begin QoS STA supported
mesh.SetMacType("QosSupported",BooleanValue(true));
//end configuration
mesh.SetMacType ("RandomStart", TimeValue (Seconds (m_randomStart)));
// Set number of interfaces - default is single-interface mesh point
mesh.SetNumberOfInterfaces (m_nIfaces);
// Install protocols and return container if MeshPointDevices
meshDevices = mesh.Install (wifiPhy, nodes);
// Setup mobility - static grid topology
//begin personzalized mesh nodes position
ListPositionAllocator myListPositionAllocator;
//node 0
Vector3D n_pos_0 (130.0, 0.0, 0.0);
myListPositionAllocator.Add(n_pos_0);
//node 1
Vector3D n_pos_1 (130.0, 90.0, 0.0);
myListPositionAllocator.Add(n_pos_1);
//node 2
Vector3D n_pos_2 (0.0, 160.0, 0.0);
myListPositionAllocator.Add(n_pos_2);
//node 3
Vector3D n_pos_3 (40.0, 160.0, 0.0);
myListPositionAllocator.Add(n_pos_3);
//node 4
Vector3D n_pos_4 (130.0, 160.0, 0.0);
myListPositionAllocator.Add(n_pos_4);
//node 5
Vector3D n_pos_5 (200.0, 160.0, 0.0);
myListPositionAllocator.Add(n_pos_5);
//node 6
Vector3D n_pos_6 (260.0, 160.0, 0.0);
myListPositionAllocator.Add(n_pos_6);
//node 7
Vector3D n_pos_7 (130.0, 230.0, 0.0);
myListPositionAllocator.Add(n_pos_7);
//node 8
Vector3D n_pos_8 (130.0, 310.0, 0.0);
myListPositionAllocator.Add(n_pos_8);
//end configuration
MobilityHelper mobility;
mobility.SetPositionAllocator(&myListPositionAllocator);
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (nodes);
- 140 -
if (m_pcap)
wifiPhy.EnablePcapAll (std::string ("mp-"));
}
void
MeshTest::InstallInternetStack ()
{
InternetStackHelper internetStack;
internetStack.Install (nodes);
Ipv4AddressHelper address;
address.SetBase ("10.1.1.0", "255.255.255.0");
interfaces = address.Assign (meshDevices);
}
void
MeshTest::InstallApplication ()
{
//Server Side --> Node 8
UdpServerHelper server_8 (3999);
ApplicationContainer Sapps_8 = server_8.Install (nodes.Get(8));
Sapps_8.Start (Seconds (0.0));
Sapps_8.Stop (Seconds (51.0*a));
//Client Side --> Nodeo GW (4)
UdpClientHelper udpClient_4_8 (interfaces.GetAddress (8), 3999);
udpClient_4_8.SetAttribute ("MaxPackets", UintegerValue (100000000));
udpClient_4_8.SetAttribute ("Interval", TimeValue (Seconds (m_packetInterval)));
udpClient_4_8.SetAttribute ("PacketSize", UintegerValue (m_packetSize));
ApplicationContainer Capps_4_8_1 = udpClient_4_8.Install (nodes.Get(m_gwnode)) ;
Capps_4_8_1.Start (Seconds (8.5*a));
Capps_4_8_1.Stop (Seconds (13.5*a));
ApplicationContainer Capps_4_8_2 = udpClient_4_8.Install (nodes.Get(m_gwnode)) ;
Capps_4_8_2.Start (Seconds (21.0*a));
Capps_4_8_2.Stop (Seconds (26.0*a));
ApplicationContainer Capps_4_8_3 = udpClient_4_8.Install (nodes.Get(m_gwnode)) ;
Capps_4_8_3.Start (Seconds (33.5*a));
Capps_4_8_3.Stop (Seconds (38.5*a));
ApplicationContainer Capps_4_8_4 = udpClient_4_8.Install (nodes.Get(m_gwnode)) ;
Capps_4_8_4.Start (Seconds (46.0*a));
Capps_4_8_4.Stop (Seconds (51.0*a));
//Server Side---> Node 2
UdpServerHelper server_2 (3999);
ApplicationContainer Sapps_2 = server_2.Install (nodes.Get(2));
Sapps_2.Start (Seconds (0.0));
Sapps_2.Stop (Seconds (51.0*a));
//Client Side
UdpClientHelper udpClient_4_2 (interfaces.GetAddress (2), 3999);
udpClient_4_2.SetAttribute ("MaxPackets", UintegerValue (100000000));
udpClient_4_2.SetAttribute ("Interval", TimeValue (Seconds (m_packetInterval)));
udpClient_4_2.SetAttribute ("PacketSize", UintegerValue (m_packetSize));
ApplicationContainer Capps_4_2_1 = udpClient_4_2.Install (nodes.Get(m_gwnode)) ;
Capps_4_2_1.Start (Seconds (1.0*a));
Capps_4_2_1.Stop (Seconds (6.0*a));
ApplicationContainer Capps_4_2_2 = udpClient_4_2.Install (nodes.Get(m_gwnode)) ;
Capps_4_2_2.Start (Seconds (11.0*a));
Capps_4_2_2.Stop (Seconds (13.5*a));
ApplicationContainer Capps_4_2_3 = udpClient_4_2.Install (nodes.Get(m_gwnode)) ;
Capps_4_2_3.Start (Seconds (18.5*a));
Capps_4_2_3.Stop (Seconds (21.0*a));
ApplicationContainer Capps_4_2_4 = udpClient_4_2.Install (nodes.Get(m_gwnode)) ;
Capps_4_2_4.Start (Seconds (26.0*a));
Capps_4_2_4.Stop (Seconds (31.0*a));
- 141 -
ApplicationContainer Capps_4_2_5 = udpClient_4_2.Install (nodes.Get(m_gwnode)) ;
Capps_4_2_5.Start (Seconds (36.0*a));
Capps_4_2_5.Stop (Seconds (38.5*a));
ApplicationContainer Capps_4_2_6 = udpClient_4_2.Install (nodes.Get(m_gwnode)) ;
Capps_4_2_6.Start (Seconds (43.5*a));
Capps_4_2_6.Stop (Seconds (46.0*a));
//Server Side---> Node 6
UdpServerHelper server_6 (3999);
ApplicationContainer Sapps_6 = server_6.Install (nodes.Get(6));
Sapps_6.Start (Seconds (0.0));
Sapps_6.Stop (Seconds (51.0*a));
//Client Side
UdpClientHelper udpClient_4_6 (interfaces.GetAddress (6), 3999);
udpClient_4_6.SetAttribute ("MaxPackets", UintegerValue (100000000));
udpClient_4_6.SetAttribute ("Interval", TimeValue (Seconds (m_packetInterval)));
udpClient_4_6.SetAttribute ("PacketSize", UintegerValue (m_packetSize));
ApplicationContainer Capps_4_6_1 = udpClient_4_6.Install (nodes.Get(m_gwnode)) ;
Capps_4_6_1.Start (Seconds (3.5*a));
Capps_4_6_1.Stop (Seconds (8.5*a));
ApplicationContainer Capps_4_6_2 = udpClient_4_6.Install (nodes.Get(m_gwnode)) ;
Capps_4_6_2.Start (Seconds (16.0*a));
Capps_4_6_2.Stop (Seconds (21.0*a));
ApplicationContainer Capps_4_6_3 = udpClient_4_6.Install (nodes.Get(m_gwnode)) ;
Capps_4_6_3.Start (Seconds (28.5*a));
Capps_4_6_3.Stop (Seconds (33.5*a));
ApplicationContainer Capps_4_6_4 = udpClient_4_6.Install (nodes.Get(m_gwnode)) ;
Capps_4_6_4.Start (Seconds (41.0*a));
Capps_4_6_4.Stop (Seconds (46.0*a));
//Server Side---> Node 0
UdpServerHelper server_0 (3999);
ApplicationContainer Sapps_0 = server_0.Install (nodes.Get(0));
Sapps_0.Start (Seconds (0.0));
Sapps_0.Stop (Seconds (51.0*a));
//Client Side
UdpClientHelper udpClient_4_0 (interfaces.GetAddress (0), 3999);
udpClient_4_0.SetAttribute ("MaxPackets", UintegerValue (100000000));
udpClient_4_0.SetAttribute ("Interval", TimeValue (Seconds (m_packetInterval)));
udpClient_4_0.SetAttribute ("PacketSize", UintegerValue (m_packetSize));
ApplicationContainer Capps_4_0_1 = udpClient_4_0.Install (nodes.Get(m_gwnode)) ;
Capps_4_0_1.Start (Seconds (1.0*a));
Capps_4_0_1.Stop (Seconds (3.5*a));
ApplicationContainer Capps_4_0_2 = udpClient_4_0.Install (nodes.Get(m_gwnode)) ;
Capps_4_0_2.Start (Seconds (6.0*a));
Capps_4_0_2.Stop (Seconds (8.5*a));
ApplicationContainer Capps_4_0_3 = udpClient_4_0.Install (nodes.Get(m_gwnode)) ;
Capps_4_0_3.Start (Seconds (13.5*a));
Capps_4_0_3.Stop (Seconds (16.0*a));
ApplicationContainer Capps_4_0_4 = udpClient_4_0.Install (nodes.Get(m_gwnode)) ;
Capps_4_0_4.Start (Seconds (21.0*a));
Capps_4_0_4.Stop (Seconds (23.5*a));
ApplicationContainer Capps_4_0_5 = udpClient_4_0.Install (nodes.Get(m_gwnode)) ;
Capps_4_0_5.Start (Seconds (26.0*a));
Capps_4_0_5.Stop (Seconds (28.5*a));
ApplicationContainer Capps_4_0_6 = udpClient_4_0.Install (nodes.Get(m_gwnode)) ;
Capps_4_0_6.Start (Seconds (31.0*a));
Capps_4_0_6.Stop (Seconds (33.5*a));
ApplicationContainer Capps_4_0_7 = udpClient_4_0.Install (nodes.Get(m_gwnode)) ;
Capps_4_0_7.Start (Seconds (38.5*a));
Capps_4_0_7.Stop (Seconds (41.0*a));
- 142 -
ApplicationContainer Capps_4_0_8 = udpClient_4_0.Install (nodes.Get(m_gwnode)) ;
Capps_4_0_8.Start (Seconds (46.0*a));
Capps_4_0_8.Stop (Seconds (48.5*a));
}
int
MeshTest::Run ()
{
CreateNodes ();
InstallInternetStack ();
PopulateArpCache ();
InstallApplication ();
Simulator::Schedule (Seconds (51*a), &MeshTest::Report, this);
std::ostringstream oss;
std::ostringstream oss2;
std::ofstream ofile;
//bool managed=true;//true
//double pl=0.001;//0.00001
double w=0.001;
double tu=0.01;
double td=0.1;
// ALL MESH NODES //
for (uint32_t i=0;i<=((uint32_t)nodes.GetN())-1;i++) {
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/MacTx";
Config::Connect (oss.str(), MakeCallback(&MacTxCallback));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac <<"_EdcaTxopN/Queue/Enqueue";
Config::Connect (oss.str(), MakeCallback(&EnqueueCallback));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac <<"_EdcaTxopN/Queue/Dequeue";
Config::Connect (oss.str(), MakeCallback(&DequeueCallback));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac <<"_EdcaTxopN/Queue/Drop";
Config::Connect (oss.str(), MakeCallback(&DropCallback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/TxOkHeader";
Config::Connect (oss.str(), MakeCallback(&TxOkHeaderCallback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/TxErrHeader";
Config::Connect (oss.str(), MakeCallback(&TxErrHeaderCallback));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Phy/PhyTxBegin";
Config::Connect (oss.str(), MakeCallback(&PhyTxBeginCallback));
oss.str("");
oss << "/NodeList/" << i <<
"/DeviceList/1/$ns3::WifiNetDevice/RemoteStationManager/$ns3::ConstantRateWifiManager/DataMode";
Config::Set (oss.str(), StringValue("OfdmRate6Mbps"));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac <<"_EdcaTxopN/IsQueueSizeManaged";
Config::Set (oss.str(), BooleanValue(m_managed));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/LossProbability";
Config::Set (oss.str(), DoubleValue(m_pl));
oss.str("");
- 143 -
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/Weight";
Config::Set (oss.str(), DoubleValue(w));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/ThresholdUp";
Config::Set (oss.str(), DoubleValue(tu));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/ThresholdDown";
Config::Set (oss.str(), DoubleValue(td));
oss.str("");
oss2.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac <<"_EdcaTxopN/AvailableMemoryFile";
oss2 << "M_availableMemory_" << i << ".txt";
ofile.open((oss2.str()).c_str());
ofile << "0" << "\n";
ofile.close();
Config::Set (oss.str(), StringValue(oss2.str()));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/Queue/MaxPacketNumber";
Config::Set (oss.str(), UintegerValue(m_qInit));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/QueueSizeUpdated_1";
Config::Connect (oss.str(), MakeCallback(&QueueSizeUpdated_1Callback));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/QueueSizeUpdated_2";
Config::Connect (oss.str(), MakeCallback(&QueueSizeUpdated_2Callback));
oss.str("");
oss << "/NodeList/" << i << "/DeviceList/1/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/"<<
m_ac << "_EdcaTxopN/QueueSizeUpdated_3";
Config::Connect (oss.str(), MakeCallback(&QueueSizeUpdated_3Callback));
}
//END
//begin FlowMonitor configuration
Ptr<FlowMonitor> flowMon;
FlowMonitorHelper flowMonHelper;
flowMon = flowMonHelper.InstallAll();
//end configuration
Simulator::Stop (Seconds (51*a));//5100 sec
Simulator::Run ();
//begin for save different flow monitor
stringstream pl;
pl << m_pl;
string plstr = pl.str();
nameflow="mesh_scenario2_proactive_Flow_"+m_ac+"_"+plstr+".xml";
flowMon->SerializeToXmlFile(nameflow, true, true);
//end configuration
Simulator::Destroy ();
return 0;
}
void
MeshTest::Report ()
{
unsigned n (0);
for (NetDeviceContainer::Iterator i = meshDevices.Begin (); i != meshDevices.End (); ++i, ++n)
{
std::ostringstream os;
os << "mp-report-sce2-" << n << ".xml";
std::cerr << "Printing mesh point device #" << n << " diagnostics to " << os.str () << "\n";
std::ofstream of;
of.open (os.str ().c_str ());
if (!of.is_open ())
- 144 -
{
std::cerr << "Error: Can't open file " << os.str () << "\n";
return;
}
mesh.Report (*i, of);
of.close ();
}
}
//begin_code for pre-polulate ARP cache (From google groups Pavel Boyko)
void
MeshTest::PopulateArpCache ()
{
Ptr<ArpCache> arp = CreateObject<ArpCache> ();
arp->SetAliveTimeout (Seconds(3600 * 24 * 365));
for (NodeList::Iterator i = NodeList::Begin(); i != NodeList::End(); ++i)
{
Ptr<Ipv4L3Protocol> ip = (*i)->GetObject<Ipv4L3Protocol> ();
NS_ASSERT(ip !=0);
ObjectVectorValue ifcs;
ip->GetAttribute("InterfaceList", ifcs);
for(ObjectVectorValue::Iterator j = ifcs.Begin(); j != ifcs.End (); j ++)
{
Ptr<Ipv4Interface> ipIface = (*j)->GetObject<Ipv4Interface> ();
NS_ASSERT(ipIface != 0);
Ptr<NetDevice> device = ipIface->GetDevice();
NS_ASSERT(device != 0);
Mac48Address addr = Mac48Address::ConvertFrom(device->GetAddress ());
for(uint32_t k = 0; k < ipIface->GetNAddresses (); k ++)
{
Ipv4Address ipAddr = ipIface->GetAddress (k).GetLocal();
if(ipAddr == Ipv4Address::GetLoopback())
continue;
ArpCache::Entry * entry = arp->Add(ipAddr);
entry->MarkWaitReply(0);
entry->MarkAlive(addr);
}
}
}
for (NodeList::Iterator i = NodeList::Begin(); i != NodeList::End(); ++i)
{
Ptr<Ipv4L3Protocol> ip = (*i)->GetObject<Ipv4L3Protocol> ();
NS_ASSERT(ip !=0);
ObjectVectorValue interfaces;
ip->GetAttribute("InterfaceList", interfaces);
for(ObjectVectorValue::Iterator j = interfaces.Begin(); j != interfaces.End (); j ++)
{
Ptr<Ipv4Interface> ipIface = (*j)->GetObject<Ipv4Interface> ();
ipIface->SetAttribute("ArpCache", PointerValue(arp));
}
}
}
int
main (int argc, char *argv[])
{
MeshTest t;
LogComponentEnable ("UdpClient", LOG_LEVEL_INFO);
LogComponentEnable ("UdpServer", LOG_LEVEL_INFO);
t.Configure (argc, argv);
return t.Run ();
}
- 145 -
Appendix B
Python Script: For T Computation
- 146 -
- 147 -
References
[1] Guido R. Hiertz, Sebastian Max, Yunpeng Zang, Thomas Junge and Dee Denteneert,
“IEEE802.11s MAC Fundamentals”, in IEEE International Conference on Mobile Adhoc and
Sensor Systems MASS 2007.
[2] G. Hiertz, S. Max, R. Zhao, D. Denteneer, and L. Berlemann, “Principles of IEEE 802.11s” in
Proc. ICCCN, Aug. 2007, pp. 1002–1007.
[3] Md. Shariful Islam, Muhammad Mahbub Alam, Choong Seon Hong, and Sungwon Lee,
“eMCCA: An Enhanced Mesh Coordinated Channel Access Mechanism for IEEE 802.11s
Wireless Mesh Networks” in Journal of Communications and Networks, vol 13, no. 6, Dec.
2011, pp. 639-654.
[4] Fan Ning and Yalong Wang, “A New Adaptive EDCA Scheme for Improving the Performance
of IEEE 802.11s Network” in Engineering and Technology (S-CET), May. 2012.
[5] Romdhani, L; Qiang Ni; Turletti, T. “Adaptive EDCF: Enhanced Service Differentiation for
IEEE 802.11 Wireless Ad-hoc Networks”, in IEEE Wireless Communications and Networking,
Conference , March 2003 ,Vol.2:16-20.
[6] Jelena Tomi ´c and Nataša Neškovi´c, “An analysis of medium access control in IEEE 802.11s
networks”, in Telecommunication Forum (TELFOR), 22-24 Nov. 2011, pp. 513-516.
[7] J. Bicket, D. Aguayo, S. Biswas, and R. Morris, “Architecture and Evaluation of an Unplanned
802.11b Mesh Network,” in MobiCom ’05: Proceedings of the 11th annual international
conference on Mobile computing and networking, Association for Computing Machinery
Special Interest Group on Mobility of Systems, Users, Data and Computing. New York, NY,
USA: ACM Press, 2005, pp. 31–42.
[8] G. Anastasi, M. Conti, and M. Gregori, “IEEE 802.11 Ad Hoc Networks: Protocols,
Performance and Open Issues”. in Mobile Ad Hoc Networking, S. Basagni, M. Conti, S.
Giordano, and I. Stojmenovic, Eds. Wiley, Aug. 2004, p. 480.
[9] G. Anastasi, E. Borgia, M. Conti, and E. Gregori, “Wi-fi in ad hoc mode: a measurement
study,” in Pervasive Computing and Communications, 2004. PerCom 2004. Proceedings of the
Second IEEE Annual Conference on, 2004, pp. 145–154.
[10] Ricardo C. Carrano, Luis C.S. Magalhaes, and Débora C. Machaluat,“IEEE 802.11s
Multihop MAC: A Tutorial”, in IEEE Communications survey & Tutorials, VOl. 13, No.1,
2011, pp.52-67.
[11] IEEE 802.11standard, http://standards.ieee.org/about/get/802/802.11.html
[12] Andrés Vázquez Rodas, Luis J. de la Cruz, Monica Aguilar and Emilio Sanvicente,
“Dimensionado dinámico de buffers para flujos de tráfico diferenciados no elásticos”, Jornadas
de Ingeniería Telemática JITEL 2013, Granada, octubre 2013, ISBN: 978-84-616-5597-7
- 148 -
[13] J. Gettys and K. Nichols, “Bufferbloat dark buffers in the internet”, Communications of the
ACM, vol 55, n. 1, 2012, pp. 57-65.
[14] Kirill Andrev and Pabel Boyko, “Simulation Study of VoIP Performance in IEEE 802.11
Wireless Mesh Networks”, MACOM 2010, pp. 139-150.
[15] Kirill Andrev and Pabel Boyko, “IEEE 802.11s Mesh Networking NS-3 Model”
[16] Mansour J. Karam, Fouad A. T obag, “On Traffic T ypes and Service Classes in the
Internet”, in Global Telecommunications Conference, 2000. GLOBECOM '00. IEEE (Volume:1
),2000, pp. 548-554.
[17] C. Shannon and W. Weaver, The Mathematical Theory of Communication, University of
Illinois Press, 1972.
[18] T.M. Cover and J.A. Thomas, Elements of Information Theory, John Wiley, 1991.
[19] R.K. Sundaram, A First Course in Optimization Theory, Cambridge University Press, 1996.
[20] E.C. Molina, The theory of probability applied to telephone trunking problems, The Bell
System Technical Journal, 1(2):69–81, (1922).
[21] W.E. Leland, M.S. Taqqu, W. Willinger, D.V. Wilson, On the self-similar nature of Ethernet
traffic (extended version), Networking IEEE/ACM Transactions on, vol.2, no.1, pp.1-15, 1994.
[22] M. Fras, J. Mohorko, Z. Cucej, Packet size process modeling of measured self-similar
network traffic with defragmentation method, Systems, Signals and Image Processing, 2008.
IWSSIP 2008. 15th International Conference on, vol., no., pp.253-256, 2008.
[23] Z. Sahinoglu, S. Tekinay, On multimedia networks: self-similar traffic and network
performance, Communications Magazine, IEEE, vol.37, no.1, pp.48-52, 1999.
[24] L.J. de la Cruz, E. Pallares, J.J. Alins, J. Mata, Self-similar traffic generation using a
fractional ARIMA model. Application to the VBR MPEG video traffic, Telecommunications
Symposium, 1998. ITS '98 Proceedings. SBT/IEEE International, vol., no., pp.102-107 vol.1, 9-
13, 1998.
[25] B.K. Ryu and A. Elwalid, The importance of long-range dependence of VBR video traffic
in ATM traffic engineering: myths and realities, SIGCOMM Comput. Commun. Rev. 26, 4, pp.
3-14, 1996.
[26] T.G. Robertazzi, Computer networks and systems: queueing theory and performance
evaluation, Springer-Verlag New York Incorporated, Third Ed., 2000.
[27] Thomas R. Henderson. ns-3 tutorial. Presentation at WNS3 ’09: Workshop on ns-3 in
conjunction with SIMUTools ’09, March 2009. http://www.nsnam.org/workshops/wns3-2009/
ns-3-tutorial-part-1.pdf.
[28] ns-3 Model Library, Release ns-3.16, December 2012.
http://www.nsnam.org/docs/release/3.16/models/ns-3-model-library.pdf
- 149 -
[29] Marc Esquius Morote, “IEEE 802.11s Mesh Networking Evaluation unde NS-3”, Final
Degree Project, Universitat Politècnica de Catalunya, Abril 2011.
[30] www.nsnam.org
[31] NS-3 doxygen documentation, www.nsnam.org/doxygen-release/index.html."
[32] Timo Bingmann, “Accuracy Enhancements of the 802.11 Model and EDCA QoS
Extensions in ns-3”, Diploma Thesis, University of Karlsruhe, Abril 2009.
[33] A. Vasan, R. Ramjee, and T. Woo, “Echos – enhanced capacity 802.11 hotspots”, in
INFOCOM 2005,24th
Annual Joint Conference of the IEEE Computer and Communication
Societies. Proceedings IEEE,vol. 3, 13-17 March 2005, pp. 1562 – 1572, vol. 3.
[34] A. P. Jardosh, K. N. Ramachandran, K. C. Almeroth, and E. M. Belding-Royer,
“Understanding Congestion in IEEE 802.11b Wireless Networks”, in Proceedings of the IMC
’05, 2005 Internet Measurement Conference, ACM SIGCOMM. USENIX, Oct. 2005, pp. 279–
292. [Online]. Available: http://www.usenix.org/events/imc05/tech/jardosh.htm
[35] IITP RAS Institute: http://www.iitp.ru/en/about
- 150 -
- 151 -
List of Figures
Fig.1. Flow chart for CSMA/CA .......................................................................................................................... 13
Fig.2. CSMA/CA Example .................................................................................................................................. 14
Fig.3. Flow chart for CSMA/CA with RTS/CTS...................................................................................................... 16
Fig.4. CSMA with RTS/CTS Example ................................................................................................................... 16
Fig.5. Example of Fragmentation using CSMA with RTS/CTS ................................................................................... 16
Fig.6. Interframe Space (IFS) [32] ........................................................................................................................ 18
Fig.7. EDCA Queues [32] ................................................................................................................................... 19
Fig.6. Inefficient medium usage problem with Energy Detection (ED) range [2]. ............................................................ 20
Fig.7. Typical architecture of the IEEE 802.11s WMN [3] ........................................................................................ 22
Fig.8. WMN routers provide a wireless backhaul that interconnects wired and wireless stations [10] ................................ 22
Fig. 9. The establishment of a peer link in 802.11s [10]............................................................................................ 24
Fig.10. IEEE 802.11s internetworking scenarios [10] ............................................................................................... 25
Fig. 11. HWMP on-demand route discovery. .......................................................................................................... 27
Fig. 12. HWMP proactive route discovery using “Proactive PREQ” mechanism [10]. .................................................... 28
Fig. 13. Pictorial definition of t(i) and Bt . ............................................................................................................ 31
Fig. 14. Pictorial definition of na(i) and nd(i). ......................................................................................................... 31
Fig. 15. Calculation of β................................................................................................................................... 36
Fig. 16. Probabilities of packets in the system, p(i), and probabilities seen by arrivals, a(i), with infinite queue size............ 39
Fig. 17. Probabilities seen by arrivals, aQ(i), with finite queue size (Q = 11). ............................................................... 41
Fig. 18. Packet loss probability vs. buffer size. ...................................................................................................... 42
Fig. 19. Buffer size vs. packet loss probability. ...................................................................................................... 42
Fig. 20. Packet loss probability vs. buffer size using the three models ( = 0.6). .......................................................... 43
Fig. 21. Buffer size vs. packet loss probability using the three models (= 0.6). .......................................................... 43
Fig. 22. Ns-3 node architecture [27] .................................................................................................................... 44
Fig. 24. UML diagram of core mesh classes [15] ..................................................................................................... 48
Fig. 25. Caller graph for MAC IEEE 802.11 classes in ns-3 ...................................................................................... 49
Fig. 26. Caller graph for STA and mesh STA functions that use DCF and EDCAF. ....................................................... 50
Fig. 27. Scenario-1 ns-3 simulation topology ........................................................................................................ 52
Fig. 28. Activation pattern for scenario 2 nodes. .................................................................................................... 52
Fig. 29. Average Channel Occupancy for scenario 3 nodes. (a) WLAN1 nodes; (b) WLAN2 nodes. ................................. 54
Fig. 30. Buffer size for the N0 node configured with three different PL target values. .................................................... 55
Fig. 31. Buffer Size vs. Buffer Occupancy for the Interface 2 of the N0 node with target L
P =1E-3. ................................ 56
Fig. 32. pmf for random variable d computed in the N0 node with static buffer allocation. .............................................. 58
Fig. 33. pmf for random variable d computed in the N0 node with dynamic buffer allocation. .......................................... 58
Fig. 34.Flow chart of packet transmission in 802.11 ns-3 implementation .................................................................... 61
Fig. 35. Delay p.d.f. for Dynamic Queue Size - Node 4 Interface 1 with target L
P =1E-3 .............................................. 62
Fig 36. Delay p.d.f. for Static Queue Size - Node 4 Interface 1 with target L
P =1E-3 ................................................... 62
Fig 37. Delay p.d.f. for Dynamic Queue Size - Node 4 Interface 1 with target L
P =1E-4 ............................................... 62
Fig. 38. Delay p.d.f. for Static Queue Size - Node 4 Interface 1 with target L
P =1E-4 .................................................. 63
Fig. 39. Delay p.d.f. for Dynamic Queue Size - Node 4 Interface 1 with target L
P =1E-5 ............................................... 63
Fig 40. Delay p.d.f. for Static Queue Size - Node 4 Interface 1 with target L
P =1E-5 ................................................... 63
Fig. 41. Scenario-2: Mesh Chain Topology ........................................................................................................... 66
- 152 -
Fig. 42. Offered Load Diagram ............................................................................................................................. 67
Fig. 43. PLR vs Number of hops in static queue size. .............................................................................................. 70
Fig. 44. End-to-end packet loss versus number of hops. ......................................................................................... 79
Fig. 45. End-to-end delay versus number of hops. ................................................................................................. 79
Fig. 46. Average Channel utilization for different number of hops and Target L
P =1E-3. ................................................ 80
Fig. 47. Buffer Size for different number of hops and Target L
P =1E-3. ....................................................................... 81
Fig. 48.Buffer Size for 1x4 chain topology and different target L
P . ............................................................................. 81
Fig. 49.Buffer Size utilization for 1x4 chain topology and different target L
P . .............................................................. 82
Fig. 50.Average Channel utilization for different number of hops and Target L
P =1E-3. ................................................. 82
Fig. 51.Buffer Size for different number of hops and Target L
P =1E-3. ........................................................................ 83
Fig. 52.Buffer Size for 1x4 chain topology and different target L
P . ............................................................................. 83
Fig. 53.Buffer Size utilization for 1x4 chain topology and different target L
P . .............................................................. 83
Fig. 54.Node 0 Delay p.d.f. with Dynamic Queue Size for BE traffic and target L
P =1E-3 ............................................... 84
Fig. 55.Node 0 Delay p.d.f. with Dynamic Queue Size for VO traffic and target L
P =1E-3 .............................................. 84
Fig. 56.Service Time p.d.f. with N=1.3602 for 1x5 Mesh Topology and VO traffic ......................................................... 86
Fig. 57.Service Time p.d.f. with N=3.3406 for 1x5 Mesh Topology and VO traffic. ........................................................ 87
Fig. 58.Avg. channel utilization for 1x6 mesh topology, VO traffic, and Target L
P =1E-3 with Infinite Buffer Size. .............. 89
Fig. 59.Avg. channel utilization for 1x6 mesh topology, VO traffic, and Target L
P =1E-3 with Finite Buffer Size Qmax=5. ... 90
Fig. 60.Buffer utilization for 1x6 mesh topology, VO traffic, and Target L
P =1E-3 with Infinite Buffer Size. ....................... 90
Fig. 61.Buffer utilization for 1x6 mesh topology, VO traffic, and Target L
P =1E-3 with Infinite Buffer Size (zoom version). .. 90
Fig. 62.Buffer utilization for 1x6 mesh topology, VO traffic, and Target L
P =1E-3 Finite Buffer Size Qmax=5. ................... 91
Fig. 63.Avg. channel utilization for 1x7 mesh topology, VO traffic, and Target L
P =1E-3 with Infinite Buffer Size. .............. 91
Fig. 64.Avg. channel utilization for 1x7 mesh topology, VO traffic, and Target L
P =1E-3 with Finite Buffer Size Qmax=5. .. 91
Fig. 65.Buffer utilization for 1x7 mesh topology, VO traffic, and Target L
P =1E-3 with Infinite Buffer Size. ....................... 92
Fig. 66.Buffer utilization for 1x7 mesh topology, VO traffic, and Target L
P =1E-3 Finite Buffer Size Qmax=5. ................... 92
Fig. 67.Mesh network topology for scenario-3. ....................................................................................................... 93
Fig. 68.GW Traffic pattern and Activation/Deactivation pattern of intermediate nodes .................................................. 94
(a) Fig. 69.Node GW Delay p.d.f. with Dynamic Queue Size for AC_BE traffic and target L
P =1E-3 ................................ 100
(b) Fig. 69.Node GW Delay p.d.f. with Static Queue Size for AC_BE traffic and target L
P =1E-3 .................................... 100
(a) Fig. 70.Node GW Delay p.d.f. with Dynamic Queue Size for AC_VO traffic and target L
P =1E-3 ................................ 101
(b) Fig. 70.Node GW Delay p.d.f. with Static Queue Size for AC_VO traffic and target L
P =1E-3 ................................... 101
Fig. 71.Average Channel utilization in scenario-3 for AC_BE and AC_VO and Target L
P =1E-3. .................................... 101
Fig. 72.Buffer Size in scenario-3 for different Target L
P and AC_BE ......................................................................... 101
Fig. 73.Buffer Size utilization in scenario-3 for Target L
P =1E-3 and AC_BE .............................................................. 102
Fig. 74.Buffer Size utilization in scenario-3 for Target L
P =1E-3 and AC_BE (zoomed version) ...................................... 102
Fig. 75.Buffer Size in scenario-3 for different Target L
P and AC_VO ........................................................................ 102
Fig. 76.Buffer Size utilization in scenario-3 for Target L
P =1E-3 and AC_VO .............................................................. 103
(a) Fig. 77.Node GW Delay p.d.f. with Dynamic Queue Size for AC_BE traffic and target L
P =1E-3 ................................ 106
(b) Fig. 77.Node GW Delay p.d.f. with Static Queue Size for AC_BE traffic and target L
P =1E-3 .................................... 106
- 153 -
Fig. 78.Average Channel utilization in scenario-3 for AC_BE and Target L
P =1E-3. ..................................................... 107
Fig. 79.Buffer Size in scenario-3 for different Target L
P and AC_BE ......................................................................... 107
Fig. 80.Buffer Size utilization in scenario-3 for Target L
P =1E-3 and AC_BE .............................................................. 107
- 154 -
List of Tables
Table 1. Relevant parameters for IEEE 802.11 CSMA/CA ........................................................................................ 15
Table 2. Standard EDCA Parameters [6] ............................................................................................................... 18
Table 3. Suggested mapping of the traffic types to available traffic classes in IEEE 802.1D ........................................... 19
Table 4. Airtime Link Metric constants ................................................................................................................. 29
Table 5. Traffic configuration parameters ............................................................................................................... 39
Table 6. Traffic streams (packet length) ................................................................................................................. 41
Table 7. Traffic streams (interarrival time) ............................................................................................................. 41
Table 8. Data used in simulation for chain mesh topology and Static buffer size ............................................................ 52
Table 9. ns-3 mac/phy parameters used in simulations............................................................................................. 53
Table 10. Memory efficiency comparison for the two interfaces-node configured with Static vs. Dynamic buffer size............ 57
Table 11. Mean difference between the buffer size and the buffer occupancy ................................................................ 59
Table 12. Different time delays for Dynamic and Static buffer size in scenario-1 ........................................................... 64
Table 13. Data used in simulation for chain mesh topology and Static buffer size .......................................................... 66
Table 14. Static_Q: Measured L
P for 1x2 mesh topoly ............................................................................................. 68
Table 15. Static_Q: Measured L
P for 1x3 mesh topoly ............................................................................................. 68
Table 16. Static_Q: Measured L
P for 1x4 mesh topoly ............................................................................................. 68
Table 17. Static_Q : Measured L
P for 1x5 mesh topoly ............................................................................................ 68
Table 18. Static_Q: Measured L
P for 1x6 mesh topoly ............................................................................................. 68
Table 19. Static_Q: Measured L
P for 1x7 mesh topoly ............................................................................................. 69
Table 20. Static_Q: summary of Measured end-to-end LP for chain mesh topoly .......................................................... 69
Table 21. Data used in simulation for chain mesh topology and Dynamic buffer size ....................................................... 70
Table 22. ns-3: MAC(ieee 802.11s)/PHY parameters used in simulation ..................................................................... 71
Table 23. Dynamic_Q: Measured L
P and t for 1x2 mesh topoly ................................................................................. 72
Table 24. Dynamic_Q: Measured L
P and t for 1x2 mesh topoly ................................................................................. 72
Table 25. Dynamic_Q: Measured L
P and t for 1x3 mesh topoly ................................................................................. 72
Table 26. Dynamic_Q: Measured L
P and t for 1x3 mesh topoly ................................................................................. 73
Table 27. Dynamic_Q: Measured L
P and t for 1x4 mesh topoly ................................................................................. 73
Table 28. Dynamic_Q: Measured L
P and t for 1x4 mesh topoly ................................................................................. 73
Table 29. Dynamic_Q: Measured L
P and t for 1x5 mesh topoly ................................................................................. 74
Table 30. Dynamic_Q: Measured L
P and t for 1x5 mesh topoly ................................................................................. 74
Table 31. Dynamic_Q: Measured L
P and t for 1x6 mesh topoly ................................................................................. 74
Table 32. Dynamic_Q: Measured L
P and t for 1x6 mesh topoly ................................................................................. 75
Table 33. Dynamic_Q: Measured L
P and t for 1x7 mesh topoly ................................................................................. 75
Table 34. Dynamic_Q: Measured L
P and t for 1x7 mesh topoly .................................................................................. 75
Table 35. Dynamic_Q: Measured L
P for 1x8 mesh topoly ........................................................................................ 76
Table 36. Dynamic_Q: Measured LP for 1x8 mesh topoly ......................................................................................... 76
Table 37. Dynamic_Q: Measured L
P for 1x9 mesh topoly ........................................................................................ 77
Table 38. Dynamic_Q: Measured L
P for 1x9 mesh topoly ........................................................................................ 77
- 155 -
Table 39. Dynamic_Q: summary of Measured end-to-end L
P and tee for chain mesh topoly ........................................... 78
Table 40. Dynamic_Q: summary of Measured end-to-end L
P and tee for chain mesh topoly ........................................... 78
Table 41 . delay and mean no. of transmissions for 1x5 mesh topoly and AC_VO with target L
P =1e-3 ............................. 86
Table 42. delay and mean no. of transmissions for 1x5 mesh topoly and AC_VO with target L
P =1e-3 .............................. 86
Table 43. Measured L
P for AC_VO with infinite and finite buffer size ......................................................................... 88
Table 44. Measured L
P for AC_VO with infinite and finite buffer size ......................................................................... 88
Table 45. summary of Measured en-to-end L
P for AC_VO with infinite and finite buffer size .......................................... 88
Table 47. ns-3: mac(ieee 802.11s)/phy parameters used in simulation ........................................................................ 94
Table 48. Measured L
P and mean end-to-end delay for AC_BE and target L
P =1e-3 .................................................... 95
Table 49. Measured L
P and mean end-to-end delay for AC_VO and target L
P =1e-3 .................................................... 96
Table 50. Measured L
P and mean end-to-end delay for AC_BE and target L
P =1e-4 .................................................... 97
Table 51. Measured L
P and mean end-to-end delay for AC_VO and target L
P =1e-4 .................................................... 98
Table 52. Measured mean transfer time for AC_BE and target L
P =1e-3 ...................................................................... 99
Table 53. Measured mean transfer time for AC_VO and target L
P =1e-3 ..................................................................... 99
Table 54. Memory efficiency comparison for the two ac configured with Static vs. Dynamic buffer size ............................. 104
Table 55. Mean difference between the buffer size and the buffer utilization ................................................................ 104
Table 56. Measured L
P and mean end-to-end delay for ac_be and target L
P =1e-3 ...................................................... 105
Table 57. Measured L
P and mean end-to-end delay for AC_BE and target L
P =1e-4 ................................................... 105
Table 58. Measured mean transfer time for AC_BE and target L
P =1e-3 ..................................................................... 106
