Performance Metrics

In the following, several performance metrics used throughout the paper are defined.

The Average Transmission Opportunity Utilization of Nodes (ATOUN) The utilization of a node’s control-plane bandwidth is an important metric used to evaluate the efficiency of a holdoff time setting scheme. To define the utilization of the control-plane bandwidth from the perspective of an SS node, one first recalls the notion of the two-hop neighborhood (Eq. 2.1). For an SS node, since the hidden terminal problem can occur only with nodes that are in its two-hop neighborhood, the IEEE 802.16 standard requires that each node resolve the contention of each transmission opportunity with the nodes in its two-hop neighborhood. Thus, within a node’s two-hop neighborhood, only one node can transmit a control message at any given transmission opportunity.

The average transmission opportunity utilization viewed from a node j is defined in (4.38). This definition indicates how well the nodes in node j’s two-hop neighborhood (including node j itself) together utilize the network’s transmission opportunities. Ideally, the average transmission opportunity utilization viewed from each node should be 100%, which indicates that, from the perspective of each node, each transmission opportunity is used by one and only one node and no transmission opportunity is left unused.

The ATOUN metric of a network case is defined in (4.40). It is the average across all nodes’ AvgTxOpp values in a network case.

AvgT xOpp(j) = P

i∈nbr(j)txnum(i)

total(j) (4.20)

AT OUN = Pm

j=1AvgT xOpp(j)

m (4.21)

where txnum(j) denotes the number of transmission opportunities won by node j, total(j) denotes the number of total transmission opportunities since node j has attached itself to the network, and m is the number of nodes in a network case.

The ATOUN metric reflects the utilization of the control-plane bandwidth from the aggregate of the local view of each node. A higher value of this metric indicates that a network case has a higher control-plane bandwidth utilization; a lower value indicates that a network case has a lower control-plane bandwidth utilization.

The ATOUN metric does not measure the fairness of bandwidth sharing in a network.

To solve this problem, we designed another metric, explained in Section 4.2.1, to evaluate how fairly network nodes share the control-plane bandwidth.

The Average Three-way Handshake Procedure Time (ATHPT)

The average three-way handshake procedure time (ATHPT) metric is defined as the average time required by the three-way handshake procedure to establish a data schedule across all network nodes in a case. This metric is computed as follows. For a network case, we first use (4.41) to average the times required to establish data schedules for every node. We then use (4.42) to compute the case’s ATHPT value, which is the average across all nodes’ THPT values. Like the ATOUN metric, for each scheme, the average and standard deviation of its ATHPT values across all simulation cases will be presented.

T HP T (j) =

where tij denotes the time required for establishing the ith data schedule of node j, n is the number of node j’s data schedules, and m is the number of nodes in a network case.

ATHPT is a common metric used in the literature to evaluate the effect of the holdoff time value. The three-way handshake procedure requires transmitting three MSH-DSCH messages, each of which contains the request, grant, and confirm information elements (IE), respectively. The detailed procedure is described below.

First, the requesting node transmits a request IE to the peer node. The request IE specifies (1) the number of requested mini-slots on the peer node and (2) the available mini-slots on the requesting node from which the peer node can choose. On receiving the request IE, the peer node decides whether it would like to accept this request. If not, it ignores this message. Otherwise, out of its own available mini-slots, it allocates a data schedule from the requesting node’s available mini-slots. The peer node then transmits a grant IE containing the information of the allocated data schedule to the requesting node. Upon receiving the grant IE, the requesting node broadcasts a confirm IE to all of its neighboring nodes to notify them of this allocation information.

The reasons for the above procedure are clear. First, the mini-slots of the requesting and the peer nodes are already synchronized over the time axis in an IEEE 802.16 mesh network. Second, when the requesting node is transmitting data to the peer node, the peer node must be able to receive the data at the same time. Therefore, the requesting node must negotiate with the peer node to find a range of mini-slots that is available to

Time Src:RequestIE

Dst:GrantIE

Src:ConfirmIE Data packet

Figure 4.6: A good case for establishing a data schedule in the distributed coordinated scheduling mode when the network is not congested

Time Src:RequestIE

Dst:GrantIE

Src:ConfirmIE Data packet

Figure 4.7: A bad case for establishing a data schedule in the distributed coordinated scheduling mode when the network is not congested

both of them (i.e., good for transmitting at the requesting node and good for receiving at the peer node) and can accommodate the requested number of mini-slots.

Fig. 4.6 and Fig. 4.7 are two examples showing the effect of the holdoff time value.

(Note that these two figures are for illustration purposes and the minimum number of slots between subsequent MSH-DSCH messages should be 16 according to the standard.) Fig. 4.6 shows a good case for establishing a data schedule when the network is not congested. In this case, all control messages required for establishing a data schedule are exchanged within one control subframe due to the use of a small holdoff time value.

Thus, data packets can be quickly transmitted within the same frame in which the control messages are transmitted. In contrast, Fig. 4.7 shows a bad case for establishing a data schedule when the network is not congested. In this case, the three control messages are transmitted over three different frames due to the use of a large holdoff time value. In such a condition, the data packets can only be transmitted over the mini-slots that are at least two frames away from the transmission of the Request IE. Since a node is allowed to transmit data packets to its neighboring node only after they have established a data schedule, the increased delay of the three-way handshake procedure directly degrades the network quality experienced by application programs.

Network Unfairness Index (NetUI) and Node Unfairness Index (NodeUI) We define two new performance metrics, named “Network Unfairness Index (NetUI),”

and “Node Unfairness Index (NodeUI),” to evaluate how fairly network nodes share the control-plane bandwidth. We explain the definitions of these two metrics here. To un-derstand them, one first realizes that, viewed from a node, if every node in its two-hop neighborhood has data to send at any given time, the optimal way to schedule these nodes’ control message transmissions is to schedule them in a round-robin fashion. That is, a node should on average transmit one and only one control message every N TxOpps, where N is the number of nodes in its two-hop neighborhood (including itself). We call this round-robin scheme “the static optimal scheme” in this dissertation. This is the optimal design for a static network in which every node has data to send at all time.

This is because when a node wants to transmit a control message, the transmission must be resolved among all the nodes in its two-hop neighborhood. Thus, to avoid congestion while reducing transmission delays, on average a node can only transmit a control message every N TxOpps, where N is defined above.

For a fixed-value holdoff time scheme, to avoid any congestion from occurring in the network, the maximum of the N values of all nodes should be used as the fixed value for all nodes. Since in a general network topology not all nodes have the same N value, this fixed-value approach will waste the transmission opportunities of the nodes whose N values are smaller than the maximum one.

We define a node’s TxOpp utilization during a period as the ratio of the number of TxOpps that it wins during the period to the total number of TxOpps available during that period. If such ratios of all nodes under a holdoff time scheme closely approximate their counterparts under the static optimal scheme, this holdoff time scheme is considered to perform as well as the static optimal scheme.

The following explains the steps used to compute NetUI. First, we convert the actual utilization ratio of a node i into the logarithmic form as follows:

R1(i) = −log2(NumT xoppwin(i) NumT xopptotal

) (4.24)

where NumT xoppwin(i) denotes the number of TxOpps that node i wins in the period and NumT xopptotal denotes the total number of TxOpps available in the period. Also, the logarithmic form of the static optimal utilization ratio for a node i is shown in the

following:

R2(i) = −log2( 1

|nbr(i)|) (4.25)

where |nbr(i)| denotes the number of nodes in node i’ two-hop neighborhood. Second, the absolute value of the difference between the two logarithms is computed and shown as follows.

Dif f (i) = AbsoluteV alue(R1(i) − R2(i)) (4.26) Finally, the NetUI metric is defined as the sum of the Diff values of all nodes in a network and shown as follows:

where m is the number of nodes in a network case.

The rationale for the NetUI metric is that when evaluating a holdoff time scheme, one should consider its impacts on all network nodes. This sum shows the degree of inefficient and unfair use of available transmission opportunities across all nodes in a network. A zero NetUI value means that a holdoff time setting scheme schedules transmission opportunities for the whole network as if the static optimal scheme were used. In contrast, a non-zero NetUI value indicates that the scheme schedules transmission opportunities either inefficiently or unfairly when compared with the static optimal scheme. As expected, a high NetUI value indicates that the used holdoff time setting scheme deviates much from the static optimal scheme.

The definition of NodeUI is given as follows:

NodeUI =

where m is the number of nodes in a network case.

The NodeUI metric is similar to the NetUI metric. However, it is more suitable for observing the inefficiency and unfairness degree of a node’s control message scheduling.

The best value for this difference is zero, which means that the scheduling generated by the used scheme for this node is equivalent to that generated by the static optimal scheme.

If this difference value increases, it means that the scheme performs worse than the static optimal scheme. In the following sections, either NetUI or NodeUI is used to evaluate the fairness degree of TxOpp sharing in the network, depending on the context.

Table 4.1: The parameter setting used in simulations

Parameter Name Value

MSH-CTRL-LEN 8

MSH-DSCH-NUM 8

Scheduling Frames 2

Requested Mini-slot Size 20 Requested Frame Length 32

Modulation/Coding Scheme 64QAM-3/4 Maximum Transmission Range 500 meter

Frame Duration 10 ms