在 NCTUns 平台上模擬 WiMAX 網狀網路

在 NCTUns 平台上模擬 WiMAX 網狀網路

Simulating WiMAX Mesh Networks over the NCTUns Network

Simulator

研 究 生：朱漢威 Student：Han-Wei Chu

指導教授：王協源 Advisor：Shie-Yuan Wang

國 立 交 通 大 學

資 訊 科 學 與 工 程 研 究 所

碩 士 論 文

Submitted to Institute of Computer Science and Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer Science

June 2006

Hsinchu, Taiwan, Republic of China

NCTUns

WiMAX

Simulating WiMAX Mesh Networks over the

NCTUns Network Simulator

  

Æ  

IEEE 802.16 ( !"WiMAX)#$%&'()*+,-./012345

*6789:%67;<8=,>?ABC-DE$#FGHFC-8

IJ3KL5+2-M1*NOP$QRSTUEV#WXC-8YIZ

[$\K*01℄^_`aWbDL5*IEEE 802.11WXWb d8IEEE

802.16WXWbef>gh*iI/.jg*klmnD9WiMAXWbo

MpHqr8stuvw(Quality of Service)xyz{|I(spatial reuse)j

Wb}~D€8‚&ƒ€„M$%…†*WbC‡ˆiJ‰ŠWiMAXW b*C‡D9:‹Œ<8ŽǑ9NCTUnsWbC‡ˆo‘j’B>$% WiMAXWXWb*C‡458“ef*”~•–>—˜DŽǑ™š>9› œ*C‡ž[*Wb}~8Ÿ ¡Œ45*i¢£¤j¥*§¨©ªD
WbC‡ˆ8WXWb801℄^_`aWb8IEEE 802.168 WiMAXD

Simulating WiMAX Mesh Networks over the

NCTUns Network Simulator

Student: Han-Wei Chu Advisors: Prof. Shie-Yuan Wang

Institute of Computer Science and Engineering National Chiao Tung University

ABSTRACT

The IEEE 802.16d standard (also known as WiMAX) is a promising technology for future fixed broadband wireless access (FBWA) systems. There are two oper-ation modes defined in this standard. First, the point-to-multipoint (PMP) mode aims to replace the traditional wired last-mile solutions. Second, the Mesh mode is designed for the next-generation wireless metropolitan area networks (Wireless-MANs). Compared with the traditional 802.11-based mesh network, the 802.16 Mesh network provides higher throughput and larger coverage.

Many critical issues of WiMAX networks such as quality of service (QoS), spa-tial reuse, and network performance are being broadly studied by researchers. How-ever, there is still no general-purposed and publicly available network simulators for WiMAX networks.

In this thesis, we design and implement a WiMAX Mesh simulation system over the NCTUns network simulator. Functionalities of our implementation are vali-dated. We evaluate the performance of WiMAX Mesh networks under different conditions. Scalability issues are also discussed. Finally, possible future develop-ments are proposed.

Keywords: network simulator, mesh networks, wireless metropolitan area net-works, IEEE 802.16, WiMAX.

«¬8­®Ž* ¯°x±²³ ´jµ¶· ´8 *:?¸8¹ºǑ»o ¼½H¾¿*•—ÀÁ8 ÂGZŽ¥ÄÅ ÆÇÈÉ ℄MÊ*ËÌD ­®ÍÎÏ ´x±²³ ´jµ¶· ´89Ñ;<Òy8ӎÔÕ Ö×ØjÙÚÛÜÝÞD­®ßàœá*âãǑ8äåJPæ~Mç^è9$ éD ­®êë8:?¸* ì‰íÓî8ïŽǑ(¼ðñgH*òFD­® óxõõxóöx÷øø$ùúxûóö$ùújüü$ùú8®®ºǑ* ýþÿ DOP®®
*¯8*#Ž9É boO* D

Contents

2.1 IEEE 802.16 Mesh Mode Operations . . . 4

2.1.1 Service-Specific Convergence Sublayer . . . 4

2.1.2 MAC Common Part Sublayer . . . 4

2.1.3 Security Sublayer . . . 14

2.1.4 Physical Layer . . . 15

2.2 The NCTUns Network Simulator . . . 15

3 Design and Implementation 18 3.1 High Level Architecture . . . 18

3.1.1 Network Scenario . . . 18

3.1.3 Protocol Stacks . . . 20

3.1.4 Packet Processing flows . . . 21

3.2 MAC Layer Design and Implementation . . . 23

3.2.1 Mesh SS . . . 23

3.2.2 Mesh BS . . . 30

3.3 PHY Layer Design and Implementation . . . 31

3.3.1 Channel Coding . . . 31

3.3.2 Channel Model . . . 31

3.4 A Simple Route Module . . . 32

4 Functionality Validation 34 4.1 Network Entry Process . . . 34

4.2 Distributed Election-based Scheduling . . . 36

4.3 PHY Modes and Corresponding Throughput . . . 40

5 Performance Evaluation 43 5.1 Multihop Traffic . . . 43 5.2 TCP Fairness . . . 47 5.3 Downstream Traffic . . . 48 5.4 Client-to-Client Traffic . . . 49 6 Scalability Issues 54 6.1 Number of Connections . . . 54

6.2 Channel Model and Channel Coding . . . 56

7 Future Work 58

8 Conclusion 60

List of Figures

2.1 The IEEE Std 802.16 protocol layering . . . 3

2.2 Mesh CID construction: (a) broadcast CID, and (b) unicast CID . . . 6

2.3 The MAC PDU format . . . 6

2.4 The Mesh frame structure . . . 7

2.5 Mesh subframes in detail . . . 8

2.6 The registration procedure . . . 9

2.7 Current Xmt Time, Next Xmt Time, and Earliest Subsequent Xmt Time . . . 11

2.8 Scheduling next MSH-NCFG transmission . . . 12

2.9 The three-way handshake procedure to establish a schedule . . . 14

2.10 Channel coding scheme . . . 15

2.11 The module-based platform provided by the NCTUns network simulator 16 2.12 The module skeleton provided by the NCTUns network simulator . . 17

3.1 Mesh network scenario . . . 19

3.2 Four types of mesh nodes supported and their corresponding protocol stacks . . . 20

3.3 A non-forwarding example of packet processing flows . . . 22

3.4 A forwarding example of packet processing flows . . . 23

3.5 State transition of the Sponsoring Node . . . 24

3.6 State transition of the New Node . . . 24

3.7 Format of tunneled messages . . . 25

3.9 A simple chain topology . . . 26

3.10 Our proposed amendment to the computation of control message transmission timing . . . 28

3.11 The delay induced by the three-way handshake procedure . . . 29

3.12 Minislot state transition . . . 30

4.1 The simulation scenarios used in Section 4.1 . . . 34

4.2 The simulation scenarios used in Section 4.2: (a) a 5x5 grid topology, and (b) a general topology consisting of 25 nodes . . . 36

4.3 Number of MSH-DSCH TxOpps vs. Node ID for the network topol-ogy in Fig. 4.2(a) . . . 38

4.4 Number of MSH-DSCH TxOpps vs. Node ID for the network topol-ogy in Fig. 4.2(b) . . . 38

4.5 Average latency vs. Node ID for the network topology in Fig. 4.2(a) . 39 4.6 Average latency vs. Node ID for the network topology in Fig. 4.2(b) . 39 5.1 The network topology used to evaluate the performances of UDP/TCP multihop connections . . . 44

5.2 Performances of multihop UDP connections . . . 45

5.3 Performances of multihop UDP connections under a more realistic wireless channel . . . 45

5.4 Performances of multihop TCP connections . . . 46

5.5 The network topology used to demonstrate TCP fairness over WiMAX Mesh network links . . . 47

5.6 TCP fairness over WiMAX Mesh network links . . . 48

5.7 Network topologies for evaluating the downstream performance . . . . 49

5.8 Downstream UDP performance for the network topology in Fig. 5.7(a) 51 5.9 Downstream UDP performance for the network topology in Fig. 5.7(b) 51 5.10 Downstream TCP performance for the network topology in Fig. 5.7(a) 52 5.11 Downstream TCP performance for the network topology in Fig. 5.7(b) 52 5.12 Client-to-client UDP performance . . . 53

5.13 Client-to-client TCP performance . . . 53

6.1 Number of UDP CBR connections vs. elapsed time and memory usage 55

6.2 Number of UDP CBR connections vs. elapsed time and number of

events . . . 55

6.3 Number of UDP CBR connections vs. elapsed time and memory

usage (under a more realistic wireless channel) . . . 57

6.4 Number of UDP CBR connections vs. elapsed time and number of

List of Tables

2.1 MAC subheaders . . . 6

2.2 MAC management messages used in the Mesh mode . . . 7

2.3 Mandatory PHY modes . . . 16

3.1 Numerical values of model parameters. . . 32

3.2 An example of the fixed routing table. . . 33

4.1 Simulation parameters used in Section 4.2 . . . 37

4.2 Simulation parameters used in Section 4.3 . . . 40

4.3 PHY, MAC and application throughput using mandatory PHY modes 42 5.1 Common simulation parameters . . . 44

Chapter 1

Introduction

The IEEE 802.16d standard [1], recently standardized by the IEEE 802.16 working group, is a promising technology for future FBWA systems. The standard defines two operation modes, namely the PMP mode and the Mesh mode. The PMP mode is a novel last-mile technology to replace traditional wired solutions. The downlink, from the base station (BS) to subscriber stations (SSs), operates on a PMP basis, while the uplink is shared by all SSs. On the other hand, the Mesh mode is designed for constructing the infrastructure of Wireless-MANs. In this mode, traffic can be routed through other SSs and can occur directly between SSs.

WiMAX networks have many critical issues such as QoS, spatial reuse, and network performance. Researchers focusing on these issues usually develop their own simulation programs either to evaluate their proposed schemes or to validate their analytical methods [3] [6] [8] [11]. Unfortunately, these simulation programs are often special-purposed or not publicly available. Therefore, a high-quality simulator capable of simulating WiMAX networks is desired. It is valuable to researchers who develop, test or improve the mechanisms specified in the standard. Vendors can also carry out important experiments by simulations before the actual hardware deployment takes place.

Motivated by the above observation, in this thesis we design and implement a WiMAX Mesh simulation system over the NCTUns network simulator [10].

Func-tionalities such as coordinated distributed scheduling, control message exchanging, and the network entry process are implemented and validated. When coordinated distributed scheduling is used, peers in the mesh network exchange their schedule information via MSH-DSCH messages. The transmission timing of such messages is determined by the distributed election-based transmission timing (EBTT) mech-anism. The mechanism is fair and robust. Also, it ensures that the exchange is free from collision. By running a simulation case consisting of 25 nodes, we show that the implementation meets the standard specification.

Our contributions are threefold. First, this is the first public WiMAX simulation system and is developed over a general-purposed network simulator. Second, our WiMAX simulation system is validated by many simulation cases under different conditions. Third, we present the detailed design and implementation of this system. Other researchers can improve the system based on our work.

The rest of this thesis is organized as follows. In Chapter 2, the background on the IEEE 802.16 Mesh mode and the NCTUns network simulator are presented. We describe the detailed design and implementation in Chapter 3, then validate the implementation in Chapter 4. Chapter 5 presents experiments to evaluate the performance of WiMAX Mesh networks and Chapter 6 discusses scalability issues. Finally, we propose possible extensions to our simulation modules in Chapter 7 and conclude in Chapter 8.

Chapter 2

Background

The IEEE 802.16d standard defines the specification of the air interface for FBWA systems. Two operation modes are specified in the standard. Firstly, the PMP mode is designed to replace the traditional wired last-mile. When operating in the 10-66 GHz licensed bands, its line-of-sight (LOS) applications offer data rates greater than 120 Mb/s. Secondly, the Mesh mode is defined to support multihop wireless communication. Compared with the traditional 802.11-based mesh network, the 802.16 Mesh network provides higher throughput and larger coverage, which makes it a promising technology for the next-generation Wireless-MANs.

Fig. 2.1 illustrates the reference model proposed in the standard. The MAC layer consists of three sublayers, namely the service-specific convergence sublayer (CS), the MAC common part sublayer (MAC CPS), and the security sublayer. The PHY

Service-Specific Convergence Sublayer

(CS)

MAC Common Part Sublayer (MAC CPS) Security Sublayer Physical Layer (PHY) M A C

layer adopts technologies such as single-carrier and orthogonal frequency division multiplexing (OFDM), supporting both LOS and non-LOS applications.

In this chapter, we describe the MAC layer and the PHY layer operations of the IEEE 802.16 Mesh mode, especially the MAC CPS. An introduction to the NCTUns network simulator and its module-based platform is also presented.

2.1

IEEE 802.16 Mesh Mode Operations

2.1.1

Service-Specific Convergence Sublayer

The standard specifies two CS specifications: the asynchronous transfer mode (ATM) CS and the packet CS. The major function performed by this sublayer is classifying data from the higher layer and associating them to appropriate MAC connections. Optionally, the repetitive portion of the payload headers of the higher layer can be suppressed by the sending CS and restored by the receiving CS.

The packet CS supports transport for packet-based protocols such as Internet Protocol (IP), Point-to-Point Protocol (PPP), and Ethernet. In this thesis, we only consider the IP CS.

2.1.2

MAC Common Part Sublayer

In the following, some terminologies used extensively in the standard are introduced. • Mesh BS and Mesh SS

A station that has a direct link to the backhaul service (i.e. the Internet) outside the WiMAX Mesh network is termed as a Mesh BS. Other stations are termed as Mesh SSs.

• New Node, Candidate Node, and Sponsoring Node

In the network entry process, a New Node becomes a Candidate Node after selecting some regular node as its sponsor. The Sponsoring Node assists the Candidate Node in entering the WiMAX Mesh network.

• Registration Node

A Registration Node is a Mesh node that assigns Node IDs to newcomers of the WiMAX Mesh network.

• Connection

In the PMP mode, a connection is a unidirectional mapping between two MAC peers. It is associated with a set of QoS parameters and identified by a 16-bit connection identifier (CID). The CID is carried in the MAC header and indicates the target destination.

• Link

In the Mesh mode, a link, instead of a connection, is established between two nodes. QoS is provisioned over links on a message-by-message basis. A link is identified by an 8-bit link identifier (Link ID) and used to construct the CID, as shown in Fig. 2.2.

• Node ID

After a node is authorized to enter the network, it shall receive a 16-bit node identifier (Node ID).Thereafter, the Node ID is transferred together with every outgoing MAC protocol data unit (PDU). This unique identifier is used to indicate the identity of the transmitting node.

• Neighbor, neighborhood, and extended neighborhood

The stations with which a node has direct links are called the node’s neighbors. Neighbors of a node form a neighborhood and are considered to be one-hop away from the node. An extended neighborhood contains, additionally, all the neighbors of the nodes in the neighborhood.

Before detailed operations of the MAC CPS are elaborated, the format of the MAC PDU and the frame structure are presented first. As shown in Fig. 2.3, the MAC PDU comprises a 6-byte generic MAC header, zero or more subheaders (if

Type Reliability Priority Drop Precedence

Xmt Link ID 2 bits 1 bit 3 bits 2 bits 8 bits

(b) Unicast CID

Logical Network ID Xmt Link ID

8 bits 8 bits

(a) Broadcast CID

Figure 2.2: Mesh CID construction: (a) broadcast CID, and (b) unicast CID

Generic MAC Header Subheaders

(if necessary) Payload

CRC-32 (optional)

Figure 2.3: The MAC PDU format

necessary), a payload, and an optional 32-bit cyclic redundancy check (CRC). The generic MAC header indicates whether subheaders are presented in the message and whether the CRC is appended. Possible subheaders are shown in Table 2.1.

Fragmentation is a process of dividing a MAC service data unit (SDU) into one or more MAC PDUs. This allows efficient use of available bandwidth. Capabilities of fragmentation and reassembly are mandatory. Packing is the process of pack-ing multiple MAC SDUs into a spack-ingle MAC PDU. The capability of unpackpack-ing is mandatory.

The payload carries either data from the higher layer or MAC management mes-sages. Table 2.2 lists important management messages used in the Mesh mode.

Table 2.1: MAC subheaders

Subheader type Carried information

Fragmentation The fragmentation state of the payload

Grant Bandwidth management needs

Packing The fragmentation state of the payload

Mesh Xmt Node ID

Table 2.2: MAC management messages used in the Mesh mode

Message name Message description

REG-REQ Registration Request

REG-RSP Registration Response

SBC-REQ SS Basic Capability Request

SBC-RSP SS Basic Capability Response

MSH-NCFG Mesh Network Configuration

MSH-NENT Mesh Network Entry

MSH-DSCH Mesh Distributed Schedule

MSH-CSCH Mesh Centralized Schedule

MSH-CSCF Mesh Centralized Schedule Configuration

Frame n-1 Frame n Frame n+1 Frame n+2

Time Network Control Subframe Schedule Control Subframe Data Subframe Data Subframe

Figure 2.4: The Mesh frame structure Frame Structure

The Mesh frame structure is illustrated in Fig. 2.4 and Fig. 2.5. Only time di-vision duplex (TDD) is supported in the Mesh mode. A Mesh frame consists of a control subframe and a data subframe. There are two kinds of control subframes, namely the network control subframe and the schedule control subframe. The for-mer is used for network configuration, node entry, and synchronization. The latter facilitates the exchange of coordinated schedule information.

The MSH-NCFG message contains a Network Descriptor that dictates the de-tailed frame format. The length of the control subframe is a fixed value of length MSH-CTRL-LEN transmit opportunities (TxOpps). Each TxOpp consists of 7 OFDM symbols. Scheduling-Frames defines the period of frames with a network

ΘΘΘ ΘΘΘ Network Control Subframe MSH-NENT MSH-NCFG MSH-NCFG Network Entry Network Configuration Schedule Control Subframe MSH-CSCH MSH-CSCF MSH-DSCH Centralized Schedule Distributed Schedule Centralized Schedule Configuration (MSH-CTRL-LEN-MSH-DSCH-NUM) opportunities MSH-DSCH-NUM opportunities 1 opportunity (MSH-CTRL-LEN-1) opportunities

(b) The schedule control subframe (a) The network control subframe

ΘΘΘ Data Subframe Burst from SS#i Burst from SS#j Burst from SS#n Up to 256 minislots

(c) The data subframe

Figure 2.5: Mesh subframes in detail

control subframe. All other frames contain a schedule control subframe. In the net-work control subframe, there is one TxOpp for the netnet-work entry process, followed by (MSH-CTRL-LEN - 1) TxOpps for the network configuration. MSH-DSCH-NUM defines the number of MSH-DSCH TxOpps per schedule control subframe. During the schedule control subframe, the first (MSH-CTRL-LEN - MSH-DSCH-LEN) TxOpps are reserved for centralized scheduling. The remainder is allocated to distributed scheduling.

Scheduled data transmissions and uncoordinated scheduling packets take place in the data subframe, which is divided into (up to) 256 minislots. A scheduled allo-cation consists of one or more minislots.

Network Entry Process

A new node shall perform the network entry process before it can start a sched-uled transmission. In this process, the New Node first listens to the ongoing trans-missions in the air, searching for MSH-NCFG messages to synchronize with the net-work. In the meantime, the New Node shall build a physical neighbor list according

to the information carried in the MSH-NCFG message. When enough information is acquired, the New Node selects a potential Sponsoring Node from the list, and itself becomes a Candidate Node. By exchanging MSH-NENT and MSH-NCFG messages, the Candidate Node and the Sponsoring Node establish a temporary Sponsor Chan-nel. From that moment on, activities between the two peers are over the Sponsor Channel.

After basic capabilities (such as ARQ support and CRC support) are negotiated and authorization is performed, the registration procedure in Fig. 2.6 is followed. The Candidate Node transmits a REG-REQ message to register with the Registra-tion Node. Upon receiving the REG-REQ message the Sponsor shall tunnel the message by prepending a tunnel subheader, a UDP header and a IP header. This tunneled message is sent to the Registration Node, which can optionally be co-located with the Mesh BS. Upon receiving the REG-RSP message from the Regis-tration Node, the Sponsor shall extract the message and forward it to the Candidate Node, which then retrieves its Node ID from the message. The Candidate Node con-tinues to establish IP connectivity via DHCP, retrieve the current system time via the protocol defined in IETF RFC 868, and download a file containing operational parameters via TFTP. Finally, the Sponsor Channel is closed and the Candidate Node becomes a regular node in the network. Links between this newcomer and its neighbors can be later established by exchanging MSH-NCFG messages.

Registration Node Sponsor Node Candidate Node REG-REQ Tunneled REG-REQ TunneledREG-RSP REG-RSP Retrieve the Node ID from the message Tunnel the message Extract the message Assign a Node ID for the Candidate Node Time

Network Synchronization

Regular nodes in the network periodically broadcast MSH-NCFG messages to exchange network configuration information with their neighbors. The transmission timing (i.e. the TxOpp) of the MSH-NCFG message is determined by a distrib-uted EBTT mechanism, which works without explicit negotiation and is completely distributed, fair, and robust. This mechanism ensures the resulting transmission is collision-free within the extended neighborhood (2-hop neighborhood) of each node. To reduce the signalling overhead, a node does not broadcast its exact schedule. Instead, only a 5-bit Next Xmt Mx and a 3-bit Xmt Holdoff Exponent are advertised in the MSH-NCFG message. The interval of the next transmit time (Next Xmt Time) of the node (i.e. the sender of the MSH-NCFG message) can be computed as follows:

2XmtHoldof f Exponent_{·NextXmtMx < NextXmtT ime ≤ 2}XmtHoldof f Exponent_{·(NextXmtMx+1)} The Xmt Holdoff Time is the number of MSH-NCFG TxOpps within which

this node is not eligible to transmit MSH-NCFG packets after the Next Xmt Time.

XmtHoldOf f T ime = 2XmtHoldof f Exponent+4

In other words, the node cannot transmit any MSH-NCFG messages in this period. Thus, we can obtain the node’s Earliest Subsequent Xmt Time by

EarliestSubsequentXmtT ime = 2XmtHoldof f Exponent_{·NextXmtMx+XmtHoldOffT ime+1}

To make it clearer, to the sender itself, the Next Xmt Time is pointing to an exact TxOpp. To its neighbors, however, the Next Xmt Time of the sender is an interval that covers the actual Next Xmt Time of the sender. The timing is illustrated in Fig. 2.7.

A node broadcasts not only its own Next Xmt Mx and Xmt Holdoff Expo-nent but also these two values of all its one-hop neighbors. By this way, every regular node possesses the scheduling information within its extended neighborhood. When the node is about to transmit the MSH-NCFG message, it shall schedule its next

Time Current Xmt Time

Advertised Xmt Holdoff Time

Starts competing for TxOpps here

Time

Current Xmt Time Next Xmt Time

(An interval that covers the actual Next Xmt Time) 2XmtHoldoffExponentΘNextXmtMx

Actual Next Xmt Time

Earliest Subsequent Xmt Time Advertised

Xmt Holdoff Time

(a) Sender's view

(b) Neighbors' view

Figure 2.7: Current Xmt Time, Next Xmt Time, and Earliest Subsequent Xmt Time MSH-NCFG transmission using these scheduling information as shown in Fig. 2.8. By definition, the node can only compete for TxOpps later than the Current Xmt Time plus the node’s advertised Xmt Holdoff Time (Fig. 2.7). That’s where the Temp Xmt Time starts from. Neighbors that are eligible to compete with the sender for the Temp Xmt Time are those who meet one or more of the following conditions:

1. Its Next Xmt Time interval includes the Temp Xmt Time.

2. Its Earliest Subsequent Xmt Time is less than or equals to the Temp Xmt Time.

3. Its schedule is unknown.

A Mesh Election for the Temp Xmt Time is held among the sender and the el-igible competing nodes. A pseudorandom mixing number f(N ode ID, T emp Xmt T ime)is computed for each of the nodes involved in the election. If f(Sender′_{s N ode ID, T emp Xmt T ime)}

Temp Xmt Time = Current Xmt Time +

the node’s Xmt Holdoff Time

Determine the eligible competing nodes within the node’s two-hop neighborhood.

Winner for

Temp Xmt Time? Temp Xmt Time = Temp Xmt Time + 1

No

Yes

Next Xmt Time = Temp Xmt Time

Run Mesh Election algorithm

Figure 2.8: Scheduling next MSH-NCFG transmission

Temp Xmt Time. Otherwise, the Temp Xmt Time is advanced and the algo-rithm is repeated. Note that the fairness is ensured by the way the pseudorandom mixing numbers are computed. The seeds (Temp Xmt Time) are different for every TxOpp.

After the Next Xmt Time is decided, it is converted into the corresponding Next Xmt Mx. The Next Xmt Mx and the fixed Xmt Holdoff Exponent are then added to the outgoing MSH-NCFG message.

The MAC CPS coordinates the access to the shared wireless transmission media. Network resources may be allocated in a centralized fashion, a distributed fashion, or a combination of both. These mechanisms also determine the way data PDUs are routed in the network.

When centralized scheduling is used, the Mesh BS acts as a central coordinator to allocate network resources. It builds a scheduling tree made of nodes within a certain hop range and gathers resource requests in a bottom-up way. After

deter-mining the amount of granted resources for each link in the scheduling tree, the Mesh BS broadcasts the schedule information, which are rebroadcasted by other nodes if needed. In contrast, when the network adopts distributed scheduling, all nodes including the Mesh BS are peers. Schedules are established in a distributed way. A three-way handshake procedure ensures the resulting transmissions do not cause collisions within the extended neighborhood. In the following we describe distributed scheduling in more detail.

Distributed Scheduling

In coordinated distributed scheduling, all nodes including the Mesh BS trans-mit a MSH-DSCH message periodically in the control subframe to announce their schedules. The transmission timing is determined by the same algorithm used for

MSH-NCFG messages. Therefore, the resulting transmissions are collision-free. In

the uncoordinated case, MSH-DSCH messages are exchanged in the data subframe. Collisions may occur if two or more nearby stations send their messages at the same time.

There are four kinds of information elements (IEs) that can be included in the MSH-DSCH message. The Scheduling IE carries the coordinated distributed scheduling information: Next Xmt Mx and Xmt Holdoff Exponent. Each node reports these two parameters of its own and all its one-hop neighbors. The Request IE is used to convey resource requests on a link, with the demand expressed in terms of minislots. The Availabilities IE indicates free minislot ranges of the re-questing node. The granting node uses the Grant IE to indicate the range of granted minislots selected from the free minislots reported by the requesting node. When sent by the requesting node, the Grant IE acts as a grant confirmation.

In both coordinated and uncoordinated cases, schedules are established between two nodes using a three-way handshake procedure. The requesting node first trans-mits a MSH-DSCH message containing a Request IE and one or more Availabilities IEs. Upon reception of this message, the granting node responds a MSH-DSCH mes-sage with a Grant IE, indicating the actual grant. Neighbors of the granting node

Requesting node

Granting node

Effective transmission range

(a) The requesting node transmits a MSH-DSCH message containing a Request IE and one or

more Availabilities IEs.

Aware of the schedule Aware of the schedule Aware of the schedule

(b) The granting node responses a MSH-DSCH message with a Grant IE.

(c) The requesting node sends a MSH-DSCH message containing a copy of the Grant IE to confirm the schedule.

Requesting node Granting node Requesting node Granting node

Figure 2.9: The three-way handshake procedure to establish a schedule (except the requesting node) shall assume the schedule takes places as granted. The requesting node then sends a MSH-DSCH message containing a copy of the Grant IE to confirm the schedule to the third party (i.e. its neighbors except the grant-ing node). This three-way handshake procedure ensures data transmissions in the established schedule are collision-free. Fig. 2.9 illustrates this procedure.

2.1.3

Security Sublayer

The security sublayer provides subscribers with privacy across the fixed broadband wireless network by encrypting connections between stations. It also provides oper-ators with strong protection from theft of service. The capability to support 802.16 security is negotiated during the network entry process.

2.1.4

Physical Layer

The physical layer for the Mesh mode is operating in the licensed bands below 11GHz and based on the OFDM technology. OFDM with a 256 point transform is used to overcome delay spread, multipath, and inter-symbol interference (ISI) in this physical environment.

To better utilize the channel, a typical channel coding scheme is included in the standard, as shown in Fig. 2.10. The randomizer first scrambles the bit stream to avoid long runs of zeros or ones. The encoding is performed by passing the scrambled data blocks through the Reed-Solomon (RS) encoder and then passing the RS-encoded blocks through the convolutional code (CC) encoder. The RS code is a shortened and punctured code derived from a systematic RS(N = 255, K =

239, T = 8) code using GF (28_{). The CC is a punctured code derived from the basic}

CC 1/2. Various correcting capabilities can thus be realized by this concatenated coding scheme. The coded block is further interleaved to avoid long runs of bit errors. Finally, bits are entered serially to the constellation mapper.

Mandatory PHY modes are listed in Table 2.3 in the order of decreasing robust-ness (or increasing efficiency).

2.2

The NCTUns Network Simulator

The NCTUns network simulator is a high-fidelity and extensible network simulator. By using a novel kernel re-entering simulation methodology, a real-life UNIX kernel’s protocol stack can be directly used to generate simulation results. Also, real-life UNIX application programs can run on top of the simulation environment without any modification.

Randomizer RS encoder CC encoder Interleaver Modulator Data

To RF channel

Table 2.3: Mandatory PHY modes Mandatory mode Uncoded block size (bytes) Coded block size (bytes) RS code (N,K,T) CC code rate BPSK-1/2 12 24 (12,12,0) 1/2 QPSK-1/2 24 48 (32,24,4) 2/3 QPSK-3/4 36 48 (40,36,2) 5/6 16-QAM-1/2 48 96 (64,48,8) 2/3 16-QAM-3/4 72 96 (80,72,4) 5/6 64-QAM-2/3 96 144 (108,96,6) 3/4 64-QAM-3/4 108 144 (120,108,6) 5/6

The simulation engine of the NCTUns network simulator uses the discrete-event simulation method to advance its virtual clock. Therefore, its performance depends on the number of events it needs to process. The more events it needs to process, the slower its simulation speed will be.

It adopts an open-system architecture and provides a module-based platform. Fig. 2.11 is an example that depicts a network topology consisting of three nodes and the organization of each node. In the module-based platform, a module skeleton is provided as shown in Fig. 2.12. Based on the skeleton, researcher can easily develop their own protocol modules and integrate them into the simulator.

Switch FIFO 802.3 PHY Link FIFO 802.3 PHY Link FIFO 802.3 PHY Link ARP Interface FIFO 802.3 PHY Link ARP Interface Node 1 Switch Node 2

Figure 2.11: The module-based platform provided by the NCTUns network simula-tor

Module Upper-layer module Lower-layer module recv() send() sendtarget_ recvtarget_ class NslObject { private: char *name_; u_int32_t nodeID_; u_int32_t portid_; u_int32_t nodeType_; public: MBinder *recvtarget_; MBinder *sendtarget_; virtual inline int int();

virtual inline int recv(ePacket_ *); virtual inline int send(ePacket_ *); ...

};

Chapter 3

Design and Implementation

This chapter presents our WiMAX Mesh reference implementation over the NCTUns network simulator. We first describe a high level architecture of the entire system and then the detailed design and implementation of our protocol modules.

3.1

High Level Architecture

3.1.1

Network Scenario

Infrastructure meshing, client meshing, and hybrid meshing are three common ap-proaches to deploy wireless mesh networks (WMNs) [2]. In infrastructure WMNs, mesh routers and gateways constitute a high-speed wireless mesh backbone for mesh clients, providing connectivity to other networks such as the Internet and cellular networks. On the contrary, mesh clients themselves constitute the network in client WMNs. Hybrid WMNs, combining these two approaches, provide the best flexibil-ity to allow mesh clients either to access the network through mesh routers or to communicate with each other in a peer-to-peer fashion.

A typical scenario of hybrid WiMAX Mesh networks is shown in Fig. 3.1. The Mesh BS Gateway has a direct connection to the Internet and constitutes a wire-less mesh backbone together with Mesh SS Gateways and Forwarders. Mesh SS Clients connected to the backbone can also perform direct meshing with each other.

16 Internet 16 WiFi Hotspot Home Local Area Network Mesh SS Client Mesh SS Forwarder Mesh BS Gateway 16 16 16 16 16 16 16 16 Mesh SS Gateway

Figure 3.1: Mesh network scenario

The differences between the Mesh SS Gateway and the Mesh SS Forwarder are as follows: A Mesh SS Forwarder performs functions such as multihop routing and self-configuration. A Mesh SS Gateway, on the other hand, is a Mesh SS Forwarder that additionally performs gateway functions and connects private or public networks to the wireless mesh backbone.

In our reference implementation of WiMAX Mesh networks, we support the four types of mesh nodes mentioned above. Using the fully-integrated GUI environment of the NCTUns network simulator, researchers can easily design a network topology similar to Fig. 3.1.

3.1.2

Routing Scheme

A mesh network with layer-2 routing leads to a layer-2 network in which mobility management can be easily achieved. Nevertheless, in a big layer-2 network, common protocols such as DHCP, ARP and RARP that require layer-2 broadcast

functional-16 Mesh BS Gateway Mesh SS Gateway Mesh SS Forwarder Interface MAC802_16 MeshBS LINK Mesh_Route OFDM_Mesh Router Interface ARP FIFO MAC802_3 PHY LINK Interface MAC802_16 MeshSS LINK Mesh_Route OFDM_Mesh Router Interface ARP FIFO MAC802_3 PHY LINK Interface MAC802_16 MeshSS LINK Mesh_Route OFDM_Mesh Mesh SS Client Interface MAC802_16 MeshSS LINK Mesh_Route OFDM_Mesh 16 16 16

Figure 3.2: Four types of mesh nodes supported and their corresponding protocol stacks

ity can result in bandwidth wastage [9]. Therefore, in our reference implementation of WiMAX Mesh networks, we adopt layer-3 routing which does not suffer from this drawback. Mobility management is beyond the scope of this thesis. However, it can be achieved via a Mobile IP based solution.

In our current implementation, a fixed layer-3 routing scheme is used. This can be later replaced by other layer-3 routing protocols such as AODV, OSPF and RIP.

3.1.3

Protocol Stacks

The four types of mesh nodes supported and their corresponding protocol stacks are shown in Fig. 3.2. Protocol modules colored with deep blue are WiMAX-related modules. Others are existing and well-tested modules provided by the original

NC-TUns network simulator. In the following we briefly describe some of these modules. • Mesh Route

Before a simulation starts, a fixed routing table is predetermined for the target network topology. During the simulation, Mesh Route looks up this table to find the next-hop Node ID of a received IP packet. This process effectively associates IP packets to appropriate MAC connections (or links). In other words, functions of the IP CS are included in this module.

• MAC802 16 MeshSS

This module performs important functions including the network entry process, the Mesh Election algorithm, and distributed scheduling.

• MAC802 16 MeshBS

This module performs all functions of MAC802 16 MeshSS and is responsible for assigning Node IDs to newcomers of the WiMAX Mesh network.

• OFDM Mesh

This module performs channel coding and simulates a path loss model for the underlying wireless channel.

• Router

This is not a real protocol module. Instead, it represents the layer-3 rout-ing functions provided by the operatrout-ing system which are only used in wired networks.

• Interface

This can be view as a network interface owned by a router or a host.

3.1.4

Packet Processing flows

Here we give two examples of packet processing flows. Fig. 3.3 shows a

Router LINK ARP FIFO PHY Interface LINK Router LINK ARP FIFO PHY Interface LINK 16 Mesh BS Gateway Host

Wireless Link Wired Link

Mesh SS Gateway 16 Mesh_Route MAC802_16 MeshBS OFDM_Mesh Mesh_Route MAC802_16 MeshSS

OFDM_Mesh MAC802_3 MAC802_3

LINK PHY FIFO ARP Interface MAC802_3 Interface Interface

Figure 3.3: A non-forwarding example of packet processing flows

the wired protocol stack of the Mesh BS Gateway. The layer-3 routing mechanism provided by the operating system directs this packet to the WiMAX protocol stack.

Mesh Route _{then finds the next-hop of the packet and passes the packet together}

with this information to MAC802 16 MeshBS. At a scheduled minislot range, the packet is delivered to OFDM Mesh. After channel coding is applied, the packet is transmitted to the air.

Upon reception of the packet, OFDM Mesh of the Mesh SS Gateway applies chan-nel decoding to the packet and delivers the packet to MAC802 16 MeshSS. After CRC and other tests are done in MAC802 16 MeshSS, the packet is passed to Mesh Route.

Mesh Route finds that the destination of the packet is located behind the Mesh SS

Gateway, so it further passes the packet to the upper layer. The remaining process-ing is the same as the original packet processprocess-ing flows of wired networks in the NCTUns network simulator.

Fig. 3.4 illustrates a forwarding example. It can be seen that in the Mesh SS Forwarder the received packet is redirected in Mesh Route. Note that the Mesh BS Gateway and the Mesh SS Gateway also perform the forwarding function. In other words, they also forward packets in the multihop wireless network.

Router LINK ARP FIFO PHY Interface Interface LINK LINK Mesh_Route Interface 16 Mesh BS Gateway Mesh SS Forwarder 16 Router LINK ARP FIFO PHY Interface Interface LINK Mesh SS Gateway 16

Wireless Link Wireless Link

Mesh_Route Mesh_Route MAC802_16 MeshBS MAC802_16 MeshSS MAC802_16 MeshSS

OFDM_Mesh OFDM_Mesh OFDM_Mesh MAC802_3

MAC802_3

Figure 3.4: A forwarding example of packet processing flows

3.2

MAC Layer Design and Implementation

3.2.1

Mesh SS

Here we present the detailed design and implementation of our protocol module

MAC802 16 MeshSS_.

Network Entry Process

To support the network entry process in our simulation system, we design a network entry subsystem in MAC802 16 MeshSS. This subsystem includes procedures performed by the New Node, the Sponsoring Node, and the Registration Node. The state transition of the Sponsoring Node and the New Node in this process are shown in Fig. 3.5 and Fig. 3.6 respectively..

During the network entry process, some MAC messages are exchanged between nodes separated by multiple hops. For example, the REG-REQ and REG-RSP message are exchanged between the Registration Node and the New Node. (In our implementation, the Registration Node is co-located with the Mesh BS.) The Spon-soring Node is responsible for tunneling the REG-REQ received from the New Node

Received NetEntReq

Sponsoring

Available

Receive a MSH-NENT:NetEntryRequest from the new node.

Send a MSH-NCFG:NetEntryOpen to the new node.

Closing Sponsor Channel

Receive a MSH-NENT:NetEntryClose from the new node.

Send a MSH-NCFG:NetEntryAck to the new node.

Opening Sponsor Channel Receive a MSH-NENT:NetEntryAck from the new node.

(1) Negotiate basic capabilities with the Candidate Node.

(2) Assist the new node in performing the registration procedure.

Figure 3.5: State transition of the Sponsoring Node

Initial Sync Opening Sponsor Channel Sponsor Channel Opened Closing Sponsor Channel Operational

(1) Negotiate basic capabilities with the Sponsor Node. (2) Perform the registration procedure.

Synchronize to the network.

Select a Sponsor Node and send a MSH-NENT:NetEntryRequest to it.

Receive a MSH-NCFG:NetEntryOpen from the Sponsor Node.

Send a MSH-NENT:NetEntryClose to the Sponsor Node.

Receive a MSH-NCFG:NetEntryAck from the Sponsor Node.

IP header UDP header Tunnel subheader MAC message including headers

Src. Port = 54706 Dst. Port = 54706

Length Checksum

Ξ

Src. = Sponsor Node's IP address Dst. = Registration Node's IP address

Figure 3.7: Format of tunneled messages

NodeID: 1 HopCount: 1 ReportedFlag: True NextXmtTimeNCFG XmtHoldoffTimeNCFG NextXmtTimeDSCH XmtHoldoffTimeDSCH NodeID: 2 HopCount: 2 ReportedFlag: True NextXmtTimeNCFG XmtHoldoffTimeNCFG NextXmtTimeDSCH XmtHoldoffTimeDSCH NodeID: 3 HopCount: 1 ReportedFlag: False NextXmtTimeNCFG XmtHoldoffTimeNCFG NextXmtTimeDSCH XmtHoldoffTimeDSCH

Physical Neighborhood List

Figure 3.8: Physical neighborhood list

and forwarding the tunneled message to the Registration Node. Upon reception of the tunneled REG-RSP message from the Registration Node, the Sponsoring Node extracts the REG-RSP message and forwards it to the New Node. The tunneling mechanism is illustrated in Fig. 3.7. We use a specific port number (i.e. 54706) as an identifier so that the MAC layer modules can be aware of this action and respond accordingly.

Transmission Timing of Control Messages

In the Mesh network, basic functions including distributed scheduling and net-work synchronization are based on the physical neighbor list maintained by each node. Fig. 3.8 shows an example of the list. For the aforementioned functions to work correctly, each node shall regularly update the information contained in the neighborhood list. However, the IEEE 802.16 standard does not define how the information is updated.

Consider a simple network topology in Fig. 3.9. Two ambiguous situation may occur as follows:

C B

A

Figure 3.9: A simple chain topology

Case 1_:

• At time t, Node A computes its scheduling information (Next Xmt Mx and Xmt Holdoff Exponent) based on the Current Xmt Time t. This information of Node A and its on-hop neighbors is included in its outgoing MSH-DSCH message. Node B, upon receiving this message, is able to deter-mine the Next Xmt Time for Node A base on the Current Xmt Time t.

• At time t + k, Node B computes its scheduling information based on the Current Xmt Time t + k. This information of Node B and its one-hop neighbors is included in its outgoing MSH-DSCH message. Upon receiving the message, Node C computes a erroneous Next Xmt Time for Node A, since Node C has no idea when Node A transmits its last MSH-DSCH message.

Case 2_:

• At time t, Node A computes its scheduling information and adjusts the infor-mation of its one-hop neighbors based on the Current Xmt Time t. All the information is included in its outgoing MSH-DSCH message. Node B, upon receiving this message, is able to determine the Next Xmt Time for Node

A base on the Current Xmt Time t.

• At time t + k, Node B computes its scheduling information and adjusts the in-formation of its one-hop neighbors based on the Current Xmt Time t+k. All the information is included in Node B ’s outgoing MSH-DSCH message. How-ever, the new Next Xmt Time of Node A may not exactly match the original Next Xmt Time of Node A, if k is not a multiple of 2XmtHoldof f ExponentA

Tx-Opps. Therefore, upon receiving the message, Node C computes a erroneous Next Xmt Time for Node A accordingly.

In both cases, the erroneous information computed by Node C is likely to cause collisions in the succeeding control message exchanges, since Node C cannot deter-mine the eligibility of Node A correctly. We can observe that to avoid the ambiguity,

a reference TxOpp number is needed for both the sender and the receiver of the

MSH-DSCH control messages. Therefore, we propose an amendment to the stan-dard, which requires no modification to any control message format or any existing mechanism. In the following we describe our proposed amendment.

When a node is about to transmit its MSH-DSCH message, it first computes two reference TxOpp numbers by:

Interval = 2Xmt Holdof f Exponent

Ref1 = ⌊Current Xmt T ime − 1

Interval ⌋ · Interval + 1

Ref2 = ⌊Next Xmt T ime − 1

Interval ⌋ · Interval + 1

The Node’s Next Xmt Mx can then be computed as follows:

Next Xmt Mx = Ref 2 − Ref1

Interval

Upon receiving the MSH-DSCH message, its one-hop neighbors can compute its Next Xmt Time by

Ref = ⌊Current Xmt T ime − 1

Interval ⌋ · Interval + 1

Next Xmt T ime Start = Ref + Next Xmt Mx · Interval Next Xmt T ime End = Next Xmt T ime Start + Interval − 1

The scheduling information of all its one-hop neighbors can also be adjusted us-ing the above equations. Since all regular nodes in the Mesh network maintain the same TxOpp sequence number, the aforementioned ambiguity can be avoided. The timing is illustrated in Fig. 3.10. Our amendment also applies to MSH-NCFG mes-sages, since the mechanisms to determine the transmission timing of both messages are the same.

(a) Sender's view

Time

Current Xmt Time Actual Next Xmt Time

2Xmt Holdoff Exponent

Ref1 Ref2

Time Current Xmt Time

Ref

Next Xmt Time Start

Next Xmt Time (An interval that covers the actual Next Xmt Time) 2Xmt Holdoff ExponentΘNextXmtMx

(b) Neighbors' view

Next Xmt Time End

Figure 3.10: Our proposed amendment to the computation of control message trans-mission timing

Bandwidth Allocation and Request Mechanism

In the distributed scheduling mode, schedules are established between two nodes using the three-way handshake procedure as mentioned in Section 2.1.2. This pro-cedure ensures the corresponding data transmissions are collision-free. However, it adversely induces a large delay to establish a schedule. Specifically, the requester suffers a delay of at least Xmt Holdoff Time TxOpps as shown in Fig. 3.11. This greatly reduces the link utilization and increases the latency of the packets sent by the upper layer protocol.

To overcome these problems, we propose an enhancement which allows the re-quester to have a chance to send a request before its current schedule expires. The used algorithm is listed in the next page. Chapter 5 evaluates the improvement made by our proposed enhancement.

The data subframe in which scheduled transmissions occur is divided into min-islots. A minislot (or a range of minislots) may be available for requests or occupied by an established schedule. We design a state transition scheme for managing the

Time Established Schedule

The requester sends a request in its MSH-DSCH TxOpp.

The granter responds with a grant in its MSH-DSCH TxOpp.

Three-way Handshake

The requester sends a confirmation in its MSH-DSCH TxOpp.

Established Schedule

The requester's Xmt Holdoff Time

Figure 3.11: The delay induced by the three-way handshake procedure

Algorithm 1 Send Request

1: if there is no pending data then

2: do nothing.

3: else if we don’t have any schedules then

4: append a request to the outgoing MSH-DSCH message.

5: else if we already have one schedule then

6: N ⇐ the frame number that the current schedule becomes valid

7: L ⇐ the lifetime of the current schedule

8: if N > current f rame number then

9: do nothing.

10: else if L > Xmt Holdof f T ime then

11: do nothing.

12: else

13: append a request to the outgoing MSH-DSCH message.

14: end if

Free Grant Received Request Received Busy Xmit Grant Sent Send a request to the granter.

Receive a request from the requester. Recv Sent a confirm to the granter. Sent a grant to the requester.

Receive a confirm from the requester. Receive a grant/confirm

from any of our neighbors. (1) Receive a grant from some node

other than the granter. (2) Receive a confirm from any of our neighbors.

Receive a grant/confirm from any of our neighbors. Request

Sent

Receive a grant from the granter.

Receive a grant/confirm from any of our neighbors.

Figure 3.12: Minislot state transition minislots. Fig. 3.12 illustrates the state transition of a minislot.

3.2.2

Mesh BS

The Mesh BS provides backhaul connectivity for the entire mesh network. The protocol stacks of the Mesh BS are shown in Fig. 3.2. It can be seen that the wired protocol stack represents a direct link to the Internet.

As mentioned earlier, in our implementation the Mesh BS also performs the registration function, i.e. the Node ID assignment. For this purpose, we generate a configuration file containing mappings of MAC addresses and Node IDs. When the Mesh BS receives a REG-REQ message from a New Node, it maps the MAC address carried in the message to a unique Node ID. The Node ID is included in the REG-RSP message and returned to the New Node.

Despite the two functions described above, using distributed scheduling, the Mesh BS is merely a peer node in the network. Therefore, it shall also assist new

nodes in entering the mesh network, broadcast control messages periodically, and establish distributed schedule with its neighbors.

3.3

PHY Layer Design and Implementation

3.3.1

Channel Coding

We implement a rate 1

2 systematic convolutional code that realizes various code rates with puncturing. A hard-decision Viterbi decoder is used to decode the coded bit stream. When the punctured pattern is used, dummy bits that do not affect the metric are inserted in the corresponding positions.

The randomizer and the interleaver are both implemented as defined in the standard. The Reed-Solomon code implementation is obtained from [7].

3.3.2

Channel Model

For simulating the wireless channel, we adopt an empirically based path loss model presented in [4] and [5]. The path loss (in dB) is

P L = A + 10 · γ · log d

d0

+ s + ∆P Lf + ∆P Lh

where A is a fixed quantity given by the free-space path loss formula at distance

d0 = 100m, s represents the shadow fading variation, and the path loss exponent γ

is a Gaussian random variable given by

γ = (a − b · hb+

c

hb), 10m ≥ hb ≥ 80m

where hb is the base station antenna height in meters and a, b, c are constants

dependent on the terrain category given in Table 3.1. Category A, the maximum path loss category, is a hilly terrain with moderate-to-heavy tree densities. Category B is either a mostly flat terrain with moderate-to-heavy tree densities, or a hily terrain with light tree densities. Category C, the minimum path loss category, is

Table 3.1: Numerical values of model parameters.

Model parameter Category A Category B Category C

a 4.6 4.0 3.6

b 0.0075 0.0065 0.005

c 12.6 17.1 20.0

a mostly flat terrain with light tree densities. For different frequencies and receive antenna heights, the following correction terms are used:

∆P Lf = 6 · log f 2000 ∆P Lh = −10.8 · log h 2; f or Categories A and B ∆P Lh = −20 · log h 2; f or Category C

where f is the freqyency in MHz, and h is the receive antenna height between 2m and 10m.

We adopt Rayleigh fading channels, because WiMAX Mesh networks are likely to be deployed in non-LOS environments. The bit-error-rates (BERs) of various modulation modes under Rayleigh fading channels are given by:

PBP SK/QP SK = 1 2(1 − s γ 1 + γ) PQAM = 2( √ M − 1_√ M ) 1 log2M √M/2 X i=1 (1 − v u u t 1.5(2i − 1) 2_{γ log} 2M M − 1 + 1.5(2i − 1)2_{γ log} 2M )

where γ is the energy per bit per noise power spectral density (i.e. Eb

N0), and M is

16 for 16-QAM and 64 for 64-QAM.

3.4

A Simple Route Module

In our current implementation, we adopt a fixed layer-3 routing scheme, which can be later replaced by other layer-3 routing protocols such as AODV, OSPF and RIP.

Table 3.2: An example of the fixed routing table.

Owner IP address/Netmask Next-hop Node ID

$node (1) 1.0.1.2/32 2 $node (1) 1.0.1.3/32 2 $node (2) 1.0.1.1/32 1 $node (2) 1.0.1.3/32 3 $node (3) 1.0.1.1/32 2 $node (3) 1.0.1.2/32 2

The fixed routing table is generated and stored in a file before the simulation starts. An example of the routing table is shown in Table 3.2.

Chapter 4

Functionality Validation

4.1

Network Entry Process

To validate our implementation of the network entry process, we demonstrate an simulation example step by step. Fig. 4.1 shows the network topology with a Mesh BS located in Node 1. The steps of the network entry process to the stage when all nodes can start scheduled transmissions are as follows:

1. Node 1 periodically broadcasts MSH-NCFG messages.

2. Node 2 and Node 3 synchronize with Node 1, build their physical neighbor lists in the meantime, and select Node 1 as their Sponsoring Node.

3. Node 2 and Node 3 transmit MSH-NENT messages with network entry re-quests to Node 1 at the same time, causing a collision at Node 1. Neither of

4

3 1 2

Mesh BS

the messages is successfully received by Node 1.

4. Node 2’s and Node 3’s timers set for receiving responses from the Sponsoring Node expire. They both defer their further attempts according to a random backoff mechanism.

5. The deferring time of Node 3 is up.

6. Node 3 transmits a MSH-NENT message with a network entry request to Node 1. Upon reception of this message, Node 1 responds to Node 3 by transmitting a MSH-NCFG message with a network entry grant to Node 3. The Sponsor Channel is established after Node 3 transmits a MSH-NENT message with a network entry acknowledgment to Node 1.

7. After basic capabilities are negotiated and authorization is performed, Node 3 registers with the Mesh BS (i.e. Node 1) by transmitting a REG-REQ message to it. The Mesh BS then replies a REG-RSP message with a unique Node ID assigned to Node 3.

8. The Sponsor Channel is closed and Node 3 becomes a regular node in the network.

9. Node 2’s deferring time is up and repeats step 6 to step 8.

10. Node 4 synchronizes with Node 2, builds its physical neighborhood list in the meantime, and selects Node 2 as its Sponsoring Node. Step 6 to step 8 are repeated except that (1) the REG-REQ message transmitted by Node 4 is tunneled by Node 2 and forwarded to the Mesh BS, and (2) the REG-RSP message transmitted by the Mesh BS is extracted by Node 2 and delivered to Node 4.

2 1 3 4 5 7 6 8 9 10 12 11 13 14 15 17 16 18 19 20 22 21 23 24 25 2 1 3 4 5 7 6 8 9 10 12 11 13 14 15 17 16 18 19 20 22 21 23 24 25 400m

Figure 4.2: The simulation scenarios used in Section 4.2: (a) a 5x5 grid topology, and (b) a general topology consisting of 25 nodes

4.2

Distributed Election-based Scheduling

As mentioned in Section 2.1.2, the transmission timing of DSCH and MSH-NCFG messages is determined by the distributed EBTT mechanism. In the following we examine our implementation of this mechanism by simulations. The simulation scenarios are shown in Fig. 4.2, each consisting of 25 nodes. Table 4.1 lists impor-tant network parameters used in both scenarios. Because it takes some time for the network to become stable (i.e. all nodes have completed the network entry process), we start collecting simulation results at 80 seconds.

Fairness

In the long term, all nodes should acquire an almost equal number of TxOpps if they have the same value of Xmt Holdoff Exponent. This fairness is ensured by the way the pseudorandom mixing number is computed.

Fig. 4.3 shows the TxOpps acquired by each node in the simulation case of the 5x5 grid topology. We see that nodes located in the center of the grid, for example

Table 4.1: Simulation parameters used in Section 4.2

Parameter name Value Description

Xmt Holdoff Exponent 1 Xmt Holdoff Time = 21+4_{= 32 TxOpps}

MSH-CTRL-LEN 8 TxOpps per frame

MSH-DSCH-NUM 8 MSH-DSCH TxOpps per frame

Scheduling-Frames 1 Four frames have a schedule control subframe

between two frames with network control subframes

Frame-Duration 10 ms

Simulation Time 400 sec Simulation results are collected after 80 seconds.

node Node 12, 13 and 14, have slightly less TxOpps than their neighboring nodes. This phenomenon can be explained because nodes with more neighbors within their extended neighborhood have more potential competitors when the Mesh Election for some TxOpp is held. A similar result is obtained for the general topology case, which is shown in Fig. 4.4.

Latency

The latency of a node is the number of TxOpps between its two consecutive MSH-DSCH/MSH-NCFG transmissions. Intuitively, the average latency is inversely proportional to the number of TxOpps acquired. Moreover, a node’s latency should approximate to its Xmt Holdoff Time if the number of neighbors within its ex-tended neighborhood does not exceed its Xmt Holdoff Time.

The average latency experienced by each node is illustrated in Fig. 4.5. All nodes have an average latency slighly more than the Xmt Holdoff Time. A similar result is obtained for the general topology case, which is shown in Fig. 4.6.

Exclusion

Within the extended neighborhood, only one node is permitted to transmit at a time. This ensures that the exchange of MSH-DSCH and MSH-NCFG messages is

4000 4500 5000 5500 6000 6500 7000 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 Number of MSH-DSCH TxOpps Node ID

Figure 4.3: Number of MSH-DSCH TxOpps vs. Node ID for the network topology in Fig. 4.2(a) 4000 4500 5000 5500 6000 6500 7000 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 Number of MSH-DSCH TxOpps Node ID

Figure 4.4: Number of MSH-DSCH TxOpps vs. Node ID for the network topology in Fig. 4.2(b)

0 5 10 15 20 25 30 35 40 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 Average Latency Node ID

Figure 4.5: Average latency vs. Node ID for the network topology in Fig. 4.2(a)

0 5 10 15 20 25 30 35 40 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 Average Latency Node ID

Table 4.2: Simulation parameters used in Section 4.3

Parameter name Value Description

Tb 11.1 us OFDM useful symbol time

Tg Tb/4 OFDM guard time

MSH-CTRL-LEN 8 TxOpps per frame

Frame Duration 10 ms

collision-free. The simulation results of the above two topologies show that there is no collision after the network becomes stable.

4.3

PHY Modes and Corresponding Throughput

In this section, we compute the theoretical capacity at the PHY layer and the MAC layer using parameters listed in Table 4.2. The derived throughput is then compared with the application throughput obtained from our simulation results.

Let TCtrl. and TData denote the throughput of the control subframe and the data

subframe, respectively; SF rame denotes the number of OFDM symbols per frame;

SCtrl. and SData denote the number of OFDM symbols in the control subframe and

the data subframe, respectively. The PHY throughput, TP HY, over a link can be

expressed as:

TP HY = TCtrl.+ TData

There are MSH-CTRL-LEN TxOpps per control subframe, with each TxOpp con-sisting of 7 OFDM symbols. So we have

SCtrl. = MSH −CT RL−LEN · 7

= 56

SData = SF rame− SCtrl.

= F rame Duration

= 664

All transmissions in the control subframe are sent using the QPSK-1/2 mode. The size of a coded block in this mode is 48 bytes. Thus, TCtrl. is a fixed value and can be computed as : TCtrl. = SCtrl.· 48 F rame Duration = 268.8 Kbyte/sec = 2.15 Mbit/sec

TData depends on the type of the PHY mode used. For example, when operating in

the QPSK-3/4 mode, TData can be computed as:

TData =

SData· 48 F rame Duration = 3.19 Mbyte/sec = 25.5 Mbit/sec

Using the same example, the PHY throughput is 2.15 + 25.5 = 27.65Mbit/sec. The

MAC throughput, TM AC, can be derived by considering the coding rate:

TM AC = TCtrl.· 1 2 + TData· 3 4 = 20.2 Mbit/sec

The PHY throughput and the MAC throughput using mandatory PHY modes are shown in the second and the third columns of Table 4.3. To obtain the applica-tion throughput, we setup a simple simulaapplica-tion case containing only two mesh nodes. One of the nodes is running a greedy UDP sender program, transmitting data pack-ets as soon as possible, while the other is running a UDP receiver program. To fully utilize the available bandwidth, a permanent distributed schedule which spans the whole data subframe is established between the sender and the receiver. The simu-lation results are shown in the fourth column of Table 4.3. Protocol overheads such

Table 4.3: PHY, MAC and application throughput using mandatory PHY modes Mandatory mode PHY throughput (Mbit/sec) MAC throughput (Mbit/sec) Application throughput (Mbit/sec) BPSK-1/2 14.90 7.45 6.14 QPSK-1/2 27.65 13.82 12.35 QPSK-3/4 27.65 20.2 18.45 16QAM-1/2 53.15 26.57 24.61 16QAM-3/4 53.15 39.32 36.92 64QAM-2/3 78.64 52.07 49.23 64QAM-3/4 78.64 58.44 55.39

as UDP/IP headers, the MAC header/subheaders/trailer (CRC), and MAC man-agement messages exchanged in the control subframe contribute to the difference between the MAC throughput and the application throughput.

Chapter 5

Performance Evaluation

In this chapter, we evaluated the performance of the WiMAX Mesh network. Through-out this chapter, the common simulation parameters listed in Table 5.1 are used. The channel model in the physical layer is disabled by default. The MAC throughput in the data subframe, TM AC, Data, over a link is

TM AC, Data = Request Size · Minislot Size · Uncoded Block Size F rame Duration

= 10 · 3 · 108

10 ms

= 324.0 Kbyte/sec

5.1

Multihop Traffic

The IEEE 802.16 Mesh mode is primarily defined to support multihop wireless com-munication. However, when distributed scheduling is used, the three-way handshake procedure to establish schedules between two nodes incurs an unavoidable large de-lay. Therefore, as mentioned in Section 3.2.1, we propose a scheme for Mesh nodes to aggressively establish distributed schedules with their neighbor before their current schedules are expired. In the following, we perform two suites of performance tests to observe the performance of UDP/TCP multihop connections over the WiMAX Mesh network. We also evaluate the improvement made by our proposed scheme.

Table 5.1: Common simulation parameters

Parameter name Value Description

MSH-CTRL-LEN 8 TxOpps per frame

Xmt Holdoff Exponent 1 Xmt Holdoff Time = 21+4 _{= 32 TxOpps}

Schedule Persistence 128 Number of frames over which the

schedule is valid

Request Size 10 Maximal number of minislots per

established schedule

Minislot Size 3 Number of OFDM symbols per minislot

PHY mode 64QAM-2/3 108 bytes per uncoded block

Frame Duration 10 ms

The network configuration used is shown in Fig. 5.1. The node on the left hand side is the source host while the host on the right hand side is the destination host. Intermediate nodes act as traffic forwarders. In the first suite, an greedy UDP connection is established between the source and the destination. In the second suite, a greedy TCP connection is established instead. The simulation time of each suite is 300 seconds.

Fig. 5.2 shows the simulation results of the first test suite. We see that for the

1-hop case without using our proposed scheme, there is a gap between TM AC, Data

and the UDP application throughput. The reasons are twofold. First, various unavoidable protocol overheads contribute to this gap. Second, the sender issues a request only after the current schedule is expired. Therefore, there is a delay before the new schedule can be established. During the schedule setup time, no application

2

1 _ΟΟΟ N N+1

400m

Figure 5.1: The network topology used to evaluate the performances of UDP/TCP multihop connections

0 50 100 150 200 250 300 350 7-hop 6-hop 5-hop 4-hop 3-hop 2-hop 1-hop

UDP Throughput (Kbyte/sec)

Hop Count

Original Improved

Figure 5.2: Performances of multihop UDP connections

0 50 100 150 200 250 300 350 5-hop 4-hop 3-hop 2-hop 1-hop

UDP Throughput (Kbyte/sec)

Hop Count

Original Improved

Figure 5.3: Performances of multihop UDP connections under a more realistic wire-less channel

0 50 100 150 200 250 300 350 7-hop 6-hop 5-hop 4-hop 3-hop 2-hop 1-hop TCP Throughput (Kbyte/sec) Hop Count Original Improved

Figure 5.4: Performances of multihop TCP connections

data can be transmitted. It can be seen that using our proposed scheme there is a constant improvement of about 25%, because the delay has been mostly eliminated. Fig. 5.3 shows the simulation results of the same test suite with the channel model enabled. Unlike Fig. 5.2, performance of multihop UDP connections downgrade as the number of hops increases.

Fig. 5.4 shows the simulation results of the second test suite. For 1-hop, 2-hop and 3-hop TCP connections, our proposed scheme improve the TCP application throughput by 25%, 99% and 41%, respectively. Note that the performance of TCP connections are constrained by the round-trip-time (RTT) between the source and the destination. Our proposed scheme can only eliminate the schedule setup delay from the source to the destination. In the reverse direction, however, it cannot be triggered since TCP ACK packets are sent in a much slower rate.

5.2

TCP Fairness

TCP is one of the most important protocols of the Internet protocol suite. Many popular applications including WWW and E-mail are built on top of TCP. It is a connection-oriented protocol and guarantees reliable and in-order delivery over the connections established between end systems. To achieve high performance without adding the network’s level of congestion, several techniques including slow-start, flow control and congestion control are used. In this section, we set up a simulation case to demonstrate that TCP congestion control exhibits fairness when sharing the same bottleneck wireless links in the WiMAX Mesh network.

The network configuration used is depicted in Fig. 5.5. In this configuration, there are six nodes, one Mesh BS, two Mesh SSs, two networked hosts connected to the Mesh BS gateway, and one networked host connected to the Mesh SS Gateway. Two greedy TCP connections are established between the two TCP senders and the TCP receiver. The simulation time is 100 seconds.

Fig. 5.6 shows the simulation result of this case. It can be seen that TCP still exhibits long-term fairness across the WiMAX Mesh network.

Host (TCP sender 1) Host (TCP sender 2) 16 Mesh BS Gateway 16 16 Mesh SS Forwarder Mesh SS Gateway Host (TCP receiver)

Figure 5.5: The network topology used to demonstrate TCP fairness over WiMAX Mesh network links