NS-2 Release 2 6 Documentation

Project Title Number and File Name
WiMAX Forum Application Working Group
The WiMAX Forum System Level Simulator

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)
Source(s)
Are all proposing organizations members of the WiMAX Forum? Yes [X ] No [ ] Original Document Membership Re: This contribution examines coexistence issues between WiMAX and WiMAX and non-WiMAX systems. New Document This document is submitted to the WiMAX Forum as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Rational
Each contributor grants a free, irrevocable license to the WiMAX Forum to incorporate material contained in this contribution, and any modifications thereof, in the creation of a WiMAX Forum Current Text publication and at the WiMAX Forums sole discretion to permit others to reproduce in whole or in part Section the resulting WIMAX Forum publication. The contributor also acknowledges and accepts that this Number contribution may be made public by WiMAX Forum. Complete IPR and copyright rules governing contributions submitted to the WiMAX Forum are available from the WiMAX Forum administrator. Notice Release AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09-1-
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 Proprietary

For Reference Purposes Only 2009 WiMAX Forum. All Rights Reserved.
AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09-2-
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 this document and any related materials is limited as follows: A. WiMAX Forum members MAY use this document for the sole purpose of participating in approved WiMAX Forum activities, including the activities of the Working Group that has produced it. Participants in the standards development activities of other organizations MAY use this document for reference purposes, namely (i) to review and evaluate the WiMAX Forums use and implementation of third-party standards in its technical documents, and (ii) to review, evaluate and, in their sole discretion, adapt their standards activities in a manner that encourages, promotes and/or implements enhanced compatibility and/or interoperability between their respective standards and the standards that the WiMAX Forum is promoting.
B.
A user of this document MAY duplicate and distribute copies of the document in connection with the authorized uses described above. Any duplication in whole or in part will include the copyright notice on the first 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 as expressly authorized by the WiMAX Forum in writing, any other use of this document and all other duplication and distribution of this document are prohibited. The WiMAX Forum regards the unauthorized use, duplication or distribution of this document by a member as a material breach of the members obligations under the organizations rules and regulations, which MAY result in the suspension or termination of its WiMAX Forum membership. Unauthorized use, duplication, or distribution by nonmembers is an infringement of the WiMAX Forums copyright. Distribution of this document to persons or organizations that are not involved in the standards 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 this document, the user agrees to the following terms and conditions: THIS DOCUMENT IS PROVIDED AS IS AND WITHOUT WARRANTY OF ANY KIND . TO THE GREATEST EXTENT PERMITTED BY LAW, THE WiMAX FORUM DISCLAIMS ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF TITLE, NONINFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE WiMAX FORUM DOES NOT WARRANT THAT THIS DOCUMENT IS COMPLETE OR WITHOUT ERROR AND DISCLAIMS ANY WARRANTIES TO THE CONTRARY. The user acknowledges that any products or services provided using technology described in or implemented in connection with this document MAY be subject to various regulatory controls under the laws and regulations of various governments worldwide. The user acknowledges that it is solely responsible for the compliance of its products with any such laws and regulations and for obtaining any and all required authorizations, permits, or licenses for its products as a result of such regulations within the applicable jurisdiction. NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER REGARDING THE APPLICABILITY OR NON-APPLICABILITY OF ANY SUCH LAWS OR REGULATIONS OR THE SUITABILITY OR NON-SUITABILITY OF ANY SUCH PRODUCT OR SERVICE FOR USE IN ANY JURISDICTION. NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER REGARDING THE SUITABILITY OR NON-SUITABILITY OF A PRODUCT OR A SERVICE FOR CERTIFICATION UNDER ANY CERTIFICATION PROGRAM OF THE WiMAX FORUM OR ANY THIRD PARTY. The user acknowledges that the WiMAX Forum has not investigated or made an independent determin ation regarding title or noninfringement of any technologies that MAY be incorporated, described or referenced in this document. Use of this document or implementation of any technologies described or referenced herein MAY therefore infringe undisclosed third-party patent rights or other intellectual property rights. The user acknowledges that it is solely responsible for making all assessments relating to title and noninfringement of
any technology, standard, or document referenced in this document and for obtaining appropriate authorization to use such technologies, technologies, standards, and documents, including through the payment of any required license fees. NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES OF TITLE NONINFRINGEMENT WITH RESPECT TO ANY TECHNOLOGIES, STANDARDS DOCUMENTS REFERENCED OR INCORPORATED INTO THIS DOCUMENT. OR OR
IN NO EVENT SHALL THE WiMAX FORUM OR ANY MEMBER BE LIABLE TO ANY OTHER MEMBER OR TO A THIRD PARTY FOR ANY CLAIM ARISING FROM OR RELATING TO THE USE OF THIS DOCUMENT, INCLUDING, WITHOUT LIMITATION, A CLAIM THAT SUCH USE INFRINGES A THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS OR THAT IT FAILS TO COMPLY WITH APPLICABLE LAWS OR REGULATIONS. BY USE OF THIS DOCUMENT, THE USER WAIVES ANY SUCH CLAIM AGAINST THE WiMAX FORUM AND ITS MEMBERS RELATING TO THE USE OF THIS DOCUMENT. The WiMAX Forum reserves the right to modify or amend this document without notice and in its sole discretion. WiMAX, WiMAX Forum, WiMAX Certified, and WiMAX Forum Certified are trademarks of the WiMAX Forum. Third-party trademarks contained in this document are the property of their respective owners.
The WiMAX Forum System Level Simulator NS-2 MAC+PHY Add-On for WiMAX (IEEE 802.16)
A Collaborative Effort of Application Working Group (AWG), WiMAX Forum and National Institute of Standards and Technology (NIST) March 20, 2009 NIST Team: Nada Golmie, Richard Rouil RPI Team: David Doria, Xingting Guo, Raj Iyengar, Prof. Shiv Kalyanaraman, Sharath Krishnaiyer, Sampad Mishra, Prof. Biplab Sikdar WUSTL Team: Prof. Raj Jain, Ritun Patney, Chakchai So-In WiMAX 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 ( sparekh@alcatel-lucent.com). AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09-5-
TABLE OF CONTENTS
1 2 3 4 Overview................................................................................................................................. 9 1.1 History............................................................................................................................ 9 Glossary .................................................................................................................................. 9 New Features in Release 2.6 ................................................................................................. 10 NS-2 High level Structure and Simulation Cycle ................................................................. 11 4.1 NS-2 Event Scheduling and Packet Handling .............................................................. 11 4.2 NS-2: C++/OTcl Duality and Impact ........................................................................... 12 Structure of 802.16 System Level Simulation Model ........................................................... 12 5.1 Base Station.................................................................................................................. 13 5.1.1. Structure of BS node ................................................................................................ 13 5.1.2. Decomposition BS into modules.............................................................................. 13 5.1.2.4. DL Frame Assembler........................................................................................... 14 5.1.2.5. Packet Parser........................................................................................................ 14 5.2. Mobile Subscriber Station ............................................................................................ 15 5.2.1. Structure of MSS node............................................................................................. 15 5.2.2. Decomposition of MSS into modules ...................................................................... 15 5.3. Packet flows in the simulator ....................................................................................... 16 5.3.1. Regular DL data packet flow ................................................................................... 16 5.3.2. Regular UL Data Packet Flow ................................................................................. 16 5.3.3. Packet flow for bandwidth request messages........................................................... 17 5.3.4. Packet flow for CQICH............................................................................................ 17 5.3.5. Packet flows for HARQ ........................................................................................... 18 5.3.6. Packet flows for ARQ .............................................................................................. 19 Packet CS .............................................................................................................................. 19 6.1. Classifier class structure ............................................................................................... 20 6.2. DestClassifier example................................................................................................. 20 6.3. TCL commands ............................................................................................................ 21 MAC Common Part Sublayer ............................................................................................... 21 7.1. MAC module structure ................................................................................................. 22 7.2. Addressing and connection .......................................................................................... 23 7.3. MAC PDU format ........................................................................................................ 24 7.3.1 Packet header structure ............................................................................................ 24 7.3.1 Defined Management messages ............................................................................... 24 7.4 Construction and transmission of MAC PDUs ............................................................ 25 7.4.1 Fragmentation .......................................................................................................... 25 7.4.2 Packing..................................................................................................................... 25 7.5 ARQ ............................................................................................................................. 25 7.5.1 ARQ with Fragmentation and Packing .................................................................... 25 7.5.2 ARQ Transmitter and Receiver Logic ..................................................................... 26 7.5.3 ARQ parameters....................................................................................................... 29 7.5.4 ARQ class diagram .................................................................................................. 29 7.5.5 Configuration of ARQ ............................................................................................. 31 7.6 Scheduling services ...................................................................................................... 31 7.6.1 Schedulers ................................................................................................................ 31 7.6.2 Default Scheduler..................................................................................................... 33 7.6.2.1 DL scheduler at BS.............................................................................................. 34 7.6.2.2 UL scheduler at BS.............................................................................................. 34 AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09-6-
6.
7.
7.6.2.3 Horizontal Stripping ............................................................................................ 35 7.6.2.4 Vertical Stripping................................................................................................. 35 7.6.2.5 UL scheduler at MS ............................................................................................. 35 7.6.2.6 Bandwidth request and Piggybacking.................................................................. 36 7.6.3 TCL commands........................................................................................................ 36 7.7 Bandwidth allocation and request mechanisms ............................................................ 36 7.7.1 CDMA Based Contention ........................................................................................ 36 7.7.2 Contention resolution............................................................................................... 40 7.7.3 TCL commands........................................................................................................ 42 7.8 MAC support of PHY................................................................................................... 43 7.9 Network entry and initialization ................................................................................... 43 7.10 Ranging ........................................................................................................................ 44 7.11 QoS Policing ................................................................................................................ 45 7.11.1 TCL commands ................................................................................................... 46 7.12 MAC layer handover procedures ................................................................................. 46 7.12.1 Scanning .............................................................................................................. 46 7.12.2 TCL commands ................................................................................................... 47 7.13 Frame structure............................................................................................................. 48 7.14 Packet processing ......................................................................................................... 49 8 PHY....................................................................................................................................... 52 8.1 OFDMA PHY............................................................................................................... 52 8.1.1 OFDMA physical layer class diagram ..................................................................... 52 8.1.2 OFDMA Packet schedulers...................................................................................... 54 8.1.3 TCL Configuration................................................................................................... 55 8.2 OFDMA PHY............................................................................................................... 55 8.2.1 Cost231 .................................................................................................................... 55 8.2.2 Fast/Frequency Selective Fading ............................................................................. 56 8.2.3 Interference Modeling (SIR) .................................................................................... 58 8.3 Details of OFDMA channel Implementation in NS2 ................................................... 59 8.4 Received SINR Averaging (EESM) ............................................................................. 60 8.5 Transmission and Interference Power calculation logic............................................... 60 9 Configuration ........................................................................................................................ 60 9.1 Setup............................................................................................................................. 60 9.1.1 Configure the node................................................................................................... 60 9.1.2 Configure a packet classifier.................................................................................... 60 9.1.3 Configure a scheduler .............................................................................................. 61 9.1.4 Configure the channel .............................................................................................. 61 9.1.5 Select the OFDMA Propagation Model ................................................................... 62 9.1.6 Select a Fading Model.............................................................................................. 62 9.2 Statistics ....................................................................................................................... 62 9.3 Tracing ......................................................................................................................... 62 10 Parameters and Constants ..................................................................................................... 62 10.1 Parameters .................................................................................................................... 62 11 Sample TCL script ................................................................................................................ 63 12 Validation Results ................................................................................................................. 69 13 Current limitations ................................................................................................................ 73 14 Future Plans........................................................................................................................... 73 15 Annexes................................................................................................................................. 74 15.1 Sample scripts............................................................................................................... 74 15.1.1 test-arq-be.tcl ....................................................................................................... 74 15.1.2 test-arq-ugs.tcl ..................................................................................................... 74 AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09-7-
15.1.3 test_arq_be.tcl...................................................................................................... 74 15.2 FAQ.............................................................................................................................. 74 16 References............................................................................................................................. 75
Overview
The model currently implemented is based on the IEEE 802.16 standard (802.16-2004) [1] and the mobility extension IEEE 802.16e-2005 [2]. A snapshot of available and missing features is listed below: Available features WirelessMAN-OFDMA physical layer with configurable modulation Time Division Duplexing (TDD) Management messages to execute network entry (without authentication) Default scheduler providing round robin uplink allocation to registered Mobile Stations (MSs) according to bandwidth requested IEEE 802.16e extensions to support scanning and handovers Fragmentation and reassembly of frames 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) Summary of features NOT implemented (see also section 13) - Periodic ranging and power adjustments - 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 model implements one solution, which may or may not fit the users need. This is the case for the bandwidth scheduler, and flow handler, or scanning scheduler. The model was designed to be relatively extensible.
1.1
History
The earlier version of the NS-2 add-on (for OFDM PHY) was developed at NIST. At the WiMAX Forum Plenary Meeting at Hawaii (January 30 - February 2, 2007), the decision to merge the independent development efforts supported by Application Architecture Task Group (AATG), WiMAX Forum and NIST was taken. This updated documentation and the accompanying software module for OFDMA PHY are the results of this collaboration. The teams at Rensselaer Polytechnic Institute (RPI) and Washington University in St. Louis (WUSTL) are the primary development teams supported by the AATG.
Glossary
BS: Base Station MSS: Mobile Subscriber Station AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09-9-
CID: Connection IDentifier CS: Convergence Sublayer MAC: Media Access Control MIB: Management Information Base OFDM: Orthogonal Frequency Division Multiplexing OFDMA: Orthogonal Frequency Division Multiple Access PDU: Protocol Data Unit PMP: Point to MultiPoint PS: Physical Slot RTG: Receive Transition Gap SAP: Service Access Point TTG: Transmit Transition Gap BWR: BandWidth Request
New Features in Release 2.6
As 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, initial ranging, 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 transmission opportunity 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 in both 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 of UL_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 data allocation. 8. Channel Index random allocation scheme update based on CDMA Ranging mechanism. 9. Effective SINR realignment to dB scale. 10. Support ARQ in Handover scenario 11. New transmission power and interference power calculation logic. Features in Release 2.5 1. Triggering of channel scanning is now based on the power level of the DL_MAP message 2. Enhanced propagation and interference power calculation 3. Changed the management zone from OFDM to OFDMA 4. Clean OFDMA Physical Layer support 5. Support for ARQ 6. Support for CDMA initial and bandwidth ranging 7. Piggybacking of bandwidth requests 8. Support for unicast polling 9. Validation scripts have been added to the distribution.
AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 10 -
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) script interpreter that has a simulation event scheduler and network component object libraries, and network setup (plumbing) module libraries (actually, plumbing modules are implemented as member functions of the base simulator object). In other words, to use NS, you program in OTcl script language. To setup and run a simulation network, a user should write an OTcl script that initiates an event scheduler, sets up the network topology using the network objects and the plumbing functions in the library, and tells traffic sources when to start and stop transmitting packets through the event scheduler. The term "plumbing" is used for a network setup, because setting 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 to make a new network object, he or she can easily make an object either by writing a new object or by 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 very easy. The power of NS comes from this plumbing.
4.1
NS-2 Event Scheduling and Packet Handling
Another major component of NS beside network objects is the event scheduler. An event in NS is a packet ID that is unique for a packet with scheduled time and the pointer to an object that handles the event. In NS, an event scheduler keeps track of simulation time and fires all the events in the event queue scheduled for the current time by invoking appropriate network components, which usually are the ones who issued the events, and let them do the appropriate action associated with packet pointed by the event. Network components communicate with one another passing packet; however this does not consume actual simulation time. All the network components that need to spend some simulation time handling a packet (i.e. need a delay) use the event scheduler by issuing an event for the packet and waiting for the event to be fired to itself before doing further action handling the packet. For example, a network switch component that simulates a switch with 20 microseconds of switching delay issues an event for a packet to be switched to the scheduler as an event 20 microsecond later. The scheduler after 20 microseconds dequeues the event and fires it to the switch component, which then passes the packet to an appropriate output link component. Another use of an event scheduler is timer. For example, TCP needs a timer to keep track of a packet transmission time out for retransmission (transmission of a packet with the same TCP packet number but different NS packet ID). Timers use event schedulers in a similar manner that delay does. The only difference is that timer measures a time AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 11 -
value associated with a packet and does an appropriate action related to that packet after a certain time 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 path implementation from control path implementations. In order to reduce packet and event processing time (not simulation time), the event scheduler and the basic network component objects in the data path are written and compiled using C++. These compiled objects are made available to the OTcl interpreter through an OTcl linkage that creates a matching OTcl object for each of the C++ objects and makes the control functions and the configurable variables specified by the C++ object act as member functions and member variables of the corresponding OTcl object. In this way, the controls of the C++ objects are given to OTcl. It is also possible to add member functions and variables to a C++ linked OTcl object. The objects in C++ that do not need to be controlled in a simulation or internally used by another object do not need to be linked to OTcl. Likewise, an object (not in the data path) can be entirely implemented in OTcl. Figure 2 shows an object hierarchy example in C++ and OTcl. One thing to note in the figure is that for C++ objects that have an OTcl linkage forming a hierarchy, there is a matching OTcl object hierarchy very similar to that of C++.
Structure of 802.16 System Level Simulation Model
This is the framework we are following in our software architecture. However, not all of these features have been implemented.
5.1
Base Station
5.1.1. Structure of BS node

UL Scheduler API DL Scheduler API
From higher layer
Flow Classifier
DL ARQ / HARQ
DL resource allocator Fragmentation /packing DL queue BW grant queue
List of MAC PDUs and locations
DL Frame Assembler
Tx PHY Module
BW request
PHY Abstraction API
To higher layer
UL ARQ Module
Packet Parser
Rx PHY Module Rx HARQ combining
Figure 3: Structure of Base Station (BS)
5.1.2. Decomposition BS into modules

The structure of Base Station (BS) is illustrated in Figure 3. The main features of the BS model are:
5.1.2.1.
Flow Classifier
This 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 also performs Packet Header Suppression (PHS) if the corresponding rule is defined for the service flow. All incoming packets from the higher layers (Application layer) pass through this block before 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 schedule data packets properly and efficiently. The scheduler need to maintain the following information: 1. QoS information for each flow 2. DL Queue status for each flow 3. 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 mobile 4. 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 based on their CIDs, maintains certain information such as the total number of packets and the total data size of each queue, and provides interface to enque, dequeue packets and query the status of each queue.
If ARQ and HARQ are implemented, Queue Manager also maintains their status such as the ARQ counter, timer, etc. A major modification for the ARQ operation is that the Queue Manager shall not free a packet until it is acknowledged. This implies that ACK packets for each connection will be 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 to convert it to simpler versions of ARQ if the extra information in the Selective ACK messages is ignored. More detail on how Selective Repeat ARQ can be used to default to Stop and Wait/ Go Back N ARQ is required. We propose that HARQ (Type I) be emulated, not explicitly simulated. The impact of HARQ is the overhead of increased packet (fragment) size due to error correcting codes. Extensions to Type II HARQ using emulations for Chase Combining etc can be discussed, but from the point of view of extensibility of Type I features only. (An immediate requirement is for the receiver to hold on to error packets/fragments so that subsequent transmissions can be combined with existing data)
5.1.2.2.1. DL/UL scheduling

The role of the scheduling function is to decide the right priority of each flow and schedule proper number of data packets for transmission. The details of the scheduling function are covered in Section 7.
5.1.2.2.2. DL resource allocator

The role of the DL resource allocator is to determine the size and location of each data burst in a frame. Depending on the implementation, it can be either combined with the scheduling function or after that.
5.1.2.2.3. Packet fragmentation/packing

The allocated data slot may not match exactly the size of packets in queue, fragmentation and packing is needed to better utilize the allocated slot. Depending on the implementation, it can be inside the resource allocator or after that.
5.1.2.3.
UL ARQ Module
This block manages the packets that are received out of order or partially. The ARQ feedback information is sent back to the transmitter through state information transferred between this block and the DL ARQ/HARQ module.
5.1.2.4.
DL Frame Assembler
DL frame assembler combines all packets generated by the scheduler to form a frame and add some additional frame information such as the DL and UL maps. The DL frame assembler then pass the DL frame to the Tx PHY module.
5.1.2.5.
Packet Parser
The BS parses packets (classifies incoming packets based on the type in packet headers: data packets 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 in other modules. Data packets are directly sent to the higher layer after ARQ processing is completed.
5.1.2.6.
Tx/Rx PHY Module

AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) - 14 -
-DRAFT 03/20/09-
DL PHY Module simply passes the packets to the wireless channel. Optionally, it can stamp some 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 the interface to the PHY layer tables which provide Block Error Information when queried with Block Size and SINR value. More details on the PHY Module will be provided by PHY abstraction group.
5.1.2.6.1. Rx HARQ Combining

Our current plan is that the HARQ will only support the chase combining. As a result, the UL HARQ module only combines the signal of the current packet and that of the same packet transmitted in previous frames (but not successfully received). If the packet is successfully decoded, it will be passed to the upper layers and a HARQ ACK will be generated and sent to the Scheduler to update the HARQ status in the MS.
5.2.
Mobile Subscriber Station
5.2.1. Structure of MSS node
Rx PHY Module Rx HARQ combining Packet Parser DL ARQ Module
To higher layer
UL Scheduler API
Tx PHY Module
UL Assembler
UL ARQ /HARQ Module

UL resource allocator Fragmentation /packing
(UL queue)
Flow Classifier
From higher layer
Figure 4: Structure of Mobile Subscriber Station (MSS)
5.2.2. Decomposition of MSS into modules

The structure of MSS is illustrated in Figure 4. One of the main functions of the MSS is to parse the incoming UL-Maps and extract information (start and end time of burst in the case of SCPHY) 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 parser and then it schedule proper amount of data in the granted UL slots. The detail of the scheduling function is covered in Section 7.
5.2.2.2.
UL Assembler
This block scans the queues at the MSS and generates a burst of data which fits int o the granted slots. 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

Flow Classifier DL ARQ/HARQ Module DL Frame Assembler Tx PHY Module To higher layer
Rx PHY Module
Packet Parser
DL ARQ Module
To higher layer
UL ARQ Module
Packet Parser
Rx PHY Module
Tx PHY Module
UL Assembler
UL ARQ/HARQ Module
Flow Classifier
From higher layer
BS
MSS
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 from higher 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 MAC connection. Classified packets are forwarded to the DL ARQ/HARQ Module and stored in queues. 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 DL ARQ/HARQ module. DL ARQ/HARQ module outputs a list of MAC PDUs and their location to the 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 complete the 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
Flow Classifier
DL ARQ/HARQ Module
DL Frame Assembler
Tx PHY Module
Rx PHY Module
Packet Parser
DL ARQ Module
To higher layer
To higher layer
UL ARQ Module
Packet Parser
Rx PHY Module
Tx PHY Module
UL Assembler
UL ARQ/HARQ Module
Flow Classifier
From higher layer
BS
MSS
Figure 6: Regular UL data packet flow
Uplink (UL) data traffic is sent from MSS to BS. UL packet flow is similar to DL packet flow except its transmitting in opposite direction.
5.3.3. Packet flow for bandwidth request messages

Flow Classifier DL ARQ/HARQ Module DL Frame Assembler Tx PHY Module Packet Parser DL ARQ Module To higher layer
Rx PHY Module
To higher layer
UL ARQ Module
Packet Parser
Rx PHY Module
Tx PHY Module
UL Assembler BW request
UL ARQ/HARQ Module
Flow Classifier
From higher layer
BS
MSS
Figure 7: Packet flow for bandwidth request
Bandwidth is requested by MSS UL ARQ/HARQ Module. The BS Packet Parser parse received packets. If a bandwidth request header is parsed, the size of the bandwidth request and the CID is extracted and the information is sent to Scheduler as an internal control packet. All bandwidth requests are stored in the BW grant queue. UL Scheduler API looks over the grant queue and schedule UL BW grants to subscriber stations according to its scheduling algorithm. UL MAP is formed based on UL Schedulers outputs. UL MAP is included into the DL frame to be transmitted to MSS.
5.3.4. Packet flow for CQICH

Flow Classifier DL ARQ/HARQ Module DL Frame Assembler Tx PHY Module Packet Parser DL ARQ Module To higher layer
Rx PHY Module
To higher layer
UL ARQ Module
Packet Parser
Rx PHY Module
Tx PHY Module
UL Assembler
UL ARQ/HARQ Module
Flow Classifier
From higher layer
BS
MSS
Figure 8: Packet flow for CQICH
CQICH is designed for HARQ enabled MSS. CQI basically is reported by the MSS Tx PHY module. 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, and translates to Channel_state, and then forwards the info to DL ARQ/HARQ Module for channel quality awareness scheduling. DL ARQ/HARQ module can optionally forward CQI to BS Tx PHY module, if there is any simulation work in PHY that need the CQI information.
5.3.5. Packet flows for HARQ 5.3.5.1.

Flow Classifier
Packet flow for UL HARQ

ACK/NACK DL ARQ/HARQ Module DL Frame Assembler Tx PHY Module Rx PHY Module
(Rx HARQ Combining)
Packet Parser
DL ARQ Module
To higher layer
Req to send ACK/NACK
To higher layer
UL ARQ Module
Packet Parser
Rx PHY Module
(Rx HARQ Combining)
Tx PHY Module
UL Assembler
UL ARQ/HARQ Module
Flow Classifier
Determine ACK/NACK
Data
From higher layer
BS
MSS
Figure 9: Packet flow for UL HARQ
In UL HARQ packet flow, MSS is the transmitter, and BS is the receiver. HARQ bursts are transmitted in the UL subframe and ACK/NACKs are transmitted as part of the DL map. BS Rx HARQ determines whether send ACK/NACK to MSS; UL HARQ only passes successful packets to Packet Parser. The ACK delay is specified as part of the channel configuration in the UCD; the ACK/NACK message doesnt need to be scheduled. MSSs Rx HARQ forwards ACK/NACK to UL ARQ/HARQ module for updating UL queue structure. Upon receiving ACK/NACK, MSS UL 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.
Flow Classifier
Packet flow for DL HARQ

Data
DL ARQ/HARQ Module DL Frame Assembler Tx PHY Module Determine ACK/NACK Rx PHY Module
(Rx HARQ Combining)
Packet Parser
DL ARQ Module
To higher layer
To higher layer
UL ARQ Module
Packet Parser
Rx PHY Module
(Rx HARQ Combining)
Tx PHY Module ACK/NACK
UL Assembler
UL ARQ/HARQ Module
Flow Classifier
From higher layer
BS
MSS
Figure 10: Packet flow for DL HARQ
In DL HARQ packet flow, BS is the transmitter, and MSS is the receiver. HARQ bursts are transmitted in the DL subframe and ACK/NACKs are transmitted in HARQ ACK regions in the UL subframe. MSS DL HARQ determines whether send ACK/NACK to BS; Rx HARQ module only passes successful packets to Packet Parser. The ACK delay is specified as part of the channel configuration in the DCD; the ACK/NACK message doesnt need to be scheduled . Upon receiving 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
5.3.6. Packet flows for ARQ 5.3.6.1.

Flow Classifier
Packet flow for UL ARQ

ACK/NACK DL ARQ/HARQ Module DL Frame Assembler Tx PHY Module Rx PHY Module Packet Parser DL ARQ Module To higher layer
Req to send ACK/NACK To higher layer UL ARQ Module Determine ACK/NACK Packet Parser Tx PHY Module UL Assembler UL ARQ/HARQ Module Flow Classifier
Rx PHY Module
Data
From higher layer
BS
MSS
Figure 11: Packet flow for UL ARQ
In UL ARQ packet flow, MSS is the transmitter, and BS is the receiver. BS UL ARQ module determines whether send ACK/NACK to MSS. The ACK/NACK message is a packet and needs to be scheduled for transmission. Upon receiving ACK/NACK, MSS UL ARQ/HARQ shall do the following: - ACK received: remove the packet from UL queue - NACK received: initiate re-transmit the packet
5.3.6.2.
Flow Classifier
Packet flow for DL ARQ

Data
DL ARQ/HARQ Module DL Frame Assembler Tx PHY Module Rx PHY Module Packet Parser Determine ACK/NACK DL ARQ Module To higher layer
To higher layer
UL ARQ Module
Packet Parser
Rx PHY Module
Tx PHY Module
UL Assembler
UL ARQ/HARQ Module
Flow Classifier
ACK/NACK
From higher layer
BS
MSS
Figure 12: Packet flow for DL ARQ
In DL ARQ, BS is the transmitter, and MSS is the receiver. MSS DL ARQ determine whether send 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 CS
The 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 AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 19 -
In the current implementation, the Packet CS only performs classification. The method used to classify packets is implementation dependent. It may also be useful to implement multiple solutions 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 of SDUClassifier and implement the classify (Packet *) method. The SDUClassifier supports priority, which can be used to specify the order in which the classifiers are called. The smaller the priority 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 order the list of classifiers.
6.2.
DestClassifier example
The DestClassifier class can be used as a reference to implements more complex packet classifiers. It uses the destination IP address to classify the packets.
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 no match, it will return -1.
6.3.
TCL commands
$classifier set-priority $prio Change the classifiers priority. Default value is 0. $mac reset-classifiers Clear the list of classifier in the MAC. This must be called before adding custom packet classifier. $mac add-classifier $classifier Add classifier to the list of packet classifiers to use.
7.
MAC Common Part Sublayer
This section presents the MAC sublayer that currently supports PMP.
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 common elements of the BS and MS. For example it stores the MAC MIB and PHY MIB. It is the interface with other layers for sending and receiving packets. Figure shows the class and the relations with other modules. A MAC has a list of packet classifiers ( SDUClassifier) that maps each outgoing packet with the proper connection identifier (CID). Using TCL, the user configures the list of classifiers to be used (see section 3). The current implementation uses the destination IP address as the classifying element. The ServiceFlowHandler is responsible for handling flow requests/responses. It also stores the list of flows for the node. A MSS is registered to a BS, and a BS can be connected to multiple MSSs. The class PeerNode contains information about the peer, such as its connections and status. The Connections are also accessed via the ConnectionManager, which contains the list of incoming and outgoing connections. The WimaxScheduler abstract class is used to create an interface with the MAC. There are mainly two types of schedulers: one for the BS, and one for the MSS. Since the scheduler is specified in TCL, it is easy to implement the abstract class and change it. Finally, the MAC computes statistics via StatWatch and ThroughputWatch objects for packet and traffic information. The values are used to trigger events, but can also be printed during the simulation for post processing. AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 22 -
Since a BS and a MSS have different state machines we defined 2 subclasses, namely Mac802_16BS and Mac802_16SS, as shown below.
Figure 16: classes Mac802_16, Mac802_16BS and Mac802_16SS
7.2.
Addressing and connection
Each 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 of connections. 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: AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 23 -
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.
7.3.1
MAC PDU format

Packet header structure
The model defines a new header for carrying IEEE 802.16 packets.
The 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 a bandwidth request. - Structures to store the different sub headers. The structures are present in all the packets but 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 the number of elements in the list. The maximum number of elements can be updated if needed.
7.3.1
Defined Management messages
The following table indicates the packets currently defined in the model. All the packet definitions are located in the file mac802_16pkt.h. To compute the packet size, utility functions have been implemented in the file mac802_16pkt.cc.
Category Synchronization and Network Entry
Messages defined DL-MAP / DCD UL-MAP / UCD RNG-REQ/RSP REG-REQ/RSP DSA-REQ/RSP/ACK MOB_NBR_ADV MOB_SCN-REQ/RSP MOB_BSHO-REQ/RSP MON_SSHO-REQ MOB_HO-IND MOB_SCN-REP MOB_ASC-REP
Service flows Mobility
7.4
Construction and transmission of MAC PDUs
The 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 classifiers to find the proper CID. If a valid CID is found, it appends a default MAC header and puts the packet in the connection queue. 2- Scheduling: Every frame the schedulers go through the list of connections to find the packets to transmit. At the BS, the scheduler performs burst allocation then transfer packets from the connection queue to the bursts. At the MS, it uses the received UL MAP to 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 packets stored in the burst queues.
7.4.1
Fragmentation
Fragmentation can be enabled/disabled on a connection based. Currently the default value is to enable the fragmentation. When scheduling packets for transmission, the scheduler checks if fragmentation is enabled for the connection and splits the packet to fit into the burst. The fragmentation context is stored in the Connection. The method transfered_packets in the file scheduling/wimaxscheduler.cc takes care of transferring packet from their connection queue to the bursts.
7.4.2
Packing
Packing is currently implemented only with ARQ enabled.
7.5
ARQ
The ARQ mechanism is one part of the MAC layer and it may be enabled on a per-connection basis. The per-connection ARQ shall be specified and negotiated during connection creation.
7.5.1
ARQ with Fragmentation and Packing
The fragmentation always occurs at the ARQ boundaries. That is to say, the fragmentation block is always consisting of multiple number of ARQ block. If packing is enabled, the packed PDU might consist of ARQ blocks from multiple SDUs. The following diagram shows the AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 25 -
fragmentation and packing of ARQ blocks with and without rearrangement. In our current implementation, the rearrangement is supported. The minimum unit in transmission queue and retransmission queue at sender side is the ARQ block. Given a data burst allocation from BS, the sender will try to fill up the allocated data burst as much as possible. The boundary of the original PDU will be considered only when the current ARQ belongs to a different MAC SDU. In this case, a new FSH will be needed to form new MAC PDUs. Sometimes, the intermediate ARQ blocks of a original MAC SDU after it is divided are successfully received and the other ARQ blocks 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 ARQ blocks 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 7.5.2.1
ARQ Transmitter and Receiver Logic Transmitter Logic
When the SDUs from higher layer come to MAC layer, they will be divided into several ARQ blocks according to the ARQ_BLOCK_SIZE. The size of the last ARQ block is variable and might not equal to the ARQ_BLOCK_SIZE. After dividing the SDU, FRAG_STATUS and SEQ_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 time of transmission comes, scheduler will try to transmit the ARQ blocks in re-transmission queue first and transmission queue second. The transmitter will first calculate the maximum size of data which could be fit into the allocated data burst. If the allocated data burst could only fit in a bandwidth request packet, the MSS will just send a bandwidth request to ask for more bandwidth for the remaining data packets. If the allocated data burst could fit in more than one ARQ block and a bandwidth request, the MAC layer will send out an ARQ block as well as a BW request for the remaining ARQ block. When the requested bandwidth is ready, the transmitter will send the remaining ARQ blocks out.
Figure 19: ARQ Transmitter Logic
The following is the full view of transmitter state machine.
Figure 20: Transmitter Tx State Machine
In our current implementation, the Discarded condition is not supported. That is to say, if ARQ blocks are corrupted and need to be retransmitted, the transmitter will retransmit these ARQ blocks 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 to their original size. Also it will remove the generic header and CRC part. Then all these MAC PDUs will be put into ARQ In-Order queue or Out-Order queue according to the BSN saved in FSH or PSH. Later on, receiver will check if the PDUs in the Out-Order queue can be fit into the In-Order queue since a lost packet could be re-transmitted under ARQ mechanism. The algorithm for 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 queue 2) If in order, update cumulative ACK, transfer packet to in order queue. Update the expect BSN of the next new packet. AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 28 -
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 been checked. The advantage of separating packets in different queue is that it will reduce the possibility of retransmission, in the same time, it will be easier to reconstruct to original MAC SDU in In-Order queue. The algorithm of ARQ to generate the MAC SDU is like this. Firstly, the receiver will pick packets from FRAG_FIRST to FRAG_LAST in In-Order queue. If all the blocks are present, the receiver will create one single MAC SDU, update the size and send it to the upper layer. After sending the MAC SDU to the upper layer, delete all the corresponding blocks from the In-Order queue. Otherwise the receiver will keep the received ARQ blocks and wait until the expect ARQ block(s) can be successfully received.
7.5.2.3
ARQ Feedback
ARQ feedback IE messages could be transmitted in Basic CID or Data CID. Cumulative with selective feedback is supported in this release. The first feedback IE will be always be cumulative ACK and the following ACK will be selective ones. Before sending out the ACK feedback, the field of Num_of_ACKs needs to be updated. When the ACK packets are received, receiver will change 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 the Acknowledged 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 Timing
When an ARQ object is created, a timer will be started and expired every 20ms. At expiry, the transmitter will copy the corresponding packets form ARQ transmission queue to ARQ retransmission queue and reschedule the timer. As to the timing for transmission of ARQ blocks, if there is corresponding data burst allocation from the BS, the transmitter could transmit the ARQ blocks in re-transmission queue and transmission queue using it.
7.5.3
ARQ parameters
There 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
Figure 22: ARQ Related Class Diagram
Arqstatus class and its attributes and operations are used to realize the ARQ related functions, like ARQ slide window mechanism, ARQ acknowledgement mechanism, ARQ retransmission mechanism 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 which the ACK for packet reception should reach the sender. A copy of the sent packet is maintained in the arq_send_queue ArqReceive(): This function is called at the receiver side. Here if the packet received is in order, an acknowledgement is queued in the ack_queue. Else, the packet is discarded. It could be argued that buffering of such packets will reduce retransmissions, however, in our current implementation we have set the timers to 5 ms within which the packets need to be received for 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 the BASIC CID or they can be piggybacked if there is data on the opposite direction too. There are options in the script to set these. ArqReceiveFeedback(): This function is called at the sender when the feedback for the sent packet is received. This function will increment the next sequence number to be received and will also reset the timer for which the feedback was received. It also deletes the packet from the arq_send_queue. At a point, we were considering keeping only one timer and maintain a linked list of the transmission time of packets, however, we observed that at a given point we were sending just about eight packets and hence only eight timers were enabled. This being a minimal number, the current implementation uses exclusive timers for each packet transmitted. AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 30 -
ArqTimerHandler(): This function is called when the timer expires for a particular transmitted packet for which the ACK was not timely received characterized by the sequence number. This removes the corresponding packet from the arq_send_queue and puts it into arq_retrans_queue. Whenever a bandwidth request is sent, the size of bandwidth requested is sum total of the arq_retrans_queue and the queue where the MAC PDUs for transmission are stored. Also while scheduling a packet for transmission; first the arq_retrans_queue is given more priority; then the packets from the regular queue are scheduled.
Mac802_16BS:: process_mac_pdu_witharqfragpack() is used at the BaseStation side to control the UL direction ARQ reception and call the following ARQ related operations, like ARQ feedback, MAC SDU reconstruction etc. Mac802_16SS:: process_mac_pdu_witharqfragpack() is used at the Subscriber Station side to control the DL direction ARQ reception and call the following ARQ related operations, like ARQ feedback, MAC SDU reconstruction etc. WimaxScheduler::transfer_packets_with_fragpackarq() is used at both the BS and MSS sides. It is mainly used to control the transmission of ARQ block in ARQ transmission queue and retransmission queue, in the same time, it also used to issue bandwidth request from MSS side to BS. ARQTimer is mainly used to control the ARQ retransmission.
7.5.5
Configuration of ARQ
1 1 128 # Allows sending DL ARQ FB in data connection # Allows sending UL ARQ FB in data connection
Mac/802_16 set arqfb_in_dl_data_ Mac/802_16 set arqfb_in_ul_data_ Mac/802_16 set arq_block_size_ set arq_enable 1 set arq_retrans_time 0.05 set arq_max_window_size 30 set arq_ack_period 1
#enable the ARQ
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 services
The class structure allows for specifying different data services namely UGS, rtPS, nrTPS, and Best Effort. The services are specified in the ServiceFlow class. See section 7.11 for detailed information on QoS. The scheduling of the packets is done by a Scheduler. This scheduler is interacting with the MAC via well defined API allowing custom implementations.
7.6.1
Schedulers
Different types of nodes require different packet schedulers. In IEEE 802.16, the BS controls the bandwidth allocation and there are an infinite number of implementations. The model includes an abstract class, WimaxScheduler, created to easily use different packet schedulers. As shown in AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 31 -
Figure , this class already contains two implementations, an SSscheduler for MSSs and a BSscheduler for BSs. These schedulers can be replaced by using the TCL as defined in section 9.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.
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. The one in the BS is responsible (wimax/scheduling/bsscheduler.cc) for filling up the down link subframe, and producing the UL Map. The one at the MSS (wimax/scheduling/sscheduler.cc) is responsible 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 set of input parameters and expects the map structure as an output. The set of input parameters are as follows: 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 the downlink scheduler, a list of downlink connections is passed where as to the uplink scheduler a list of uplink connections is passed. The number of symbols and sub-channels represent all the symbols and sub-channels that should be allocated by the scheduler. The symbol offset is the offset 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 for DL_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, the interpretation of num_of_subchannels is #slots (wimax/mac802_16pkt.h). [this issue will be fixed in 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 AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 33 -
information for power calculation purpose. Particularly for small packet, this may lower the throughput due to the waste portion in slot. [this slot boundary allocation will be fixed in next release] At the BS, there are two scheduling components: UL scheduler and DL scheduler.
7.6.2.1
DL scheduler at BS
DL-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 the following order: UGS, rtPS (only to meet minimum reserved bandwidth), and nrtPS (only to meet a minimum reserved bandwidth). Then, if there is a left-over resource, the algorithm fairly allocates to rtPS, nrtPS, and BE. DL-BS only allocates bandwidth to a connection when it has data to be sent. For UGS, if there are enqueued packets, there are two options: first the allocation is made in every frame, that is, #slots = ceil[(SDU_size/UGS_period)/Slot_size]. Note that to enable this function, #define UGS_AVG is to be uncommented. Second, the scheduler allocates full SDU_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 as well. For BE and additional bandwidth request for rtPS and nrtPS, the algorithm allocates the left-over resource fairly. In fact, DL-BS requires having a rectangular burst; however, in this version, the mapping is only done vertically. Given the rectangular burst constraint, it may result in more unused space. [this feature will be taken into account in next release]
7.6.2.2
UL scheduler at BS
UL-BS is similar to DL-BS but bandwidth request information is used instead of enqueued packets. 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 regarding of the enqueued packets at MSS transmission queue. Bandwidth in the uplink direction is allocated per MSS . That means if a MSS has multiple connections, the bandwidth allocated to it is represented by a single UL Map IE in a frame, in which the allocated bandwidth is the aggregate 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 not participate in contention resolution mechanism, given the polling interval, UL-BS allocates at least one bandwidth request opportunity to the subscriber (Polling). Note that the minimum allocation is one slot. nrtPS scheduling is similar to rtPS; however, it allows contention resolution mechanism. Note that 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-over resource fairly. AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 34 -
Given the number of slots required/ granted for each traffic class, the slots are either allocated in a horizontal stripping method or vertical stripping method, which is passed to the scheduler as an input. In fact the default scheduling for DL-BS is vertical stripping and horizontal stripping for UL-BS; however, in this version, both DL-BS and UL-BS use vertical stripping. [horizontal stripping will be supported in next updated version] Once UL-BS grants the allocation, the scheduler updates the bandwidth request variable. UL-BS also has tried to allocate in frame after if the bandwidth request variable remains non-zero.
7.6.2.3
Horizontal Stripping
In 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 Stripping
In vertical stripping, the allocation is done in sub-channels first, and when the last sub-channel is filled, 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 main functions are to create the bandwidth request and given the grant, since the grant is per MSS, ULMSS needs to split this transmitted opportunity among the connections.
7.6.2.5
UL scheduler at MS
UL-MSS first transmits data from its basic, primary and then secondary connections till they are empty. It then services the data connections. In the current implementation, a MSS can have only one connection in the DL and UL direction. The scheduler checks which connection it has and transmits data from that connection. For all connections, apart from UGS and rtPS, a BWR packet is created which is enqueued for transmission. UL-Scheduler returns the UL-MAP, which has burst allocations per MS. Multiple PDU's are then fit into the UL-Bursts for transmission.
7.6.2.6
Bandwidth request and Piggybacking
There are two mechanisms to send bandwidth request: bandwidth request packet and piggybacking. 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 enqueued packets 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 if applicable. The default bandwidth request is aggregation and the bandwidth request variable is approximately calculated from the total connection queue size. With piggybacking, again given the transmitted opportunity, UL-MSS first check if the opportunity is more than bandwidth request size, 6 bytes. If no, only bandwidth request packet is transmitted. Otherwise, it calculates if all enqueued packets can be transmitted and if yes, no piggybacking is required. If no, the bandwidth request is piggybacked at the first MPDU (adding 2 bytes). Since the piggybacking is done at the first MPDU, the bandwidth request variable is approximately calculated from the total enqueued packet sizes and the size of transmitted opportunity.
7.6.3
TCL commands
$mac set-scheduler $scheduler Set the MAC scheduler. It removes the previously assigned scheduler if present.
7.7
Bandwidth allocation and request mechanisms
This section describes the implementation of the different mechanisms by which a MSS can request bandwidth.
7.7.1 CDMA Based Contention 7.7.1.1 CDMA Frame Structure

The CDMA contention structure is shown in the figure below.
CDMA_INIT_REQ: UIUC_INITIAL_RANGING Area: One transmission opportunity is 2 symbols 6 subchannels CDMA_BW_REQ: UIUC_REQ_REGION_FULL Area: 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 and number of CDMA_BW_REQ opportunities per frame. These two parameters are fixed to 5. Note that each 5 opportunity results in 3 OFDM symbols for CDMA ranging region. As a result, 5 subchannels and 3 symbols left-over are unused. [variable size of this region and unused space will be considered next release] Mac/802_16 set init_contention_size_ 5;# number of init opportunities per frame Mac/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. In this version, it is set to one frame. Since the MSS scheduler decides if its needed to send CDMA request or not at the beginning of uplink subframe, CDMA_TIMEOUT is set to 2, and it is decreased by one for each WiMAX frame. Also, a maximum CDMA code is set to 256 for each transmission 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 AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 37 -
CDMA_INIT_REQ and 1 subchannel and 1 OFDM symbol for CDMA_BW_REQ. CDMA packet 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 this special 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 Stages
Unlike other MAC packets, CDMA packet is treated as a special packet. As a result, the power calculation is not calculated at wimax/mac802_16BS.cc and mobile/prop_OFDMA.cc, so for detecting 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 same among two or more CDMA packets. At scheduling stage, the base station first does the collision detection for CDMA request. If there is a collision of code and transmission opportunity among CDMA packets, BS drops the CDMA request. Otherwise, BS allocates ranging request opportunity (12 bytes) for CDMA_INIT_REQ or 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 ID are encapsulated in the CDMA packet. In particularly for CDMA_BW_REQ, BS makes use of these parameters to allocate bandwidth request opportunity to each requested subscriber. In other word, BS uses a normal UL_MAP_IE as an indication of uplink grant; however, for CDMA_INIT_REQ, BS does send code and transmission opportunity back to requested subscriber 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 , for CDMA_INIT_REQ, first it checks if the transmitted code is the same as what it send and if its the same, MSS basically transmits ranging message. For CDMA_BW_REQ, since the allocation is treated as a regular grant, the MSS first checks if it can transmit all enqueued packet. If not, the bandwidth request packet is created and transmitted. Also, MSS transmits other packets after the bandwidth request packet if applicable (wimax/scheduling/wimaxscheduler.cc). AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 38 -
Figure 28: Steps in CDMA request
Note that, backoff_start, request_retry, and backoff_stop parameters are defined in tcl/lib/nswimax.tcl.
Mac/802_16 set request_retry_ requests Mac/802_16 set reg_req_retry_ Mac/802_16 set rng_backoff_start_ Mac/802_16 set rng_backoff_stop_ Mac/802_16 set bw_backoff_start_ Mac/802_16 set bw_backoff_stop_ 2 3 2 6 2 6 ;# number of retries on bandwidth allocation ;# number of retries on registration requests ;# initial backoff window size for ranging requests ;# maximal backoff window size for ranging requests ;# initial backoff window size for bandwidth requests ;# 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 MSS sends ranging request, MSS will reset the timeout_timer to t6 and so if the ranging process is not successful 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 bandwidth request packet, MSS will reset timeout_timer to t16 and so if MSS can not send any data packets out 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;
mac_->getMap()->getUlSubframe()->getRanging()->setTIMEOUT (mac_->addr(), t6time); debug10("\t Reset CDMA_INIT_REQ timer to #frame :%d (%f sec) since send INIT-RNGMSGQ 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 out for cid :%d\n", t16time, mac_->macmib_.t16_timeout, c->get_cid());
7.7.1.6
CDMA dequeue
In order to remove CDMA packets from the CDMA request queue, for CDMA_INIT_REQ, if ranging 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 resolution
The BS allocates slots that are subject to collisions in the uplink direction. These slots are used in two cases: - Initial Ranging request - Bandwidth request
The model supports a truncated binary exponential backoff for contention resolution. The UCD messages broadcasted by the BS contain the window sizes (as a power-of-two value). The BS also decides on the number of slots allocated in each frame. Figure 2 shows the class structure used for contention resolution. An uplink subframe contains a BwContentionslot and a RngContentionSlot. Both are subclasses of ContentionSlot which provides the basic mechanisms related to contention. During Network Entry, the MSS performs ranging to adjust its transmission power. During this step, the MSS generates a RangingRequest. The MSS picks a random backoff within the windows provided by the BS and stores it. Then the MSS decrements the counter every time a new contention slot is found in the frame. When the counter reaches 0, the packet is being transmitted.
Figure 29: Contention slots and contention requests
7.7.3
TCL commands
Mac/802_16 set rng_backoff_start_ 2 Mac/802_16 set rng_backoff_stop_ 6 Set the backoff window size for initial ranging requests Mac/802_16 set bw_backoff_start_ 2 Mac/802_16 set bw_backoff_stop_ 6 Set the backoff window size for bandwidth requests Mac/802_16 set contention_rng_retry_ 16 Number of retransmission for sending ranging requests. AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 42 -
Mac/802_16 set request_retry_ 2 Number of retransmission for bandwidth requests Note: the backoff windows are MAC parameters while the number of contention slots for ranging and bandwidth is a BS scheduler parameter.
7.8
MAC support of PHY
The model currently supports TDD. In this mode, uplink transmission occurs after downlink in each frame. The DL_MAP and UL_MAP messages sent every frame defines the burst allocation and transmission 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 initialization

the
Please 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 model implements the following components of the network entry: - Scan downlink channel - Obtain transmit parameters - Initial ranging - Registration
MS
Channel Selection Downlink synchronization
DL_MAP (Downlink map) DCD (Downlink Channel Descriptor)
Uplink synchronization
UCD (Uplink Channel Descriptor)
UL_MAP (Uplink map)
Initial ranging
Ranging request Ranging response
Registration request
Registration
Registration response
Normal operation
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 the MSS has acquired the transmission parameters from the serving BS or during scanning (see section 7.12).
7.10 Ranging
Ranging is a mechanism to allow a MSS to maintain a good link quality by adjusting its transmission 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 <= 11 Set the profile to use by the MAC. The command is only valid at an MS.
7.11 QoS Policing

The framework defines structures to support the implementation of schedulers that make use of the different classes of service defined in [1]. Each Connection can be associated with a ServiceFlow and corresponding QoS parameters as show in Figure 32.
Figure 32: Service Flow
The user configures the list of flows in each MSS via TCL. These provisioned flows are stored in the ServiceFlowHandler as static connections. They are established every time the MSS attaches to a new BS. While the structure supports the definition of QoS flows, it is up to the scheduler to make use of that information. The ServiceFlowHandler is responsible for handling creation of flows. The default implementation does not provide any admission control mechanism. It accepts all the flow requests from the MSs.
7.11.1 TCL commands

$mac set-servicehandler FlowHandler Replace the default service flow handler. [$wl_node_($i) set mac_(0)] setflow DL 10000 BE 700 2 1 0.01 8 1 The 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 procedures

The model supports layer 2 mobility. Depending on the configuration, the MSS may perform scanning and handover between BSs. This section presents the configuration parameters that affect the handover capability.
7.12.1 Scanning
When the link quality deteriorates, the MSS can send a MOB-SCN_REQ to the serving BS to request scanning interval for the purpose of finding surrounding BSs. shows the messages sequence during scanning as implemented in the model.
MS
Decision to search possible BSs
Serving BS
Normal operation
MOB-SCN_REQ MOB-SCN_RSP
Target BS
Listen to channels
Repeat scanning and normal mode intervals Scanning
Synchronization messages (DL_MAP,DCD, UCD, UL_MAP)
Normal mode
MOB-SCN_REP MOB-MSHO_REQ MOB-MSHO_RSP MOB-MSHO_IND
Switch channel and network entry Normal operation

Figure 33: Scanning procedure
To trigger the sending of a MOB-SCN_REQ, the MSS monitors the signal level of the incoming packets. When the level crosses a threshold, the message is sent. AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 46 -
By default, the threshold is set to the RXThreshold therefore scanning is not used. To enable scanning, change the lgd_factor_ attribute of the MIB to a value greater than 1.0. The higher the value, the sooner the scanning will trigger. During scanning, the MSS collects RSSI values of incoming packets. These values are reported to the 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 indicating its intention to perform handover. The introduction of the delay is to allow the traffic buffered during 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 MSS waits 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 the MSS will find a dedicated ranging region. After sending a ranging request, the MSS waits for 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 is required. The WiMAXCtrlAgent is an Agent performing 3 functions. The first one is to exchange DCD/UCD information between the neighbor BSs. The second is to trigger the sending of NBRADV messages to the MSs. The third one is to synchronize the serving BS and the target BSs when performing scanning level 1 or 2. The messages are exchanged over wired links using standard IP packets.
7.12.2 TCL commands

Mac/802_16 set lgd_factor_ factor ;# factor >= 1.0 Set the factor used to generate a link going down. When the received power is less that factor*RXThresh_, a trigger is generated to initiate scanning. The higher the factor, the sooner the trigger is generated. Mac/802_16 set scan_duration_ 50 Set the number of frames to perform scanning. Mac/802_16 set interleaving_interval_ 50 The number of frames interleaved between two scanning iterations. Mac/802_16 set scan_iteration_ 2 Set the number of iterations to perform scanning. Mac/802_16 set nbr_adv_interval_ 0.5 ;#in seconds The interval time between two MOB_NBR-ADV messages Mac/802_16 set scan_req_retry_ 3 Set the number of retransmission for MOB_SCAN-REQ Agent/WimaxCtrl set debug_ 0 ;#set to 1 to print debug AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 47 -
Indicates if debug information must be printed regarding the scanning controller. Agent/WimaxCtrl set adv_interval_ 1.0 ;# in seconds Set 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_ 0 Set the scanning level to use. The information is embedded in the MOB_SCAN-RSP message sent by the BS to the MS. Agent/WimaxCtrl set synch_frame_delay_ 50 ;# in second Processing delay between the reception of a MOB_SCAN-REQ and the sending of the MOB_SCAN-RSP when synchronization with target BSs is needed.
7.13 Frame structure
Figure 34: Frame class diagram
Figure 35: TDD Frame structure
The design used to represent a frame is closely similar to the structure defined in IEEE 802.16 for TDD. A frame (class FrameMap) contains a downlink and an uplink subframe (abstract class SubFrame, class DlSubFrame and UlSubFrame). The subframes are themselves seperated into PHY PDU intervals. In each of these intervals, bandwidth is allocated in burst (abstract class Burst, class UlBurst and class DlBurst) for the different stations. Each of these bursts can have a different modulation and frequency called profile (class Profile). Normally the BS allocates bandwidth for a station to transmit its data. In some cases, generally initial ranging and bandwidth requests, the MSSs need to compete with each other to access the medium. These intervals (class ContentionSlot) are only present in the uplink since the BS has total 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 the functions getDL_MAP, getUL_MAP, getDCD, and getUCD, to retrieve the packets containing the necessary information to be sent to the MSSs. At the MSS, the scheduler calls the reverse functions parseDL_MAP, parseUL_MAP, parseDCD, and parseUCD to recreate the datastructure necessary to handle proper reception and transmission of packets.
7.14 Packet processing

The Figure below shows the packet flows for incoming and outgoing packets.
Outgoing packet
Upper layer protocols
Classifiers DSx frames
Synchronization Messages
Service Flow Handler

Outgoing queues with fragmentation per CID
Scheduler
STA: process synchronization messages from BS. Schedule uplink traffic. BS: generate synchronization messages and schedule downlink traffic. Also perform admission control. Synchronization Messages
DSx frames
Service flows
Controls frame transmission
Frame reassembly
OFDM Physical layer Incoming packet

Figure 36: Packet processing overview
The activity diagrams provide more detailed information on how the packets cross the MAC layer.
Figure 37: Outgoing packet processing
A packet received from an upper layer is classified using the registered classifiers. Since there may 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 queue otherwise it is dropped. When a new packet is received, i.e. its first bit, steps shown in Figure 38 are executed. At the end of the reception, the packet is processed as shown in the Figure below. AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 50 -
Figure 38: New incoming packet processing
Figure 39: Received Packet Processing
8
8.1
8.1.1
PHY
OFDMA PHY
OFDMA physical layer class diagram
Figure 40: OFDMA Physical layer class diagram
The OFDMA physical layer is used to transmit packets in the implemented model. The configuration is done using TCL bindings for the frequency bandwidth and cyclic prefix. Since it inherits from the WirelessPhy class, attributes such as frequency or transmission power can also be configured by TCL. As Shown in Figure 40, the physical layer can be in different states. When in sending mode, all incoming packets are discarded. In receiving mode, packets cannot be sent. Furthermore, the packet 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 allocates bursts that can use different modulations according to distance or interference. This affects the data rate and transmission time. The physical layer includes helper functions called by the MAC layers 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 the number of OFDM symbols, number of subchannels, Permutation Scheme and the modulation used. - getNumSubchannels, getSlotCapacity, getMCSindex, getMaxBlocksize, etc. AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 53 -
The node_on and node_off functions enable or disable blocking all transmissions and receptions of packets, but is not currently linked to any power consumption mechanisms.
8.1.2 8.1.2.1
OFDMA Packet schedulers BSscheduler
The current implementation of the packet scheduler for BS can be configured using the following commands: set scheduler [new WimaxScheduler/BS] Creates a packet scheduler for BS. $scheduler set-contention-size $size Set the number of contention slots to be allocated for initial ranging and bandwidth requests in each frame. The scheduler implements a Best-Effort scheduler coupled with a Round Robin algorithm to distribute the bandwidth allocations among the users. To support BE, bandwidth requests are generated at the MSS indicating the amount of data to transfer. The ratio between the downlink and uplink subframes is fixed and is configured via TCL WimaxScheduler/BS set dlratio_ 0.6 Indicates 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 $modulation Sets the modulation to use for the initial ranging and bandwidth requests slots. Profile bursts are created by default as follows: Profile name DIUC_PROFILE_1, UIUC_PROFILE_1 DIUC_PROFILE_2, UIUC_PROFILE_2 DIUC_PROFILE_3, UIUC_PROFILE_3 DIUC_PROFILE_4, UIUC_PROFILE_4 DIUC_PROFILE_5, UIUC_PROFILE_5 DIUC_PROFILE_6, UIUC_PROFILE_6 DIUC_PROFILE_7, UIUC_PROFILE_7
Modulation OFDM_BPSK_1_2 OFDM_QPSK_1_2 OFDM_QPSK_3_4 OFDM_16QAM_1_2 OFDM_16QAM_3_4 OFDM_64QAM_2_3 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 7 Note: By default, the profile (modulation) is the same for BOTH downlink and uplink for communication between a MSS and a BS.
8.1.2.2
SSscheduler
set scheduler [new WimaxScheduler/SS] AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 54 -
Creates a packet scheduler for MSS.
8.1.3
TCL Configuration
Phy/WirelessPhy/OFDMA set g_ 0 ;# cyclic prefix Set 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 maximum throughput. 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 to transmitting state The duration required to switch from receiving to transmitting. Increasing the value decreases the maximum achievable throughput. Mac/802_16 set ttg_ 10 ;# number of PS to switch from transmitting to receiving state The duration required to switch from transmitting to receiving. Increasing the value decreases the maximum achievable throughput. Mac/802_16 set channel_ 0 ;# channel number Set the channel to use. This is configured at the MAC and passed to the physical layer. It is required to set it at the BS. The MSS will scan the channels to detect surrounding BSs.
8.2
OFDMA PHY
The channel model used in this OFDMA module is a Cost231 bulk path loss component combined with a Clarke-Gans implementation of Rayleigh Fading. Doppler effects are included to capture mobility effects. Fast fading is included by modeling the channel as a Rayleigh fading channel 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 of this, it is possible to skip a major step of the actual transmission process in a WiMAX system. In practice, once the symbols have been created in the frequency domain, they must be converted into a time domain signal via the IFFT. This time domain signal is then effectively convolved with the actual physical channel, yielding the received signal, y(t). However, Y(f) is the signal that must be seen at the receiver, so an FFT must be taken to convert back to a frequency domain representation. The exact same result is obtained if the IFFT/FFT steps are not performed, but rather X(f) simply multiplied element-wise by H(f), the channel frequency response. This greatly reduces the computational burden of the model. The bulk path loss component of the channel is computed during the simulation, because the distance between nodes and current transmit power are necessary parameters. However, the fast fading 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
Cost231
This is the bulk path loss model that is used. The details are taken from Channel Models: A Tutorial, Feb 21, 2007, Raj Jain AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 55 -
The propagation loss is computed using the following formula:
Where: P_L is the propagation loss f_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 8.2.2.1
Fast/Frequency Selective Fading Pre-Simulation Calculations
This part of the model is to include the Doppler Effect. A vector of Rayleigh numbers (whose length is the number of channel realization) is generated and element-wise multiplied with a Doppler spectrum of the same length. The IFFT of this array is taken to give a correlated time domain sequence of the appropriate length. This is repeated n times, where n is the number of taps in the ITU-PDP model. The n numbers of each array are then put at appropriate sample points and scaled by the tap powers given by the ITU model. Then a 1024 pt FFT is taken of this n 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 name corresponds to the ITU model which was used). The same channel is shown in both the time and frequency domain in Figure 42.
Figure 42: Conversion from Time Domain to Frequency Domain Channel
The result of this implementation is that these channel model computations are done completely offline, which produces large savings in simulation run time. An example of a channel realization file 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 multitap channel. The last step of the process is to convert the time domain channel gains to a frequency domain view of the channel. This is useful because in NS2 we are interested in the AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 57 -
receive power on each subcarrier. However, the correlation can be seen more clearly in a time domain visualization. Figure shows three consecutive snapshots of the channel. The correlation is 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 is computed. Then the packet is recorded and a timer starts (time is the duration of the packet) and its power is added to an I1 array as interference on each sub-carrier. This is done at the physical layer. Now when we receive the 1st bit of the packet at the MAC, it is decided t o be either an S Packet (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 the interference (the I in SIR) power). If it is an S Packet, the current I1 array is obtained. The power 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 interference caused due to the packets currently undergoing transmissions when we receive our 1 st bit. Now to calculate the interference that will be caused while our packet was being received we initialize another I2array and add the powers of the packets that we receive. When we receive our S packet completely, we check this I2 array and add it to I1 array at the subcarrier level and do an EESM to get the SIR value. The SIR Table is then queried to get the error probability. If the packet is in error, it is dropped, else it is processed.
Figure 45: Snapshot of Interference
8.3
Details of OFDMA channel Implementation in NS2
To implement the channel modeled above in NS2, a class called prop_OFDMA was created. It is a derived class of the base class propagation. When an OFDMA propagation model is instantiated, the selected ITU model based frequency domain channels are all read into memory from the proper file. In the first frame of the simulation, a random channel is assigned to each MSS. Every time the frame timer expires (every 5ms, the coherence time of the channel), the index 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 the received power after path loss. We then compute the multipath fading loss. We extract the subcarrier information over which the packet was transmitted. We assume that if the total power of the packet is P, the power on each sub-carrier is P/N, where N is the total number of subcarriers over which it was transmitted. We then scale the powers at each sub-carrier with the channel 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 as OFDMA and also specify the ITU model.
8.4
Received SINR Averaging (EESM)
Once the received SINR on each subcarrier used by the current packet is obtained, a decision is made to SendUp or drop the packet. This is done by finding the EESM to get the effective SINR and then extracting the BLER from SINR, MCS and Block size. The packet is mapped to blocks and from the BLER a decision is made whether to drop the packet or not. EESM is obtained by the following formula.
8.5
Transmission and Interference Power calculation logic
Once a packet is incoming, its transmission region can be calculated according to the number of OFDMA symbols, OFDMA symbol offset, number of subchannel and subchannel offset. The BS and MS will always trying to use the peak transmission power to transmit packets. The peak Tx power will keep constant among each OFDMA symbols in the transmission area and then it will be evenly distributed to each subcarrers in the OFDMA symbol (data subcarriers, pilot subcarriers and NULL/guard subcarriers). Whatever size of the packet, the Tx power on each subcarrier is the same. The advantage of using peak Tx power to each OFDMA symbols is that it will help MS 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 a limitation of physical layer which can only pass 1024 power information to the MAC layer to proceed, the evenly distributing peak Tx power to subcarriers makes the 1024 limitation enough to pass power information.
9 Configuration
9.1
9.1.1
Setup
Configure the node
There are multiple steps required to start using the IEEE 802.16 model in the simulations.
The 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 classifier
In IEEE 802.16, packets received by the MAC layer from upper layers are classified in order to direct them to the proper connection. The model proposes a classifier based on the destination MAC address and packet type. AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 60 -
# Create classifier set 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, reset the list and add a new classifier.
9.1.3
Configure a scheduler
To allow flexibility the MAC layer can use different types of schedulers. Mainly there is one for Base Stations (BSs) and one for Subscriber Stations (SSs). Section 7.6.1 shows how to extend the default schedulers. For BS, the following TCL code sets the scheduler # Create scheduler set 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 scheduler set 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 channel
To allow multi cell topologies, the MAC layers can operate at different frequencies. To set the frequencies, 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 frequency bandwidth.
9.1.5
Select the OFDMA Propagation Model
In the previous release, the propagation model used was TwoRayGround. To use the propagation model described in this document, OFDMA must be used. set opt(prop) Propagation/OFDMA
9.1.6
Select a Fading Model
The following TCL code loads the channel realizations of the selected ITU model into an array in the c++ code. set prop_inst [$ns set propInstance_] $prop_inst ITU_PDP PED_A #other choices are PED_B, VEHIC_A
9.2
Statistics
Some statistics are collected at the MAC layer. The following command is used to display their values during the simulation. Mac/802_16 set print_stats_ true
9.3
Tracing
The IEEE 802.16 model introduces new values in the trace file. Two new reasons for dropping a packet appear: - CID: this reason code is used when a packet received at the MAC layer cannot be matched to any connection. - QWI: each connection has a queue to store pending frames. When the queue is full, the packet 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 synchronization purposes. A new agent called Agent/WimaxCtrl handles this communication, and sends packets marked 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 not received. At the last fragment, the complete packet can be decoded and passed to upper layer which would then create a trace entry on the receiver side. For example, lets consider a packet with 1520 bytes which will be fragmented in four fragments of 396, 396, 396, and 364 bytes. The trace file will contain four send entries for each of the fragments but only one received entry of 1520 bytes for the complete packet.
10 Parameters and Constants

10.1 Parameters
Many 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 configuration Phy/WirelessPhy/OFDMA set g_
;# cyclic prefix
Mac/802_16 set channel_ Mac/802_16 set fbandwidth_ Mac/802_16 set rtg_ Mac/802_16 set ttg_ #MAC layer configuration Mac/802_16 set queue_length_
0 10e+6 10 10
;# channel number ;# frequency bandwidth (Hz) ;# number of PS to switch from receiving to transmitting state ;# number of PS to switch from transmitting to receiving state
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 used Mac/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 timeout Mac/802_16 set t2_timeout_ [expr 5* [Mac/802_16 set init_rng_interval_]] ;# wait for broadcast ranging timeout Mac/802_16 set t3_timeout_ 0.2 ;# ranging response timeout Mac/802_16 set t6_timeout_ 3 ;# registration response t imeout Mac/802_16 set t12_timeout_ [expr 5* [Mac/802_16 set ucd_interval_]] ;# UCD descriptor timeout Mac/802_16 set t16_timeout_ 0.1 ;# bandwidth request timeout Mac/802_16 set t17_timeout_ 5 ;# authentication. Not used Mac/802_16 set t21_timeout_ 0.02 ;# wait for DL_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 requests Mac/802_16 set reg_req_retry_ 3 ;# number of retries on registration requests Mac/802_16 set tproc_ 0.001 ;# time between arrival of last bit of a UL_MAP and effectiveness. Note used Mac/802_16 set dsx_req_retry_ 3 ;# number of retries on DSx requests Mac/802_16 set dsx_rsp_retry_ 3 ;# number of retries on DSx responses Mac/802_16 set rng_backoff_start_ Mac/802_16 set rng_backoff_stop_ Mac/802_16 set bw_backoff_start_ Mac/802_16 set bw_backoff_stop_ 2 6 2 6 ;# initial backoff window size for ranging requests ;# maximal backoff window size for ranging requests ;# initial backoff window size for bandwidth requests ;# maximal backoff window size for bandwitdh requests
Mac/802_16 set scan_duration_ 50 ;# duration (in frames) of scan interval Mac/802_16 set interleaving_interval_ 50 ;# duration (in frames) of interleaving interval Mac/802_16 set scan_iteration_ 2 ;# number of scan iterations Mac/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 requests Mac/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 statistics Mac/802_16 set rxp_avg_alpha_ 1 ;# coefficient for statistic on receiving power Mac/802_16 set delay_avg_alpha_ 1 ;# coefficient for statistic on frame delay Mac/802_16 set jitter_avg_alpha_ 1 ;# coefficient for statistic on frame jitter Mac/802_16 set loss_avg_alpha_ 1 ;# coefficient for statistic on frame loss Mac/802_16 set throughput_avg_alpha_ 1 ;# coefficient for statistic on throughput Mac/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 script

In this section we present a sample tcl script for the WiMAX simulations to serve as a guide to the various steps needed to setup simulations using the simulator. In the sample script, we consider a simple scenario with one MSS and one BS. Best effort traffic is sent by the MSS and ARQ is enabled. AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 63 -
# 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 parameters if {$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 variables set nb_mn [lindex $argv 0] set 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]
;# max number of mobile node
set packet_size 1500 ;# packet size in bytes at CBR applications set output_dir . set gap_size 0.05 ;#compute gap size between packets puts "gap size=$gap_size" set traffic_start 20 set traffic_stop 25 set simulation_stop 50 set diuc 7 ;#modulation for MNs
#define debug values Mac/802_16 set debug_ 1 Mac/802_16 set rtg_ 20 Mac/802_16 set ttg_ 20 Mac/802_16 set frame_duration_ 0.005 Mac/802_16 set ITU_PDP_ 2 Mac/802_16/BS set dlratio_ .3 Mac/802_16/SS set dlratio_ .3 Mac/802_16 set fbandwidth_ 10e+6 Mac/802_16 set disable_interference_ 0 #param for ARQ set arq_max_window_size $ARQ_window_size Mac/802_16 set arq_block_size_ $ARQ_b_size Mac/802_16 set arqfb_in_dl_data_ 1 Mac/802_16 set arqfb_in_ul_data_ 1 Mac/802_16 set data_loss_rate_ $ARQ_data_loss_rate Mac/802_16 set queue_length_ 10000
Phy/WirelessPhy/OFDMA set g_ 0.25 #define coverage area for base station Phy/WirelessPhy set Pt_ 0.2 Phy/WirelessPhy set RXThresh_ 1.90546e-16 Phy/WirelessPhy set CSThresh_ [expr 0.9*[Phy/WirelessPhy set RXThresh_]] Phy/WirelessPhy set OFDMA_ 1 # Parameter for wireless nodes set opt(chan) Channel/WirelessChannel ;# channel type set opt(prop) Propagation/OFDMA ;# radio-propagation model set opt(netif) Phy/WirelessPhy/OFDMA ;# network interface type set opt(mac) Mac/802_16/BS ;# MAC type set opt(ifq) Queue/DropTail/PriQueue ;# interface queue type set opt(ll) LL ;# link layer type set opt(ant) Antenna/OmniAntenna ;# antenna model set opt(ifqlen) 50 ;# max packet in ifq set opt(adhocRouting) NOAH ;# routing protocol set opt(x) set opt(y) 1100 1100 ;# X dimension of the topography ;# Y dimension of the topography
#defines function for flushing and closing files proc finish {} { global ns tf output_dir nb_mn $ns flush-trace close $tf exit 0 } #create the simulator set ns [new Simulator] $ns use-newtrace
#create the topography set topo [new Topography] $topo load_flatgrid $opt(x) $opt(y) #puts "Topology created" #open file for trace set 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 hierarchical AddrParams set domain_num_ 2 ;# domain number lappend cluster_num 1 1 ;# cluster number for each domain AddrParams set cluster_num_ $cluster_num lappend eilastlevel 1 [expr ($nb_mn+1)] ;# number of nodes for each cluster (1 for sink and one for mobile nodes + base station AddrParams set nodes_num_ $eilastlevel puts "Configuration of hierarchical addressing done" # Create God create-god [expr ($nb_mn + 2)] #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 model set prop_inst [$ns set propInstance_] $prop_inst ITU_PDP PED_A puts "after set pPDP"
;# nb_mn + 2 (base station and sink node)
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_size 10000000000 [$wl_node_($i) set mac_(0)] setflow UL 10000 BE 275 2 $ARQ_Enable_flag 0.05 $ARQ_window_size 10000000000 #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)
} # 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 collision set diff 0.02 for {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 simulation puts "Running simulation for $nb_mn mobile nodes..." $ns run puts "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 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 AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 68 -
0 Traffic Priority 0 Peak Traffic Rate 0 Min Reserved Traffic Rate 0 Requested Transmit Policy 0 Jitter 0 SDU Indicator 0 Min Tolerable Traffic Rate 0 SDU Size 0 Max Burst Size 0 SA ID
12 Validation Results
In this section we present some results that validate the accuracy of the developed simulator. We present three sets of results for validating: 1. The modulation schemes 2. Handovers 3. ARQ To validate the implemented modulation schemes, we consider a scenario with one BS and one MS. We then observe the achieved throughout given that 15Mb/s of data is generated for various modulation schemes as the node position is varied. The results are shown below.
Figure 46: Achieved data rates for uplink transmissions
Figure 47: Achieved data rates for downlink transmissions
Next we consider the delivery of packets in the case of handovers. We consider a scenario with two BS and one MS. Due to node mobility, the MSS moves from BS1 to BS2 at time and then back to BS1 at time. The mobile IP implementation of ns-2 is used in these results. In the figure below, we show the received data packets as a function of time and note that once the handovers are complete, packet flows proceed as normal.
Figure 48: Packet delivery in a scenario with handovers
Figure 49: Packet delay in a scenario with handovers
To validate the implemented ARQ mechanism, we consider a scenario with one BS and one MSS. We then observe the achieved throughout given that 170Kbps of data is generated for various modulation schemes as the node position is varied. The ARQ block size is 256 bytes and the data loss rate is 20%. The results are shown below.
Figure 50: Downlink throughput with ARQ for various modulation schemes
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 modulation coding rate. The following diagram shows the validation results.
Modulation Coding with ARQ (ARQ Block size:256, ARQ window size:1024, data loss rate:0.5, distance 30m)
120 100 Percentage % 80 60 40 20 0
3/ 4 16 Q AM 1/ 2 16 Q AM 3/ 4 64 Q AM 2/ 3 64 Q AM 3/ 4 1/ 2 K 1/ 2 SK K
DL sucessful reception rate UL sucessful reception rate
PS Q
BP
PS
Modulation and Coding
Figure 52: Reception Rate with ARQ under different Modulation and Coding and 50% data loss rate Notice: 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 be needed to find the destination MAC address. Once the ARP resolution timeouts or a new data pac ket comes, the current data packet in the ARP buffer will be dropped. But once the data packets get to the WiMAX Mac layer, all of them will be successfully received if we set the simulation time long enough.
13 Current limitations
Following is the list of known limitations: 1. The Packet CS only does packet classification. 2. Slot definitions are as per the PUSC permutation scheme 3. Support for only 10 MHz channel 4. Support for only vertical allocation in both uplink and downlink 5. 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 retransmissions 9. 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 per CID/for each burst but per MSS for uplink allocation.We dont consider CQI/CH region and any fast-feedback in this version.UGS scheduling is basically either allocate the resource in every frame or a whole request size in every period. Therefore, users need to aware 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 Plans
The next release of the simulator (depending on AWGs future workplan) is expected to address a number of the current limitations as well as add new features. These include: 1. More accurate abstractions for PUSC and FUSC permutation scheme 2. Support for arbitrary channel rates 3. Support for adaptive modulation and coding 4. Support for horizontal allocation 5. 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. AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 73 -
19. Support HARQ
15 Annexes
15.1 Sample scripts
15.1.1 test-arq-be.tcl
A demonstration of how to configure a node with UDP CBR traffic with a best effort connection and 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.tcl
A demonstration of how to configure a node with UDP CBR traffic with an UGS connection and ARQ. To run this: ns test-arq-ugs.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.3 test_arq_be.tcl
A demonstration of how to configure a node with UDP CBR traffic with a best effort connection and ARQ. To run this: ns test_arq_be_ugs.tcl 1 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.2 FAQ
Q: 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)? AWG, WIMAX Forum, Release 2.6 (In Collaboration with NIST) -DRAFT 03/20/09- 74 -
A: No. Though the architecture defines the structures to use it, the current scheduler does not make 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 burst can use a different modulation and therefore have different datarates, we opted for a dynamic calculation 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 ranging and bandwidth requests or the downlink/uplink ratio affect the maximum amount of data that can be 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.

NS-2 Release 2 6 Documentation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NS-2 Release 2 6 Documentation

Uploaded by

Copyright:

Available Formats

Project Title Number and File Name

WiMAX Forum Application Working Group

The WiMAX Forum System Level Simulator

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

WiMAX Forum Proprietary

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

New Features in Release 2.6

NS-2 High level Structure and Simulation Cycle

Figure 1: Simulation Cycle in NS-2

NS-2 Event Scheduling and Packet Handling

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

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

Structure of 802.16 System Level Simulation Model

5.1.1. Structure of BS node

From higher layer

List of MAC PDUs and locations

PHY Abstraction API

Rx PHY Module Rx HARQ combining

Figure 3: Structure of Base Station (BS)

5.1.2. Decomposition BS into modules

Scheduler (DL ARQ/HARQ)

5.1.2.2.1. DL queue manager (DL ARQ/HARQ)

5.1.2.2.1. DL/UL scheduling

5.1.2.2.2. DL resource allocator

5.1.2.2.3. Packet fragmentation/packing

Tx/Rx PHY Module

5.1.2.6.1. Rx HARQ Combining

Mobile Subscriber Station

5.2.1. Structure of MSS node

Rx PHY Module Rx HARQ combining Packet Parser DL ARQ Module

UL ARQ /HARQ Module

From higher layer

Figure 4: Structure of Mobile Subscriber Station (MSS)

5.2.2. Decomposition of MSS into modules

UL Scheduler (ARQ/HARQ Module)

Packet flows in the simulator

5.3.1. Regular DL data packet flow

From higher layer

indicates the beginning of the flow.

5.3.2. Regular UL Data Packet Flow

From higher layer

Figure 6: Regular UL data packet flow

5.3.3. Packet flow for bandwidth request messages

From higher layer

Figure 7: Packet flow for bandwidth request

5.3.4. Packet flow for CQICH

From higher layer

Figure 8: Packet flow for CQICH

5.3.5. Packet flows for HARQ 5.3.5.1.

Packet flow for UL HARQ

Req to send ACK/NACK

From higher layer

Figure 9: Packet flow for UL HARQ

Packet flow for DL HARQ

Req to send ACK/NACK

Tx PHY Module ACK/NACK

From higher layer

Figure 10: Packet flow for DL HARQ

5.3.6. Packet flows for ARQ 5.3.6.1.

Packet flow for UL ARQ

From higher layer

Figure 11: Packet flow for UL ARQ

Packet flow for DL ARQ

Req to send ACK/NACK