Wimax Forum System Level Simulator

AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST)

-DRAFT 03/20/09- - 1 -

Project WiMAX Forum Application Working Group

Title The WiMAX Forum System Level Simulator

Number andFile Name

The WiMAX Forum System Level Simulator NS-2 MAC+PHY Add-On for WiMAX

(IEEE 802.16)

NS-2 Development Team (Contacts: Shyam Parekh,Alcatel-Lucent; Biplab Sikdar, RPI)

Are all proposing organizations members of theWiMAX Forum? Yes [X ] No [ ]

Source(s)

Original Document

Membership This contribution examines coexistence issues between WiMAX and WiMAX and non-WiMAX systems.

Re: New Document

Rational

This document is submitted to the WiMAX Forum as a basis for discussion and is not binding on thecontributing individual(s) or organization(s). The material in this document is subject to change in formand content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw materialcontained herein.

Current TextSectionNumber

Each contributor grants a free, irrevocable license to the WiMAX Forum to incorporate materialcontained in this contribution, and any modifications thereof, in the creation of a WiMAX Forumpublication and at the WiMAX Forum’s sole discretion to permit others to reproduce in whole or in partthe resulting WIMAX Forum publication. The contributor also acknowledges and accepts that thiscontribution may be made public by WiMAX Forum. Complete IPR and copyright rules governingcontributions submitted to the WiMAX Forum are available from the WiMAX Forum administrator.

Notice

Release


-DRAFT 03/20/09- - 2 -

WiMAX Forum System Level Simulator

NS-2 MAC+PHY Add-On for WiMAX (IEEE 802.16)

Version 2.6 (Beta), March 20, 2009

This is an unapproved draft, subject to change.March 2009 DRAFT

WiMAX Forum ProprietaryFor Reference Purposes Only

© 2009 WiMAX Forum. All Rights Reserved.


-DRAFT 03/20/09- - 3 -

Copyright Notice, Use Restrictions, Disclaimer, and Limitation of Liability.

The WiMAX ForumTM owns the copyright in this document and reserves all rights therein. Use of thisdocument and any related materials is limited as follows:

A. WiMAX Forum members MAY use this document for the sole purpose of participating inapproved WiMAX Forum activities, including the activities of the Working Group that hasproduced it.

B. Participants in the standards development activities of other organizations MAY use thisdocument for reference purposes, namely (i) to review and evaluate the WiMAX Forum’suse and implementation of third-party standards in its technical documents, and (ii) toreview, evaluate and, in their sole discretion, adapt their standards activities in a mannerthat encourages, promotes and/or implements enhanced compatibility and/orinteroperability between their respective standards and the standards that the WiMAXForum is promoting.

A user of this document MAY duplicate and distribute copies of the document in connection with theauthorized uses described above. Any duplication in whole or in part will include the copyright notice on thefirst page of this document and all notices and restrictions contained in this Section of the document(“Copyright Notice, Use Restrictions, Disclaimers and Limitation of Liability”) . Except for the foregoing or asexpressly authorized by the WiMAX Forum in writing, any other use of this document and all other duplicationand distribution of this document are prohibited. The WiMAX Forum regards the unauthorized use, duplicationor distribution of this document by a member as a material breach of the member’s obligations under theorganization’s rules and regulations, which MAY result in the suspension or termination of its WiMAX Forummembership. Unauthorized use, duplication, or distribution by nonmembers is an infringement of the WiMAXForum’s copyright. Distribution of this document to persons or organizations that are not involved in thestandards development process or who are not WiMAX Forum members is prohibited.

Use of this document is subject to the additional disclaimers and limitations described below. By using thisdocument, the user agrees to the following terms and conditions:

THIS DOCUMENT IS PROVIDED “AS IS” AND WITHOUT WARRANTY OF ANY KIND . TO THEGREATEST EXTENT PERMITTED BY LAW, THE WiMAX FORUM DISCLAIMS ALL EXPRESS,IMPLIED AND STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, THEIMPLIED WARRANTIES OF TITLE, NONINFRINGEMENT, MERCHANTABILITY AND FITNESSFOR A PARTICULAR PURPOSE. THE WiMAX FORUM DOES NOT WARRANT THAT THISDOCUMENT IS COMPLETE OR WITHOUT ERROR AND DISCLAIMS ANY WARRANTIES TOTHE CONTRARY.

The user acknowledges that any products or services provided using technology described in or implemented inconnection with this document MAY be subject to various regulatory controls under the laws and regulations ofvarious governments worldwide. The user acknowledges that it is solely responsible for the compliance of itsproducts with any such laws and regulations and for obtaining any and all required authorizations, permits, orlicenses for its products as a result of such regulations within the applicable jurisdiction.

NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER REGARDINGTHE APPLICABILITY OR NON-APPLICABILITY OF ANY SUCH LAWS OR REGULATIONS ORTHE SUITABILITY OR NON-SUITABILITY OF ANY SUCH PRODUCT OR SERVICE FOR USE INANY JURISDICTION.

NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER REGARDINGTHE SUITABILITY OR NON-SUITABILITY OF A PRODUCT OR A SERVICE FORCERTIFICATION UNDER ANY CERTIFICATION PROGRAM OF THE WiMAX FORUM OR ANYTHIRD PARTY.

The user acknowledges that the WiMAX Forum has not investigated or made an independent determinationregarding title or noninfringement of any technologies that MAY be incorporated, described or referenced inthis document. Use of this document or implementation of any technologies described or referenced hereinMAY therefore infringe undisclosed third-party patent rights or other intellectual property rights. The useracknowledges that it is solely responsible for making all assessments relating to title and noninfringement of


-DRAFT 03/20/09- - 4 -

any technology, standard, or document referenced in this document and for obtaining appropriate authorizationto use such technologies, technologies, standards, and documents, including through the payment of anyrequired license fees.

NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES OF TITLE ORNONINFRINGEMENT WITH RESPECT TO ANY TECHNOLOGIES, STANDARDS ORDOCUMENTS REFERENCED OR INCORPORATED INTO THIS DOCUMENT.

IN NO EVENT SHALL THE WiMAX FORUM OR ANY MEMBER BE LIABLE TO ANY OTHERMEMBER OR TO A THIRD PARTY FOR ANY CLAIM ARISING FROM OR RELATING TO THEUSE OF THIS DOCUMENT, INCLUDING, WITHOUT LIMITATION, A CLAIM THAT SUCH USEINFRINGES A THIRD PARTY’S INTELLECTUAL PROPERTY RIGHTS OR THAT IT FAILS TOCOMPLY WITH APPLICABLE LAWS OR REGULATIONS. BY USE OF THIS DOCUMENT, THEUSER WAIVES ANY SUCH CLAIM AGAINST THE WiMAX FORUM AND ITS MEMBERSRELATING TO THE USE OF THIS DOCUMENT.

The WiMAX Forum reserves the right to modify or amend this document without notice and in its solediscretion.

“WiMAX,” “WiMAX Forum,” “WiMAX Certified,” and “WiMAX Forum Certified” are trademarks of theWiMAX Forum. Third-party trademarks contained in this document are the property of their respective owners.


-DRAFT 03/20/09- - 5 -

The WiMAX Forum System LevelSimulator NS-2 MAC+PHY Add-On for

WiMAX (IEEE 802.16)

A Collaborative Effort of Application Working Group (AWG), WiMAX Forum andNational Institute of Standards and Technology (NIST)

March 20, 2009

NIST Team: Nada Golmie, Richard RouilRPI Team: David Doria, Xingting Guo, Raj Iyengar, Prof. Shiv Kalyanaraman, Sharath Krishnaiyer, Sampad Mishra, Prof. Biplab SikdarWUSTL Team: Prof. Raj Jain, Ritun Patney, Chakchai So-InWiMAX Forum Task Lead: Shyam Parekh (Alcatel-Lucent)

Special thanks are due to the following individuals for their contributions:Manish Airy (Beceem)Alberto Bestetti (Alcatel-Lucent)Shaili Desai (University of Maryland)Salih Ergut (Nextwave)Arun Ghosh (AT&T)Giovanni Giambene (University of Siena)Snezana Hadzic (University of Siena)Jie Hui (Intel)Jay Kim (Samsung)John Kim (Sprint-Nextel)Seungwoon Kim (ICU)Jay Martin (Space-Time Engineering)Jeonghoon Mo (Yonsei)Pedro Miguel Neves (PT Inovacao)Anuj Puri (Beceem)Arvind Raghavan (Arraycomm)Krishna Ramadas (Venturi Wireless)Kurt Rausch (Alcatel-Lucent)Francis E. Retnasothie (Huawei)Alexander Sayenko (Nokia)Roshni Srinivasan (Intel)Mineo Takai (Space-Time Engineering)Tom Tofigh (AT&T)Tran Minh Trung (ICU)Hua-Chiang Yin (III)Honghai Zhang (NEC)Comments and feedback should be sent to Shyam Parekh ([email protected]).


-DRAFT 03/20/09- - 6 -

TABLE OF CONTENTS

1 Overview................................................................................................................................. 91.1 History............................................................................................................................ 9

2 Glossary .................................................................................................................................. 93 New Features in Release 2.6 ................................................................................................. 104 NS-2 High level Structure and Simulation Cycle ................................................................. 11

4.1 NS-2 Event Scheduling and Packet Handling .............................................................. 114.2 NS-2: C++/OTcl Duality and Impact ........................................................................... 12

5 Structure of 802.16 System Level Simulation Model ........................................................... 125.1 Base Station.................................................................................................................. 13

5.1.1. Structure of BS node ................................................................................................ 135.1.2. Decomposition BS into modules.............................................................................. 135.1.2.4. DL Frame Assembler........................................................................................... 145.1.2.5. Packet Parser........................................................................................................ 14

5.2. Mobile Subscriber Station ............................................................................................ 155.2.1. Structure of MSS node............................................................................................. 155.2.2. Decomposition of MSS into modules ...................................................................... 15

5.3. Packet flows in the simulator ....................................................................................... 165.3.1. Regular DL data packet flow ................................................................................... 165.3.2. Regular UL Data Packet Flow ................................................................................. 165.3.3. Packet flow for bandwidth request messages........................................................... 175.3.4. Packet flow for CQICH............................................................................................ 175.3.5. Packet flows for HARQ ........................................................................................... 185.3.6. Packet flows for ARQ.............................................................................................. 19

6. Packet CS .............................................................................................................................. 196.1. Classifier class structure ............................................................................................... 206.2. DestClassifier example................................................................................................. 206.3. TCL commands ............................................................................................................ 21

7. MAC Common Part Sublayer ............................................................................................... 217.1. MAC module structure ................................................................................................. 227.2. Addressing and connection .......................................................................................... 237.3. MAC PDU format ........................................................................................................ 24

7.3.1 Packet header structure ............................................................................................ 247.3.1 Defined Management messages ............................................................................... 24

7.4 Construction and transmission of MAC PDUs ............................................................ 257.4.1 Fragmentation .......................................................................................................... 257.4.2 Packing..................................................................................................................... 25

7.5 ARQ ............................................................................................................................. 257.5.1 ARQ with Fragmentation and Packing .................................................................... 257.5.2 ARQ Transmitter and Receiver Logic ..................................................................... 267.5.3 ARQ parameters....................................................................................................... 297.5.4 ARQ class diagram .................................................................................................. 297.5.5 Configuration of ARQ ............................................................................................. 31

7.6 Scheduling services ...................................................................................................... 317.6.1 Schedulers ................................................................................................................ 317.6.2 Default Scheduler..................................................................................................... 337.6.2.1 DL scheduler at BS.............................................................................................. 347.6.2.2 UL scheduler at BS.............................................................................................. 34

[email protected]


-DRAFT 03/20/09- - 7 -

7.6.2.3 Horizontal Stripping ............................................................................................ 357.6.2.4 Vertical Stripping................................................................................................. 357.6.2.5 UL scheduler at MS............................................................................................. 357.6.2.6 Bandwidth request and Piggybacking.................................................................. 367.6.3 TCL commands........................................................................................................ 36

7.7 Bandwidth allocation and request mechanisms............................................................ 367.7.1 CDMA Based Contention ........................................................................................ 367.7.2 Contention resolution............................................................................................... 407.7.3 TCL commands........................................................................................................ 42

7.8 MAC support of PHY................................................................................................... 437.9 Network entry and initialization ................................................................................... 437.10 Ranging ........................................................................................................................ 447.11 QoS Policing ................................................................................................................ 45

7.11.1 TCL commands ................................................................................................... 467.12 MAC layer handover procedures ................................................................................. 46

7.12.1 Scanning .............................................................................................................. 467.12.2 TCL commands ................................................................................................... 47

7.13 Frame structure............................................................................................................. 487.14 Packet processing ......................................................................................................... 49

8 PHY....................................................................................................................................... 528.1 OFDMA PHY............................................................................................................... 52

8.1.1 OFDMA physical layer class diagram ..................................................................... 528.1.2 OFDMA Packet schedulers...................................................................................... 548.1.3 TCL Configuration................................................................................................... 55

8.2 OFDMA PHY............................................................................................................... 558.2.1 Cost231 .................................................................................................................... 558.2.2 Fast/Frequency Selective Fading ............................................................................. 568.2.3 Interference Modeling (SIR) .................................................................................... 58

8.3 Details of OFDMA channel Implementation in NS2 ................................................... 598.4 Received SINR Averaging (EESM)............................................................................. 608.5 Transmission and Interference Power calculation logic............................................... 60

9 Configuration ........................................................................................................................ 609.1 Setup............................................................................................................................. 60

9.1.1 Configure the node................................................................................................... 609.1.2 Configure a packet classifier .................................................................................... 609.1.3 Configure a scheduler .............................................................................................. 619.1.4 Configure the channel .............................................................................................. 619.1.5 Select the OFDMA Propagation Model ................................................................... 629.1.6 Select a Fading Model.............................................................................................. 62

9.2 Statistics ....................................................................................................................... 629.3 Tracing ......................................................................................................................... 62

10 Parameters and Constants ..................................................................................................... 6210.1 Parameters .................................................................................................................... 62

11 Sample TCL script ................................................................................................................ 6312 Validation Results ................................................................................................................. 6913 Current limitations ................................................................................................................ 7314 Future Plans........................................................................................................................... 7315 Annexes................................................................................................................................. 74

15.1 Sample scripts............................................................................................................... 7415.1.1 test-arq-be.tcl ....................................................................................................... 7415.1.2 test-arq-ugs.tcl ..................................................................................................... 74


-DRAFT 03/20/09- - 8 -

15.1.3 test_arq_be.tcl...................................................................................................... 7415.2 FAQ.............................................................................................................................. 74

16 References............................................................................................................................. 75


-DRAFT 03/20/09- - 9 -

1 OverviewThe model currently implemented is based on the IEEE 802.16 standard (802.16-2004) [1] andthe mobility extension IEEE 802.16e-2005 [2]. A snapshot of available and missing features islisted below:

Available features Summary of features NOT implemented(see also section 13)

- WirelessMAN-OFDMA physical layerwith configurable modulation

- Time Division Duplexing (TDD)- Management messages to execute

network entry (without authentication)- Default scheduler providing round

robin uplink allocation to registeredMobile Stations (MSs) according tobandwidth requested

- IEEE 802.16e extensions to supportscanning and handovers

- Fragmentation and reassembly offrames

- OFDMA physical layer- Per-subcarrier interference modeling

with EESM- Selectable fast fading models: ITU

PED A, PED B and VEHIC A- Service Flow and QoS scheduling- ARQ- Packing (with ARQ)- CDMA based Contention Resolution.- Concatenation (multiple MAC PDUs

packed into a single PHY burst)

- Periodic ranging and poweradjustments

- Error Correction- NrtPS and ertPS- Adaptive Modulation and Coding- MIMO- HARQ- Admission Control- Authentication

It is important to note that many components are not defined in the standard. Therefore the modelimplements one solution, which may or may not fit the user’s need. This is the case for thebandwidth scheduler, and flow handler, or scanning scheduler. The model was designed to berelatively extensible.

1.1 HistoryThe earlier version of the NS-2 add-on (for OFDM PHY) was developed at NIST. At theWiMAX Forum Plenary Meeting at Hawaii (January 30 - February 2, 2007), the decision tomerge the independent development efforts supported by Application Architecture Task Group(AATG), WiMAX Forum and NIST was taken. This updated documentation and theaccompanying software module for OFDMA PHY are the results of this collaboration. The teamsat Rensselaer Polytechnic Institute (RPI) and Washington University in St. Louis (WUSTL) arethe primary development teams supported by the AATG.

2 GlossaryBS: Base StationMSS: Mobile Subscriber Station


-DRAFT 03/20/09- - 10 -

CID: Connection IDentifierCS: Convergence SublayerMAC: Media Access ControlMIB: Management Information BaseOFDM: Orthogonal Frequency Division MultiplexingOFDMA: Orthogonal Frequency Division Multiple AccessPDU: Protocol Data UnitPMP: Point to MultiPointPS: Physical SlotRTG: Receive Transition GapSAP: Service Access PointTTG: Transmit Transition GapBWR: BandWidth Request

3 New Features in Release 2.6As part of Release 2.6, we have the following additions and modifications to the code:

1. The cdma_codes (0-255) are distributed among codes for bandwidth request, initialranging, handover and CQICH. These cdma-code ranges can be set at “ns-wimax.tcl”.

2. To send the bandwidth request (BWR), MSS scheduler makes use of transmissionopportunity and cdma_ranging code to verify the opportunity to transmit for each MSS.

3. This version supports a variable part of DL_MAP by taking number of burst allocation inboth uplink and downlink.

4. Number of DL_PREAMBLE can variably set to either 1 or 3 symbol-columns.5. The best effort fair scheduling for downlink allocation is written up with the decrease in

complexity.6. With OFDMA PHY, the end of downlink map entity is removed. The end of UL_MAP

will be removed in the next patch. Note that although there is a presence of the end ofUL_MAP entity, there is no packet transmission during this region.

7. The downlink subframe is utilized; we take the space right after the MAP for dataallocation.

8. Channel Index random allocation scheme update based on CDMA Ranging mechanism.9. Effective SINR realignment to dB scale.10. Support ARQ in Handover scenario11. New transmission power and interference power calculation logic.

Features in Release 2.51. Triggering of channel scanning is now based on the power level of the DL_MAP

message2. Enhanced propagation and interference power calculation3. Changed the management zone from OFDM to OFDMA4. Clean OFDMA Physical Layer support5. Support for ARQ6. Support for CDMA initial and bandwidth ranging7. Piggybacking of bandwidth requests8. Support for unicast polling9. Validation scripts have been added to the distribution.


-DRAFT 03/20/09- - 11 -

4 NS-2 High level Structure and Simulation Cycle

Figure 1: Simulation Cycle in NS-2

As shown in Figure 1, in a simplified user's view, NS is Object-oriented Tcl (OTcl) scriptinterpreter that has a simulation event scheduler and network component object libraries, andnetwork setup (plumbing) module libraries (actually, plumbing modules are implemented asmember functions of the base simulator object). In other words, to use NS, you program in OTclscript language. To setup and run a simulation network, a user should write an OTcl script thatinitiates an event scheduler, sets up the network topology using the network objects and theplumbing functions in the library, and tells traffic sources when to start and stop transmittingpackets through the event scheduler. The term "plumbing" is used for a network setup, becausesetting up a network is plumbing possible data paths among network objects by setting the"neighbour" pointer of an object to the address of an appropriate object. When a user wants tomake a new network object, he or she can easily make an object either by writing a new object orby making a compound object from the object library, and plumb the data path through the object.This may sound like complicated job, but the plumbing OTcl modules actually make the job veryeasy. The power of NS comes from this plumbing.

4.1 NS-2 Event Scheduling and Packet HandlingAnother major component of NS beside network objects is the event scheduler. An event in NS isa packet ID that is unique for a packet with scheduled time and the pointer to an object thathandles the event. In NS, an event scheduler keeps track of simulation time and fires all theevents in the event queue scheduled for the current time by invoking appropriate networkcomponents, which usually are the ones who issued the events, and let them do the appropriateaction associated with packet pointed by the event. Network components communicate with oneanother passing packet; however this does not consume actual simulation time. All the networkcomponents that need to spend some simulation time handling a packet (i.e. need a delay) use theevent scheduler by issuing an event for the packet and waiting for the event to be fired to itselfbefore doing further action handling the packet. For example, a network switch component thatsimulates a switch with 20 microseconds of switching delay issues an event for a packet to beswitched to the scheduler as an event 20 microsecond later. The scheduler after 20 microsecondsdequeues the event and fires it to the switch component, which then passes the packet to anappropriate output link component. Another use of an event scheduler is timer. For example, TCPneeds a timer to keep track of a packet transmission time out for retransmission (transmission of apacket with the same TCP packet number but different NS packet ID). Timers use eventschedulers in a similar manner that delay does. The only difference is that timer measures a time


-DRAFT 03/20/09- - 12 -

value associated with a packet and does an appropriate action related to that packet after a certaintime goes by, and does not simulate a delay.

4.2 NS-2: C++/OTcl Duality and Impact

Figure 2: C++/OTcl Duality in NS-2

NS is written not only in OTcl but in C++ also. For efficiency reason, NS separates the data pathimplementation from control path implementations. In order to reduce packet and eventprocessing time (not simulation time), the event scheduler and the basic network componentobjects in the data path are written and compiled using C++. These compiled objects are madeavailable to the OTcl interpreter through an OTcl linkage that creates a matching OTcl object foreach of the C++ objects and makes the control functions and the configurable variables specifiedby the C++ object act as member functions and member variables of the corresponding OTclobject. In this way, the controls of the C++ objects are given to OTcl. It is also possible to addmember functions and variables to a C++ linked OTcl object. The objects in C++ that do not needto be controlled in a simulation or internally used by another object do not need to be linked toOTcl. Likewise, an object (not in the data path) can be entirely implemented in OTcl. Figure 2shows an object hierarchy example in C++ and OTcl. One thing to note in the figure is that forC++ objects that have an OTcl linkage forming a hierarchy, there is a matching OTcl objecthierarchy very similar to that of C++.

5 Structure of 802.16 System Level Simulation ModelThis is the framework we are following in our software architecture. However, not all of thesefeatures have been implemented.


-DRAFT 03/20/09- - 13 -

5.1 Base Station

5.1.1. Structure of BS node

Rx PHY Module

FlowClassifier

DL FrameAssembler

Packet ParserTo higherlayer

From higherlayer

UL ARQ Module

Tx PHYModule

BWrequest

Rx HARQ combining

DL ARQ / HARQDL Scheduler API

UL Scheduler API

PHY Abstraction API

DL resource allocatorFragmentation/packing

List of MAC PDUs andlocations

DL queueBW grant queue

Figure 3: Structure of Base Station (BS)

5.1.2. Decomposition BS into modulesThe structure of Base Station (BS) is illustrated in Figure 3. The main features of the BS modelare:

5.1.2.1. Flow ClassifierThis module performs 802.16 MAC CS functions mapping arriving network service data units(SDUs) to the proper MAC service flow identifier (SFID) and connection identifier (CID). It alsoperforms Packet Header Suppression (PHS) if the corresponding rule is defined for the serviceflow. All incoming packets from the higher layers (Application layer) pass through this blockbefore being directed to a queue corresponding to a CID.

5.1.2.2. Scheduler (DL ARQ/HARQ)The scheduler is a complex module as it needs to keep much information in order to scheduledata packets properly and efficiently. The scheduler need to maintain the following information:

1. QoS information for each flow2. DL Queue status for each flow3. UL bandwidth grant (including the bandwidth request and bandwidth grant updated due

to the scheduling service such as UGS) for each flow or for each mobile4. Channel state information for each mobile

This block has the following functions or sub-modules:

5.1.2.2.1. DL queue manager (DL ARQ/HARQ)This module manages the queues in each connection. It stores packets in different queues basedon their CIDs, maintains certain information such as the total number of packets and the total datasize of each queue, and provides interface to enque, dequeue packets and query the status of eachqueue.


-DRAFT 03/20/09- - 14 -

If ARQ and HARQ are implemented, Queue Manager also maintains their status such as the ARQcounter, timer, etc. A major modification for the ARQ operation is that the Queue Manager shallnot free a packet until it is acknowledged. This implies that ACK packets for each connection willbe sent from the receiving module to the transmitting module (on both forward and reverse links).

Support for Selective Repeat ARQ can be developed as a default, since it will be simple toconvert it to simpler versions of ARQ if the extra information in the Selective ACK messages isignored. More detail on how Selective Repeat ARQ can be used to default to Stop and Wait/ GoBack N ARQ is required.

We propose that HARQ (Type I) be emulated, not explicitly simulated. The impact of HARQ isthe overhead of increased packet (fragment) size due to error correcting codes. Extensions toType II HARQ using emulations for Chase Combining etc can be discussed, but from the point ofview of extensibility of Type I features only. (An immediate requirement is for the receiver tohold on to error packets/fragments so that subsequent transmissions can be combined withexisting data)

5.1.2.2.1. DL/UL schedulingThe role of the scheduling function is to decide the right priority of each flow and scheduleproper number of data packets for transmission. The details of the scheduling function arecovered in Section 7.

5.1.2.2.2. DL resource allocatorThe role of the DL resource allocator is to determine the size and location of each data burst in aframe. Depending on the implementation, it can be either combined with the scheduling functionor after that.

5.1.2.2.3. Packet fragmentation/packingThe allocated data slot may not match exactly the size of packets in queue, fragmentation andpacking is needed to better utilize the allocated slot. Depending on the implementation, it can beinside the resource allocator or after that.

5.1.2.3. UL ARQ ModuleThis block manages the packets that are received out of order or partially. The ARQ feedbackinformation is sent back to the transmitter through state information transferred between thisblock and the DL ARQ/HARQ module.

5.1.2.4. DL Frame AssemblerDL frame assembler combines all packets generated by the scheduler to form a frame and addsome additional frame information such as the DL and UL maps. The DL frame assembler thenpass the DL frame to the Tx PHY module.

5.1.2.5. Packet ParserThe BS parses packets (classifies incoming packets based on the type in packet headers: datapackets or control packets). An example of a control packet is a Bandwidth Request (BWR)packet. Another control packet is the CQICH packet. They are used to update data structures inother modules. Data packets are directly sent to the higher layer after ARQ processing iscompleted.

5.1.2.6. Tx/Rx PHY Module


-DRAFT 03/20/09- - 15 -

DL PHY Module simply passes the packets to the wireless channel. Optionally, it can stampsome PHY information to the packets, such as the transmission time, power, and frequency.UL PHY Module calculates the SINR information for all incoming packets and implements theinterface to the PHY layer tables which provide Block Error Information when queried withBlock Size and SINR value. More details on the PHY Module will be provided by PHYabstraction group.

5.1.2.6.1. Rx HARQ CombiningOur current plan is that the HARQ will only support the chase combining. As a result, the ULHARQ module only combines the signal of the current packet and that of the same packettransmitted in previous frames (but not successfully received). If the packet is successfullydecoded, it will be passed to the upper layers and a HARQ ACK will be generated and sent to theScheduler to update the HARQ status in the MS.

5.2. Mobile Subscriber Station

5.2.1. Structure of MSS node

Tx PHYModule

UL ARQ /HARQ ModuleUL Assembler FlowClassifier From higher

layer

Rx PHY ModulePacket Parser DL ARQ Module To higher

layerRx HARQ combining

UL Scheduler API

UL resource allocatorFragmentation /packing

(UL queue)

Figure 4: Structure of Mobile Subscriber Station (MSS)

5.2.2. Decomposition of MSS into modulesThe structure of MSS is illustrated in Figure 4. One of the main functions of the MSS is to parsethe incoming UL-Maps and extract information (start and end time of burst in the case of SC-PHY) and assemble a burst using data from the data queues associated with the MSS.

5.2.2.1. UL Scheduler (ARQ/HARQ Module)The UL scheduler gets the bandwidth grant to the mobile in every frame from the packet parserand then it schedule proper amount of data in the granted UL slots. The detail of the schedulingfunction is covered in Section 7.


-DRAFT 03/20/09- - 16 -

5.2.2.2. UL AssemblerThis block scans the queues at the MSS and generates a ‘burst’ of data which fits into the grantedslots. The functions of the remainder of the blocks are the same as in the case of the Base Station.

5.3. Packet flows in the simulator

5.3.1. Regular DL data packet flow

FlowClassifier

DL ARQ/HARQModule

PacketParser

Tohigherlayer

BS MSS

UL ARQ Module

Tx PHYModule

Tx PHYModule

UL ARQ/HARQModule

ULAssembler

FlowClassifier From

higherlayer

Rx PHY Module

Rx PHY Module PacketParser

DL ARQModule

Tohigherlayer

DL FrameAssembler

‘ ’ indicates the beginning of the flow.Figure 5: Regular DL data packet flow

Downlink (DL) data traffic is sent from BS to the MSS. Data packets that BS received fromhigher layer are forwarded to the Flow Classifier module which performs 802.16 CS(Convergence Sublayer) functions by assigning packets to the service flow and the MACconnection. Classified packets are forwarded to the DL ARQ/HARQ Module and stored inqueues. The DL scheduler looks over queues and schedules packets for transmission to MSS.Each individual of MAC PDU is generated by the fragmentation/packing function in the DLARQ/HARQ module. DL ARQ/HARQ module outputs a list of MAC PDUs and their location tothe DL Frame Assembler, and then the Frame Assembler assembles them into the DL subframe,also adds DL MAP, UL MAP, and other data structure as needed for the simulation to completethe DL frame. DL Frame Assembler forwards the complete DL frame to the Tx PHY Module.Tx PHY Module maintains PHY link and transmits the DL frame to MSS.

5.3.2. Regular UL Data Packet Flow

FlowClassifier

DL ARQ/HARQModule

PacketParser

Tohigherlayer

BS MSS

UL ARQ Module

Tx PHYModule

Tx PHYModule

UL ARQ/HARQModule

ULAssembler

FlowClassifier From

higherlayer

Rx PHY Module


DL ARQModule

Tohigherlayer

DL FrameAssembler

Figure 6: Regular UL data packet flow


-DRAFT 03/20/09- - 17 -

Uplink (UL) data traffic is sent from MSS to BS. UL packet flow is similar to DL packet flowexcept it’s transmitting in opposite direction.

5.3.3. Packet flow for bandwidth request messages

FlowClassifier

DL ARQ/HARQModule

PacketParser

Tohigherlayer

BS MSS

UL ARQ Module

Tx PHYModule

Tx PHYModule

UL ARQ/HARQModule

ULAssembler

FlowClassifier From

higherlayer

Rx PHY Module


DL ARQModule

Tohigherlayer

DL FrameAssembler

BWrequest

Figure 7: Packet flow for bandwidth request

Bandwidth is requested by MSS UL ARQ/HARQ Module. The BS Packet Parser parse receivedpackets. If a bandwidth request header is parsed, the size of the bandwidth request and the CID isextracted and the information is sent to Scheduler as an internal control packet. All bandwidthrequests are stored in the BW grant queue. UL Scheduler API looks over the grant queue andschedule UL BW grants to subscriber stations according to its scheduling algorithm. UL MAP isformed based on UL Scheduler’s outputs. UL MAP is included into the DL frame to betransmitted to MSS.

5.3.4. Packet flow for CQICH

FlowClassifier

DL ARQ/HARQModule

PacketParser

Tohigherlayer

BS MSS

UL ARQ Module

Tx PHYModule

Tx PHYModule

UL ARQ/HARQModule

ULAssembler

FlowClassifier From

higherlayer

Rx PHY Module


DL ARQModule

Tohigherlayer

DL FrameAssembler

Figure 8: Packet flow for CQICH

CQICH is designed for HARQ enabled MSS. CQI basically is reported by the MSS Tx PHYmodule. MSS Tx PHY module is using the CQICH fast feedback channel (in the UL subframe)sending channel quality information. BS Rx PHY module extracts CQI from the UL frame, andtranslates to Channel_state, and then forwards the info to DL ARQ/HARQ Module for channelquality awareness scheduling. DL ARQ/HARQ module can optionally forward CQI to BS TxPHY module, if there is any simulation work in PHY that need the CQI information.


-DRAFT 03/20/09- - 18 -

5.3.5. Packet flows for HARQ

5.3.5.1. Packet flow for UL HARQ

FlowClassifier

DL ARQ/HARQModule

PacketParser

Tohigherlayer

BS MSS

UL ARQ Module

Tx PHYModule

Tx PHYModule

UL ARQ/HARQModule

ULAssembler

FlowClassifier From

higherlayer

Rx PHY Module(Rx HARQ Combining)


PacketParser

DL ARQModule

Tohigherlayer

DL FrameAssembler

DetermineACK/NACK

ACK/NACK

Data

Req to sendACK/NACK

Figure 9: Packet flow for UL HARQ

In UL HARQ packet flow, MSS is the transmitter, and BS is the receiver. HARQ bursts aretransmitted in the UL subframe and ACK/NACKs are transmitted as part of the DL map. BS RxHARQ determines whether send ACK/NACK to MSS; UL HARQ only passes successful packetsto Packet Parser. The ACK delay is specified as part of the channel configuration in the UCD; theACK/NACK message doesn’t need to be scheduled. MSS’s “Rx HARQ” forwards ACK/NACKto UL ARQ/HARQ module for updating UL queue structure. Upon receiving ACK/NACK, MSSUL ARQ/HARQ shall do the following:

- ACK: Remove all packets relative to the ACK from UL Queue- NACK: initiate to transmit the next packet

5.3.5.2. Packet flow for DL HARQ

FlowClassifier

DL ARQ/HARQModule

PacketParser

Tohigherlayer

BS MSS

UL ARQ Module

Tx PHYModule

Tx PHYModule

UL ARQ/HARQModule

ULAssembler

FlowClassifier From

higherlayer



PacketParser

DL ARQModule

Tohigherlayer

DL FrameAssembler

DetermineACK/NACK

ACK/NACK

Data

Req to sendACK/NACK

Figure 10: Packet flow for DL HARQ

In DL HARQ packet flow, BS is the transmitter, and MSS is the receiver. HARQ bursts aretransmitted in the DL subframe and ACK/NACKs are transmitted in HARQ ACK regions in theUL subframe. MSS DL HARQ determines whether send ACK/NACK to BS; Rx HARQ moduleonly passes successful packets to Packet Parser. The ACK delay is specified as part of thechannel configuration in the DCD; the ACK/NACK message doesn’t need to be scheduled. Uponreceiving ACK/NACK, BS DL ARQ/HARQ shall do the following:

- ACK: Remove all packets relative to the ACK from UL Queue- NACK: initiate to transmit the next packet


-DRAFT 03/20/09- - 19 -

5.3.6. Packet flows for ARQ

5.3.6.1. Packet flow for UL ARQ

FlowClassifier

DL ARQ/HARQModule

PacketParser

Tohigherlayer

BS MSS

UL ARQ Module

Tx PHYModule

Tx PHYModule

UL ARQ/HARQModule

ULAssembler

FlowClassifier From

higherlayer

Rx PHY Module


DL ARQModule

Tohigherlayer

DL FrameAssembler

DetermineACK/NACK Data

Req to sendACK/NACK

ACK/NACK

Figure 11: Packet flow for UL ARQ

In UL ARQ packet flow, MSS is the transmitter, and BS is the receiver. BS UL ARQ moduledetermines whether send ACK/NACK to MSS. The ACK/NACK message is a packet and needsto be scheduled for transmission. Upon receiving ACK/NACK, MSS UL ARQ/HARQ shall dothe following:

- ACK received: remove the packet from UL queue- NACK received: initiate re-transmit the packet

5.3.6.2. Packet flow for DL ARQ

FlowClassifier

DL ARQ/HARQModule

PacketParser

Tohigherlayer

BS MSS

UL ARQ Module

Tx PHYModule

Tx PHYModule

UL ARQ/HARQModule

ULAssembler

FlowClassifier From

higherlayer

Rx PHY Module


DL ARQModule

Tohigherlayer

DL FrameAssembler

DetermineACK/NACK

ACK/NACK

Data

Req to sendACK/NACK

Figure 12: Packet flow for DL ARQ

In DL ARQ, BS is the transmitter, and MSS is the receiver. MSS DL ARQ determine whethersend ACK/NACK to BS. The ACK/NACK message needs to be scheduled for transmission.Upon receiving ACK/NACK, BS DL ARQ/HARQ shall do the following:

- ACK received: Remove the packet from the DL queue- NACK received: initiate to re-transmit the packet

Next, we describe the various layers in detail.

6. Packet CSThe CS layer resides on top of the MAC_CPS layer and performs the following functions:

- Receives higher-layer PDUs- Perform classification- Deliver the CS PDUs to the MAC SAP- Receives CS PDUs from the peer entity


-DRAFT 03/20/09- - 20 -

In the current implementation, the Packet CS only performs classification. The method used toclassify packets is implementation dependent. It may also be useful to implement multiplesolutions in order to find the appropriate connection. The model supports user-defined classifiers.

6.1. Classifier class structure

Figure 13: Packet classifier class diagram

The SDUClassifier is the abstract class. To create a classifier, the user must create a subclass ofSDUClassifier and implement the classify (Packet *) method. The SDUClassifier supportspriority, which can be used to specify the order in which the classifiers are called. The smaller thepriority value, the sooner it will be called (default value=0).

Note: The priority must be set prior to adding the classifier into the MAC since it is used to orderthe list of classifiers.

6.2. DestClassifier exampleThe DestClassifier class can be used as a reference to implements more complex packetclassifiers. It uses the destination IP address to classify the packets.


-DRAFT 03/20/09- - 21 -

Figure 14: Flow diagram for DestClassifier

As show in Figure 14, the DestClassifier uses the destination MAC address located in the packet(and computed at the routing level) and the packet type to determine the proper CID. If there is nomatch, it will return -1.

6.3. TCL commands$classifier set-priority $prioChange the classifier’s priority. Default value is 0.

$mac reset-classifiersClear the list of classifier in the MAC. This must be called before adding custom packet classifier.

$mac add-classifier $classifierAdd classifier to the list of packet classifiers to use.

7. MAC Common Part SublayerThis section presents the MAC sublayer that currently supports PMP.


-DRAFT 03/20/09- - 22 -

7.1. MAC module structure

Figure 15: MAC 802.16 class diagram

The Mac802_16 is a subclass of the Mac class. It is an abstract class that contains the commonelements of the BS and MS. For example it stores the MAC MIB and PHY MIB. It is theinterface with other layers for sending and receiving packets. Figure shows the class and therelations with other modules.

A MAC has a list of packet classifiers (SDUClassifier) that maps each outgoing packet with theproper connection identifier (CID). Using TCL, the user configures the list of classifiers to beused (see section 3). The current implementation uses the destination IP address as the classifyingelement.

The ServiceFlowHandler is responsible for handling flow requests/responses. It also stores thelist of flows for the node.

A MSS is registered to a BS, and a BS can be connected to multiple MSSs. The class PeerNodecontains information about the peer, such as its connections and status. The Connections are alsoaccessed via the ConnectionManager, which contains the list of incoming and outgoingconnections.

The WimaxScheduler abstract class is used to create an interface with the MAC. There are mainlytwo types of schedulers: one for the BS, and one for the MSS. Since the scheduler is specified inTCL, it is easy to implement the abstract class and change it.

Finally, the MAC computes statistics via StatWatch and ThroughputWatch objects for packet andtraffic information. The values are used to trigger events, but can also be printed during thesimulation for post processing.


-DRAFT 03/20/09- - 23 -

Since a BS and a MSS have different state machines we defined 2 subclasses, namelyMac802_16BS and Mac802_16SS, as shown below.

Figure 16: classes Mac802_16, Mac802_16BS and Mac802_16SS

7.2. Addressing and connectionEach MAC has a unique address coded as an int that is defined in the MAC class of NS-2.

The model also defines connection identifiers as int but they are carried as 16-bit in the messages.The CIDs are assigned according to section 10.4 of [1] during initialization and dynamic setup ofconnections.The following connections are created during initialization at the BS:

- Initial Ranging (incoming and outgoing)- Padding (incoming and outgoing)- Broadcast (outgoing)- Adaptive Antenna System (AAS) (outgoing, not used)

The following connections are created during initialization at the MSS:- Initial Ranging (incoming and outgoing)- Padding (incoming and outgoing)- Broadcast (incoming)

Additionally, during network entry the following connections are setup and CIDs assigned:


-DRAFT 03/20/09- - 24 -

- Basic CID (incoming and outgoing)- Primary CID (incoming and outgoing)- Secondary CID (incoming and outgoing)- Data (Transport) CIDs. Currently the model only supports one data connection.

7.3. MAC PDU formatThe model defines a new header for carrying IEEE 802.16 packets.

7.3.1 Packet header structureThe class diagram of the hdr_mac802_16 class is show in Figure 17.

Figure 17: Class diagram of MAC header

The header contains 3 main elements:- A virtual physical header of type phy_info_t. This structure is used to carry physical

information such as frequency, modulation and cyclic prefix.- A generic MAC header of type gen_mac_header_t containing the generic MAC

information. The structure can be cast to bw_req_header_t when the packet is abandwidth request.

- Structures to store the different sub headers. The structures are present in all the packetsbut the type attribute of the generic header indicates if the entry is valid or not.

When ARQ is enabled, the header also contains feedback information.

For MAC management messages, the payload contains the variable size information.

Note: Since it is not advised to use pointers in packets we implement list as arrays and include thenumber of elements in the list. The maximum number of elements can be updated if needed.

7.3.1 Defined Management messagesThe following table indicates the packets currently defined in the model. All the packetdefinitions are located in the file mac802_16pkt.h. To compute the packet size, utility functionshave been implemented in the file mac802_16pkt.cc.


-DRAFT 03/20/09- - 25 -

Category Messages definedSynchronization and Network Entry DL-MAP / DCD

UL-MAP / UCDRNG-REQ/RSPREG-REQ/RSP

Service flows DSA-REQ/RSP/ACK

Mobility MOB_NBR_ADVMOB_SCN-REQ/RSPMOB_BSHO-REQ/RSPMON_SSHO-REQMOB_HO-INDMOB_SCN-REPMOB_ASC-REP

7.4 Construction and transmission of MAC PDUsThe construction and transmission of packets can be divided into three steps:

1- Reception of outgoing packet from the upper layer: The MAC runs through the classifiersto find the proper CID. If a valid CID is found, it appends a default MAC header and putsthe packet in the connection queue.

2- Scheduling: Every frame the schedulers go through the list of connections to find thepackets to transmit. At the BS, the scheduler performs burst allocation then transferpackets from the connection queue to the bursts. At the MS, it uses the received UL MAPto find the allocation and transfer the packets to the bursts.

3- Transmission: two timers are going through the DL and UL MAP to transmit the packetsstored in the burst queues.

7.4.1 FragmentationFragmentation can be enabled/disabled on a connection based. Currently the default value is toenable the fragmentation.

When scheduling packets for transmission, the scheduler checks if fragmentation is enabled forthe connection and splits the packet to fit into the burst. The fragmentation context is stored in theConnection. The method transfered_packets in the file scheduling/wimaxscheduler.cc takes careof transferring packet from their connection queue to the bursts.

7.4.2 PackingPacking is currently implemented only with ARQ enabled.

7.5 ARQThe ARQ mechanism is one part of the MAC layer and it may be enabled on a per-connectionbasis. The per-connection ARQ shall be specified and negotiated during connection creation.

7.5.1 ARQ with Fragmentation and PackingThe fragmentation always occurs at the ARQ boundaries. That is to say, the fragmentation blockis always consisting of multiple number of ARQ block. If packing is enabled, the packed PDUmight consist of ARQ blocks from multiple SDUs. The following diagram shows the


-DRAFT 03/20/09- - 26 -

fragmentation and packing of ARQ blocks with and without rearrangement. In our currentimplementation, the rearrangement is supported. The minimum unit in transmission queue and re-transmission queue at sender side is the ARQ block. Given a data burst allocation from BS, thesender will try to fill up the allocated data burst as much as possible. The boundary of the originalPDU will be considered only when the current ARQ belongs to a different MAC SDU. In thiscase, a new FSH will be needed to form new MAC PDUs. Sometimes, the intermediate ARQblocks of a original MAC SDU after it is divided are successfully received and the other ARQblocks failed transmission. Once retransmission, the previous packed PDUs might be rearranged.The sender will add a new FSH to these remain part of ARQ blocks and new FSHs to ARQblocks of other MAC SDUs which also will be put into one allocated data burst.

Figure 18: Block usage examples for ARQ with and without rearrangement

7.5.2 ARQ Transmitter and Receiver Logic

7.5.2.1 Transmitter LogicWhen the SDUs from higher layer come to MAC layer, they will be divided into several ARQblocks according to the ARQ_BLOCK_SIZE. The size of the last ARQ block is variable andmight not equal to the ARQ_BLOCK_SIZE. After dividing the SDU, FRAG_STATUS andSEQ_NUM in Packing Subheader(PSH) and Fragmentation Subheader(FSH) will be updated.Then the transmitter enqueues a copy of packet into the ARQ transmission queue. When the timeof transmission comes, scheduler will try to transmit the ARQ blocks in re-transmission queuefirst and transmission queue second. The transmitter will first calculate the maximum size of datawhich could be fit into the allocated data burst. If the allocated data burst could only fit in abandwidth request packet, the MSS will just send a bandwidth request to ask for more bandwidthfor the remaining data packets. If the allocated data burst could fit in more than one ARQ blockand a bandwidth request, the MAC layer will send out an ARQ block as well as a BW request forthe remaining ARQ block. When the requested bandwidth is ready, the transmitter will send theremaining ARQ blocks out.


-DRAFT 03/20/09- - 27 -

Figure 19: ARQ Transmitter Logic

The following is the full view of transmitter state machine.

Figure 20: Transmitter Tx State Machine


-DRAFT 03/20/09- - 28 -

In our current implementation, the Discarded condition is not supported. That is to say, if ARQblocks are corrupted and need to be retransmitted, the transmitter will retransmit these ARQblocks till they are successfully received as well as the corresponding ARQ ACK.

7.5.2.2 Receiver Logic

Figure 21: ARQ Receiver Logic

When the ARQ blocks come to the receiver, it will try to convert the size of the MAC PDUs totheir original size. Also it will remove the generic header and CRC part. Then all these MACPDUs will be put into ARQ In-Order queue or Out-Order queue according to the BSN saved inFSH or PSH. Later on, receiver will check if the PDUs in the Out-Order queue can be fit into theIn-Order queue since a lost packet could be re-transmitted under ARQ mechanism. The algorithmfor receiver to handle the In-Order queue and Out-Order queue is as follows.1) Reset Iterator and start getting the packets from out of order queue2) If in order, update cumulative ACK, transfer packet to in order queue. Update the expect BSNof the next new packet.


-DRAFT 03/20/09- - 29 -

3) If out of order, fetch next packet to see if it can fit.4) Loop will be terminated till all the packets in In-Order queue and Out-Order queue have beenchecked.

The advantage of separating packets in different queue is that it will reduce the possibility ofretransmission, in the same time, it will be easier to reconstruct to original MAC SDU in In-Orderqueue.

The algorithm of ARQ to generate the MAC SDU is like this. Firstly, the receiver will pickpackets from FRAG_FIRST to FRAG_LAST in In-Order queue. If all the blocks are present, thereceiver will create one single MAC SDU, update the size and send it to the upper layer. Aftersending the MAC SDU to the upper layer, delete all the corresponding blocks from the In-Orderqueue. Otherwise the receiver will keep the received ARQ blocks and wait until the expect ARQblock(s) can be successfully received.

7.5.2.3 ARQ FeedbackARQ feedback IE messages could be transmitted in Basic CID or Data CID. Cumulative withselective feedback is supported in this release. The first feedback IE will be always be cumulativeACK and the following ACK will be selective ones. Before sending out the ACK feedback, thefield of Num_of_ACKs needs to be updated. When the ACK packets are received, receiver willchange the data packet size and delete the corresponding packets in transmission queue.Sometime when ARQ ACK is received, the receiver also might need to check if theAcknowledged packet might be in re-transmission queue. If it is present in re-transmission queue,make sure delete it as well.

7.5.2.4 ARQ TimingWhen an ARQ object is created, a timer will be started and expired every 20ms. At expiry, thetransmitter will copy the corresponding packets form ARQ transmission queue to ARQ re-transmission queue and reschedule the timer. As to the timing for transmission of ARQ blocks, ifthere is corresponding data burst allocation from the BS, the transmitter could transmit the ARQblocks in re-transmission queue and transmission queue using it.

7.5.3 ARQ parametersThere are 6 important parameters for ARQ mechanism as follows:

1. ARQ_BSN_MODULUS = 2048 (hardcoded)2. ARQ_BLOCK_LIFETIME = 20ms (hardcoded)3. ARQ_WINDOW_SIZE = 1- 1024 (configurable)4. ARQ_BLOCK_SIZE = 16, 32, 64, 128, 256, 512 and 1024 (configurable)5. ARQ_ACK_PERIOD (configurable)6. ARQ_ENABLE (configurable)

7.5.4 ARQ class diagram


-DRAFT 03/20/09- - 30 -

Figure 22: ARQ Related Class Diagram

Arqstatus class and its attributes and operations are used to realize the ARQ related functions, likeARQ slide window mechanism, ARQ acknowledgement mechanism, ARQ retransmissionmechanism etc. ArqSend (): This is called at the transmitter while sending the packet at the node if ARQ is

enabled. The sequence number is filled in the 802.16 header and a timer is set within whichthe ACK for packet reception should reach the sender. A copy of the sent packet ismaintained in the arq_send_queue

ArqReceive(): This function is called at the receiver side. Here if the packet received is inorder, an acknowledgement is queued in the ack_queue. Else, the packet is discarded. It couldbe argued that buffering of such packets will reduce retransmissions, however, in our currentimplementation we have set the timers to 5 ms within which the packets need to be receivedfor best performance; thus buffering would be of not help here.The feedbacks queued in the feedback queue can be sent either as explicit packets on theBASIC CID or they can be piggybacked if there is data on the opposite direction too. Thereare options in the script to set these.

ArqReceiveFeedback(): This function is called at the sender when the feedback for the sentpacket is received. This function will increment the next sequence number to be received andwill also reset the timer for which the feedback was received. It also deletes the packet fromthe arq_send_queue. At a point, we were considering keeping only one timer and maintain alinked list of the transmission time of packets, however, we observed that at a given point wewere sending just about eight packets and hence only eight timers were enabled. This being aminimal number, the current implementation uses exclusive timers for each packettransmitted.


-DRAFT 03/20/09- - 31 -

ArqTimerHandler(): This function is called when the timer expires for a particulartransmitted packet for which the ACK was not timely received characterized by the sequencenumber. This removes the corresponding packet from the arq_send_queue and puts it intoarq_retrans_queue. Whenever a bandwidth request is sent, the size of bandwidth requested issum total of the arq_retrans_queue and the queue where the MAC PDUs for transmission arestored.Also while scheduling a packet for transmission; first the arq_retrans_queue is given morepriority; then the packets from the regular queue are scheduled.

Mac802_16BS:: process_mac_pdu_witharqfragpack() is used at the BaseStation side to controlthe UL direction ARQ reception and call the following ARQ related operations, like ARQfeedback, MAC SDU reconstruction etc.

Mac802_16SS:: process_mac_pdu_witharqfragpack() is used at the Subscriber Station side tocontrol the DL direction ARQ reception and call the following ARQ related operations, like ARQfeedback, MAC SDU reconstruction etc.

WimaxScheduler::transfer_packets_with_fragpackarq() is used at both the BS and MSS sides. Itis mainly used to control the transmission of ARQ block in ARQ transmission queue and re-transmission queue, in the same time, it also used to issue bandwidth request from MSS side toBS.

ARQTimer is mainly used to control the ARQ retransmission.

7.5.5 Configuration of ARQMac/802_16 set arqfb_in_dl_data_ 1 # Allows sending DL ARQ FB in data connectionMac/802_16 set arqfb_in_ul_data_ 1 # Allows sending UL ARQ FB in data connectionMac/802_16 set arq_block_size_ 128

set arq_enable 1 #enable the ARQset arq_retrans_time 0.05set arq_max_window_size 30set arq_ack_period 1

setflow UL 10000 BE 275 2 $arq_enable $arq_retrans_time $arq_max_window_size$arq_ack_period 0 0 0 0 0 0 0 0 0 0

7.6 Scheduling servicesThe class structure allows for specifying different data services namely UGS, rtPS, nrTPS, andBest Effort. The services are specified in the ServiceFlow class. See section 7.11 for detailedinformation on QoS.

The scheduling of the packets is done by a Scheduler. This scheduler is interacting with the MACvia well defined API allowing custom implementations.

7.6.1 SchedulersDifferent types of nodes require different packet schedulers. In IEEE 802.16, the BS controls thebandwidth allocation and there are an infinite number of implementations. The model includes anabstract class, WimaxScheduler, created to easily use different packet schedulers. As shown in


-DRAFT 03/20/09- - 32 -

Figure , this class already contains two implementations, an SSscheduler for MSSs and aBSscheduler for BSs. These schedulers can be replaced by using the TCL as defined in section9.1.3.

Figure 23: Packet scheduler class diagram

When implementing a new scheduler, the following methods must be implemented:- init (): initialize the scheduler.- process (Packet *): This method is used to process packets received by the scheduler

(such as synchronization messages).- start_ulsubframe (): code to be executed at the beginning of a new uplink subframe.- start_dlsubframe (): code to be executed at the beginning of a new downlink subframe.

A detailed description of the default schedulers is available in the PHY sections.


-DRAFT 03/20/09- - 33 -

7.6.2 Default Scheduler

Figure 24: Component Schedulers at BS and MSs

The scheduler is split into 2 parts. One part resides in the BS and the other resides in the MS. Theone in the BS is responsible (wimax/scheduling/bsscheduler.cc) for filling up the down link sub-frame, and producing the UL Map. The one at the MSS (wimax/scheduling/sscheduler.cc) isresponsible for dividing the bandwidth allocated to it amongst its various connections.

An interface is defined between the scheduler and the remaining code. The interface defines a setof input parameters and expects the map structure as an output. The set of input parameters are asfollows:

• List of downlink/uplink connections• Number of sub-channels• Number of symbols• Symbol offset• Slot allocation method• Horizontal or vertical stripping

The downlink interface returns the DL Map and the uplink interface returns the UL Map. To thedownlink scheduler, a list of downlink connections is passed where as to the uplink scheduler alist of uplink connections is passed. The number of symbols and sub-channels represent all thesymbols and sub-channels that should be allocated by the scheduler. The symbol offset is theoffset from which the allocations start in the overall downlink sub-frame.

Note that in this version, though UL_MAP_IE size is fixed to 4 bytes and 7.5 bytes forDL_MAP_IE, the scheduler also sends more information in MAP_IE such as symbol_offset,subchannel_offset, num_of_symbols, and num_of_subchannels. Moreover, in this version, theinterpretation of num_of_subchannels is #slots (wimax/mac802_16pkt.h). [this issue will be fixedin next release]

Moreover, the allocation for each packet is in slot-boundary say symbol_offset,subchannel_offset, num_of_symbols, and num_of_subchannels are included in packet


-DRAFT 03/20/09- - 34 -

information for power calculation purpose. Particularly for small packet, this may lower thethroughput due to the waste portion in slot. [this slot boundary allocation will be fixed in nextrelease]

At the BS, there are two scheduling components: UL scheduler and DL scheduler.

7.6.2.1 DL scheduler at BSDL-BS is basically a round robin priority scheduler, that is, after allocating bandwidth for basic,primary and secondary connections. Then, DL-BS allocates bandwidth for data connections in thefollowing order: UGS, rtPS (only to meet minimum reserved bandwidth), and nrtPS (only to meeta minimum reserved bandwidth). Then, if there is a left-over resource, the algorithm fairlyallocates to rtPS, nrtPS, and BE. DL-BS only allocates bandwidth to a connection when it hasdata to be sent.

For UGS, if there are enqueued packets, there are two options: first the allocation is made inevery frame, that is, #slots = ceil[(SDU_size/UGS_period)/Slot_size]. Note that to enable thisfunction, “#define UGS_AVG” is to be uncommented. Second, the scheduler allocates fullSDU_size in every frame_period.

For rtPS, again if there are enqueued packets, the allocation is made in every frame; #slots =ceil[(minimum reserved bandwidth, MBps × FRAME_SIZE)/Slot_size]. This applies to nrtPS aswell.

For BE and additional bandwidth request for rtPS and nrtPS, the algorithm allocates the left-overresource fairly.

In fact, DL-BS requires having a rectangular burst; however, in this version, the mapping is onlydone vertically. Given the rectangular burst constraint, it may result in more unused space. [thisfeature will be taken into account in next release]

7.6.2.2 UL scheduler at BSUL-BS is similar to DL-BS but bandwidth request information is used instead of enqueuedpackets. For example, for UGS, the allocation is made either in every frame of by UGS_period;however, unlike DL_BS, there is no bandwidth request so the allocation will be made regardingof the enqueued packets at MSS transmission queue. Bandwidth in the uplink direction isallocated per MSS . That means if a MSS has multiple connections, the bandwidth allocated to itis represented by a single UL Map IE in a frame, in which the allocated bandwidth is theaggregate bandwidth for all its connections. Basic CID is used to represent per MSS allocation.

For rtPS, if there is a bandwidth request, the allocation is made in every frame; #slots =ceil[(minimum reserved bandwidth, MBps × FRAME_SIZE)/Slot_size]. If not, since rtPS can notparticipate in contention resolution mechanism, given the polling interval, UL-BS allocates atleast one bandwidth request opportunity to the subscriber (Polling). Note that the minimumallocation is one slot.

nrtPS scheduling is similar to rtPS; however, it allows contention resolution mechanism. Notethat usually polling interval is set to more than 1 second.

For BE and additional bandwidth request for rtPS and nrtPS, the algorithm allocates the left-overresource fairly.


-DRAFT 03/20/09- - 35 -

Given the number of slots required/ granted for each traffic class, the slots are either allocated in ahorizontal stripping method or vertical stripping method, which is passed to the scheduler as aninput. In fact the default scheduling for DL-BS is vertical stripping and horizontal stripping forUL-BS; however, in this version, both DL-BS and UL-BS use vertical stripping. [horizontalstripping will be supported in next updated version]

Once UL-BS grants the allocation, the scheduler updates the bandwidth request variable. UL-BSalso has tried to allocate in frame after if the bandwidth request variable remains non-zero.

7.6.2.3 Horizontal StrippingIn horizontal stripping, the slots are allocated in time first, and when the last symbol is filled in,the allocation goes on to the next sub-channel.

Figure 25: Horizontal striping

7.6.2.4 Vertical StrippingIn vertical stripping, the allocation is done in sub-channels first, and when the last sub-channel isfilled, allocation starts from the next symbol.

Figure 26: Vertical striping

At the MSS, there is only one scheduling component, that is, UL-MSS scheduler. The mainfunctions are to create the bandwidth request and given the grant, since the grant is per MSS, UL-MSS needs to split this transmitted opportunity among the connections.

7.6.2.5 UL scheduler at MSUL-MSS first transmits data from its basic, primary and then secondary connections till they areempty. It then services the data connections. In the current implementation, a MSS can have onlyone connection in the DL and UL direction. The scheduler checks which connection it has andtransmits data from that connection. For all connections, apart from UGS and rtPS, a BWR packetis created which is enqueued for transmission. UL-Scheduler returns the UL-MAP, which hasburst allocations per MS. Multiple PDU's are then fit into the UL-Bursts for transmission.


-DRAFT 03/20/09- - 36 -

7.6.2.6 Bandwidth request and PiggybackingThere are two mechanisms to send bandwidth request: bandwidth request packet andpiggybacking. To enable piggybacking feature, “//#define IF_PIG” is needed to be uncommented(wimax/scheduling/wimaxscheduler.cc).

Without piggybacking, given the transmitted opportunity, first UL-MSS computes if all enqueuedpackets can be transmitted and if yes, bandwidth request packet is not transmitted. Otherwise,first the bandwidth request packet is transmitted and follows by the enqueued packet ifapplicable. The default bandwidth request is “aggregation” and the bandwidth request variable isapproximately calculated from the total connection queue size.

With piggybacking, again given the transmitted opportunity, UL-MSS first check if theopportunity is more than bandwidth request size, 6 bytes. If no, only bandwidth request packet istransmitted. Otherwise, it calculates if all enqueued packets can be transmitted and if yes, nopiggybacking is required. If no, the bandwidth request is piggybacked at the first MPDU (adding2 bytes). Since the piggybacking is done at the first MPDU, the bandwidth request variable isapproximately calculated from the total enqueued packet sizes and the size of transmittedopportunity.

7.6.3 TCL commands$mac set-scheduler $schedulerSet the MAC scheduler. It removes the previously assigned scheduler if present.

7.7 Bandwidth allocation and request mechanismsThis section describes the implementation of the different mechanisms by which a MSS canrequest bandwidth.

7.7.1 CDMA Based Contention7.7.1.1 CDMA Frame StructureThe CDMA contention structure is shown in the figure below.


-DRAFT 03/20/09- - 37 -

CDMA_INIT_REQ:UIUC_INITIAL_RANGINGArea: One transmission opportunity is 2 symbols× 6 subchannels

CDMA_BW_REQ:UIUC_REQ_REGION_FULLArea: One transmission opportunity is 1 symbol× 6 subchannels

Figure 27: CDMA frame structure

7.7.1.2 CDMA-based Contention Parameters (tcl/lib/ns-wimax.tcl)

There are two main parameters: number of CDMA_INIT_REQ opportunities per frame andnumber of CDMA_BW_REQ opportunities per frame. These two parameters are fixed to 5. Notethat each 5 opportunity results in 3 OFDM symbols for CDMA ranging region. As a result, 5subchannels and 3 symbols left-over are unused. [variable size of this region and unused spacewill be considered → next release]

Mac/802_16 set init_contention_size_ 5;# number of init opportunities per frameMac/802_16 set bw_req_contention_size_ 5;# number of bw_req opportunities per frame

Moreover, at wimax/scheduling/ssscheduler.h, retransmission timeout of CDMA is defined. Inthis version, it is set to one frame. Since the MSS scheduler decides if it’s needed to send CDMArequest or not at the beginning of uplink subframe, CDMA_TIMEOUT is set to 2, and it isdecreased by one for each WiMAX frame. Also, a maximum CDMA code is set to 256 for eachtransmission opportunity.

#define CDMA_TIMEOUT 2#define MAXCODE 256

7.7.1.3 CDMA Packet

CDMA signal is treated as a special packet; 6 bytes in size (similar to bandwidth request packet).However, the transmission opportunity is 1 subchannel and 2 OFDM symbols for


-DRAFT 03/20/09- - 38 -

CDMA_INIT_REQ and 1 subchannel and 1 OFDM symbol for CDMA_BW_REQ. CDMApacket structure is defined in wimax/mac802_16pkt.h.

Struct cdma_req_header_t {u_char ht : 1;

u_char ec : 1;u_char type : 3; //use this MSB => 00:BW_REQ, 01:CDMA-BW_REQ, 11:CDMA-INIT-REQ

u_char top; //use 8 bits so max_opportunity is 2^8 = 256 u_int16_t br : 11; //use this "br" to indicate #subcribers; max => 2^11 = 2048 MS

u_char code; u_int16_t cid;};

Moreover, this current version specifies the CDMA flag at mac802_16 header to distinguish thisspecial packet among others as shown below;

struct hdr_mac802_16{ //virtual info for physical layer phy_info_t phy_info;

//to mark cmda packets, cdma packet indication char cdma;…..

7.7.1.4 CDMA StagesUnlike other MAC packets, CDMA packet is treated as a special packet. As a result, the powercalculation is not calculated at wimax/mac802_16BS.cc and mobile/prop_OFDMA.cc, so fordetecting collision purpose; however, the collision will be detected at the scheduling stage instead(wimax/scheduling/bsscheduler.cc) say if the code and transmission opportunity is the sameamong two or more CDMA packets.

At scheduling stage, the base station first does the collision detection for CDMA request. If thereis a collision of code and transmission opportunity among CDMA packets, BS drops the CDMArequest. Otherwise, BS allocates ranging request opportunity (12 bytes) for CDMA_INIT_REQor at least bandwidth request opportunity (6 bytes) for CDMA_BW_REQ.Maximum [ bandwidth_request_opportunity, remaining_bandwidth_request_opportunity ]

This version does not support CDMA_MAP_IE yet. However, since the CID and subscriber IDare encapsulated in the CDMA packet. In particularly for CDMA_BW_REQ, BS makes use ofthese parameters to allocate bandwidth request opportunity to each requested subscriber. In otherword, BS uses a normal UL_MAP_IE as an indication of uplink grant; however, forCDMA_INIT_REQ, BS does send code and transmission opportunity back to requestedsubscriber but the size of CDMA_MAP_IE is not put into consideration yet.[CDMA_UL_MAP_IE → next updated version]

Once BS allocates the transmitted opportunity or bandwidth request opportunity, at MSS , forCDMA_INIT_REQ, first it checks if the transmitted code is the same as what it send and if it’sthe same, MSS basically transmits ranging message. For CDMA_BW_REQ, since the allocationis treated as a regular grant, the MSS first checks if it can transmit all enqueued packet. If not, thebandwidth request packet is created and transmitted. Also, MSS transmits other packets after thebandwidth request packet if applicable (wimax/scheduling/wimaxscheduler.cc).


-DRAFT 03/20/09- - 39 -

Figure 28: Steps in CDMA request

Note that, backoff_start, request_retry, and backoff_stop parameters are defined in tcl/lib/ns-wimax.tcl.

Mac/802_16 set request_retry_ 2 ;# number of retries on bandwidth allocationrequestsMac/802_16 set reg_req_retry_ 3 ;# number of retries on registration requestsMac/802_16 set rng_backoff_start_ 2 ;# initial backoff window size for ranging requestsMac/802_16 set rng_backoff_stop_ 6 ;# maximal backoff window size for ranging requestsMac/802_16 set bw_backoff_start_ 2 ;# initial backoff window size for bandwidth requestsMac/802_16 set bw_backoff_stop_ 6 ;# maximal backoff window size for bandwidth requests

7.7.1.5 CDMA Timers (wimax/scheduling/wimaxscheduler.cc)

There are two main timers: t6 and t16. T6 is a timeout for ranging request. In this version, if MSSsends ranging request, MSS will reset the timeout_timer to t6 and so if the ranging process is notsuccessful within t6, CDMA_INIT_REQ will be transmitted again.

T16 is a timeout for bandwidth request. Similar to t6, in this version, if MSS sends bandwidthrequest packet, MSS will reset timeout_timer to t16 and so if MSS can not send any data packetsout within t16, CDMA_BW_REQ will be transmitted again.

int WimaxScheduler::transfer_packets1 (Connection *c, Burst *b, int b_data){ Packet *p; hdr_cmn* ch;…


-DRAFT 03/20/09- - 40 -

mac_->getMap()->getUlSubframe()->getRanging()->setTIMEOUT (mac_->addr(), t6time); debug10("\t Reset CDMA_INIT_REQ timer to #frame :%d (%f sec) since send INIT-RNG-MSGQ out for cid :%d, ssid :%d\n", t6time, mac_->macmib_.t6_timeout, c->get_cid(), mac_->addr());…

mac_->getMap()->getUlSubframe()->getBw_req()->setTIMEOUT (c->get_cid(),t16time); debug10("Reset CDMA_BW_REQ timer to #frame :%d (%f sec) since send BW-REQ outfor cid :%d\n", t16time, mac_->macmib_.t16_timeout, c->get_cid());

7.7.1.6 CDMA dequeueIn order to remove CDMA packets from the CDMA request queue, for CDMA_INIT_REQ, ifranging process is successful, CDMA_INIT_REQ will be removed (wimax/mac802_16SS.cc).For CDMA_BW_REQ, if MSS can send some packets out, CDMA_BW_REQ will be removed(wimax/scheduling/wimaxscheduler.cc").

void Mac802_16SS::process_ranging_rsp (mac802_16_rng_rsp_frame *frame){ if (frame->ss_mac_address != addr()) return;

Connection *basic, *primary; PeerNode *peer; switch (frame->rng_status) { case RNG_SUCCESS: debug ("Ranging response (remove cdma intial ranging request) : status = Success.Basic :%d, Primary:%d\n", frame->basic_cid, frame->primary_cid);

peer = getPeerNode_head(); assert (peer); getMap()->getUlSubframe()->getRanging()->removeRequest_mac (addr());

int WimaxScheduler::transfer_packets1 (Connection *c, Burst *b, int b_data){ Packet *p; hdr_cmn* ch;… debug10("\tRemove CDMA_BW_REQ (if exist) since send some packet out for cid [%d].\n",c->get_cid()); mac_->getMap()->getUlSubframe()->getBw_req()->removeRequest (c->get_cid());

7.7.2 Contention resolutionThe BS allocates slots that are subject to collisions in the uplink direction. These slots are used intwo cases:

- Initial Ranging request- Bandwidth request


-DRAFT 03/20/09- - 41 -

The model supports a truncated binary exponential backoff for contention resolution. The UCDmessages broadcasted by the BS contain the window sizes (as a power-of-two value). The BSalso decides on the number of slots allocated in each frame.

Figure 2 shows the class structure used for contention resolution. An uplink subframe contains aBwContentionslot and a RngContentionSlot. Both are subclasses of ContentionSlot whichprovides the basic mechanisms related to contention.

During Network Entry, the MSS performs ranging to adjust its transmission power. During thisstep, the MSS generates a RangingRequest. The MSS picks a random backoff within the windowsprovided by the BS and stores it. Then the MSS decrements the counter every time a newcontention slot is found in the frame. When the counter reaches 0, the packet is being transmitted.


-DRAFT 03/20/09- - 42 -

Figure 29: Contention slots and contention requests

7.7.3 TCL commandsMac/802_16 set rng_backoff_start_ 2Mac/802_16 set rng_backoff_stop_ 6Set the backoff window size for initial ranging requests

Mac/802_16 set bw_backoff_start_ 2Mac/802_16 set bw_backoff_stop_ 6Set the backoff window size for bandwidth requests

Mac/802_16 set contention_rng_retry_ 16Number of retransmission for sending ranging requests.


-DRAFT 03/20/09- - 43 -

Mac/802_16 set request_retry_ 2Number of retransmission for bandwidth requests

Note: the backoff windows are MAC parameters while the number of contention slots for rangingand bandwidth is a BS scheduler parameter.

7.8 MAC support of PHYThe model currently supports TDD. In this mode, uplink transmission occurs after downlink ineach frame.The DL_MAP and UL_MAP messages sent every frame defines the burst allocation andtransmission opportunities for each station.The information contained in the UL_MAP belongs to the same frame as shown in Figure .

Figure 30: Time relevance of DL_MAP and UL_MAP

7.9 Network entry and initializationPlease refer to Section 7.7.1 for CDMA based contention.

When an MSS wants to join a network it needs to perform network entry. As shown in themodel implements the following components of the network entry:

- Scan downlink channel- Obtain transmit parameters- Initial ranging- Registration


-DRAFT 03/20/09- - 44 -

MS

Channel Selection

Normal operation

DL_MAP (Downlink map)

DCD (Downlink Channel Descriptor)

Ranging request

UCD (Uplink Channel Descriptor)

UL_MAP (Uplink map)

Downlinksynchronization

Uplinksynchronization

Ranging responseInitial ranging

Registration request

Registration responseRegistration

MS

Channel Selection

Normal operation

DL_MAP (Downlink map)

DCD (Downlink Channel Descriptor)

Ranging request

UCD (Uplink Channel Descriptor)

UL_MAP (Uplink map)

Downlinksynchronization

Uplinksynchronization

Ranging responseInitial ranging

Registration request

Registration responseRegistration

Figure 31: Network entry

The following parameters can be configured:- Timers to perform channel scanning- Frequency of the DCD/UCD messages- Parameters for initial ranging (backoff window size and number of slots per frame)- Channel allocation

Some aspects are IEEE 802.16e are implemented therefore network entry can be reduced if theMSS has acquired the transmission parameters from the serving BS or during scanning (seesection 7.12).

7.10 RangingRanging is a mechanism to allow a MSS to maintain a good link quality by adjusting itstransmission power and modulation.

During the initial ranging, the MSS includes the default DIUC profile to use for transmission.This allows the simulation of nodes transmitting at different rates.

Please refer to Section 7.7.1 for CDMA based contention.

TCL command:$mac set-diuc ProfileID ;# 1<= ProfileID <= 11Set the profile to use by the MAC. The command is only valid at an MS.


-DRAFT 03/20/09- - 45 -

7.11 QoS PolicingThe framework defines structures to support the implementation of schedulers that make use ofthe different classes of service defined in [1].

Each Connection can be associated with a ServiceFlow and corresponding QoS parameters asshow in Figure 32.

Figure 32: Service Flow

The user configures the list of flows in each MSS via TCL. These provisioned flows are stored inthe ServiceFlowHandler as static connections. They are established every time the MSS attachesto a new BS.

While the structure supports the definition of QoS flows, it is up to the scheduler to make use ofthat information.

The ServiceFlowHandler is responsible for handling creation of flows. The defaultimplementation does not provide any admission control mechanism. It accepts all the flowrequests from the MSs.


-DRAFT 03/20/09- - 46 -

7.11.1 TCL commands$mac set-servicehandler FlowHandlerReplace the default service flow handler.

[$wl_node_($i) set mac_(0)] setflow DL 10000 BE 700 2 1 0.01 8 1The parameters are as follow:

- DL – Downlink, use UL for Uplink- 10000 – Data Rate (bytes/s)- BE - Scheduling Type BE/rtPS/nrtPS/ertPS- 700 – Datasize (bytes)- 2 – Period (For UGS traffic)- 1 - To indicate if ARQ is enabled or not- 0.01 - ARQ Retransmission timer value (s)- 8 - ARQ Window size- 1 - counter to indicate when ARQ ACKs have to be sent

Configure the list of flows that must be setup after network entry.

7.12 MAC layer handover proceduresThe model supports layer 2 mobility. Depending on the configuration, the MSS may performscanning and handover between BSs. This section presents the configuration parameters thataffect the handover capability.

7.12.1 ScanningWhen the link quality deteriorates, the MSS can send a MOB-SCN_REQ to the serving BS torequest scanning interval for the purpose of finding surrounding BSs. shows the messagessequence during scanning as implemented in the model.

MS Serving BS Target BSNormal operation

Decision to searchpossible BSs

Normal operation

Listen to channels

Synchronization messages (DL_MAP,DCD, UCD, UL_MAP)

MOB-SCN_REQ

MOB-SCN_RSP

Scanning

Normal mode

Repeatscanningand normalmodeintervals

MOB-SCN_REP

MOB-MSHO_REQ

MOB-MSHO_RSP

Switch channel and network entry

MOB-MSHO_IND

MS Serving BS Target BSNormal operation

Decision to searchpossible BSs

Normal operation

Listen to channels

Synchronization messages (DL_MAP,DCD, UCD, UL_MAP)

MOB-SCN_REQ

MOB-SCN_RSP

Scanning

Normal mode

Repeatscanningand normalmodeintervals

MOB-SCN_REP

MOB-MSHO_REQ

MOB-MSHO_RSP

Switch channel and network entry

MOB-MSHO_IND

Figure 33: Scanning procedure

To trigger the sending of a MOB-SCN_REQ, the MSS monitors the signal level of the incomingpackets. When the level crosses a threshold, the message is sent.


-DRAFT 03/20/09- - 47 -

By default, the threshold is set to the RXThreshold therefore scanning is not used. To enablescanning, change the lgd_factor_ attribute of the MIB to a value greater than 1.0. The higher thevalue, the sooner the scanning will trigger.

During scanning, the MSS collects RSSI values of incoming packets. These values are reported tothe serving BS that uses the information to select the best target BS.After the MSS receives indication of the selected BS, it waits for a few frames before indicatingits intention to perform handover. The introduction of the delay is to allow the traffic bufferedduring scanning to be exchanged before switching BSs.

Different scanning modes are implemented:• In scan without association, the MSS attempts to identify and synchronize with one or

more BSs. It also estimates the signal quality.• In association level 0, the target BS has no information about the scanning MSS and only

provides contention-based ranging allocations. After sending a ranging request, the MSSwaits for a response from the BS with a default timeout value of 50ms.

• In association level 1, the serving BS negotiates with the target BSs a time at which theMSS will find a dedicated ranging region. After sending a ranging request, the MSS waitsfor a response from the BS with a default timeout value of 50ms.

Association level 2 is not currently implemented.

To allow these different scanning modes and to perform fast handovers, the WiMAXCtrlAgent isrequired. The WiMAXCtrlAgent is an Agent performing 3 functions. The first one is to exchangeDCD/UCD information between the neighbor BSs. The second is to trigger the sending of NBR-ADV messages to the MSs. The third one is to synchronize the serving BS and the target BSswhen performing scanning level 1 or 2. The messages are exchanged over wired links usingstandard IP packets.

7.12.2 TCL commandsMac/802_16 set lgd_factor_ factor ;# factor >= 1.0Set the factor used to generate a link going down. When the received power is less thatfactor*RXThresh_, a trigger is generated to initiate scanning. The higher the factor, the soonerthe trigger is generated.

Mac/802_16 set scan_duration_ 50Set the number of frames to perform scanning.

Mac/802_16 set interleaving_interval_ 50The number of frames interleaved between two scanning iterations.

Mac/802_16 set scan_iteration_ 2Set the number of iterations to perform scanning.

Mac/802_16 set nbr_adv_interval_ 0.5 ;#in secondsThe interval time between two MOB_NBR-ADV messages

Mac/802_16 set scan_req_retry_ 3Set the number of retransmission for MOB_SCAN-REQ

Agent/WimaxCtrl set debug_ 0 ;#set to 1 to print debug


-DRAFT 03/20/09- - 48 -

Indicates if debug information must be printed regarding the scanning controller.

Agent/WimaxCtrl set adv_interval_ 1.0 ;# in secondsSet the interval time between the exchanges of DCD/UCD information between neighboring BSs.This exchange is done using the backbone network.

Agent/WimaxCtrl set default_association_level_ 0Set the scanning level to use. The information is embedded in the MOB_SCAN-RSP messagesent by the BS to the MS.

Agent/WimaxCtrl set synch_frame_delay_ 50 ;# in secondProcessing delay between the reception of a MOB_SCAN-REQ and the sending of theMOB_SCAN-RSP when synchronization with target BSs is needed.

7.13 Frame structure

Figure 34: Frame class diagram


-DRAFT 03/20/09- - 49 -

Figure 35: TDD Frame structure

The design used to represent a frame is closely similar to the structure defined in IEEE 802.16 forTDD. A frame (class FrameMap) contains a downlink and an uplink subframe (abstract classSubFrame, class DlSubFrame and UlSubFrame). The subframes are themselves seperated intoPHY PDU intervals. In each of these intervals, bandwidth is allocated in burst (abstract classBurst, class UlBurst and class DlBurst) for the different stations. Each of these bursts can have adifferent modulation and frequency called profile (class Profile).

Normally the BS allocates bandwidth for a station to transmit its data. In some cases, generallyinitial ranging and bandwidth requests, the MSSs need to compete with each other to access themedium. These intervals (class ContentionSlot) are only present in the uplink since the BS hastotal control over the downlink traffic.

The FrameMap class also contains methods to extract and parse the control messages. At the BS,the scheduler creates the map structure according to an allocation algorithm, and then calls thefunctions getDL_MAP, getUL_MAP, getDCD, and getUCD, to retrieve the packets containing thenecessary information to be sent to the MSSs. At the MSS, the scheduler calls the reversefunctions parseDL_MAP, parseUL_MAP, parseDCD, and parseUCD to recreate the datastructurenecessary to handle proper reception and transmission of packets.

7.14 Packet processingThe Figure below shows the packet flows for incoming and outgoing packets.


-DRAFT 03/20/09- - 50 -

OFDM Physical layer

Upper layer protocols

Classifiers

Frame reassembly

Outgoing queues withfragmentation per CID

Service Flow Handler

Service flows

Scheduler

STA: process synchronizationmessages from BS. Schedule uplink

traffic.BS: generate synchronization

messages and schedule downlinktraffic. Also perform admission

control.

DSx frames

SynchronizationMessages

DSx frames


Controlsframetransmission

Outgoing packet

Incoming packetOFDM Physical layer

Upper layer protocols

Classifiers

Frame reassembly

Outgoing queues withfragmentation per CIDOutgoing queues withfragmentation per CID


Service flows


Service flows

Scheduler

STA: process synchronizationmessages from BS. Schedule uplink

traffic.BS: generate synchronization

messages and schedule downlinktraffic. Also perform admission

control.

DSx frames


DSx frames


Controlsframetransmission

Outgoing packet

Incoming packet

Figure 36: Packet processing overview

The activity diagrams provide more detailed information on how the packets cross the MAClayer.

Figure 37: Outgoing packet processing

A packet received from an upper layer is classified using the registered classifiers. Since theremay be multiple classifiers, the MAC accesses them one by one trying until a valid CID is found,or all classifiers have been tested. If the CID is valid, the packet is added to the matching queueotherwise it is dropped.

When a new packet is received, i.e. its first bit, steps shown in Figure 38 are executed. At the endof the reception, the packet is processed as shown in the Figure below.


-DRAFT 03/20/09- - 51 -

Figure 38: New incoming packet processing


-DRAFT 03/20/09- - 52 -

Figure 39: Received Packet Processing

8 PHY

8.1 OFDMA PHY

8.1.1 OFDMA physical layer class diagram


-DRAFT 03/20/09- - 53 -

Figure 40: OFDMA Physical layer class diagram

The OFDMA physical layer is used to transmit packets in the implemented model. Theconfiguration is done using TCL bindings for the frequency bandwidth and cyclic prefix. Since itinherits from the WirelessPhy class, attributes such as frequency or transmission power can alsobe configured by TCL.

As Shown in Figure 40, the physical layer can be in different states. When in sending mode, allincoming packets are discarded. In receiving mode, packets cannot be sent. Furthermore, thepacket header contains virtual information, such as frequency, modulation, and cyclic prefix,which are used to filter incoming packets.

The model supports different modulations and PUSC permutation. The MAC layer allocatesbursts that can use different modulations according to distance or interference. This affects thedata rate and transmission time. The physical layer includes helper functions called by the MAClayers when transmitting data:

- getTrxTime returns the time required to send a packet given its size and modulation,number of subchannels , Permutation scheme.

- getMaxPktSize is the reverse function and returns the maximum packet size given thenumber of OFDM symbols, number of subchannels, Permutation Scheme and themodulation used.

- getNumSubchannels, getSlotCapacity, getMCSindex, getMaxBlocksize, etc.


-DRAFT 03/20/09- - 54 -

The node_on and node_off functions enable or disable blocking all transmissions and receptionsof packets, but is not currently linked to any power consumption mechanisms.

8.1.2 OFDMA Packet schedulers

8.1.2.1 BSschedulerThe current implementation of the packet scheduler for BS can be configured using the followingcommands:

set scheduler [new WimaxScheduler/BS]Creates a packet scheduler for BS.

$scheduler set-contention-size $sizeSet the number of contention slots to be allocated for initial ranging and bandwidth requests ineach frame.

The scheduler implements a Best-Effort scheduler coupled with a Round Robin algorithm todistribute the bandwidth allocations among the users.

To support BE, bandwidth requests are generated at the MSS indicating the amount of data totransfer.

The ratio between the downlink and uplink subframes is fixed and is configured via TCL

WimaxScheduler/BS set dlratio_ 0.6Indicates 60% of the frame is for downlink and 40% is for uplink.

The scheduler also allows users to have different modulations.$scheduler set-default-modulation $modulationSets the modulation to use for the initial ranging and bandwidth requests slots.

Profile bursts are created by default as follows:Profile name Modulation

DIUC_PROFILE_1, UIUC_PROFILE_1 OFDM_BPSK_1_2DIUC_PROFILE_2, UIUC_PROFILE_2 OFDM_QPSK_1_2DIUC_PROFILE_3, UIUC_PROFILE_3 OFDM_QPSK_3_4DIUC_PROFILE_4, UIUC_PROFILE_4 OFDM_16QAM_1_2DIUC_PROFILE_5, UIUC_PROFILE_5 OFDM_16QAM_3_4DIUC_PROFILE_6, UIUC_PROFILE_6 OFDM_64QAM_2_3DIUC_PROFILE_7, UIUC_PROFILE_7 OFDM_64QAM_3_4

The user can select the burst profile to use [1-7] by TCL using the following:[$SSWithWiMax set mac_(0)] set-diuc 7Note: By default, the profile (modulation) is the same for BOTH downlink and uplink forcommunication between a MSS and a BS.

8.1.2.2 SSschedulerset scheduler [new WimaxScheduler/SS]


-DRAFT 03/20/09- - 55 -

Creates a packet scheduler for MSS.

8.1.3 TCL ConfigurationPhy/WirelessPhy/OFDMA set g_ 0 ;# cyclic prefixSet the cyclic prefix to use. Valid values are 0.25 (1/4), 0.125 (1/8), 0.0625 (1/16), 0.03125 (1/32)By increasing the cyclic prefix, the overhead is increasing thus reducing the maximumthroughput.

Mac/802_16 set fbandwidth_ 10e+6 ;# frequency bandwidth (MHz)Configure the frequency bandwidth. Setting a higher bandwidth increases the throughput.

Mac/802_16 set rtg_ 10 ;# number of PS to switch from receiving totransmitting state

The duration required to switch from receiving to transmitting. Increasing the value decreases themaximum achievable throughput.

Mac/802_16 set ttg_ 10 ;# number of PS to switch from transmitting toreceiving state

The duration required to switch from transmitting to receiving. Increasing the value decreases themaximum achievable throughput.

Mac/802_16 set channel_ 0 ;# channel numberSet the channel to use. This is configured at the MAC and passed to the physical layer. It isrequired to set it at the BS. The MSS will scan the channels to detect surrounding BSs.

8.2 OFDMA PHYThe channel model used in this OFDMA module is a Cost231 bulk path loss componentcombined with a Clarke-Gans implementation of Rayleigh Fading. Doppler effects are includedto capture mobility effects. Fast fading is included by modeling the channel as a Rayleigh fadingchannel with multiple taps (as described by select ITU power delay profiles).

By the nature of an OFDMA frame, symbols are created in the frequency domain. Because ofthis, it is possible to skip a major step of the actual transmission process in a WiMAX system. Inpractice, once the symbols have been created in the frequency domain, they must be convertedinto a time domain signal via the IFFT. This time domain signal is then effectively convolvedwith the actual physical channel, yielding the received signal, y(t). However, Y(f) is the signalthat must be seen at the receiver, so an FFT must be taken to convert back to a frequency domainrepresentation. The exact same result is obtained if the IFFT/FFT steps are not performed, butrather X(f) simply multiplied element-wise by H(f), the channel frequency response. This greatlyreduces the computational burden of the model.

The bulk path loss component of the channel is computed during the simulation, because thedistance between nodes and current transmit power are necessary parameters. However, the fastfading component of the channel can be computed offline, before the simulation is running.Included in this patch are 1000 pre-computed channels for each ITU model (PED. A, etc.).

8.2.1 Cost231This is the bulk path loss model that is used. The details are taken from “Channel Models: ATutorial, Feb 21, 2007, Raj Jain”


-DRAFT 03/20/09- - 56 -

The propagation loss is computed using the following formula:

Where:P_L is the propagation lossf_c is the carrier frequency (2GHz in this case)h_t is the height of the transmit antenna (can vary from 30m to 300m)h_r is the height of the receive antenna (can vary from 1m to 10m)d is the distance between the transmitter and receiver (can vary from 1km to 20km)C_M is 0dB for suburbs and 3dB for metropolitan areas

8.2.2 Fast/Frequency Selective Fading

8.2.2.1 Pre-Simulation CalculationsThis part of the model is to include the Doppler Effect. A vector of Rayleigh numbers (whoselength is the number of channel realization) is generated and element-wise multiplied with aDoppler spectrum of the same length. The IFFT of this array is taken to give a correlated timedomain sequence of the appropriate length. This is repeated n times, where n is the number oftaps in the ITU-PDP model. The n numbers of each array are then put at appropriate samplepoints and scaled by the tap powers given by the ITU model. Then a 1024 pt FFT is taken of thisn numbers to give the 1024 channel coefficients. An example ITU model is shown in Figure 41.

Figure 41: Example ITU Model

The FFT of the resulting time domain channel vector is stored as a line in a file (whose namecorresponds to the ITU model which was used). The same channel is shown in both the time andfrequency domain in Figure 42.


-DRAFT 03/20/09- - 57 -

Figure 42: Conversion from Time Domain to Frequency Domain Channel

The result of this implementation is that these channel model computations are done completelyoffline, which produces large savings in simulation run time. An example of a channel realizationfile is shown in Figure 43.

Figure 43: Example ITU Model Based Channel Realization File

The effect of the above process is to model the per-tap time correlation of a time varying multi-tap channel. The last step of the process is to convert the time domain channel gains to afrequency domain view of the channel. This is useful because in NS2 we are interested in the


-DRAFT 03/20/09- - 58 -

receive power on each subcarrier. However, the correlation can be seen more clearly in a timedomain visualization. Figure shows three consecutive snapshots of the channel. The correlationis between the taps circled in red, or “down” the diagram.

Figure 44: Time Domain Correlation

8.2.3 Interference Modeling (SIR)At every receiver, when a packet is received, the received power on the sub-carriers it comes iscomputed. Then the packet is recorded and a timer starts (time is the duration of the packet) andits power is added to an I1 array as interference on each sub-carrier. This is done at the physicallayer. Now when we receive the 1st bit of the packet at the MAC, it is decided to be either an “SPacket” (a packet addressed to the current receiver, contributing to the signal (the S in SIR)power) or an “I Packet” (a packet not addressed to the current receiver, contributing to theinterference (the I in SIR) power). If it is an “S Packet”, the current I1 array is obtained. Thepower of S packet is deducted from I1 (since we had added the power of this packet also to I1)and a packet timer is started to receive the packet completely. This I1 array is the interferencecaused due to the packets currently undergoing transmissions when we receive our 1st bit. Now tocalculate the interference that will be caused while our packet was being received we initializeanother I2array and add the powers of the packets that we receive. When we receive our S packetcompletely, we check this I2 array and add it to I1 array at the subcarrier level and do an EESMto get the SIR value. The SIR Table is then queried to get the error probability. If the packet is inerror, it is dropped, else it is processed.


-DRAFT 03/20/09- - 59 -

Figure 45: Snapshot of Interference

8.3 Details of OFDMA channel Implementation in NS2To implement the channel modeled above in NS2, a class called prop_OFDMA was created. It isa derived class of the base class propagation. When an OFDMA propagation model isinstantiated, the selected ITU model based frequency domain channels are all read into memoryfrom the proper file. In the first frame of the simulation, a random channel is assigned to eachMSS. Every time the frame timer expires (every 5ms, the coherence time of the channel), theindex of the current channel that each MSS is using is incremented.

When we receive a packet, we first call the bulk path loss module (COST231) which returns thereceived power after path loss. We then compute the multipath fading loss. We extract thesubcarrier information over which the packet was transmitted. We assume that if the total powerof the packet is P, the power on each sub-carrier is P/N, where N is the total number of sub-carriers over which it was transmitted. We then scale the powers at each sub-carrier with thechannel gains that we had generated off-line and do EESM to get the received signal power.If there are more nodes than available channels, multiple nodes might share the same channel.To enable the propagation model one has to configure in the tcl the propagation model asOFDMA and also specify the ITU model.


-DRAFT 03/20/09- - 60 -

8.4 Received SINR Averaging (EESM)Once the received SINR on each subcarrier used by the current packet is obtained, a decision ismade to SendUp or drop the packet. This is done by finding the EESM to get the effective SINRand then extracting the BLER from SINR, MCS and Block size. The packet is mapped to blocksand from the BLER a decision is made whether to drop the packet or not. EESM is obtained bythe following formula.

8.5 Transmission and Interference Power calculation logicOnce a packet is incoming, its transmission region can be calculated according to the number ofOFDMA symbols, OFDMA symbol offset, number of subchannel and subchannel offset. The BSand MS will always trying to use the peak transmission power to transmit packets. The peak Txpower will keep constant among each OFDMA symbols in the transmission area and then it willbe evenly distributed to each subcarrers in the OFDMA symbol (data subcarriers, pilot subcarriersand NULL/guard subcarriers). Whatever size of the packet, the Tx power on each subcarrier isthe same. The advantage of using peak Tx power to each OFDMA symbols is that it will helpMS on the largest possibility to finish network synchronization and entry procedures successfully.Later on the Tx power could be cut down by power control algorithm. Because of there alimitation of physical layer which can only pass 1024 power information to the MAC layer toproceed, the evenly distributing peak Tx power to subcarriers makes the 1024 limitation enoughto pass power information.

9 Configuration

9.1 SetupThere are multiple steps required to start using the IEEE 802.16 model in the simulations.

9.1.1 Configure the nodeThe MAC and Physical layers are specified using the node-configure method in TCL:

$BSWithWiMax node-config-macType Mac/802_16/BS-phyType Phy/WirelessPhy/OFDMA

$SSWithWiMax node-config-macType Mac/802_16/SS-phyType Phy/WirelessPhy/OFDMA

9.1.2 Configure a packet classifierIn IEEE 802.16, packets received by the MAC layer from upper layers are classified in order todirect them to the proper connection. The model proposes a classifier based on the destinationMAC address and packet type.


-DRAFT 03/20/09- - 61 -

# Create classifierset classifier [new SDUClassifier/Dest]

# Set the classifier priority$classifer set-priority 1

# Retrieve the MAC layer and delete all registered classifiers[$nodeWithWiMax set mac_(0)] reset-classifiers

# Retrieve the MAC layer and set classifier [$nodeWithWiMax set mac_(0)] add-classifier $classifier

Note: A default classifier (DestClassifier) is added to the MAC. To add change the classier, resetthe list and add a new classifier.

9.1.3 Configure a schedulerTo allow flexibility the MAC layer can use different types of schedulers. Mainly there is one forBase Stations (BSs) and one for Subscriber Stations (SSs). Section 7.6.1 shows how to extend thedefault schedulers.For BS, the following TCL code sets the scheduler

# Create schedulerset scheduler [new WimaxScheduler/BS]

# Add scheduler[$nodeWithWiMax set mac_(0)] set-scheduler $scheduler

Note: This scheduler is automatically created when the MAC 802.16 BS is created.

For MSS, the following needs to be used

# Create schedulerset scheduler [new WimaxScheduler/SS]# Add scheduler[$nodeWithWiMax set mac_(0)] set-scheduler $scheduler

Note: This scheduler is now automatically created when the MAC 802.16 MSS is created.

9.1.4 Configure the channelTo allow multi cell topologies, the MAC layers can operate at different frequencies. To set thefrequencies, the user can set the channel number for the MAC.

# Retrieve the MAC layer and set classifier[$nodeWithWiMax set mac_(0)] set-channel 1 #valid 0-4

The current frequency table contains 5 channels on the 3.5GHz band and 7MHz frequencybandwidth.


-DRAFT 03/20/09- - 62 -

9.1.5 Select the OFDMA Propagation ModelIn the previous release, the propagation model used was TwoRayGround. To use the propagationmodel described in this document, “OFDMA” must be used.

set opt(prop) Propagation/OFDMA

9.1.6 Select a Fading ModelThe following TCL code loads the channel realizations of the selected ITU model into an array inthe c++ code.

set prop_inst [$ns set propInstance_]$prop_inst ITU_PDP PED_A #other choices are PED_B, VEHIC_A

9.2 StatisticsSome statistics are collected at the MAC layer. The following command is used to display theirvalues during the simulation.

Mac/802_16 set print_stats_ true

9.3 TracingThe IEEE 802.16 model introduces new values in the trace file. Two new reasons for dropping apacket appear:

- CID: this reason code is used when a packet received at the MAC layer cannot bematched to any connection.

- QWI: each connection has a queue to store pending frames. When the queue is full, thepacket is dropped using this reason code.

- FRG: indicates an error during the transmission of a fragment.A new packet type is introduced. Sometimes, BSs need to communicate for synchronizationpurposes. A new agent called Agent/WimaxCtrl handles this communication, and sends packetsmarked as WimaxCtrl.

Note on traces when fragmentation is used:If MAC traces are enabled and fragmentation is used, the fragments will be shown as sent but notreceived. At the last fragment, the complete packet can be decoded and passed to upper layerwhich would then create a trace entry on the receiver side. For example, let’s consider a packetwith 1520 bytes which will be fragmented in four fragments of 396, 396, 396, and 364 bytes. Thetrace file will contain four “send” entries for each of the fragments but only one “received” entryof 1520 bytes for the complete packet.

10 Parameters and Constants

10.1 ParametersMany parameters exist to configure the MAC and Physical layers. Below is the list of parameters,default values, and descriptions as presented in the file ns-wimax.tcl.

# This class contains default value for tcl

#Physical layer configurationPhy/WirelessPhy/OFDMA set g_ 0 ;# cyclic prefix


-DRAFT 03/20/09- - 63 -

Mac/802_16 set channel_ 0 ;# channel numberMac/802_16 set fbandwidth_ 10e+6 ;# frequency bandwidth (Hz)Mac/802_16 set rtg_ 10 ;# number of PS to switch from receiving to transmitting stateMac/802_16 set ttg_ 10 ;# number of PS to switch from transmitting to receiving state

#MAC layer configurationMac/802_16 set queue_length_ 50 ;#maximum number of packets

Mac/802_16 set frame_duration_ 0.005 ;# frame duration (s)Mac/802_16 set dcd_interval_ 5 ;# interval between the broadcast of DCD messages (max 10s)Mac/802_16 set ucd_interval_ 5 ;# interval between the broadcast of UCD messages (max 10s)Mac/802_16 set init_rng_interval_ 1 ;# time between initial ranging regions assigned by the BS (max 2s). Note usedMac/802_16 set lost_dlmap_interval_ 0.6 ;# timeout value for receiving DL_MAP message (s)Mac/802_16 set lost_ulmap_interval_ 0.6 ;# timeout value for receiving UL_MAP message (s)

#Timers (all values in seconds)Mac/802_16 set t1_timeout_ [expr 5* [Mac/802_16 set dcd_interval_]] ;# wait for DCD timeoutMac/802_16 set t2_timeout_ [expr 5* [Mac/802_16 set init_rng_interval_]] ;# wait for broadcast ranging timeoutMac/802_16 set t3_timeout_ 0.2 ;# ranging response timeoutMac/802_16 set t6_timeout_ 3 ;# registration response t imeoutMac/802_16 set t12_timeout_ [expr 5* [Mac/802_16 set ucd_interval_]] ;# UCD descriptor timeoutMac/802_16 set t16_timeout_ 0.1 ;# bandwidth request timeoutMac/802_16 set t17_timeout_ 5 ;# authentication. Not usedMac/802_16 set t21_timeout_ 0.02 ;# wait forDL_MAP timeout. Replace with 20ms to emulate preamble scanning on channel.

Mac/802_16 set contention_rng_retry_ 16 ;# number of retries on ranging requests (contention mode)Mac/802_16 set invited_rng_retry_ 16 ;# number of retries on ranging requests (invited mode)Mac/802_16 set request_retry_ 16 ;# number of retries on bandwidth allocation requestsMac/802_16 set reg_req_retry_ 3 ;# number of retries on registration requestsMac/802_16 set tproc_ 0.001 ;# time between arrival of last bit of a UL_MAP and effectiveness. Note usedMac/802_16 set dsx_req_retry_ 3 ;# number of retries on DSx requestsMac/802_16 set dsx_rsp_retry_ 3 ;# number of retries on DSx responses

Mac/802_16 set rng_backoff_start_ 2 ;# initial backoff window size for ranging requestsMac/802_16 set rng_backoff_stop_ 6 ;# maximal backoff window size for ranging requestsMac/802_16 set bw_backoff_start_ 2 ;# initial backoff window size for bandwidth requestsMac/802_16 set bw_backoff_stop_ 6 ;# maximal backoff window size for bandwitdh requests

Mac/802_16 set scan_duration_ 50 ;# duration (in frames) of scan intervalMac/802_16 set interleaving_interval_ 50 ;# duration (in frames) of interleaving intervalMac/802_16 set scan_iteration_ 2 ;# number of scan iterationsMac/802_16 set t44_timeout_ 0.1 ;# timeout value for scan requests (s)Mac/802_16 set scan_req_retry_ 5 ;# number of retries on scan requestsMac/802_16 set max_dir_scan_time_ 0.2 ;# max scan for each neighbor BSs (s)Mac/802_16 set nbr_adv_interval_ 0.5 ;# interval between 2 MOB-NBR_ADV messages (s)Mac/802_16 set client_timeout_ 0.5 ;# timeout value for detecting out of range client

Mac/802_16 set lgd_factor_ 1 ;# coefficient used to trigger Link Going Down (1 for no trigger)Mac/802_16 set print_stats_ false ;# true to activate print of statisticsMac/802_16 set rxp_avg_alpha_ 1 ;# coefficient for statistic on receiving powerMac/802_16 set delay_avg_alpha_ 1 ;# coefficient for statistic on frame delayMac/802_16 set jitter_avg_alpha_ 1 ;# coefficient for statistic on frame jitterMac/802_16 set loss_avg_alpha_ 1 ;# coefficient for statistic on frame lossMac/802_16 set throughput_avg_alpha_ 1 ;# coefficient for statistic on throughputMac/802_16 set throughput_delay_ 0.02 ;# interval time to update throughput when there is no traffic

WimaxScheduler/BS set dlratio_ 0.3 ;#default DL/UL subframe ratio

11 Sample TCL scriptIn this section we present a sample tcl script for the WiMAX simulations to serve as a guide tothe various steps needed to setup simulations using the simulator. In the sample script, weconsider a simple scenario with one MSS and one BS. Best effort traffic is sent by the MSS andARQ is enabled.


-DRAFT 03/20/09- - 64 -

# Test for 802.16 scheduler.# @author rouil# @date 03/06/2008# Test file for wimax# Scenario: Communication between MN and Sink Node with MN attached to BS.# Using grep ^r out.res | grep MAC | grep -c cbr you can see the number of# mac packets received at the BS.# Using grep ^s out.res | grep MAC | grep -c cbr you can see the number of# mac packets sent (200 packets).### Topology scenario:### |-----|# | MN0 | ; 1.0.1# |-----|### (^)# |# |--------------|# | Base Station | ; 1.0.0# |--------------|# |# |# |-----------|# | Sink node | ; 0.0.0# |-----------|#

#check input parametersif {$argc != 6} { puts "" puts "Wrong Number of Arguments! No arguments in this topology" puts "Syntax: ns test-be.tcl nbMNs dl/ul block_size window_size data_loss_rate arq_enable" puts "" exit (1)}

# set global variablesset nb_mn [lindex $argv 0] ;# max number of mobile nodeset direction [lindex $argv 1]set ARQ_b_size [lindex $argv 2]set ARQ_window_size [lindex $argv 3]set ARQ_data_loss_rate [lindex $argv 4]set ARQ_Enable_flag [lindex $argv 5]

set packet_size 1500 ;# packet size in bytes at CBR applicationsset output_dir .set gap_size 0.05 ;#compute gap size between packetsputs "gap size=$gap_size"set traffic_start 20set traffic_stop 25set simulation_stop 50set diuc 7 ;#modulation for MNs

@author

@date


-DRAFT 03/20/09- - 65 -

#define debug valuesMac/802_16 set debug_ 1Mac/802_16 set rtg_ 20Mac/802_16 set ttg_ 20Mac/802_16 set frame_duration_ 0.005Mac/802_16 set ITU_PDP_ 2Mac/802_16/BS set dlratio_ .3Mac/802_16/SS set dlratio_ .3Mac/802_16 set fbandwidth_ 10e+6Mac/802_16 set disable_interference_ 0

#param for ARQset arq_max_window_size $ARQ_window_sizeMac/802_16 set arq_block_size_ $ARQ_b_sizeMac/802_16 set arqfb_in_dl_data_ 1Mac/802_16 set arqfb_in_ul_data_ 1Mac/802_16 set data_loss_rate_ $ARQ_data_loss_rateMac/802_16 set queue_length_ 10000

Phy/WirelessPhy/OFDMA set g_ 0.25

#define coverage area for base stationPhy/WirelessPhy set Pt_ 0.2Phy/WirelessPhy set RXThresh_ 1.90546e-16Phy/WirelessPhy set CSThresh_ [expr 0.9*[Phy/WirelessPhy set RXThresh_]]Phy/WirelessPhy set OFDMA_ 1

# Parameter for wireless nodesset opt(chan) Channel/WirelessChannel ;# channel typeset opt(prop) Propagation/OFDMA ;# radio-propagation modelset opt(netif) Phy/WirelessPhy/OFDMA ;# network interface typeset opt(mac) Mac/802_16/BS ;# MAC typeset opt(ifq) Queue/DropTail/PriQueue ;# interface queue typeset opt(ll) LL ;# link layer typeset opt(ant) Antenna/OmniAntenna ;# antenna modelset opt(ifqlen) 50 ;# max packet in ifqset opt(adhocRouting) NOAH ;# routing protocol

set opt(x) 1100 ;# X dimension of the topographyset opt(y) 1100 ;# Y dimension of the topography

#defines function for flushing and closing filesproc finish {} { global ns tf output_dir nb_mn $ns flush-trace close $tf

exit 0}

#create the simulatorset ns [new Simulator]$ns use-newtrace


-DRAFT 03/20/09- - 66 -

#create the topographyset topo [new Topography]$topo load_flatgrid $opt(x) $opt(y)#puts "Topology created"

#open file for traceset tf [open $output_dir/traffic.res w]$ns trace-all $tf#puts "Output file configured"

# set up for hierarchical routing (needed for routing over a basestation)#puts "start hierarchical addressing"$ns node-config -addressType hierarchicalAddrParams set domain_num_ 2 ;# domain numberlappend cluster_num 1 1 ;# cluster number for each domainAddrParams set cluster_num_ $cluster_numlappend eilastlevel 1 [expr ($nb_mn+1)] ;# number of nodes for each cluster (1 for sink and onefor mobile nodes + base stationAddrParams set nodes_num_ $eilastlevelputs "Configuration of hierarchical addressing done"

# Create Godcreate-god [expr ($nb_mn + 2)] ;# nb_mn + 2 (base station and sink node)#puts "God node created"

#creates the sink node in first addressing space.set sinkNode [$ns node 0.0.0]#provide some co-ord (fixed) to base station node$sinkNode set X_ 50.0$sinkNode set Y_ 50.0$sinkNode set Z_ 0.0#puts "sink node created"

#creates the Access Point (Base station)$ns node-config -adhocRouting $opt(adhocRouting) \

-llType $opt(ll) \-macType Mac/802_16/BS \-ifqType $opt(ifq) \-ifqLen $opt(ifqlen) \-antType $opt(ant) \-propType $opt(prop) \-phyType $opt(netif) \-channel [new $opt(chan)] \-topoInstance $topo \-wiredRouting ON \-agentTrace ON \-routerTrace ON \-macTrace ON \-movementTrace OFF

#puts "Configuration of base station"

#setup channel modelset prop_inst [$ns set propInstance_]$prop_inst ITU_PDP PED_Aputs "after set pPDP"


-DRAFT 03/20/09- - 67 -

set bstation [$ns node 1.0.0]$bstation random-motion 0#puts "Base-Station node created"#provide some co-ord (fixed) to base station node$bstation set X_ 550.0$bstation set Y_ 550.0$bstation set Z_ 0.0[$bstation set mac_(0)] set-channel 0

# creation of the mobile nodes$ns node-config -macType Mac/802_16/SS \

-wiredRouting OFF \-macTrace ON ;# Mobile nodes cannot do routing.

for {set i 0} {$i < $nb_mn} {incr i} { set wl_node_($i) [$ns node 1.0.[expr $i + 1]] ;# create the node with given @. $wl_node_($i) random-motion 0 ;# disable random motion $wl_node_($i) base-station [AddrParams addr2id [$bstation node-addr]] ;#attach mn to basestation #compute position of the node $wl_node_($i) set X_ [expr 530.0+$i] $wl_node_($i) set Y_ 550.0 $wl_node_($i) set Z_ 0.0 puts "wireless node $i created ..." ;# debug info

[$wl_node_($i) set mac_(0)] set-channel 0 [$wl_node_($i) set mac_(0)] set-diuc $diuc [$wl_node_($i) set mac_(0)] setflow DL 10000 BE 275 2 $ARQ_Enable_flag 0.05 $ARQ_window_size1 0 0 0 0 0 0 0 0 0 0 [$wl_node_($i) set mac_(0)] setflow UL 10000 BE 275 2 $ARQ_Enable_flag 0.05 $ARQ_window_size1 0 0 0 0 0 0 0 0 0 0

#create source traffic #Create a UDP agent and attach it to node n0 set udp_($i) [new Agent/UDP] $udp_($i) set packetSize_ 1500

if { $direction == "ul" } {$ns attach-agent $wl_node_($i) $udp_($i)

} else {$ns attach-agent $sinkNode $udp_($i)

}

# Create a CBR traffic source and attach it to udp0 set cbr_($i) [new Application/Traffic/CBR] $cbr_($i) set packetSize_ $packet_size $cbr_($i) set interval_ $gap_size

$cbr_($i) attach-agent $udp_($i)

#create an sink into the sink node

# Create the Null agent to sink traffic set null_($i) [new Agent/Null] if { $direction == "ul" } {

$ns attach-agent $sinkNode $null_($i)} else {

$ns attach-agent $wl_node_($i) $null_($i)


-DRAFT 03/20/09- - 68 -

}

# Attach the 2 agents $ns connect $udp_($i) $null_($i)}

# create the link between sink node and base station$ns duplex-link $sinkNode $bstation 100Mb 1ms DropTail

# Traffic scenario: if all the nodes start talking at the same# time, we may see packet loss due to bandwidth request collisionset diff 0.02for {set i 0} {$i < $nb_mn} {incr i} { $ns at [expr $traffic_start+$i*$diff] "$cbr_($i) start" $ns at [expr $traffic_stop+$i*$diff] "$cbr_($i) stop"}

$ns at $simulation_stop "finish"# Run the simulationputs "Running simulation for $nb_mn mobile nodes..."$ns runputs "Simulation done."

The code consists of the following steps:1. Initially, the ARQ parameters are passed through the command line.2. Next the CBR flow parameters are set up.3. In the next block, the frame and bandwidth related parameters are set up.4. This is followed by further parameters for the ARQ.5. We then set up the transmit power and the receiver and carrier sensing thresholds.6. The simulator instance, topography and trace files are created next.7. Hierarchical routing is set up next.8. The base station and the mobile station are then set up.9. The uplink and downlink BE flows are created.10. The CBR source and sink are created and attached to the nodes.11. The traffic started and the simulation is started and stopped.

Note that for assigning the flows, we use a command like:

[$wl_node_($i) set mac_(0)] setflow DL 10000 BE 275 2 $ARQ_Enable_flag 0.05$ARQ_window_size 1 0 0 0 0 0 0 0 0 0 0

The parameters are as follow:DL – Downlink, use UL for Uplink10000 – Data Rate (bytes/s)BE - Scheduling Type BE/rtPS/nrtPS/ertPS700 – Datasize (bytes)2 – Period (For UGS traffic)1 - To indicate if ARQ is enabled or not0.01 - ARQ Retransmission timer value (s)8 - ARQ Window size1 - counter to indicate when ARQ ACKs have to be sent


-DRAFT 03/20/09- - 69 -

0 Traffic Priority0 Peak Traffic Rate0 Min Reserved Traffic Rate0 Requested Transmit Policy0 Jitter0 SDU Indicator0 Min Tolerable Traffic Rate0 SDU Size0 Max Burst Size0 SA ID

12 Validation ResultsIn this section we present some results that validate the accuracy of the developed simulator. Wepresent three sets of results for validating:

1. The modulation schemes2. Handovers3. ARQ

To validate the implemented modulation schemes, we consider a scenario with one BS and oneMS. We then observe the achieved throughout given that 15Mb/s of data is generated for variousmodulation schemes as the node position is varied. The results are shown below.

Figure 46: Achieved data rates for uplink transmissions


-DRAFT 03/20/09- - 70 -

Figure 47: Achieved data rates for downlink transmissions

Next we consider the delivery of packets in the case of handovers. We consider a scenario withtwo BS and one MS. Due to node mobility, the MSS moves from BS1 to BS2 at time and thenback to BS1 at time. The mobile IP implementation of ns-2 is used in these results. In the figurebelow, we show the received data packets as a function of time and note that once the handoversare complete, packet flows proceed as normal.

Figure 48: Packet delivery in a scenario with handovers


-DRAFT 03/20/09- - 71 -

Figure 49: Packet delay in a scenario with handovers

To validate the implemented ARQ mechanism, we consider a scenario with one BS and oneMSS. We then observe the achieved throughout given that 170Kbps of data is generated forvarious modulation schemes as the node position is varied. The ARQ block size is 256 bytes andthe data loss rate is 20%. The results are shown below.

Figure 50: Downlink throughput with ARQ for various modulation schemes


-DRAFT 03/20/09- - 72 -

Figure 51: Uplink throughput with ARQ for various modulation schemes

Next with fixed data loss rate, we show the reception rate would be with different modulationcoding rate. The following diagram shows the validation results.

Modulation Coding with ARQ (ARQ Block size:256, ARQ windowsize:1024, data loss rate:0.5, distance 30m)

0

20

40

60

80

100

120

BPSK 1/2

QPSK 1/2

QPSK 3/4

16QAM 1/

2

16QAM 3/

4

64QAM 2/

3

64QAM 3/

4

Modulation and Coding

Perc

enta

ge %

DL sucessful reception rateUL sucessful reception rate


-DRAFT 03/20/09- - 73 -

Figure 52: Reception Rate with ARQ under different Modulation and Coding and 50% data loss rateNotice: The 100% percentage of the successful reception is based on the data after the ARP resolution.Since on some rare case, when some data packets come from application layer, ARP resolution might beneeded to find the destination MAC address. Once the ARP resolution timeouts or a new data packetcomes, the current data packet in the ARP buffer will be dropped. But once the data packets get to theWiMAX Mac layer, all of them will be successfully received if we set the simulation time long enough.

13 Current limitationsFollowing is the list of known limitations:

1. The Packet CS only does packet classification.2. Slot definitions are as per the PUSC permutation scheme3. Support for only 10 MHz channel4. Support for only vertical allocation in both uplink and downlink5. The size of CDMA ranging region is fixed to 2 and 1 column-symbols for CDMA initial

ranging and CDMA bandwidth request.6. Rectangle Mapping at Downlink is not implemented.7. The allocation is slot-based say given 2 packets, both are 100 bytes in size and with 12

bytes per slot, the total number of slot allocation are 9 + 9 = 18 not 17 (200/12) slots.8. Current ARQ implementation lacks discard state in State Machine, i.e. we have endless

retransmissions9. Problems with handover with ARQ The size of DL_MAP, UL_MAP, DCD and UCD

are verified. Each entity is treated as a single burst. The downlink allocation is perCID/for each burst but per MSS for uplink allocation.We don’t consider CQI/CH regionand any fast-feedback in this version.UGS scheduling is basically either allocate theresource in every frame or a whole request size in every period. Therefore, users need toaware of frame underutilization.Users can set the unsolicited polling interval at “ns-wimax.tcl”.We waste 5 subchannels for initial ranging and bandwidth request

14 Future PlansThe next release of the simulator (depending on AWG’s future workplan) is expected to address anumber of the current limitations as well as add new features. These include:

1. More accurate abstractions for PUSC and FUSC permutation scheme2. Support for arbitrary channel rates3. Support for adaptive modulation and coding4. Support for horizontal allocation5. Support for MIMO and beamforming.6. Support for sectorization.7. DSA retransmission will be implemented.8. Frame Control Header (4 slots) will be included.9. The end of UL_MAP will be removed.10. Similar to downlink, uplink scheduling for best effort will be written up.11. The horizontal stripping for uplink allocation will be added.12. 2D rectangular criterion for downlink mapping will be added (without HARQ).13. Simple scheduler for five classes of service will be included.14. Simple admission control will be added.15. Scheduler with ARQ/HARQ aware will be added and ARQ/HARQ simulation will be

verified and validated.16. CQI/CH and HARQ IE will be implemented.17. Adaptive modulation and coding will be included.18. The optimization of scheduler for Band AMC permutation will be added.


-DRAFT 03/20/09- - 74 -

19. Support HARQ

15 Annexes

15.1 Sample scripts

15.1.1 test-arq-be.tclA demonstration of how to configure a node with UDP CBR traffic with a best effort connectionand ARQ. To run this:ns test-arq-be.tcl 1 ul 128 1024 0.5 1> log.t

The output is forwarded to log.t . The parameters here are the number of mobile stations, ul/dl,arq_block_size, arq_window_size, data_loss_rate and arq_enable

15.1.2 test-arq-ugs.tclA demonstration of how to configure a node with UDP CBR traffic with an UGS connection andARQ. To run this:

ns test-arq-ugs.tcl 1 ul 128 1024 0.5 1> log.t


15.1.3 test_arq_be.tclA demonstration of how to configure a node with UDP CBR traffic with a best effort connectionand ARQ. To run this:

ns test_arq_be_ugs.tcl 1 1 ul 128 1024 0.5 1 > log.t


15.2 FAQQ: What does "bash: ns: command not found" mean?A: The NS-2 simulator is not properly installed/compiled. Execute "./configure; make clean;make" from the ns-2.29 directory.

Q: What does invalid command name "Phy/WirelessPhy/OFDM" while executing"Phy/WirelessPhy/OFDM set g_0" mean?A: The OFDM class is unknown to NS. This means the code has not been recompiled. Execute"./configure; make clean; make" from the ns-2.29 directory.

Q: What does invalid command name "Mac/802_16" while executing "Mac/802_16 set debug_0" mean?A: The Mac/802_16 class is unknown to NS. This means the code has not been recompiled.Execute "./configure; make clean; make" from the ns-2.29 directory.

Q: Does the current model support class of service (UGS, RTPS, NRTPS and BE)?


-DRAFT 03/20/09- - 75 -

A: No. Though the architecture defines the structures to use it, the current scheduler does notmake use of it.

Q: What scheduler is implemented?A: The default scheduler for OFDM uses a Best Effort algorithm coupled with the Round Robin.

Q: How to set the -DDEBUG_WIMAX switch?A: Look for the line starting with "DEFINE = -DTCP_DELAY_BIND_ALL" and add the -DDEBUG_WIMAX.

Q: How to set the datarate?A: Unlike the 802.11 implementation, the datarate is not something set in TCL. Since each burstcan use a different modulation and therefore have different datarates, we opted for a dynamiccalculation of the datarate. By setting the frequency bandwidth, cyclic prefix and the modulation,the datarate will change. Other parameters such as number of contention slots for initial rangingand bandwidth requests or the downlink/uplink ratio affect the maximum amount of data that canbe transferred during a frame.

16 References[1] IEEE P802.16-2004, “IEEE Standard for Local and Metropolitan Area Networks-Part 16: Air

Interface for Fixed Broadband Wireles Access Systems,”, Oct. 2004, 893 pp.[2] IEEE P802.16Rev2/D2, “DRAFT Standard for Local and metropolitan area networks,” Part

16: Air Interface for Broadband Wireless Access Systems, Dec. 2007, 2094 pp.

Date post:	08-Nov-2014
Category:	Documents
Upload:	satish-kumar
View:	52 times
Download:	2 times

Wimax Forum System Level Simulator

Documents