Related work III: Bi-directional Cognitive Radio MAC Protocol for Supporting

Lee-Chin Lau et al. identified that the major cause of the TCP performance degradation of Uni-MAC protocol that is due to the mechanism of TCP congestion control. This mechanism is employed such that a TCP sender would adjust its packet transmission rate

Figure 3.6 Illustration of Uni-MAC and the enhancement when TXOPCR value is 2

25

based on the received TCP ACK. The authors propose a Bi-directional Cognitive Radio MAC Protocol (Bi-MAC) which is an extension of the CR MAC protocol proposed by [2]. The point of Bi-MAC is that it can smartly supports either uni-directionally or bi-directionally bandwidth reservation. The enhancements give the better supports of both TCP and two way UDP flows.

We will address the reason of how TCP congestion control influences TCP flow of Uni-MAC protocol in detail and how does Bi-MAC solve this problem in following.

 The degradation of TCP throughput of Uni-MAC

Consider a CR network without any PUs and only one CRU pair is transmitting a TCP flow. Let CRU_A be TCP sender that transmits the TCP packets continuously. Let CRU_B be the TCP receiver which replies TCP ACKs while receiving TCP packets from CRUA. The selected data channel and start channel sensing for 2 ms. After that, CRU_A can transmit two frames with a 100 us QP after receives the replied 802.11 ACK from CRUB. After receiving the first TCP packet from CRU_A, CRU_B starts to generate the TCP ACK. However, with the design of Uni-MAC protocol, CRUB cannot reply the TCP ACK to CRUA at the first moment.

In order to reply TCP ACK to CRU_A, CRU_B has to wait for the current CR transmission round finish and start over from the BNP again. After the BNP, the CRU pair should find an available data channel before CRU_B can reply TCP ACK to CRU_A. Finally, CRU_B can transmit TCP ACK on an idle data channel.

26

Figure 3.7 illustrates the situation mention above. One can see there are two drawbacks for TCP flow due to the one-way design of Uni-MAC.

First, CRUB cannot reply TCP ACK immediately after it receives a TCP packet. CRUB

has to wait until CRU_A’s CR transmission round finishes and contains with other CRU for the BNP in control channel. In control channel, CRUs use IEEE 802.11 DCF [7] to access the channel. If there are many other CRUs attempt to start BNP, the CRU_B has to contain with them and may not get the opportunity to send the RTSCR right after the CRUA’s CR transmission round finishes. After BNP, the CRU pair still needs to find an available data channel through fast channel sensing. Although Uni-MAC implements the SCSS which increase the probability for CRU pair to find the available data channel at the first try; it still has a chance to fail and need a second or even a third try. The process mentioned above decided the round-trip time (RTT) of the TCP flow. In the best case (see Figure 3.7), with

Figure 3.7 Illustration of the best case of the TCP packets exchanges when TXOPCR is 2

27

no contention and failure during the BNP and SCSS, the RTT time is the summation of data transmission time, QP time, time of BNP and channel sensing time. However, in a bad case (see Figure 3.8), the SCSS may not success at the first try and will costs additional BNP time or channel sensing time. This highly increases the RTT of the TCP flow of CR sender and decrease the performance.

Second, if the receiver’s TCP ACKs arrive at the sender with the same spacing, then the sender can send new data packets at the same rate to avoid overrunning the bottleneck link. It is said that such ACK policy makes the protocol self-clocking because the sender can dynamically adapts its transmission speed to both the speed of the network and the speed of the peer sending TCP ACKs. Since a TCP’s self-clocking depends on the arrival of TCP ACKs at the same spacing with which the receiver generated them, if these TCP ACKs spend any time sitting in queues during their transit through the network, their spacing may be altered. When ACKs arrive closer together than they were sent, the sender might be misled into sending more data than the network can accept, which could led to congestion and loss of

Figure 3.8 Illustration of a bad case of the TCP packets exchanges when TXOPCR is 2

28

eficiency. This is called the ack-compression effect. It has been proven both statistically and experimentally that the ack-compression effect could result in unfairness and reduced overall throughput compared to what could be expected without this effect.

 Proposed Bi-MAC protocol in [3]

To solve the problem, the authors propose a design which supports both bi-direction traffic and uni-direction traffic. A 2-bit field is added into RTS_CR and CTS_CR control frame¹. The extension filed name as Reservation Type (RT), which indicates the bandwidth reservation type for CRU pair in a transmission run. In Bi-MAC, before a CRU transmitting RTSCR or CTSCR, a CRU always checks the head of transmitting queue (HOQ) and set RT in following rules:

 CR sender set RT of RTSCR to 00 if CR sender identifies HOQ is an UDP packet.

This indicates CR sender is issuing a uni-direction UDP flow.

 CR sender set RT of RTSCR to 01 if CR sender identifies HOQ is a TCP packet. This indicates CR sender is issuing a bi-direction TCP flow.

 CR receiver set RT of CTSCR to 10 if CR receiver identifies HOQ is not empty. This indicates CR receiver requesting a bi-direction flow.

 CR receiver copies the RT value from received RTSCR to the RT of CTSCR if CR receiver identifies HOQ is empty. Because the queue of CRU’s is empty, it follows the RT demanded reservation type by CR sender.

In summary, the bandwidth reservation of a CR transmission round is decided by the RT value of CTSCR: 00 means uni-direction bandwidth reservation is demanded by CRU pair and bi-direction bandwidth reservation is demanded by CRU pair for other value.

1 In [3] and [4], the authors change RTS_CR and CTS_CR to REQ_CR and GRANT_CR. We change it back to RTS_CR and CTS_CR forconsistence.

29

After BNP and channel sensing, the transaction interval (TI) to be filled in a RTS control packet is decided by the bandwidth reservation type. The authors only consider a simple network case with either a TCP flow or bi-directional UDP flows with uniform packet size between a CRU pair. With one-way bandwidth reservation, the TI is determined simply based on the packet length of the HOQ at the CR sender.

For a two-way bandwidth reservation, however, the TI is determined according to the value of RT of CTSCR. If the value of RT of CTSCR is filled with 01, a TCP flow is anticipated.

Therefore, the TI will be set to a duration which is adequate for transmitting a TCP data frame, a TCP ACK and two 802.11 ACK packets. Alternatively, if the RT of CTSCR is filled with a value of 10, two UDP flows of opposite directions are anticipated. In this case, the TI will be set to a duration which is adequate for transmitting two UDP packets of equal size and two 802.11 ACK packets.

With the design of two-way bandwidth reservation, the CR receiver can reply ACK right after the CR sender transmits the data frame. This can make RTT of TCP flow to a smaller value. In Figure 3.9, we illustrate the RTT of a TCP flow of both Uni-MAC and Bi-MAC.

One can see the big improvement for reducing the RTT with the proposed two-way bandwidth reservation of BI-MAC. The simulation results in [3] also prove that the proposed Bi-MAC protocol can dramatically improve both the TCP and UDP throughput of CRUs without sacrificing the performance of PUs.

30

3.4. Related work IV: An IEEE 802.11 cognitive radio MAC protocol with dynamic bandwidth allocation capabilities.

In former section, Lee-Chin Lau et al. propose a bi-directional CR MAC protocol which solves the TCP low efficiency problem of Uni-MAC protocol. However, the design of Bi-MAC protocol is inadequate in supporting traffic demands in more complicated network cases. To solve the problem, the authors propose an Advance-Bi-direction CR MAC protocol (ABi-MAC) with Dynamic Bandwidth Allocation (DBA) algorithm to supports asymmetric two-way traffic flows. Furthermore, the proposed Smart Transaction Interval Setting (STIS)

Figure 3.9 Illustration of Packets Exchanges on Data Channel of a) Uni-MAC and b) Bi-MAC, when TXOPCR is 2

31

guarantees the Quality of Service of PUs. In this section, we first address the problems of Bi-MAC and then introduce the solution of ABi-MAC.

 The definition of TXOP_CR in Uni-MAC and Bi-MAC.

In Uni-MAC and Bi-MAC, TXOP_CR is adopted as a fixed network parameter. In Uni-MAC, the TXOPCR is the number of maximum data frames that could be transmit by CR sender after CRU pair in a CR transmission round. In Bi-MAC, if two-way bandwidth reservation is adopted, TXOPCR is the number of maximum data frames that could be transmit by both CR sender and CR receiver. One should note that, during the CR transmission round when two-way bandwidth reservation is applied, each of the CR pair can send a data frame that costs two TXOP_CR in a data transmission round. Otherwise, the meaning of TXOP_CR is the same as Uni-MAC.

A small value of TXOP_CR, i.e. one, should be used when the data channels is usually in a busy state. However, if data channel is usually in an idle state, a huge overhead is caused by the time of BNP and SCSS after each data transmission run. In general, a large value of TXOPCR, i.e. four, is suitable for all network condition. If the data channel is usually idle, CRUs can stay a longer time on data channel for possible data transmission. On the other hand, when data channels are busy, the CRU still guarantee the QoS of PUs’ data transmission.

Due to the channel vacating mechanism, the CRU will vacate the data channel and hop back to control channel when a PU tries to claim the channel at QP. However, for a large value of TXOP_CR, i.e. four, will cause the unavoidable overhead when bi-directional bandwidth reservation is considered. The problem is address as following.

 The unavoidable overhead of large TXOPCR with bi-directional bandwidth reservation of Bi-MAC

32

The fixed value of TXOPCR causes the bandwidth waste while a CRU pair is transmitting asymmetric two-way traffic flows. Figure 3.10 illustrates the overhead while CRU is using Bi-MAC with bi-directional bandwidth reservation when TXOPCR equal to 3. One can see that CR receiver’s queue is empty after the first data transmission turn. In this case, the TXOPCR is set to three and there is no PUs try to claim the channel during QP. In the second data transmission round, CR sender transmits the data frame and not receiving the data frame from CR receiver. Though, the CRU pair enter QP after the timer of the bandwidth reservation expires. Again, the situation remains the same in the third data transmission turn. The CRU pair still waste their time until the timer expire after CR sender transmits the data frame. As a result, the time spent waiting for the timer to expire is an unavoidable overhead of Bi-MAC while TXOPCR is fixed. The worst case is that the queue of CR sender also becomes empty before the TXOP_CR transmission turn finish. In this situation, the CRU pair occupy the channel and do nothing until the timer expire. Such undesirable phenomena not only increase the overhead, but could also influence the PUs performance. The reason of the influence to PUs is due to the fixed TI setting which is explained as follow:

 The problem of fixed TI setting with two-way bandwidth reservation of Bi-MAC.

Bi-MAC is designed to support one TCP flow between CRU pair or two way UDP flow with uniform same size between CRU pair. The TI setting of RTS control frame with two-way bandwidth reservation is determined on the RT value of CTSCR, as elaborated in section 3.3.

However, the design does not satisfy the situation of two-way asymmetry UDP traffic over a CRU pair.

33

Figure 3.11 illustrates the negative impact to PUs QoS which is caused by the fixed TI setting in Bi-MAC when two-way bandwidth reservation is considered. In this case, the size

Figure 3.10 Illustration of Message Exchanges on Data Channel of Bi-MAC with Bi-directional Bandwidth Reservation when TXOPCR = 3

34

of data frames in CR sender’s queue is 1,450 bytes. On the other hand, the there is only one 200 bytes long data frame in CR receiver’s queue. The transmission run perform two-way bandwidth reservation due to the non-emptiness of CR receiver’s HOQ. With the design of Bi-MAC, TI is set to a duration which is long enough for transmitting two 1,450 bytes long data frames and two 802.11 ACK frames.

One can see in Figure 3.11, the first TI set to the RTS is longer than the actual transmission time of the first data transmission round due to the small packet of CR receiver.

This inappropriate design strongly breaks the opportunity of PUs to claim the channel. The CRU pair entered the QP right after the ACK reply to CR receiver is transmitted. However, due to the RTS transmitted at the beginning of data transmission round, all neighboring PUs will set their Network Allocation Vector (NAV) according to TI of RTS. The NAV is an indicator for a station on how long it must defer from accessing the medium. In this case, the neighboring PUs receives the RTS will defer until the bandwidth reservation time of CRUs is finished. As a result, the CRU pair enter QP in the reserved time which PUs cannot send a RTS to claim the channel due to NAV. After QP, CRU starts the second data transmission round and transmits RTS again. The neighboring PUs overhear the RTS and set their NAV according to TI again. At this moment, one can see the reserved time of CRU pair of first transmission run is not finish yet due to the small size frame of CR receiver. The reserved time of CRU pair of second transmission round overlaps with the first one that gives no free time for PUs to claim the channel in between the first data transmission round and second transmission round. The same case happens when the CR receiver is running out of frames in its queue, as shown in the CR receiver’s second transmission round in the figure. In this case, both the CRUs enter the QP after the timers expire but the PUs are still deferring from accessing the medium due to the NAV.

35

The CRU pair elaborated above do enter the QP after every transmission round. However, the result is it does not protect the PUs’ right to claim the channel at all. In other word, the QP is totally a waste of time. Furthermore, the CRU pair occupy the data channel until the end of

Figure 3.11 Illustration of inappropriate TI setting of Bi-MAC with Bi-directional Bandwidth Reservation

36

the TXOPCRth data transmission round. This does not satisfy the spirit of cognitive radio: the CRU should not interferes the right of primary users.

 The design of Advance-Bi-direction CR MAC protocol (ABi-MAC)

To solve the above two problems, the authors of [4] propose ABi-MAC with two phases as follow:

Dynamic Bandwidth Allocation (DBA)

The main purpose of DBA is to determine the available transmitting frame number for both CR sender/receiver right after the BNP. Thus, the CRU pair can use the channel in a more efficient way to transmit the data frames on data channel. Through this purpose, the authors defined several new variations of TXOP:

 MAX_PACKET: a pre-defined parameter. The maximum number of frames that CRU pair can transmit on the data channel. We use TXOP_CR instate in this paper

 BDs: the bandwidth demand of CR sender. It is a 5-bit field at the end of RTSCR

control frame. Representing the bandwidth demand from 0~31 data frames.

 BDr: the bandwidth demand of CR receiver. It is a 5-bit field at the end of CTSCR

control frame. Representing the bandwidth demand from 0~31 data frames

Both BDs and BDr are decided dynamically through the BNP. In ABi-MAC, BDs and BDr

is carried in the RTS_CR and CTS_CR control packet separately. The Reservation Type (RT) in Bi-MAC is replaced with a 5-bit field of BDs or BDr, as shown in Figure 3.12 and Figure 3.13.

37

The DBA of ABi-MAC operates in the following way. Firstly, assume that a CR sender maintains a separate queue for every CR receiver. Before sending an RTS_CR, the CR sender gets the number of data frames to be transmitted to a specified CR receiver by retrieving the current size of the corresponding queue. This information is treated as the value of BD_s in the RTSCR and shall be set using the following equation:

(3-3)

where Q_s denotes the current queue size of the CR sender (for the specified CR receiver) and M denotes the pre-defined and fixed network parameter TXOPCR. Upon receiving the RTSCR, the CR receiver checks the corresponding queue that contains packets to be sent to the CR sender and then decides the value of BDr using Eq. (3-4). At the same time, the CR receiver also records the value of BD_s as the number of packets to be received from the sender (NPR_s) using Eq. (3-5). After that, it replies a CTSCR to the CR sender.

(3-4) Figure 3.12 Frame Format of the control packet RTSCR of ABi-MAC

Figure 3.13 Frame Format of the control packet CTS_CR of ABi-MAC

38

where Qr denotes the size of the queue containing packets to be sent to the CR sender and A denotes M/2.

(3-5)

Finally, the CR sender reads the value of BDr in CTSCR and records the number of packets to be received from the receiver (NPR_r) using Eq. (3-6). It then finalizes its value of BD_s using the Eq. (3-7) where BDSF denotes the finalized value of BDs at the end of the BNP.

(3-6)

(3-7)

Using the proposed DBA, the ABi-MAC can offer very high flexibility in allocating bandwidth to the CRU pair regardless of their traffic condition. Through maintaining the BDs, BD_r, NPR_s and NPR_r, ABi-MAC can support (1) a uni-directional traffic flow from the CR

Using the proposed DBA, the ABi-MAC can offer very high flexibility in allocating bandwidth to the CRU pair regardless of their traffic condition. Through maintaining the BDs, BD_r, NPR_s and NPR_r, ABi-MAC can support (1) a uni-directional traffic flow from the CR