HAL Id: inria-00336858https://hal.inria.fr/inria-00336858

Submitted on 5 Nov 2008

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

An IEEE 802.16 WiMAX Module for the NS-3Simulator

Jahanzeb Farooq, Thierry Turletti

To cite this version:Jahanzeb Farooq, Thierry Turletti. An IEEE 802.16 WiMAX Module for the NS-3 Simulator. [Tech-nical Report] 2008, pp.11. �inria-00336858�

***** In Submission, November 3rd 2008 *****

An IEEE 802.16 WiMAX Module for the NS-3 Simulator

Jahanzeb FarooqINRIA, Planete Project

2004 Route Des Lucioles06902 Sophia Antipolis, France

jahanzeb.farooq@sophia.inria.fr

Thierry TurlettiINRIA, Planete Project

2004 Route Des Lucioles06902 Sophia Antipolis, France

thierry.turletti@sophia.inria.fr

ABSTRACTns-3 is a recently released next generation simulator intendedas a replacement of the popular ns-2. It enables a highly richset of features and is expected to become the first choiceof the scientific community soon. ns-3 is in its evolutionphase and work at different fronts is still ongoing. Withthe recent emergence of broadband wireless networks, sim-ulation support for such networks, especially IEEE 802.16WiMAX, is becoming a necessity. In this paper, we pro-pose and discuss in detail the design and implementation ofan IEEE 802.16 WiMAX module for ns-3, with the Point-to-Multipoint (PMP) mode and the WirelessMAN-OFDMPHY layer. Our module implements fundamental functionsof the convergence sublayer (CS) and the MAC common-part sublayer (CPS), including QoS scheduling services, band-width request/grant mechanism, and a simple uplink sched-uler. The aim is to provide a standard-compliant and well-designed implementation of the standard.

Categories and Subject DescriptorsH.4 [Simulation and Modeling]: Model development—modeling methodologies

KeywordsIEEE 802.16, WiMAX, network simulation, ns-3

1. INTRODUCTIONWith the increasing demand of high data rates and largerwireless coverage, broadband wireless access networks haverapidly emerged over the last few years. The IEEE 802.16standard [1], widely known as WiMAX (Worldwide Interop-erability for Microwave Access), defines the MAC (MediumAccess Control) and PHY (Physical) layers specifications forthe broadband wireless access networks. WiMAX offers analternative to wired networks, such as coaxial systems us-ing cable modems, fiber optics and DSL (Digital SubscriberLine). It offers high speed data access to large geograph-ical areas, covering distance up to 50 Km and supporting

data rates up to 100 Mbps, depending on the distance fromthe base station and the underlying PHY layer. With thisrange and data rates WiMAX standard is capable of deliv-ering backhaul connections for enterprise campuses, WiFihotspots and cellular networks.

The MAC layer of WiMAX supports Point-to-Multipoint(PMP) and Mesh topologies. The wireless medium accessis based on either Time Division Multiple Access (TDMA)or Frequency Division Multiple Access (FDMA), with FDD(Frequency Division Duplex) and TDD (Time Division Du-plex) as duplexing techniques. Multiple PHY layer speci-fications are supported for LOS (Line-of-Sight) and NLOS(Non-Line-of-Sight) operational environments in 10-66 GHzand 2-11 GHz frequency bands, respectively. Later on theIEEE 802.16e amendment [3] added mobility support toWiMAX networks.

The network simulator ns-2 [6] is one of the most widelyused simulators in the academic and industrial communitysince the last decade. The newly released ns-3 [7], primarilyintended as a replacement of ns-2, is a completely new sim-ulator rewritten from the scratch. It introduces major en-hancements over its predecessor and has all the capabilitiesof becoming the leading network simulator in near future.A few among the many salient features of ns-3 are a com-pletely re-written software core with fully documented API,high emphasis on conformance to real networks, easier soft-ware integration, support for simulating virtual networks,support for testbeds, attribute system for configuring sim-ulator parameters, automatic memory management, and aconfigurable tracing system, etc [14]. The first release of ns-3 (version ns-3.1) was made in June 2008 with support for anumber of modules including CSMA, Point-to-Point, 802.11WiFi, TCP, UDP and IPv4. The development on a numberof modules is still in progress.

Currently there are a number of WiMAX modules availablefor ns-2, all based on PMP topology with TDD duplexing.The module proposed by Networks and Distributed SystemsLaboratory (NDSL) [11], one of the first WiMAX modulesavailable, supports, among other features, scheduling ser-vices and bandwidth management. However the module ishighly simplified as it ignores several implementation detailsand thus is not compliant to the standard. The module pro-posed by National Institute of Standards and Technology(NIST) [4] provides a number of features including OFDMPHY layer and fragmentation and de-fragmentation. How-

ever it lacks the implementation of QoS scheduling services.Later a collaborative effort between WiMAX Forum, Rens-selaer Polytechnic Institute (RPI) and Washington Univer-sity St. Louis (WUSTL) adds support for QoS schedulingservices, ARQ mechanism and OFDMA PHY layer to thismodule. The updated module is now officially adopted bythe WiMAX Forum [8] and is available for download formembers. Note that a plug-in proposed by Telecom Bre-tagne [9] also extends the NIST module with QoS schedulingservices feature. Finally, a recent module proposed by Com-puter Networks Laboratory (CNL) [10], basically based onDOCSIS module [2], supports scheduling services and band-width management, however it lacks implementation of aWiMAX compliant PHY layer. Unfortunately, the highlynon-modular design of the NDSL and CNL modules makesthem less attractive for the developers who aim to extendthem with new features and plug-ins.

Our module is based on the IEEE 802.16-2004 standard andns-3 version 3.2. The code1 is available under the GNUGeneral Public License. It implements the PMP topologywith TDD mode and aims to provide detailed and stan-dard compliant implementation of the standard, supportingimportant features including QoS scheduling services, band-width management, uplink request/grant scheduling and theOFDM PHY layer. The module is built completely in C++with 36 classes and approximately 17000 lines of code. Be-side the fact that it is the first WiMAX module for thens-3 simulator, the module distinguishes itself from abovemodules in the respect that high attention has been put tomake the design fully object-oriented, facilitating modular-ity, reusability, scalability and maintenance of software. Uni-fied Modeling Language (UML) has been used for the designand analysis phase. We believe this work a significant contri-bution to the scientific community as it allows simulations ofWiMAX networks with a more close-to-real implementationof the standard, and with the add-on flexibility of plugging-in new modules in its various components. Furthermore,with the added benefits of ns-3, the module enables featuressuch as flexible and detailed tracing functionality, simulationof real networks and TCP/IP-stack, emulation, and definingnew simulation scenarios using the Helper API.

The remainder of the paper is organized as follows. Section 2presents a brief overview of the IEEE 802.16 standard. Sec-tion 3 presents detailed description of the proposed moduleincluding its software design, the MAC and PHY layers andthe detailed operation of each component. Future develop-ment and enhancements are discussed in Section 4. FinallySection 5 concludes our work.

2. OVERVIEW OF IEEE 802.16 STANDARDThis section presents a brief overview of the IEEE 802.16standard. For a more comprehensive overview please referto [13] or [20].

The IEEE 802.16 standard defines MAC (Medium AccessControl) and PHY (Physical) layers specifications for a Broad-band Wireless Access (BWA) network. The physical mediumis divided into frames of fixed length. Each frame is further

1The code is available at the following URL:http://code.nsnam.org/iamine/ns-3-wimax/.

divided into DL (downlink) and UL (uplink) subframes forthe downlink and uplink traffic. The structure of frame de-pends on the underlying PHY layer. The standard definesmultiple PHY layers for different operational environments.For the 10-66 GHz band the WirelessMAN-SC PHY, basedon single carrier modulation, is defined. For frequencies be-low 11 GHz, where propagation without a direct line of sight(LOS) must be accommodated, three alternatives are pro-vided: WirelessMAN-SCa using single carrier modulation,WirelessMAN-OFDM using Orthogonal Frequency DivisionMultiplexing, and WirelessMAN-OFDMA using Orthogo-nal Frequency Division Multiple Access. The standard sup-ports two duplexing techniques: FDD, where DL and ULsubframes take place at the same time but on different fre-quencies, and TDD, where DL and UL subframes take placeat different times and usually share the same frequency.

The MAC layer is divided into three sublayers. The CS(Convergence Sublayer), MAC CPS (Common-Part Sublayer)and the Security Sublayer. The CS Sublayer is responsible ofreceiving PDUs (Protocol Data Units) from the higher layer,classifying these PDUs to appropriate connections, process-ing these PDUs and delivering them to the appropriate MACSAP (Service Access Point). The MAC CPS (Common PartSublayer) provides the fundamental MAC functionalities in-cluding connection establishment and management, gener-ation of MAC management messages, SS initialization andregistration, ranging, bandwidth management, service flowmanagement and scheduling services. Two modes for shar-ing the wireless medium are defined: in the PMP mode Sub-scriber Stations (SS) communicate to each other through aBase Station (BS), and in the Mesh mode the stations areorganized in an ad-hoc fashion and communicate to eachother directly.

The MAC protocol is connection-oriented which means allthe communication takes place in terms of connections. Thereare two types of connections: management connections fortransmitting control messages and transport connections fordata transmission. The registration phase includes an ini-tial ranging phase in which special management messagesRNG-REQ and RNG-RSP are exchanged between SS andBS. The BS on receiving RNG-REQ examines parameterssuch as power level and if acceptable allocates a set of man-agement connections to the SS. These connections are thenused to transmit and receive control messages.

The MAC defines a set of control messages, called MACmanagement messages. The most important of these mes-sages are DL-MAP, UL-MAP, DCD and UCD. At the be-ginning of each frame the BS broadcasts the DL-MAP andUL-MAP messages that define access to the DL and UL sub-frames of the current frame. These messages contain a setof information elements (IE), each notifying an SS of the DLor UL grant allocated to it. These are followed by DCD andUCD messages which contain general information about thechannel and a set of burst profiles, each burst profile defin-ing a set of parameters that must be used to send or receivedata in a given DL or UL grant.

All the data traffic is carried on transport connections. Thereis a one-to-one relationship between a transport connectionand a service flow. A service flow defines a unidirectional

flow of data traffic and binds it with a set of QoS parame-ters. A wide range of QoS parameters are supported by thestandard. Special MAC management messages DSA-REQand DSA-RSP are exchanged between SS and BS to createa service flow.

The standard defines four scheduling services (or QoS classes),named UGS (Unsolicited Grant Service), rtPS (Real-TimePolling Service), nrtPS (Non-Real-Time Polling Service) andBE (Best Effort). UGS is designed for real-time applicationswith fixed size packets. UGS flows are allocated unsolicitedgrants on periodic basis. rtPS is designed for real-time appli-cations that generate variable size packets on periodic basis.Unlike UGS, a rtPS flow is polled by the BS on periodicbasis allowing it to send bandwidth requests. The request isthen serviced based on the available bandwidth. Comparedto rtPS, nrtPS is designed for more delay-tolerant applica-tions. A nrtPS flow is ensured a minimum bandwidth bypolling it on regular basis even in congestions conditions.Finally, BE (Best Effort) is designed for best effort trafficsuch as HTTP and Email and does not guarantee a min-imum bandwidth. The 802.16e amendment introduces anadditional class named ertPS (Extended Real-Time PollingService) that combines features of UGS and rtPS by allowingunsolicited grants for variable packet size applications.

Bandwidth is requested by sending a bandwidth requestpacket. It is sent either in a special transmission opportunityallocated in UL subframe or in an uplink grant allocated tothe SS. BS then responds with a grant allocated in subse-quent frames. The uplink scheduler at the BS decides whichSSs to allocate bandwidth in the next frame based on re-quests. Note that bandwidth is requested on per connectionbasis but allocated on per SS basis. This is then the respon-sibility of the SS scheduler to decide which connection willtransmit in a given grant. Similarly the BS scheduler selectspackets that will be transmitted in DL subframe. Note thatstandard does not define any scheduling algorithm for theseschedulers and leaves this up to the manufacturers to decide.

3. THE PROPOSED IEEE 802.16 MODULEThe proposed module is mainly composed of three layers:the CS (Convergence Sublayer), the MAC CPS (Common-Part Sublayer) and the PHY layer. At the PHY layer twodifferent PHY implementations are supported. Figure 1presents a block diagram of the module, illustrating someof its key components and their interaction. Subsequentsections provide detailed description of the three layers andthe key components.

3.1 Software DesignThe design of the module thoroughly follows object-orientedanalysis and design methodology in order to benefit fromthe classic characteristics of object-oriented software con-struction including modularity, polymorphism, encapsula-tion and inheritance, and to conform to fully object-orienteddesign of ns-3. UML (Unified Modeling Language) has beenadopted especially for the Design and Analysis phases ofthe SDLC (System Development Life Cycle). More specifi-cally, software construction techniques presented in [18] havebeen widely followed. The class diagram of the module ispresented in Figure 2. Note that the diagram only showsimportant data members and functions and details such as

multiplicity have been omitted due to limited space. As seenin the figure, the module is composed of several C++ classeseach representing a core component of the system and tak-ing care of a particular functionality. Responsibilities havebeen carefully delegated to different classes/components toensure high cohesion and low coupling. High attention hasbeen put to design an API that ensures reusability, scalabil-ity as well as maintainability of the software. The modulardesign facilitates extension of the software in future. Addi-tions of new components and plug-ins, such as new PHY orscheduler implementations, can easily be made.

3.2 The Convergence SublayerThe 802.16 MAC layer is divided in to two sublayers. TheConvergence Sublayer and the core MAC layer called MACCommon-Part Sublayer. CS is further sub-divided into twotypes: the Packet CS and the ATM CS. Our module im-plements the Packet CS, designed to work with the packet-based protocols at higher layers. The CS is responsible ofreceiving packet from the higher layer and from peer sta-tions, classifying packets to appropriate connections (or ser-vice flows) and processing packets. It keeps a mapping oftransport connections to service flows. This enables theMAC CPS identifying the QoS parameters associated to atransport connection and ensuring the QoS requirements.The CS currently employs a simple classifier based on des-tination MAC address. Support for other standard compli-ant classifiers is aimed in future (see Section 4). Note thatthe optional feature of PHS (Payload Header Suppression),which allows suppressing the repetitive portion of the pay-load headers, is not implemented by the module.

3.3 The MAC SublayerThe MAC CPS is the main sublayer of the IEEE 802.16MAC and performs the fundamental functions of the MAC.The module implements the PMP mode. In PMP mode BSis responsible of managing communication among multipleSSs. The key functionalities of the MAC CPS include fram-ing and addressing, generation of MAC management mes-sages, SS initialization and registration, service flow man-agement, bandwidth management and scheduling services.

Class WimaxNetDevice in Figure 2 represents the MAC layerof a WiMAX network device. This class extends the Net-Device class of the ns-3 API that provides abstraction ofa network device. WimaxNetDevice is further extended byBaseStationNetDevice and SubscriberStationNetDevice classes,defining MAC layers of BS and SS, respectively. Besidesthese main classes, the key functions of MAC are distributedto several other classes to achieve software characteristicsdiscussed in Section 3.1. As seen from Figure 2, some of thekey classes that implement the MAC functions include LinkManager (for both SS and BS), Uplink Scheduler, Scheduler(for both SS and BS), Connection Manager, Service FlowManager, Burst Profile Manager and Bandwidth Manager.

3.3.1 Framing and Management MessagesThe MAC is partitioned into frames of fixed duration. Themodule implements a frame as a fixed duration of time, i.e.,frame boundaries are defined with respect to time. Eachframe is further subdivided into DL and UL subframes. Themodule implements the TDD mode where DL and UL oper-ate on same frequency but are separated in time. A number

PHY Layer

Base Station (BS)Subscriber Station (SS)Link ManagementConnection/Service Flow ManagementBandwidth ManagementClassificationUpper Layer

Uplink SchedulingScheduling

Link ManagementConnection/Service Flow ManagementBurst Profile ManagementBurst Profile Management Bandwidth ManagementClassification

SchedulingCore MAC Core MACBasic Primary UGS1 rtPS1 nrtPS1 BE1....Connection queues SS1 ....... ...SS2Broadcast ...SSnConnection queues

Upper LayerDL/UL bandwidth allocation mapsDL/UL channel descriptorsRanging requestBandwidth request Ranging responseSF request Bandwidth requestSF response SF requestSF responseRanging requestRanging response

PDUPDU PDUPDU

Burst BurstBurstBurst

CSCPS CS

BlocksBlocksFigure 1: Block diagram of the proposed WiMAX module.

of DL and UL bursts are then allocated in DL and UL sub-frames, respectively. Since the standard allows sending andreceiving bursts of packets in a given DL or UL burst, theunit of transmission at the MAC layer is a packet burst. Themodule implements a special Packet Burst data structurefor this purpose (see Figure 2). A packet burst is essen-tially a list of packets. As seen in Figure 1, the BS downlinkand uplink schedulers (represented by classes BS Schedulerand Uplink Scheduler in Figure 2) are responsible of gen-erating DL and UL subframes, respectively. In the case ofDL, the subframe is simulated by transmitting consecutivebursts (instances of PacketBurst class). In case of UL, thesubframe is divided, with respect to time, into a number ofslots. The bursts transmitted by the SSs in these slots arethen aligned to slot boundaries. The frame is divided intointeger number of symbols and PS (Physical Slots) whichhelps in managing bandwidth more effectively. The numberof symbols per frame depends on the underlying implemen-tation of the PHY layer (see Section 3.4). The size of aDL or UL burst is specified in units of symbols. Figure 3shows the format of implemented MAC frame and the keymanagement messages DL-MAP, UL-MAP, DCD and UCD.

MAC management messages play fundamental role in IEEE802.16 MAC. A number of management messages are de-fined. These messages only carry control information andare transmitted on management connections (including pre-defined broadcast and multicast connections). The most im-portant of these messages are DL-MAP, UL-MAP and DCDand UCD. DL-MAP and UL-MAP are called DL and UL

bandwidth allocation maps and define access to the down-link and uplink, respectively. DCD and UCD are calledchannel descriptors and contain information about the chan-nel and how data shall be transmitted/received on it. Nextsubsection describes these messages in further detail. Inaddition to these messages, the standard defines separatesets of management messages to carry specific tasks such asranging, registration, service flow management, burst profilemanagement and so on. The module currently implementsthe following management messages: DL-MAP, UL-MAP,DCD, UCD, RNG-REQ, RNG-RSP, DSA-REQ, DSA-RSPand DSA-ACK. The module implements these messages,as well as the regular packets and the 802.16 MAC head-ers, Generic MAC Header, Bandwidth Request Header, andGrant Management Subheader, utilizing ns-3’s Packet/HeaderAPI, that, among other features, allows bit-by-bit serializa-tion and de-serialization of the packet bytes with the help ofthe underlying byte buffer. This serialized representation ofthe data in the packet is done to match real network packets,in order to facilitate features such as emulation.

DL-MAP/UL-MAP and DCD/UCD MessagesFigure 3 shows the format of the DL-MAP, UL-MAP, DCDand UCD messages. DL-MAP and UL-MAP messages defineaccess to the DL and UL subframes of the MAC frame. TheAllocation Start Time field of UL-MAP indicates the start-ing time of the UL subframe, relative to the beginning ofthe DL subframe. As seen in figure, DL-MAP and UL-MAPcontain a set of special data structures, called IE (Informa-tion Element). Each IE notifies an SS (or set of SSs) of an

+Schedule()+SelectConnection()+AddDownlinkBurst()-downlinkBurstsBS Scheduler+Schedule()+SelectConnection()SS Scheduler

+CalculateAllocationSize()+SelectFlowForRequest()+SendBWRequest()+ProcessBWRequest()+SetSubframeRatio()Bandwidth Manager+Schedule()+ServiceGrants()+ServiceRequests()+AllocateIRInterval()+SetupServiceFlow()+AddUplinkAllocation()-uplinkAllocationsUplink Scheduler+CreateParameterSet()+AddServiceFlow()+GetServiceFlow()+AllocateServiceFlows()+InitiateServiceFlows()+ScheduleDsaReq()+ScheduleDsaRsp()+ProcessDsaReq()+ProcessDsaRsp()+ProcessDsaAck()-serviceFlowsService Flow Manager

+CreateSSRecord()+GetSSRecord()+GetSSRecords()+IsRegistered()-ssRecordsSS Manager+Send()+StartReceive()SimpleWimaxPhy

+GetModulationType()+GetBurstProfile()+GetProfileToRequest()+GetNrProfilesToDefine()Burst Profile Manager+AllocateConnections()+CreateConnection()+AddConnection()+SetupConnection()-basicConnections-primaryConnections-transportConnectionsConnection Manager+PerformRanging()+StartScanning()+SendRangingRequest()+StartContResolution()+PerformBackoff()+AdjustRangingParams()-rangingStatus-rangingCW-rangingBO-nrRangingTransOppsSS Link Manager +CalculateRangOpps()+ProcessRangingRequest()+PerformRanging()+PerformInitialRanging()+PerformInvitedRanging()+SetParametersToAdjust()+AbortRanging()+AcceptRanging()BS Link Manager

+Send()+StartSendFecBlock()+StartReceive()+ConvertBurstToBits()+ConvertBitsToBurst()+CreateFecBlocks()+RecreateBuffer()OfdmWimaxPhy +Send()OfdmWimaxChannel+StartScanning()+GetDataRate()+GetTransmissionTime()+GetNrSymbols()-frequency-frameDuration-psDuration-symbolDurationWimaxPhy WimaxChannel+Send()SimpleWimaxChannel

+Enqueue()+Dequeue()+Peek()WimaxMacQueue+AddPacket()+GetPackets()+GetNPackets()+GetSize()-packetsPacketBurst+Classify()PacketClassifier+Classify()DestinationAddressClassifier+..()-sfid-direction-type-connection-parameterSet-isEnabled-classifier-recordServiceFlow

+..()-cid-type-queue-serviceFlowWimaxConnection+..()-maxSustainedTrafficRate-schedulingType-toleratedJitter-maxLatency-unsolicitedGrantInterval-unsolicitedPollingIntervalQoSParameterSet

+..()-macAddress-basicCid-primaryCid-modulationType-rangingStatus-pollForRanging-serviceFlowsSSRecord+..()-grantSize-grantTimeStamp-dlTimeStamp-requestedBandwidth-grantedBandwidthServiceFlowRecord MacMessages+..()-identifierConnectionIdentifier

+GetNextBasicCid()+GetNextPrimaryCid()+GetNextTransportCid()+GetCidType()CIDFactory

+ForwardUp()+ForwardDown()WimaxNetDevice+Enqueue()+Receive()+Send()+SendBurst()+ProcessMacMessage()WimaxSSNetDevice +StartDlSubFrame()+StartUlSubFrame()+Enqueue()+Receive()+Send()+SendBursts()+CreateMapMessages()+CreateDescriptorMessages()+SetBurstProfiles()WimaxBSNetDevice1

1 1 1..*

1..* 11..*

1-modulation-fecBurstProfile

Figure 2: Class diagram of the proposed WiMAX module.

upcoming DL or UL burst (or grant).

The detailed contents of DL-MAP and UL-MAP IE are asfollows. Each DL-MAP IE includes, among others, a CIDfield identifying an SS (or a set of SSs in case of multicastor broadcast) that will be receiving the corresponding DLburst, and a DIUC (Downlink Interval Usage Code) indicat-ing a burst profile to be used to receive the burst. A burstprofile defines a set of PHY parameters that the SS mustuse to send or receive packets. DL and UL burst profiles aredefined in DCD and UCD, respectively. DL-MAP IE alsoincludes a Start Time field that allows SSs to go into sleep

mode and wake up when start time is elapsed. This field iscurrently not utilized as the module does not implement thepower saving feature. Similarly, each UL-MAP IE notifiesof an upcoming UL grant. Besides the CID of the SS thatis allocated the grant, it includes a Start Time field thatmarks the beginning of the grant, a duration field indicatingduration of the grant, and a UIUC (Uplink Interval UsageCode) that maps to a UL burst profile in the UCD message.

DCD and UCD messages include information about the chan-nel as well as a set of burst profiles. The Burst ProfileManager component (see Figures 1 and 2) is responsible

Frame n-1 Initial rangingOpportunities Frame n+1Frame n Frame n+2UL burst 1DL burst 1 DL burst 2 DL burst nDownlink subframe Uplink subframeDL-MAP UL-MAP DCD UCDDCD Count BS IDConf. Chng. Count Channel InformationDownlinkBurst Profile n UplinkBurst Profile 1 UplinkBurst Profile nStart Time UL-MAP IE nStart TimeUIUC Modulation/FECDIUC Modulation/FECConf. Chng. Count Rang. BO Start/EndDownlinkBurst Profile 1

Uplink Channel ID UIUC CIDCIDDIUCChannel InformationDL-MAP IE 1 MAC PDU nMAC PDU 1 MAC message payloadMAC Hdr.UCDCount

UL burst 2 UL burst 3 UL burst nDL-MAP IE n UL-MAP IE 1Allocation Start TimeReq. BOStart/End

Figure 3: Format of the MAC frame and key man-agements messages.

of defining burst profiles and creating these messages. UCDmessage contains important parameters including the back-off limits for the contention ranging and bandwidth requestprocesses, and size of the ranging and the bandwidth requesttransmission opportunities. DCD message contains informa-tion including the size of the TTG (Transmit/receive Tran-sition Gap) and RTG (Receive/transmit Transition Gap), anumber identifying the current frame, and the duration ofthe frame. The burst profile data structure contains a com-bination of modulation and FEC code and a DIUC/UIUCuniquely identifying the burst profile. For the WirelessMAN-OFDM PHY layer, seven combinations of modulation andFEC codes are supported (see Table 4).

The four management messages described above are alwayssent in the first burst in the DL subframe, that containsbroadcast messages. In current implementation, DL-MAPand UL-MAP are sent in every frame and DCD and UCDare sent on random basis simulating the real network wheredefinitions of burst profiles may update with time. The restof the bursts in the subframe are regular data bursts directedtowards individual SSs (or a set of SSs).

As an SS receives a DL-MAP message, it iterates throughthe DL-MAP IEs to determine if a DL burst is directedtowards it following the current broadcast burst. If so, itreceives the burst by decoding it using the parameters in thecorresponding burst profile. Similarly, as an SS receives aUL-MAP indicating an UL grant for it, the SS starts sendingits pending data as the start time of the grant elapses.

3.3.2 Outbound and Uplink SchedulersThe standard defines two types of schedulers. The outboundscheduler that selects packets from the outbound queuesto send, and the BS uplink scheduler that allocates band-width to SSs in the UL, to allow them sending their pack-ets. Classes SSScheduler and BSScheduler in Figure 2 im-plement the outbound schedulers of SS and BS, and class

UplinkScheduler implements the BS uplink scheduler. TheBS Scheduler (also referred to as Downlink Scheduler) sched-ules, out of the various connections queues, packets to sendin the DL subframe. The SS Scheduler schedules, out ofits connections queues, packets to send in an UL grant allo-cated to it. The Uplink Scheduler manages UL bandwidth,with the help of Bandwidth Manager, and schedules SSs thatwill be allocated UL grants based on the QoS requirementsof the their service flow(s) and bandwidth requests (see Sec-tions 3.3.5 and 3.3.7). Note that the standard does not defineany particular scheduling algorithm for these schedulers andleaves it to the manufacturers to decide (see Section 3.3.6).

The Downlink Scheduler and Uplink Scheduler componentsof BS are invoked at the beginning of every MAC frame.These two schedulers are responsible of creating the DL andUL subframes (or the DL-MAP and UL-MAP messages),respectively. The Downlink Scheduler creates the burststo send in the DL subframe by selecting packets, from thequeues of all SSs registered with the BS. A burst may con-tain multiple packets for the same SS the burst is directedtowards. As seen in Figure 1, the BS performs schedulingon queue per connection per SS basis (see Section 3.3.4 fordetails on connections) instead of maintaining a single queueper SS or per scheduling service type. This design has beenpreferred over the latter due to expensive computations itinvolves. After creating the bursts, it creates a list of DL-MAP IEs, each IE pointing to a burst. These pre-createdDL-MAP IEs are then used to create the DL-MAP in thefirst burst of DL subframe. The pre-created bursts are sentfollowing the first burst. Similarly, the Uplink Scheduler cre-ates a list of UL-MAP IEs and based on that the UL-MAPis created. The SS Scheduler is invoked every time a ULgrant is allocated to the SS.

3.3.3 Network Entry and InitializationThe network entry and initialization phase is basically di-vided into two sub-phases, (1) scanning and synchronizationand (2) initial ranging. The entire phase is performed by theLink Manager component of SS and BS.

Scanning and SynchronizationOnce an SS wants to join the network, it first scans the down-link frequencies to search for a suitable channel. The searchis complete as soon as it detects a PHY frame. The next stepis to establish synchronization with the BS. Once SS receivesa DL-MAP message the synchronization phase is completeand it remains synchronized as long as it keeps receivingDL-MAP and DCD messages. After the synchronization isestablished, SS waits for a UCD message to acquire uplinkchannel parameters. Once acquired, the first sub-phase ofthe network entry and initialization is complete.

Initial Ranging and RegistrationOnce synchronization is achieved, the SS waits for a UL-MAP message to locate a special grant, called initial rang-ing interval, in the UL subframe. This grant is allocated bythe BS Uplink Scheduler at regular intervals, and is alwaysthe first grant if present. It is always directed towards theBroadcast CID and uses the predefined most robust burstprofile with BPSK 1/2 modulation/FEC. Currently this in-terval is set to 0.5 ms, however the user is enabled to modifyits value from the simulation script.

perform contention resolutionallocate initial ranging interval in UL subframesend RNG-REQ in an IR opportunitysend RNG-RSP with management CIDssend RNG-RSP, including parameters to adjustsend RNG-REQ in an IR opportunityallocate invited opportunity (UL grant)send RNG-REQ in UL grantsend RNG-RSP, accepting rangingadjust parametersperform contention resolution

SS BScreate management connectionscreate management connectionsstore SS in SS database

Figure 4: Initial ranging process.

Initial ranging interval is composed of one or more transmis-sion opportunities. The size of a opportunity is fixed, it isdetermined by the BS and allows sufficient time to send aRNG-REQ message including the overhead (SS learns itssize from UCD message). Once located, the SS sends aRNG-REQ message after performing a backoff based con-tention resolution process.

The BS upon receiving a RNG-REQ responds with a RNG-RSP message indicating if the ranging is accepted or not, orindicating the SS to adjust its timing offset/power param-eters. At the same time the SS Manager component addsthe SS in its database of SSs. The SS Manager componentis extensively used by the BS to manage SSs in various ofits operations. The exchange of RNG-REQ and RNG-RSPmessages continues until the ranging is accepted or rejected.Figure 4 illustrates a simplified scenario of initial rangingphase. Note that initial ranging is initially performed onthe predefined initial ranging connection until BS allocatesthe Basic and Primary management connections to the SSthrough the RNG-RSP message. From this point onwardsSS is allocated an invited (or unicast) ranging opportunity(basically a UL grant), to continue ranging process.

3.3.4 Connections and AddressingAll communication at the MAC layer is carried in terms ofconnections. The standard defines a connection as a unidi-rectional mapping between the SS and BS’s MAC entitiesfor the transmission of traffic. As discussed in Section 2,the standard defines two types of connections: managementconnections for transmitting control messages and transportconnections for data transmission. A connection is identifiedby a 16-bit CID (Connection Identifier). Classes Wimax-Connection and ConnectionIdentifier in Figure 2 implementthe connection and CID, respectively. Note that each con-nection maintains its own transmission queue where packetsto transmit on that connection are queued. The Connection

Manager component of BS is responsible of creating andmanaging connections for all SSs.

The two key management connections defined by the stan-dard, namely the Basic and Primary management connec-tions, are created and allocated to the SS during the rangingprocess. Basic connection plays an important role through-out the operation of SS also because all (unicast) DL andUL grants are directed towards SS’s Basic CID. In addi-tion to management connections, an SS may have one ormore transport connections to send data packets (see Sec-tion 3.3.5).

The Connection Manager component of SS manages theconnections associated to SS. As defined by the standard, amanagement connection is bidirectional, i.e., a pair of down-link and uplink connections is represented by the same CID.This feature is implemented in a way that one connection(in DL direction) is created by the BS and upon receivingthe CID the SS then creates an identical connection (in ULdirection) with the same CID.

Table 1: CID value ranges.CID ValueInitial Ranging 0x000Basic 0x000 - mPrimary m+1 - 2mTransport and Secondary 2m+1 - 0xFE9FMulticast 0xFEA0 - 0xFEFEMulticast Polling 0xFF00 - 0xFFF9Broadcast 0xFFFF

Note that since MAC is completely connection oriented, theMAC address of SS is only used during the initial rang-ing phase before management CIDs are assigned. Once as-signed, management and transport CIDs are used to addressthe SS and individual transport connections associated toSS. The CID is included in the MAC header of each packetto indicate the connection the packet would be sent on. TheCID Factory component (class CidFactory in Figure 2) atBS generates unique CIDs for all types of connections. Ta-ble 1 lists ranges of CID values for each type of connectionas defined by the standard.

3.3.5 Service Flow CreationThe standard defines a service flow as an unidirectional flowof MAC PDUs on a transport connection that ensures spe-cific QoS requirements. A service flow is identified by a32-bit Service Flow ID (SFID) and is associated to exactlyone transport connection and QoS parameter set. ClassesServiceFlow and QoSParameterSet in Figure 2 implementservice flow and QoS parameter set, respectively. The Ser-vice Flow Manager component at the BS is responsible ofcreating and managing service flows.

The standard defines two mechanisms of service flow cre-ation: a SS-initiated mechanism where SS requests the BSto create a service flow, and a BS-initiated mechanism whereBS automatically creates service flow for the SS. The mod-ule implements the first of the above mechanisms. In thismechanism the user is allowed to setup, for each applica-tion he/she intends to simulate, a QoS parameter set that

matches the QoS requirements of the application. Once theSS is registered, it sends a request (a DSA-REQ message)to the BS, along with the predefined QoS parameter set, tocreate the service flow. The BS examines the parametersand assuming that all parameters are supported, creates aservice flow (and transport connection) and responds with aDSA-RSP message. The SS may now start using the serviceflow to send/receive data.create service flow with user-defined QoS parameterssend DSA-REQ, including user-defined QoS parameterssend DSA-RSP, including SFID, CID and QoS parameterssend DSA-ACKcreate transport connectionupdate service flow with SFID and QoS parameters

SS BScreate transport connection create service flowregister QoS parametersset service flow as activeregister QoS parameters

Figure 5: Service flow creation process.

Figure 5 shows the main steps of service flow creation pro-cess. All DSA messages are sent on the Primary manage-ment connection. The entire service flow creation processis performed by the Service Flow Manager components ofSS and BS. Multiple service flows per SS are allowed andthe above message exchange is invoked for each service flow.Note that a pair of service flows must be created with thesame QoS parameters for both sender and receiver. Alsonote that an SS can not start data transmission unless ithas acquired at least one service flow.

3.3.6 Scheduling ServicesThe module supports the four scheduling services (UGS,rtPS, nrtPS, BE) defined by the 802.16-2004 standard. Thesescheduling services behave differently with respect to howthey request bandwidth as well as how the it is granted.Each service flow is associated to exactly one scheduling ser-vice, and the QoS parameter set associated to a service flowactually defines the scheduling service it belongs to. Table2 lists the mandatory QoS parameters defined by the stan-dard that must be supported by a scheduling service. Whena service flow is created the Uplink Scheduler calculates nec-essary parameters such as grant size and grant interval basedon QoS parameters associated to it. For the real-time ser-vices (UGS and rtPS) the BS then allocates grants/polls onregular basis, based on the calculated interval. For the non-real-time services (nrtPS and BE) only minimum reservedbandwidth is guaranteed, if available after servicing real-time flows. Note that not all of the listed parameters arecurrently utilized by the scheduler. Also note that currentlyonly service flows with fixed packet size are supported.

As discussed in Section 3.3.2, the standard does not sug-

Table 2: Scheduling services and suggested param-eters.Scheduling Service Parameter

UGS

SDU SizeMinimum Reserved Traffic RateMaximum LatencyRequest/Transmission PolicyUnsolicited Grant Interval

rtPS

Maximum LatencyMinimum Reserved Traffic RateMaximum Sustained Traffic RateTraffic PriorityRequest/Transmission PolicyUnsolicited Polling Interval

nrtPS

Minimum Reserved Traffic RateMaximum Sustained Traffic RateTraffic PriorityRequest/Transmission Policy

BEMaximum Sustained Traffic RateRequest/Transmission Policy

gest any scheduling algorithm for the schedulers. The im-plemented schedulers work based on a simple priority-basedFCFS (First Come First Served) algorithm. For the uplinkscheduling, priority is given starting from highest priorityscheduling type to the lowest priority one (UGS > rtPS >nrtPS > BE). Among the flows of same scheduling type, pri-ority is given on FCFS basis. For the BS and SS (outbound)schedulers, higher priority is given to the initial ranging andmanagement connections, i.e., broadcast > initial ranging >basic > primary > UGS > rtPS > nrtPS > BE. Followingis a brief overview of the implemented scheduling.

UGS SchedulingUGS (Unsolicited Grant Service) is designed for real-timeapplications with fixed packet size. It guarantees bandwidthon real-time basis, by allocating the flow UL grants on reg-ular basis. The key parameters for this service are toler-ated jitter, maximum latency and minimum reserved traf-fic rate. The tolerated jitter parameter specifies the maxi-mum tolerated delay variation and maximum latency spec-ifies the maximum delay between arrival and forwarding ofthe packet (at the BS side). The Minimum reserved trafficrate parameter specifies the minimum bandwidth (in bps)that must be reserved for the flow. These parameters aresupplied by the user while setting up the service flow. Basedon these parameters, the BS calculates the interval, calledunsolicited grant interval, when the service flow must be al-located a grant. The Downlink Scheduler, while schedulingUGS traffic, must ensure that the latency requirements ofthe flow are met. Every time the scheduler is invoked, thequeues are refreshed and packets whose latency deadlineshave elapsed are dropped.

rtPS SchedulingrtPS (Real-Time Polling Service) is designed for real-timeapplications with variable packet size, and is ensured ULgrants on periodic basis. For a rtPS flow, the BS polls theSS with a special grant, referred to as request opportunity,allowing it to send bandwidth request. The BS in responseallocates sufficient bandwidth (see Section 3.3.7 for details)

in the subsequent frames. This mechanism enables the SSto specify the size of the grant, to meet flow’s variable sizetraffic needs. However, compared to UGS, rtPS incurs moreoverhead due to the bandwidth request packets. The keyparameters for rtPS service are maximum latency and min-imum reserved traffic rate. The BS, based on these parame-ters, calculates the polling interval (unsolicited polling inter-val). The Uplink Scheduler ensures the flow of the minimumbandwidth. Like UGS, the Downlink Scheduler makes surethat the latency requirements of the flow are met.

nrtPS SchedulingThe only difference between rtPS and nrtPS (Non-Real-Time Polling Service) is that the latter is designed for non-real-time applications. nrtPS flows are not polled on pe-riodic basis and instead only when sufficient bandwidth isavailable. SS then specifies the size of the grant through thebandwidth request packet and BS responds by allocatingsufficient bandwidth only when available. However the BSensures the flow of the minimum bandwidth (based on min-imum reserved traffic rate parameter) by periodically mon-itoring total bandwidth granted to the flow. Currently thisperiod is set to one second. nrtPS does not use the maximumlatency parameter.

BE SchedulingBE (Best Effort) service, as the name suggests, is designedfor the low priority best effort applications. For a BE flow,the scheduler allocates bandwidth only when sufficient band-width is available after servicing higher priority flows. Nominimum bandwidth is guaranteed for this service.

3.3.7 Bandwidth Request and Grant MechanismBandwidth request and grant mechanism is a key featureof the WiMAX MAC since all three non-UGS schedulingtypes explicitly request for bandwidth by sending a band-width request packet. The bandwidth request and grantmechanism is implemented through the Bandwidth Managercomponents of BS and SS.

The mechanism works as follows. An SS with rtPS, nrtPSor BE flow is polled by the BS, by allocating it a requestopportunity, on periodic basis. A request opportunity is ba-sically a UL grant, directed towards SS’s Basic CID, howeverit cannot be used to send data packets. It is distinguished(from regular UL grants for data) by the predefined mostrobust burst profile that must be used to send bandwidth re-quest in it. The size of this grant is fixed, allowing sufficientbandwidth to send a bandwidth request packet. A band-width request packet includes a special Bandwidth RequestHeader. The BR field of this header is used to notify theBS the requested bandwidth (in units of bytes). As the SSreceives a poll, the SS Scheduler iterates through SS’s non-UGS flows and for a flow with pending packets, it sets theBR field to the size of the packet in front of the queue. CIDfield of the header is set to flow’s CID. The bandwidth re-quest packet is then sent and the BS responds by allocatingsufficient bandwidth in subsequent frames. Figure 6 illus-trates the main steps of bandwidth request/grant process.The inclusion of Bandwidth Request Header is mutually ex-clusive with Generic MAC Header. The standard defines anoptional piggyback request feature that allows sending band-width request piggybacked with data. However this feature

is not supported in our implementation.poll SS (by allocating a request opportunity)send bandwidth request packetSS BSallocate bandwidth (i.e. an uplink grant)send dataFigure 6: Bandwidth request/grant process.

As discussed above, bandwidth is always requested on a perflow basis but granted on per SS basis. The SS Schedulerthen decides which flow shall send its data in the given grant.For the UGS and rtPS flows, the scheduler utilizes the un-solicited grant interval and unsolicited polling interval pa-rameters, respectively, by selecting the flow whose intervalis closest to elapse. The non-real-time services (nrtPS andBE) are serviced only if sufficient bandwidth is left.

Since all SSs with at least one UGS service flow are au-tomatically allocated grants to service their UGS traffic,if such an SS has a non-UGS flow, it must notify this tothe BS in order to be polled to send bandwidth requests.This is done by setting the poll-me field of a special type ofsubheader, called Grant Management Subheader. This sub-header is included together with the Generic MAC Header.The BS upon receiving a UGS packet with the poll-me fieldset, starts polling the SS for non-UGS flows.

3.3.8 MAC QueueAs discussed in Section 3.3.4, each connection maintains itsown transmission queue. In order to support a number ofMAC specific features, the module implements its own spe-cialized queue (class WimaxMacQueue in Figure 2). Thisqueue data structure supports storing packets and headersseparately, enabling the schedulers to determine in advancethe CID of the connection a packet will be sent on, withoutdequeueing the packet, by peeking the header. Header is ap-pended to packet only when packet is dequeued and is aboutto be sent, following the scheduling phase. Furthermore,in order to implement the bandwidth request/grant mecha-nism, the queue data structure is designed to support bothtypes of packets, the regular packets and the bandwidth re-quest packets. As discussed in Section 3.3.7, the two packettypes contain two different types of headers. Note that thequeue still functions in FIFO (First In First Out) fashionfor both types of packets, in that the queue is iterated andthe first packet of the respective type is accessed/dequeued.Also note that this functionality is only used by the SS, asthe BS does not send bandwidth request packets.

3.4 The PHY LayerThe module provides two different versions of the PHY layer.The first is a basic PHY implementation which simply for-wards bursts received by the MAC layer ignoring any under-lying PHY layer details. Class SimpleWimaxPhy in Figure 2represents this simple PHY layer. The second is the OFDM

PHY layer based on the WirelessMAN-OFDM specification,represented by class OfdmWimaxPhy in the figure. Sincethe OFDM PHY deals with the channel encoding blocks (orFEC blocks), packet bursts are converted to bit-streams andthen splitted into smaller FEC blocks. The PHY currentlyworks at 5 GHz license-free band assuming 20 MHz channelbandwidth and a 10 milliseconds frame following the param-eters used in [15]. This results in OFDM symbol durationof 13.89 µs, hence 720 symbols per frame. Table 3 lists thekey PHY parameters.

Table 3: OFDM PHY parameters.Parameter Calculation ValueFrequency band 5 GHzFrame duration 10 msBandwidth BW 20 MHzCarriers NFFT 256Data carriers 192Sampling factor n 144/125Sampling frequency Fs n.BW 23.04 MHzSubcarrier spacing f∆ Fs/NFFT 90000G Tg/Tb 1/4Useful symbol time Tb 1/f∆ 11.11 µsCyclic Prefix time Tg G.Tb 2.78 µsOFDM symbol time Ts Tb + Tg 13.89 µsPS duration 4/Fs 0.1736 µs

The PHY utilizes an external OFDM PHY module [12],which implements the fundamental phases of the OFDMPHY layer following the specification. This module utilizesexternal mathematics and signal processing library IT++[5]. The FEC blocks are forwarded to this module whichthen performs the fundamental operations of channel en-coding, randomization, interleaving and modulation etc, andtransmits it to the channel (and the reverse process at thereceiving side). In this respect the OfdmWimaxPhy classalso serves as an interface to this external OFDM module.

WirelessMAN-OFDM PHY supports seven modulations to-gether with FEC coding rates. Table 4 lists these modula-tions with the corresponding data rates.

Table 4: Modulation and coding rates and corre-sponding data rates.

Modulation Coding Block Data RateRate Size [Mbps]

BPSK 1/2 12 6.91QPSK 1/2 24 13.82QPSK 3/4 36 20.7416 QAM 1/2 48 27.6516 QAM 3/4 72 41.4764 QAM 2/3 96 55.3064 QAM 3/4 108 62.21

3.4.1 OperationThe OFDM PHY layer works as follows. Once it receives apacket burst from the MAC layer, this burst is converted intoa plain stream of bits. This bit-stream is splitted into smallerFEC blocks depending on the modulation scheme currentlybeing used. Table 4 lists block sizes for the seven modu-lations as defined by the standard. These blocks are then

forwarded to the OFDM module one by one. The OFDMmodule performs the fundamental PHY operations on theblock and forwards it to the channel layer which transmitsthe block. The PHY layer at the receiving side then per-forms the reverse operations of concatenating the blocks tobit-stream and converting it back to packet burst. The burstis then forwarded to the MAC layer.

3.4.2 DesignThe design of the PHY layer facilitates addition of new PHYlayers in future. As seen in Figure 2, WimaxPhy is definedas an abstract class and must be extended to add a newPHY implementation, as currently done for simple PHY andOFDM PHY implementations. Similarly, WimaxChannelprovides abstract implementation of the channel, to allowaddition of PHY-compatible channel. Currently the sim-ple PHY implementation uses the compatible SimpleWimax-Channel, which transmits packet bursts, and the OFDMPHY uses OfdmWimaxChannel, which transmits FEC blocks.This design enables users to easily plug-in or switch to dif-ferent PHY layers from the simulation script.

4. LIMITATIONS AND FUTURE WORKThe module currently lacks a full implementation of the clas-sifier as well as support for fragmentation and de-fragmentationof PDUs. Due to the lack of classifier, the module currentlyallows simulating only one service flow per SS. A classifieris used to map incoming packets to appropriate connections(or service flows) based on a set of criteria. An incomingpacket from higher layer does not contain sufficient infor-mation to map it to a service flow of a particular schedulingservice. To make it work some updates needs to be done inconjunction with the higher layers, particularly the Applica-tion layer. It should be noted that due to these complexities,none of the available WiMAX modules discussed in Section1 implements a full, standard-complaint classifier.

IP over IEEE 802.16 [16] is a much highlighted area of dis-cussion ever since the release of the standard. One of thekey issues when deploying IP over IEEE 802.16 networks ishow to configure an IP Subnet over a MAC which is essen-tially connection-oriented and point-to-point. Furthermoresince the MAC address is not included in the IEEE 802.16frame headers, so typical usage of the Address ResolutionProtocol (ARP) does not apply. Appropriate updates thusneed to be done following [19] and [17] in order to make themodule compliant to that. In particular, the IP and Ether-net specific subparts of the convergence sublayer has to beupdated.

Currently the schedulers implement a simple FCFS based al-gorithm. The standard does not specify a definitive schedul-ing algorithm and leaves this up to the manufacturers todecide which algorithm to adopt. A lot of research is cur-rently going on this topic and a number of algorithms havebeen proposed. A potential future work therefore is to up-date schedulers with a more sophisticated algorithm. Sim-ilarly the bandwidth management mechanism may also beupdated with a more efficient algorithm.

Work on a propagation/error model at the PHY layer iscurrently under way. Another future work is to add supportin the BS to dynamically update burst profile information,

which is actually dependent on the implementation of thepropagation/error model.

5. CONCLUSIONSThis paper presented detailed design and implementation ofan IEEE 802.16 WiMAX module for the recently releasedns-3 simulator. The proposed module implements the PMPmode and two different PHY layers: a basic PHY layerthat simply forwards bursts received from the MAC layerand a more complete WirelessMAN-OFDM PHY that fol-lows the standard. Module’s design thoroughly follows theobject-oriented software development methodology and uti-lizes Unified Modeling Language (UML) for modeling. Highattention has been put to come up with a detailed and stan-dard compliant implementation and to design an API thatfacilitates reusability, scalability and maintainability of soft-ware. The module implements key components of WiMAXMAC, including QoS scheduling services, link manager, ser-vice flow manager, simple priority/FCFS based schedulers,and bandwidth manager. Benefiting from the features ofns-3, the module enables detailed tracing, simulation of realTCP/IP-stack, emulation, and additions of new scenariosusing the Helper API. We hope this module contributes tothe scientific society and facilitates in evaluating and design-ing WiMAX systems. The paper also discussed a number oflimitations of our module including absence of a full classifierto map incoming packets to appropriate connections. Futurework focuses on implementation of convergence sublayer forIP over IEEE 802.16 applications and updating schedulerswith more efficient algorithms.

6. ACKNOWLEDGMENTSThe authors would like to thank Fabio Cristiani of Univer-sita degli Studi di Napoli Federico II and Kave Salamatian ofLIP6 (Laboratoire d’informatique de Paris 6) for contribut-ing with their OFDM PHY work. We would also like tothank Mathieu Lacage, our colleague at INRIA Sophia An-tipolis and one of the lead developers of ns-3 project, for hisvaluable time and suggestions during the early stages of thedevelopment.

7. REFERENCES[1] IEEE Std. 802.16-2004, IEEE Standard for Local and

Metropolitan Area Networks - Part 16: Air Interfacefor Fixed Broadband Wireless Access Systems.October 2004.

[2] DOCSIS (Data Over Cable System InterfaceSpecification) Research Project,http://www.cs.clemson.edu/∼jmarty/docsis.html,July 2005.

[3] IEEE Std. 802.16e-2005, IEEE Standard for Local andMetropolitan Area Networks - Part 16: Air Interfacefor Fixed Broadband Wireless Access Systems -Amendment 2: Physical and Medium Access ControlLayers for Combined Fixed and Mobile Operation inLicensed Bands. February 2006.

[4] The Network Simulator ns-2 NIST add-on - IEEE802.16 model (MAC+PHY). Technical report,National Institute of Standards and Technology, June2007.

[5] IT++ - Library of mathematical, signal processingand communication routines,

http://itpp.sourceforge.net/, July 2008.

[6] The network simulator - ns-2,http://www.isi.edu/nsnam/ns/, October 2008.

[7] The ns-3 network simulator, http://www.nsnam.org/,October 2008.

[8] WiMAX Forum System Level Simulator NS-2MAC+PHY Add-On for WiMAX (IEEE 802.16).Technical report, WiMAX Forum, July 2008.

[9] A. Belghith and L. Nuaymi. Design andImplementation of a QoS-included WiMAX Modulefor ns-2 Simulator. In 2nd International Conference onSimulation Tools and Techniques (SIMUTools’09).ACM, March 2008.

[10] J. F. Borina and N. L. da Fonseca. WiMAX Modulefor the ns-2 Simulator. In 18th Annual IEEEInternational Symposium on Personal, Indoor andMobile Radio Communications (PIMRC’07). IEEE,September 2007.

[11] J. Chen, C.-C. Wang, F. C.-D. Tsai, C.-W. Chang,S.-S. Liu, J. Guo, W.-J. Lien, J.-H. Sum, and C.-H.Hung. Design and Implementation of WiMAX Modulefor ns-2 Simulator. In 1st International Conference onPerformance Evaluation Methodologies and Tools(VALUETOOLS’06). ACM, October 2006.

[12] F. Cristiani. Simulation of WiMAX Physical Layer.Technical report, Universita degli Studi di NapoliFederico II, Italy, December 2007.

[13] C. Eklund, R. B. Marks, and K. L. Standwood. IEEEStandard 802.16: A Technical Overview of theWirelessMAN Air Interface for Broadband WirelessAccess. IEEE Communications Magazine,40(6):98–107, June 2002.

[14] T. R. Henderson, M. Lacage, and G. F. Riley.Network Simulations with the ns-3 Simulator. Demopaper at ACM SIGCOMM’08, August 2008.

[15] C. Hoymann. Analysis and Performance Evaluation ofthe OFDM-based Metropolitan Area Network IEEE802.16. Computer Networks, Selected Papers from theEuropean Wireless 2004 Conference, 49(3):341–36,October 2005.

[16] J. Jee, S. Madanapalli, and J. Mandin. IP over IEEE802.16 Problem Statement and Goals. RFC 5154,April 2008.

[17] H. Jeon, M. Riegel, and S. Jeong. Transmission of IPover Ethernet over IEEE 802.16 Networksdraft-ietf-16ng-ip-over-ethernet-over-802.16-06.txt.IETF Draft, April 2008.

[18] C. Larman. Applying UML and Patterns: AnIntroduction to Object-Oriented Analysis and Designand Iterative Development. Prentice Hall, thirdedition, 2004.

[19] S. Madanapalli, S. D. Park, and S. Chakrabarti.Transmission of IPv4 packets over IEEE 802.16’s IPConvergence Sublayerdraft-ietf-16ng-ipv4-over-802-dot-16-ipcs-03.txt. IETFDraft, July 2008.

[20] L. Nuaymi. WiMAX: Technology for BroadbandWireless Access. John Wiley & Sons, 2007.