Vous êtes sur la page 1sur 7

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/303513195

Completing IEEE 802.11e implementation in NS-3

Conference Paper · April 2016


DOI: 10.1109/IACS.2016.7476109

CITATIONS READS

2 231

3 authors:

Islam Obaidat Mohammad Alsmirat


University of North Carolina at Charlotte Jordan University of Science and Technology
6 PUBLICATIONS   69 CITATIONS    39 PUBLICATIONS   162 CITATIONS   

SEE PROFILE SEE PROFILE

Yaser Jararweh
Jordan University of Science and Technology
207 PUBLICATIONS   1,514 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Aspect-Based Sentiment Analysis in Arabic Texts View project

A Novel Framework for Secure Cryptosystems against Side Channel Attacks View project

All content following this page was uploaded by Yaser Jararweh on 11 October 2017.

The user has requested enhancement of the downloaded file.


Completing IEEE 802.11e Implementation in NS-3
Islam Obaidat, Mohammad Alsmirat, and Yaser Jararweh
Computer Science Department,
Jordan University of Science and Technology,
Email: iaobaidat13@cit.just.edu.jo, {masmirat, yijararweh}@just.edu.jo

Abstract—Since IEEE 802.11 standard first released, it gained Usually, in order to test and verify any new network
a worldwide attention. As a result, a huge variety of devices solution, a real implementation (A hardware testbed) would
have implemented it. IEEE 802.11e standard was developed as be required. Also, accurate measurement capturing tools would
an amendment to the original 802.11 standard to provide QoS
support. Several simulators provides an implementation for this be required as well. In most cases, such hardware tests require
standard in order to study and analyze its performance. NS- a decent budget, not to mention the difficult experiment setup
3 simulator implements IEEE 802.11e, but unfortunately, we and the complex extraction of the desired measurements which
found that the implementation is not complete. In this work, may lead to incorrect results. Network simulators are usually
we complete the implementation of the IEEE 802.11e in NS-3. used to solve those problems. Simulators usually provide an
acceptable level of accuracy in the results with minimal testing
I. I NTRODUCTION effort.
Several network simulators are available. Among them, NS-
Nowadays, very large percentage of data communications 3 [5] and OPNET [6] simulators are the most common. NS-
approaches have converged toward wireless communication. 3 is an open source network simulator licensed under the
The IEEE 802.11 standard [1] is one of the most adopted GNU GPLv2 license. NS-3 development started initially in
wireless communication standards. It is commonly used for 2006 in order to be used for educational and network research
wireless local area networks (WLAN) in infrastructure mode purposes. OPNET is well known for its accuracy in modeling
due to its easy deployment and use. However, due to the the different components of the networks that it simulates.
characteristics of the wireless connections, wireless commu- Unfortunately, OPNET is a commercial simulator, which re-
nication sustains performance drawbacks. The IEEE 802.11 quires a license to be used. Academic users can acquire a free
thus, should provide appropriate wireless services to overcome license for only six months and the license then should be
these drawbacks, especially for time-sensitive applications. renowned. To acquire an academic license, a proposal should
The Wireless network connection should guarantee Quality of be sent to the OPNET Company. Upon completion of the
Service (QoS) for real time applications such as multimedia academic license, the accomplished code must be submitted to
applications. OPNET and they are free to incorporate it in the simulator. By
The IEEE 802.11 standard defines the Medium Access considering those limitations in OPNET, NS-3 provides a great
Control (MAC) and the physical layers. The MAC, in the alternative with high flexibility and portability. Moreover, NS-
standard, utilizes a Distributed Coordination Function (DCF) 3 provides vast of models for different network components
as one of its channel access method. DCF is a contention and protocols. Furthermore, lots of effort is invested in NS-
based mechanism that does not provide QoS for time sensitive 3 to enhance the current network modules and to implement
applications. The IEEE 802.11e [2] came out to address this new ones.
need. The IEEE 802.11e standard support QoS by providing 802.11 EDCA is fully implemented in OPNET. On the
the ability to prioritize traffic. Four types of traffic are distin- other hand, not all EDCA components are implemented in
guished: voice, video, best effort, and background. NS-3. NS-3 supports only the use of CWmin , CWmax , and
In the 802.11e, to support QoS, the modified MAC utilizes AIFS. TXOP is considered to be a main component for
an Enhanced Distributed Channel Access (EDCA) mechanism. EDCA but, unfortunately, it is not implemented in NS-31 .
EDCA is basically DCF that supports four different traffic In this work, we complete the NS-3 EDCA implementation
priorities. EDCA supports these priorities by varying four by implementing the TXOP full functionalities. In order to
main parameters: Contention Window Min (CWmin ), Con- implement TXOP in NS-3, many changes must be done to the
tention Window Max (CWmax ), Arbitration Inter Frame Space current implementation and many testing is needed to verify
(AIFS), and Transmission Opportunity duration (TXOP). With the implementation correctness.
EDCA, packets with different traffic types on the same node According to our knowledge, there are no researches in the
compete for the medium as if they are on separate nodes. literature that present any results of using a fully implemented
CWmin , CWmax , and AIF S control the frequency of trying EDCA in a hardware testbed. For this reason, the modified
to access the medium while TXOP controls for how long the
medium is held when an access is granted. EDCA is usually 1 https://www.nsnam.org/docs/models/html/wifi-design.html#
used for QoS purposes since it is flexible and simple [3], [4]. scope-and-limitations
NS-3 EDCA implementation is verified against the OPNET time, the backoff timer is decremented and a transmission retry
simulator implementation. occurs when the timer reaches 0.
The rest of this paper is organized as follows. Section II The values of a QoS-Parameter depends on the underlying
provides background information. Next to that, Section III physical layer used. Table I shows the standard QoS-Parameter
motivates the work done in this paper. Section IV presents values for different ACs in 802.11b and 802.11g standards.
the details of implementing the EDCA TXOP in NS-3. Next, Note that, the values of CWmin, CWmax and AIFSN are in
the evaluation methodology is detailed in Section V. Finally, time slots.
Section VI shows the main results. Two acknowledgment modes are supported in EDCA. The
first mode is known as intermediate acknowledgment. In
II. BACKGROUND I NFORMATION
which upon sending a packet, the sender waits for an ac-
A. IEEE 802.11 knowledgment in order to process the sending of the next
IEEE 802.11 standard was introduced by the IEEE com- packet. When the acknowledgment is received, the next packet
mittee for wireless communication standardization in 1999 is sent directly after Shot Frame Inter Space (SIFS) time
[1]. IEEE 802.11 is used and supported widely by numerous within the same TXOP duration. The second mode is block
number of currently used wireless communication devices. acknowledgment (BA). With BA, all the packets that are sent
IEEE 802.11 is a set of standards where it describes the within a single TXOP are separated only by SIFS time, and
physical and the medium access control (MAC) layers in they are acknowledged using only one block acknowledgment.
wireless local area networks (WLAN). Within the first release In this work, we use the first mode as it is more common.
of the 802.11, there were two options for the MAC layer
to be used for managing the device access to the wireless C. NS-3
channel [1]. The first one is the centralized control approach NS-3 is an open source event-driven network simulator
which is known as the Point Coordination Function (PCF). The licensed under the GNU GPLv2 license. Started initially in
second one is a contention based scheme called Distributed 2006 in order to be used in education and network researches.
Coordination Function (DCF). DCF is based on Carrier Sense NS-3 was developed mainly to replace NS-2 [7]. However,
Multiple Access with Collision Avoidance (CSMA/CA) mech- NS-3 is not considered to be a refinement and updates on the
anism. It is a method for medium access that utilizes multiple aforementioned NS-2 simulator. NS-2 uses OTcl as scripting
contention to reduce collisions. It also ensures that only one environment. On the other hand, python scripts and C++
radio transmitter is sending at any specific time. The DCF programs are used to define simulations in NS-3 and hence
allows only best effort facility without QoS guarantee [1]. PCF NS-3 is no backward compatible with NS-2.
is optional and only works in infrastructure mode in which The basic 802.11 DCF implementation in NS-3 is clarified
there is an access point that coordinates the nodes access to in Figure 1. This figure shows the components that a packet
the medium by giving them a specific slice of time to do that. passes through when being received by the MAC from the
upper layers.
B. EDCA
To support QoS in the 802.11 standards, an amendment
came out in 2005 [2]. The amendment defines two new
medium coordination functions that overwrite DCF and PCF
respectively: Enhanced Distributed Channel Access (EDCA)
and Hybrid coordination function Controlled Channel Access
(HCCA). EDCA mechanism prioritizes data traffic to achieve
QoS. Four main components implement EDCA and work to-
gether to provide QoS: Arbitration Inter Frame Space (AIFS),
Transmission Opportunity (TXOP), Contention Window Min
(CWmin ), and Contention Window Max (CWmax ). In order
for a node to gain access to the medium, the medium should Fig. 1: DCF MAC and Physical Implementation in NS-3
be sensed idle for AIFS time. This determines the time to
wait before an Access Category (AC) starts transmitting data. When a packet is sent down from the upper layers, it
When an AC gains the medium it keeps transmitting data for a is added to the DCF queue (implemented as DcaTxop in
duration known as Transmission Opportunities (TXOP) time Figure 1). The DCFManager keeps on sensing both Physical
limit. If a collision occurs or if the medium is found busy (represent the medium physically) and MAC low (represent the
when sensed, the AC backoffs for a random time between 0 medium virtually) until they become idle. Physical medium is
and the value of a variable called Contention Window (CW). sensed using Clear Channel Assessment (CCA) and virtual
CW is initialized to CWmin and then at each transmission sensing occurs in the MAC low using Network Allocation
failure, it is incremented until it reaches CWmax . When it Vector (NAV) counter. As soon as an idle state is sensed, the
reaches CWmax , it is reset to CWmin in case of a successful first available packet in the DCF queue is dequeued and sent
transmission. If the medium is sensed idle for at least AIFS down to the MAC low. MAC low adds MAC header and trailer
CWmin TXOP
AC CWmax AIFSN
802.11b 802.11g 802.11b 802.11g
AC BK 31 15 1023 7 0 0
AC BE 31 15 1023 3 0 0
AC VI 15 7 31 2 6.016µs 3.008µs
AC VO 7 3 15 2 3.264µs 1.504µs
TABLE I: Default EDCA Parameter Set

to the packet in order to form a MAC Protocol Data Unit Throughput is calculated as the average of the stored
(MPDU) or a MAC Service Data Unit (MSDU). Then the throughput values.
MSDU or MPDU is sent to the physical layer to be processed • Average delay: the amount of time needed for a packet to
and sent over the medium. When the packet sending is done, be transmitted along its entire path in the network. Packet
the medium is released to be used by another node to send delay is caused by (a) Processing delay, which is the time
its data. If the queue still has packets to be sent, the previous required to analyze, process, and decide where the packet
process (sensing, gaining medium and then send.) must be will be sent, (b) Buffer delay, which is the time that a
done again. specific packet stay in the queue until it is dequeued to
Figure 2 shows the current NS-3 implementation of EDCA. be transmitted, (c) Transmission delay, which is the total
The implementation is done on top of the DCF implementation time in which all the packet bits are pushed to the desired
with some modifications. Note that instead of one DCF queue, transmission medium, and (d) Propagation delay, which
multiple EDCA queues exist (four queues to represent the four is the time duration for the bit to propagate across the
Access categories). Each queue has its own DCFState object network until it reaches the end of its physical trajectory. In
that holds its own values of CWmin , CWmax , and AIF S. calculating the average delay, in each experiment, we use
Those four queues perform access to the medium separately the time difference between the time at which the packet
as if they are four different DCF nodes. The current NS-3 is received at the AP application layer and the time when
implementation of EDCA only sends one packet when gaining the packet is sent from the sender application layer. At
a channel access and then releases the medium. The node has the end of each second, the average delay of all packets
to contend for the medium again in order to send another received within that second from each station is calculated
packet. TXOP in contrast, is a time limit (named usually as and then the average of these averages is calculated.
TXOP limit) during which the node should be able to send
as much data as it can while the TXOP time duration is not III. M OTIVATION
expired. TXOP time limit has great impact on the network perfor-
mance. In order to show the impact of TXOP time limit, we
run some experiments using OPNET. The simulation parame-
ters were calibrated as described in Table II. Figures 3 and 4
show the simulation results using the IEEE 802.11b and IEEE
802.11g standards respectively. The main performance metrics
used are the Average Delay and the Average Throughput. Two
cases in each experiment were considered, when sending one
packet at each contention (T XOP = 0) and when TXOP is
set to its default value which allows more than one packet to
be sent during each TXOP.
Fig. 2: EDCA MAC and Physical Implementation in NS-3 By studying the results, we can note that using the default
TXOP reduces the packet delay and significantly increases
the average throughput. When sending multiple packets in the
D. Performance Metrics default TXOP limit without contending for the medium for
each packet, only SIFS time and the time needed to receive
In this paper, we use the following performance met-
an acknowledgment separates the sending of the packets. Thus,
rics.
the packet waiting time (which is the main factor in the packet
• Average throughput: it is the total amount of data received delay) is reduced. This also increments the received throughput
at the access point (AP) during a specific time period from at the AP as more data packets are received in less time.
all nodes that are connected to this AP averaged over
time. The average throughput was calculated in the AP IV. TXOP I MPLEMENTATION
application layer as the total size of the packets received As discussed before, the NS-3 implementation of EDCA
from all stations divided by the time in which the data is lacks TXOP implementation. With the complete implementa-
collected. In our experiments, the throughput is calculated tion, the node that gains a channel access is able to send as
each second and then it is stored. Eventually, the Average much data as it can during the TXOP duration. The old NS-3
6
8 x 10
6
7 TXOP = 0
5.5

Average Throughput (bps)


Default TXOP
Average Delay (sec)

6
5
5
4.5
4
4
3

2 3.5

1 3 TXOP = 0
Default TXOP
0 2.5
2 4 6 8 10 12 2 4 6 8 10 12
Network Size Network Size

Fig. 5: UML Diagram of TXOP amendments in NS-3


(a) Average Delay (b) Average Throughput

Fig. 3: Performance Metrics for IEEE 802.11b in OPNET


7
2.5 3.5
x 10
the packet that has not been sent to try to send it again. This
TXOP = 0
TXOP = 0 function also increases the packet retry count. If the packet
Average Throughput (bps)

2 Default TXOP 3 Default TXOP


Average Delay (sec)

2.5
exceeded the retry limit, it will be dropped. After that, the
1.5

2
EdcaTxopN::RestartAccessIfNeeded is called to re-contend
1 for the medium. If any collision is detected in the previous
1.5
0.5 process, the node immediately releases the medium and call
1
EdcaTxopN::RestartAccessIfNeeded function.
0 0.5
2 4 6 8 10 12
Network Size
2 4 6 8
Network Size
10 12 In NS-3, each EDCA queue is an object of the EdcaTxopN
class. Each queue has its own object of the DCFState class
(a) Average Delay (b) Average Throughput
which stores different values of CWmin , CWmax and AIF S.
Since each queue should also have its own value of TXOP
Fig. 4: Performance Metrics for IEEE 802.11g in OPNET limit according to the standard, we find it convenient to add
our TXOP implementation attributes and functions to the
DCFState class. The proposed changes are shown in Figure
EDCA implementation shown in Figure 2 proceeds as follows. 5. The proposed implementation changes can be summerized
When a packet arrives from the upper layers, it is enqueued in as follows.
one of the EdacaTxopN queues based on the packet traffic type • Support Enabling or Disabling TXOP. Because both the
using EdcaTxopN::Queue function. The EdcaTxopN::Queue EdcaTxop class and the DcaTxop class share the DCFState
function, then invokes the EdcaTxopN::StartAccessIfNeeded class, it is necessary to add a mechanism that prevents the
function. EdcaTxopN::StartAccessIfNeeded uses the DcfMan- DcaTxop class from using the TXOP implementation. For this
ager class to call the DcfManager::RequestAccess function in purpose, qos s, which is a flag that indicates the enabling of
order to check if the medium is idle. If the medium is not using the TXOP implementation, is added to the DCaTxop
idle, the backoff mechanism is performed. If the DcfManager class along with the function setQoS to set qos s to true for
detects an idle medium, DcfManager::DoGrantAccess function the EdcaTxop class and false for the DcaTxop class.
is called. This function checks for any internal collision that • Initializing and Tracking TXOP Duration. The attribute
may occur between the EDCA queues. If no internal colli- txop limit, defined of Type ns3::Time, is assigned a value us-
sion is detected, then the EdcaTxopN::NotifyAccessGranted ing the DcfState::SetTXOP function and its value can be got-
function is called. This function then extracts a packet from ten using the DcfState::GetTXOP function. txop limit stores
the queue and call MacLow::StartTransmission function. As the value of the default TXOP limit stated in the standard.
MacLow::StartTransmission function is called, it creates an The value of txop limit for each EdcaTxopN is assigned based
acknowledgment event and forms the MAC Service Data Unit on its Access Category and the physical standard. The values
(MSDU) or MAC Protocol Data Unit (MPDU). The processed of CWmin , CWmax , AIF S, and txop limit are assigned
frame is then sent to the physical layer to be processed and in the wifi-mac class. The SetTXOP function is added to
sent over the transmission medium. The node then waits for the abstract Dcf class as an abstract function. Since the Dcf
an acknowledgment. class is the base class of both DcaTxop and EdcaTxopN, they
If an acknowledgment is received before the acknowledg- both have SetTXOP function implementation. The SetTXOP
ment time is expired, the acknowledgment event is canceled function in the wifi-mac class calls the DcfState::SetTXOP
and then EdcaTxopN::GotAck function is called. This func- to set its value. The value of txop limit is set to zero in
tion calls the EdcaTxopN::RestartAccessIfNeeded function to case of DcaTxop class and to its default value in each of
check if there is still any packet in the queue to re-contend the EdcaTxopN classes.The attribute txop limit stores the AC
for the medium again. default TXOP duration time. Another local variable, m txop l,
If no acknowledgment is received, the acknowledgment is used to keep track of the remaining time that an AC has
event time expires. As soon as this event expires, the Ed- in its TXOP limit to expire once it gained the medium. When
caTxopN::MissedAck function is called. This function stores the first packet in the TXOP duration is added to the queue
using EdcaTxopN::Queue function, the local TXOP value period. If not, the current TXOP limit is considered expired
(m txop l) takes the value stored in the attribute txop limit. and the medium is released.
This is done in the EdcaTxopN::StartAccessIfNeeded function • Collision Handling. In case of a packet collision, all flags
using DcfState::StartTXOP function. For example, the TXOP and local variables must be reset to their default values. For
limit in the IEEE 802.11g for video traffic is 3008µseconds. this purpose, the function DcfState::ResetTXOP is used. This
In this case, the attribute txop limit is set to the value 3008 function is also called in the EdcaTxopN::GotAck function,
and the variable m txop l starts with the value 3008 and is when the TXOP time is not expired, but the EDCA queue has
decreased while sending packets during a TXOP duration. no packets to send.
• Contending for the Medium. When a packet arrives from
V. E VALUATION M ETHODOLOGY
the upper layers to EdcaTxop using the EdcaTxopN::Queue
function, a flag (m accessRequested) is set to true. This Various experiments are conducted to test the correctness
happens in order to prevent other packets from trying to of our TXOP implementation in NS-3 simulator version 3.22.
contend for the medium which may cause a collision. The The same experiments are also conducted using OPNET
DcfManager object is then notified to start contending for simulators for verification purposes. In all experiments, Wi-Fi
the medium. The m accessRequested is set to false, when the networks in infrastructure mode are used. In these networks,
current packet is sent, to let other packets start the contending several stations are sending data packets to a central Access
process for the medium process. The same thing should be Point (AP). The network traffic is generated as voice traffic
done when a node tries to send the first packet in the TXOP with IEEE 802.11b and IEEE 802.11g standards. In all experi-
limit. The node should contend for the medium only with the ments, stations always have packets to send (saturated traffic).
first packet in each TXOP limit. It also should directly send the To create saturated traffic, the application rate was calculated
subsequent packets as long as the TXOP limit is not expired. as in [4]:
P
This means that a flag should be added to prevent contending R=
S
for the medium while TXOP limit is not expired. The flag
inTXOP is used for this purpose and DcfState::IsInTXOP where R is the application rate, P is the physical rate of the
function is used to obtain the value of this flag. selected Net Device for each station, and S is the total number
• Sending of Multiple Packets. Once the channel access of stations participating in the experiment.
is gained, the TXOP burst transmission procedure begins as Moreover, since each of NS-3 and OPNET simulators
shown in Figure 6. Initially, the inTXOP flag is set to true implements its own propagation delay and path loss models,
the effect of all delay factors are eliminated except for the
packet queuing delay.
Table II summarizes the main simulation parameters.

TABLE II: Main Simulation Parameters


Parameter Model/Value(s)
Number of Sources 2, 4, 6, 8, 10, 12
Source Start Time Random (1-5) seconds
Simulation Time 4 Minutes
Application Packet Size 1024 Bytes
Fig. 6: TXOP burst transmission Procedure Application Rate Physical Rate / S
Physical Characteristics IEEE 802.11 (b & g)
Physical Data Rate (11 & 54) Mbps
and the start time of the current TXOP is stored. The attribute Buffer Size 256 packets
start txop of type Time is used for this purpose. Next, after Traffic Type Voice
each packet in the current TXOP is sent and its acknowledg- Beacon Interval 0.02 second
TXOP Limit 0 & As described in Table I
ment is received, the EdcaTxopN::GotAck function is called. CWmin, CWmax, and AIFS Default as described in the standard
Within this function, the function DcfState::CheckTXOP is
called to subtract the time needed to send the last packet and
the receiving of its acknowledgment from the TXOP remaining VI. R ESULT D ISCUSSION
time (tracked by m txop l) and check if the remaining time The results for both simulators NS-3 and OPNET are
in the current TXOP is enough to send the next packet compared using the performance metrics described in Section
and receives its acknowledgment. The next packet time is II: The Average Throughput and the Average Delay.
calculated using the MacLow class. The MacLow class has Figures 7 and 8 show the average delay and the average
a private function (MacLow::CalculateOverallTxTime) that throughput for voice traffic using the IEEE 802.11b and
calculated the expected time for the next packet to be sent until IEEE 802.11g standards respectively. These experiments are
its acknowledgment is received. In order to use this function performed when T XOP = 0 (i.e. sending one packet at each
outside the MacLow class scope, it is changed to be public. If TXOP duration) in both NS-3 and OPNET simulators. Note
the current TXOP limit has enough time for the next packet, that these figures compare the OPNET performance with the
the sending of the next packet is scheduled after SIFS time unmodified version of the NS-3. These figures show that there
6 6
8 x 10 8 x 10
10 10
7 7 9

Average Throughput (bps)

Average Throughput (bps)


8 8
Average Delay (sec)

Average Delay (sec)


6 6
7
5 5
6 OPNET 6 OPNET
NS−3 NS−3
4 4 5
3 4 3 4
3
2 2
2 2
1 OPNET 1 OPNET
NS−3 NS−3 1
0 0 0
2 4 6 8 10 12 2 4 6 8 10 12 2 4 6 8 10 12 2 4 6 8 10 12
Network Size Network Size Network Size Network Size

(a) Average Delay (b) Average Throughput (a) Average Delay (b) Average Throughput

Fig. 7: Performance Metrics when sending one packet at each Fig. 9: Performance Metrics with defult TXOP value using
TXOP limit using 802.11b standard 802.11b standard
7 7
2.5 x 10 2.5 x 10
5 5
4.5 4.5
Average Throughput (bps)

Average Throughput (bps)


2 2
4 4
Average Delay (sec)

Average Delay (sec)


3.5 3.5
OPNET
1.5 OPNET 1.5 OPNET
3 NS−3 3
NS−3 NS−3
2.5 2.5
1 1
2 2
1.5 1.5
0.5 0.5
1 1
OPNET
NS−3 0.5 0.5
0 0
2 4 6 8 10 12 2 4 6 8 10 12 2 4 6 8 10 12 2 4 6 8 10 12
Network Size Network Size Network Size Network Size

(a) Average Delay (b) Average Throughput (a) Average Delay (b) Average Throughput

Fig. 8: Performance Metrics when sending one packet at each Fig. 10: Performance Metrics with defult TXOP value using
TXOP limit using 802.11g standard 802.11g standard

are no much deferences in the results between OPENT and verified our implementation using OPNET simulator. Results
NS-3 in both 802.11 b and g standards. We can see that with show that the NS-3 TXOP implementation is very accurate.
OPNET, there is slightly more packet delay because OPNET ACKNOWLEDGMENT
keeps the packets in its queues more than that in the case of
NS-3. But as we can see, the difference is very acceptable. This work is funded in part by the Jordan University of
Science and Technology Deanship of Research grant number
Figures 9 and 10 show the average delay and average
20140245.
throughput for voice traffic using the IEEE 802.11b and
IEEE 802.11g standards respectively. These experiments are R EFERENCES
performed with the default TXOP values in both NS-3 (the [1] “Ieee standard for information technology- telecommunications and infor-
modified version) and OPNET simulators. Results show the mation exchange between systems- local and metropolitan area networks-
impact of having the complete EDCA implementation. With specific requirements- part 11: Wireless lan medium access control (mac)
and physical layer (phy) specifications,” ANSI/IEEE Std 802.11, 1999
the TXOP implementation, due to the sending of more data Edition (R2003), pp. i–513, 2003.
packets with each contention, the average throughput is in- [2] “Ieee 802.11 amendment to support quality of service,” IEEE 802.11e-
creased and the packet delay is decreased. Furthermore, both 2005, 2005.
[3] N. S. Shankar and M. Van der Schaar, “Performance analysis of video
simulators have almost the same curves for both average delay transmission over ieee 802.11 a/e wlans,” Vehicular Technology, IEEE
and average throughput with almost the same slight difference Transactions on, vol. 56, no. 4, pp. 2346–2362, 2007.
in the case of the average delay before the modification. [4] M. Alsmirat and N. Sarhan, “Cross-layer optimization and effective
airtime estimation for wireless video streaming,” in 2012 21st Interna-
These results indicate the correctness of the NS-3 modified tional Conference on Computer Communications and Networks (ICCCN).
implementation. IEEE, 2012, pp. 1–7.
[5] “The network simulator ns-3,” http://www.nsnam.org/.
[6] “Opnet modeler web page,” http://www.opnet.com/solutions/network
VII. C ONCLUSION rd/modeler.html.
[7] “The network simulator ns-2,” http://www.isi.edu/nsnam/ns/.
NS-3 Simulator holds a great and promising potential [8] “Ieee standard for information technology–telecommunications and infor-
mation exchange between systems local and metropolitan area networks–
for network simulation purposes and lots of research paper specific requirements part 11: Wireless lan medium access control (mac)
reference this simulator for their model evaluation. Unfortu- and physical layer (phy) specifications - redline,” IEEE Std 802.11-2012
nately, NS-3 implements IEEE 802.11e in the EDCA mode (Revision of IEEE Std 802.11-2007) - Redline, pp. 1–5229, March 2012.
incompletely. The NS-3 implementation lacks TXOP duration
implementation. In this paper, we completed the NS-3 EDCA
implementation by adding the TXOP implementation. We

View publication stats

Vous aimerez peut-être aussi