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

(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.

Figure 3.6: State transition of the New 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

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 Exponent^A 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 Ref₂ = ⌊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

15: end if

Free

Receive a request from 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.