<analytics uacct="UA-1580095-2" ></analytics>
This software is not actively maintained anymore, please send your technical inquiries to the general ns-2 users mailing list.
At the Computer Networking Group of the University of Pisa we developed an extension for the Network Simulator 2 for simulating the HCF Controlled Channel Access (HCCA) in an IEEE 802.11e wireless local area network.
If you use our HCCA extension for ns2 for your research, we would appreciate if you could please cite the following reference (you can download it here):
A Software Architecture for Simulating IEEE 802.11e HCCA Claudio Cicconetti, Luciano Lenzini, Enzo Mingozzi, Giovanni Stea Proc. 3rd Internet Performance, Simulation, Monitoring and Measurement IPS-MoMe 2005 March 14-15, 2005, Warsaw (Poland)
A package including the latest ns2hcca source code and documentation is available here (2.6 MB).
The proposed approach allows for flexible integration of different scheduling algorithms with the MAC. Specifically, the 802.11e sub-system consists of three modules:
- a classifier, which is used to tag incoming packets from transport agents with the appropriate Traffic stream Identifier (TID). The latter is an additional field of 802.11e MAC header for differentiating packets that have different QoS requirements;
- a HCCA scheduler, which is used at both the QoS Access Point (QAP) and the QoS Stations (QSTAs) to manage downstream HCCA packets according to the QoS parameters of their traffic stream;
- a modified MAC module, which extends the legacy 802.11 MAC class.
The HCCA scheduler and the MAC interact by means of an ad-hoc communication interface, which is discussed in detail in the code documentation.
The following MAC schedulers are currently available:
- reference: QAP HCCA scheduler that conforms to the example scheduler reported in Section I.3.3 of the draft document P802.11e/D13.0;
- oneflow: QSTA trivial HCCA scheduler that only supports the admission of one uplink traffic stream at each QSTA.
You can install the ns2hcca patch as follows:
2. unpack the file that you just downloaded in your preferred location (let us assume the location is /usr/local). This will create a directory named /usr/local/ns-allinone-2.29
4. apply the ns2hcca patch, by executing the following command
cd /usr/local/ns-allinone-2.29/ns-2.29 gzip -dc /tmp/ns2hcca-2.29-060823.patch.gz | patch -Np1
5. compile the all-in-one patched ns-2.29, by executing the following command:
6. (optional) if compilation completed correctly, you can test the HCCA module by simulating the example included in the directory tcl/ex/hcca. This example is a simple scenario with a variable number of QSTAs with one bi-directional VoIP-like traffic stream served under HCCA, which produces a standard ns2 wireless trace named example.trc. The default number of QSTAs is 1. You can analyze example.trc using a simple perl script called analyze.pl bundled into the example package as follows:
./analyze.pl < example.trc.
If you want to change the number of QSTAs with VoIP traffic or if you want to disable HCCA, then you can use the command arguments -n and -hcca, respectively. For instance, if you want to run a scenario with 10 QSTAs without HCCA, you have to run the following command:
ns example.tcl -n 10 -hcca 0.
The generation of a statistics file is turned off by default. To enable it, just add the -out mystat arguments to the command-line invokation of ns, which will create the file statistics archive mystat.
The ns2hcca patch includes the latest version of a framework for enabling effective data collection and statistical analysis with ns2. The documentation of the latter can be found in the Ns2measure page, where you can also download the stand-alone utilities to actually perform data analysis. A set of metrics have been added to the HCCA modules for your convenience.
Note that a well-known bug is that it is not possible to have downlink DCF traffic (from the QAP to QSTAs) when HCCA is enabled. Instead, uplink DCF traffic (from any QSTA to the QAP) with HCCA enabled works fine. Note that TCP traffic is inherently bi-directional.
The following documentation is available:
- chapter 8 of the Federico Stentella's graduate thesis (pdf 286K)
- self-generated doxygen documentation (pdf 484K)
The current ns2hcca extension is based on the draft amendment 802.11e/D13.0. Note that the EDCA access function is not included in our extension; if you are interested in simulating EDCA using ns2, visit the webpage of the TKN, Berlin (Germany). Also, note that an existing extension to ns2 for supporting HCCA is available here from the INRIA, Sophia Antipolis (France).
The ns2hcca patch also includes the source code of the No Ad-Hoc Routing agent, which allows for centralized medium access. The original version, and its related documentation, is available here.
Use ns2hcca at your own risk. Even though we reckon that it should not reasonably injure people or damage your computer system, we note that the ns2hcca patch modifies the existing ns2 code, which might therefore produce results that differ from the ones with the original version. Furthermore, the simulation of HCCA has been tested heavily under different traffic scenarios, but we still cannot declare it bug-free.