In this section, we introduce the MAC protocol proposed by [9] and [10], respectively.
These two previous works serve as the major related works of this dissertation.
2.4.1 Related Work I: On Synchronized Channel Sensing and Accessing for CR Users in IEEE 802.11 wireless Networks
In [9], TakChou Lou et al. considered the problem of how CRUs can opportunistically use the bandwidth of ubiquitous IEEE 802.11 networks. That is, PUs are users authorized to access the frequency used by the local IEEE 802.11 network with the DCF and CRUs are users unauthorized to access those frequencies. To solve this problem, in [9] they proposed
a CR MAC protocol for CRUs to access the authorized frequencies in an opportunistic manner. In this protocol, an 802.11 channel is used as the control channel. CRUs should monitor control messages broadcast on the control channel whenever they are idle. The protocol defines three new control messages: 1) Request-To-Send-CR (REQCR); 2) Grant-To-Send-CR (GRANTCR) and 3) Suspend (SUS). When a CR sender intends to transmit a data packet, it should perform the REQCR/GRANTCRhandshake with the CR receiver on the control channel.
The REQCRcontrol message is an RTS control message plus the following extra fields:
1) the ID of the initial selected data channel (denoted as InitCH ), and 2) increment-per-hop (denoted as Inc). InitCH denotes the initial data channel to which the pair of CR sender and receiver (denoted as CRU pair hereafter) will switch to perform data transmission, and it is randomly selected by the CR sender. Inc denotes a random number used for deriving the ID of the next data channel that the CRU pair will try to access.
Given InitCH, Inc and the number of data channel (denoted as Nc), the next-hop channel is determined by the following equation:
CH(i) = (CH(i − 1) + Inc) mod Nc, i≥ 2 , (2.1) where CH(1) = InitCH ≤ Nc.
For example, for an IEEE 802.11 network with eight data channels, given that InitCH
= 2 and Inc = 3, the derived channel hopping sequence (CHS) is (2, 5, 8, 3, 6, 1, 4, 7).
Upon receiving an REQCR sent by the CR sender, the CR receiver first uses Eq. 2.1 to derive the CHS. It then replies a GRANTCRto the CR sender, if it is ready to receive the data. Thereupon, it immediately switches itself to the InitCH indicated by the CHS.
On the other hand, on receiving the REQCR, the CR sender should also immediately switch itself to the InitCH indicated by the CHS. Because the CRU pair use the same information to derive the CHS, their CHS on the data channel will be the same. Using this design, their channel hopping behaviors can be synchronized.
When switching themselves to a data channel, the CRU pair should first monitor the channel for a predefined channel sensing period to sense the channel status. If the channel is idle, the CRU pair will carry out the original RTS/CTS/DATA/ACK transmission sequence. Otherwise, they synchronously switch themselves to the next data channel indicated by the CHS. Such a channel hopping behavior repeats until they can find an
Figure 2.2: Illustration of Packets Transmission of [9] when Txop = 1
idle data channel to transmit a data packet. The CHS should be wrapped to the InitCH if all of the data channels have been sensed.
When successfully accessing a data channel (i.e., succeeding in exchanging the RTS and CTS packets), the CRU pair are allowed to transmit Txop frames, where Txop de-notes the number of Transmission Opportunities. The CR sender should transmit a SUS control message to the CR receiver after successfully transmitting a data frame (i.e., upon receiving the corresponding ACK frame). After transmitting the SUS control message, the CR sender should keep silent on this data channel for a predefined queit period (QP).
This QP provides opportunities for PUs to broadcast RTS and CTS control packets on the data channel to reclaim the use of this data channel. Therefore, during the QP, the CRU pair will proactively evacuate from the data channel and return to the control channel upon overhearing RTS or CTS control messages.
If the Txop is set to one, the CRU pair should should return to the control channel after the QP. The packets transmission between the CRU pair when Txop is being set to one is illustrated in Fig. 2.2.
If the Txop is set to any value larger than one, the CRU pair remain to stay on the
Figure 2.3: Illustration of Packets Transmission of [9] when Txop = 3
channel after the QP if the data channel stays idle throughout the QP. The CRU pair will regard that the channel remains unused by the PUs. As such, they continue to bor-row the bandwidth of the data channel and immediately start a new DATA/ACK/SUS transmissions as described above. After Txop DATA/ACK/SUS transmissions, the CRU pair should immediately return to the control channel. Fig. 2.3 depicts the packets trans-mission when the Txop is being set to three.
Next, we illustrate the packets transmission when a data channel hopping is required.
Assumed that for an IEEE 802.11 network with eight data channels, given that InitCH = 2 and Inc = 3, the derived CHS (2, 5, 8, 3, 6, 1, 4, 7). After a successful REQCR/GRANTCR handshaking process on the control channel, both the CRU pair will switch to Channel 2 as indicated in the CHS for subsequent data transmission and data reception. We further assume that during the channel sensing period of monitoring the Channel 2, PU’s activity is sensed by both the CRUs. In this case, upon the termination of channel sensing period, the CRUs switch synchronously to next data channel as indicated in the CHS, i.e., Channel 5, and repeat the channel sensing procedure on Channel 5. Fig. 2.4 depicts the above scenario where the CRU pair manage to find an idle data channel to transmit data after one time of data channel hopping.
The CR MAC protocol proposed in [9] has two drawbacks. First, it does not assess
Figure 2.4: Illustration of data channel switching when a data channel is sensed busy
Figure 2.5: Illustration of Hidden Terminals
the statuses of data channels before deciding the CHS of a CRU pair. Therefore, the CRU pair may switch themselves to the InitCH and find that it is occupied by PUs. In this condition, they need to hop to the next data channel and sense the PUs’ behavior on the data channel again. Assuming that the primary network has only one unused data channel at this time point, using this design the CRUs may need to switch Nc-1 times to find out the unused channel for data transmission in the worst case. Thus, this CR MAC protocol is inefficient in finding an available data channel.
Second, this proposed CR MAC protocol does not consider the effects of HTs which commonly exist in wireless networks. Fig. 2.5 illustrates an example network with the existence of HTs, where nodes 1, 2, 3, and 4 are CR sender, CR receiver, PU sender and PU receiver, respectively, and nodes 1 and 3 are HTs to each other. In this example, the RTS control message sent by the PU sender for claiming the use of the data channel cannot be overheard by the CR sender. Therefore, after the QP, the CR sender will consider that the data channel remains idle and continues its data transmissions. However, this wrong decision will cause the following data frame transmitted by the CR sender to collide with those transmitted by the PU sender at the CR receiver. As a result, the flow goodputs at the CR receiver will be greatly decreased when HTs exist.
To solve these drawbacks, Shie-Yuan Wang et al. [10] proposed an enhanced CR MAC protocol as elaborated in the following section.
2.4.2 Related Work II: Enhanced MAC Protocol for Cognitive Radios over IEEE 802.11 Networks
As a remedy to the problems as identified in Section 2.4.1, Shie-Yuan Wang et al. [10]
proposed two enhancements to [9]’s CR MAC protocol: 1) a Smart Channel Selection Scheme, and 2) an enhanced data transmission and channel evacuation approach. The details of the enhancements are elaborated in the following sections.
I. Smart Channel Selection Scheme (SCSS)
In [10], a CRU pair do not use Eq. 2.1 to derive the CHS on the data channels. Instead, they use a handshake protocol to negotiate the order of CHS. To do so, each CRU should maintain a 32-bit Availability Record (AR) for each data channel to record its historic availability sensing results. A CRU updates the AR of a data channel each time when it performs the availability checking process and a 100 microseconds fast channel sensing process on this data channel. Each bit of an AR records whether the data channel is idle or not upon the execution of these two processes. The value of a bit being one means that the channel is idle and the value of a bit being zero means that the channel is busy.
Before updating an AR, the CRU should right-shift the value of the AR by one bit. It then updates the most significant bit (MSB) of the AR. This means that the MSB of an AR records the latest status of a data channel.
The availability of a data channel is determined based on the following rules:
• Overhearing an 802.11 ack packet indicates that a data transmission on this data channel is just completed. In this case, the status of this data channel is considered as IDLE.
• Overhearing an RTS or CTS control packet indicates that a data transmission is about to begin. In this case, CRUs should update the Network Allocation Vector (NAV) for this data channel based on the overheard RTS/CTS frame and consider the status of this data channel as BUSY.
• Overhearing a DATA packet indicates that a data transmission is being performed.
In this case, the status of this data channel is considered as BUSY.
• Not overhearing any MAC-layer frames indicates that the data channel is currently
Figure 2.6: Calculation of the Availability Index (AI)
unused and available for CRUs to transmit data. In this case, the status of this data channel is considered as IDLE.
When selecting candidate data channels for data transmission, the CR sender should first compute the Availability Index (AI) for each data channel using the following equa-tion:
AI =
31
X
i=0
b(i) ∗ pos(i), (2.2)
where b(i) denotes the value of i-th bit and pos(i) denotes the position of the bit from the least significant bit to MSB. Fig. 2.6 shows two examples of calculating the AI value. The AI value reflects the idle probability of a data channel. A data channel with the largest AI value is the most preferable channel to be used for exchanging data because 1) it is likely to be idle in the near future or 2) it has remained unused at most time.
The CR sender then sends an REQCRmessage to the CR receiver. The REQCRmessage is the original REQCRmessage in [9] with the InitCH and Inc being replaced by a 16-bit preferable channel (CH pr ) field to indicate the preferable channels for data transmission.
Each bit in the CH pr indicates whether a data channel is selected as a candidate by the CR sender. As explained above, the channel selection is based on the AI value of each data channel.
Upon receiving an REQCRmessage, the CR receiver should perform a 100 microseconds fast channel sensing process to check the availability of each selected data channel. In the fast channel sensing process, the CR receiver switches itself to each selected data channel, stays on the data channel for 100 microseconds, and senses the availability status of that data channel. After sensing all selected data channels, it first updates its own AI values for the selected data channels and then determines the best order of CHS among the selected data channels. Finally, the CR receiver should broadcast a GRANTCR message
Figure 2.7: Frame Format of the control packet REQCR
Figure 2.8: Frame Format of the control packet GRANTCR
to acknowledge the CR sender. The GRANTCRmessage is modified such that it contains a 32-bit channel hopping order (CH HO) field, to store the CHS determined by the CR receiver. Fig. 2.7 and Fig. 2.8 depict the frame format of REQCRand GRANTCRcontrol packets, respectively.
The rationale behind this design can be explained using Fig. 2.5. The transmission activities of PUs (e.g., node 3 in Fig. 2.5) behind the CR receiver may not be detected by the CR sender (e.g., node 1 in Fig. 2.5), due to the limited carrier-sense range of its radio.
That is, these PUs and the CR sender are HTs to each other. If they simultaneously transmit data on the same data channel, their data will be collided at the CR receiver, greatly decreasing the goodputs obtained by the CR receiver. Using [9], the CR sender cannot know the transmission activity of such a PU until it is on the data channel and has not received the CTS upon timeout.
In contrast, using [10] the CR receiver can quickly notify the CR sender of the detected PU’s transmission activities on a data channel by giving this channel a lower preference in (or excluding it from) the CH HO field. Thus, [10] can effectively reduce the time required to find an available data channel to transmit data.
II. Enhanced Data Transmission and Channel Evacuation
[9] does not consider the existence of HTs. After exchanging the RTS/CTS control messages, the CR sender is allowed to transmit a maximum of Txop data frames before
Figure 2.9: Illustration of Message Exchanges on Data Channel of [10] when Txop = 2
returning to the control channel. In between the Txop data frame transmission, QP is introduced for PUs to reclaim the channel. However, during this QP, if the PUs are hidden from the CR sender, the CR sender will not be aware of them even if the PUs have exchanged the RTS/CTS messages for channel reservation. After the QP, the CR sender will continue to transmit data frame to the CR receiver. As a result, the data frame will be collided at the CR receiver and decreases the network goodputs.
To address this problem, in [10] the CRU pair are required to complete an RTS/CTS handshake procedure before every data frame transmission on a data channel. Failure to finish the RTS/CTS handshake procedure indicates that the data channel is currently used. In this condition, the CRUs should proactively evacuate from the data channel and return to the control channel. Although performing the RTS/CTS handshake procedure prior to each data transmission will add some bandwidth overhead, it effectively prevents the data transmissions of CRUs and those of PUs from interfering with each other, thus significantly increasing the goodputs of the network when HTs are present. Fig. 2.9 illustrates the enhanced CR MAC protocol as proposed by [10].