國
立
交
通
大
學
資訊科學與工程研究所
碩
士
論
文
在 IEEE 802.11 網路上
具有動態頻寬配置功能的
雙向感知無線電媒介層多重存取協定
Bi-directional Cognitive Radio MAC Protocol with
Dynamic Bandwidth Allocation
over IEEE 802.11 Networks
研 究 生：劉莉晶
指導教授：王協源 教授
在 IEEE 802.11 網路上具有動態頻寬配置功能的
雙向感知無線電媒介層多重存取協定
Bi-directional Cognitive Radio MAC Protocol with Dynamic Bandwidth
Allocation over IEEE 802.11 Networks
研 究 生：劉莉晶 Student： Lee-Chin Lau
指導教授：王協源 Advisor：Shie-Yuan Wnag
國 立 交 通 大 學
資 訊 科 學 與 工 程 研 究 所
碩 士 論 文
A Thesis
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 2011
Hsinchu, Taiwan, Republic of China
Bi-directional CR MAC Protocol with Dynamic Bandwidth
Allocation over IEEE 802.11 Networks
Student: Lee-Chin Lau
Advisor: Dr. Shie-Yuan Wang
Institute of Computer Science and Engineering
College of Computer Science
National Chiao Tung University
ABSTRACT
Recently, the CR technology has emerged as a recent breakthrough radio technology to address the spectrum underutilization and spectrum scarcity problem by providing means to utilize the spectrum holes (i.e., unused spectrum) in an intelligent way. Therefore, this technology could facilitate efficient utilization of the radio spectrum while provide highly reliable communication for all users of the targeted wireless networks. In this research, we propose a bi-directional CR MAC protocol for the CR users (CRUs) such that the CRUs can coexist with the primary users (PUs, i.e., IEEE 802.11 users) and flexibly use the spectrum holes without affecting the performances of PUs.
The proposed bi-directional CR MAC protocol is an extension of the CR MAC protocol proposed by TakChon Lou et al. [9] and Shie-Yuan Wang et al. [10]. Although both of these previous works have dramatically improved the spectrum efficiency, their studies fail to address the protocol degradation performance in delivering TCP flows. In addition, the main limitation of their protocols is that the bandwidth allocation for the CRUs has to be done statically. Therefore, in this research, we first address the problem of the TCP performance degradation over [10] and propose a basic scheme CR MAC protocol (BBi-MAC) as a remedy. Follow on, we work on an advanced scheme of the CR MAC protocol (ABi-MAC) which possesses the ability of reserving the bandwidth dynamically according to the CRUs’ bandwidth demand. Therefore, the ABi-MAC can further well utilize the spectrum holes of an IEEE 802.11 network and support synchronous two-way traffic flows with variable packet sizes. The performances of our proposed schemes are evaluated using both mathematical
analysis and simulation. Both of the analytical and numerical results show that our proposed schemes can significantly enhance the aggregate throughputs of CRUs in an 802.11 network and dramatically improve the spectrum efficiency without degrading the performances of PUs.
Keywords: Cognitive Radio, 802.11, TCP, dynamic bandwidth allocation
iii
致謝
過去從沒想過自己會來到臺灣讀書。回顧兩年前，毅然放棄澳州大學博士候選人 的身份，決定來臺灣交通大學重新從碩士班開始裝備自己。我非常慶幸自己當初作了這 個決定。兩年的交大研究之旅雖然短暫，卻已成為我人生最重要的轉捩點。感謝指導教 授王協源老師一路來悉心的栽培及教導，讓我的研究、思考，以及解決問題的能力都逐 漸成熟。我也要感謝我的校內外論文指導委員（趙禧祿老師、伍紹勳老師以及清華大學 林華君老師）給予我的論文具有建設性的建議，使我能在畢業之際發掘自己的缺點，加 以改進，成為一個更成熟的研究者。我亦要感謝所有實驗室裡的學長學弟妹，因為你們 的陪伴，讓我在臺灣的生活增添了不少的色彩和歡笑。 另外，我特別要感謝我媽咪無私的愛、支持與體諒。感謝媽咪在爸爸去世後，仍舊 堅強的把我們四個小孩撫養成人，並悉心的栽培我們。謝謝媽咪在我升大學至現在碩士 畢業的這段漫長就學期間，成為我生活上隨時的後盾。謝謝媽咪在我做每一個大小決定 的時候，給予我許多有智慧的建議並支持。沒有您，就沒有今天的我。 我亦要感謝我的男友母親，在異地求學時非常地照顧我，給與我很多關心與生活上 的照顧，讓我在台灣也能有家的感覺。最後，我要感謝我的學長兼男友志哲。謝謝你一 路來的陪伴和指導，讓我在研究的路上，從一開始的摸索、彷徨，到如今的享受研究。 謝謝你讓我有機會來到臺灣、認識臺灣。以後將一起在這片土地上，攜手共度此生。 劉莉晶 撰於 民國一百年六月二十九日Contents
Abstract i
Acknowledgement iii
Contents iv
List of Figures vi
List of Tables viii
1 Introduction 1
1.1 Problem Description . . . 4
1.2 Dissertation Organization . . . 4
2 Background and Related Work 6 2.1 Introduction to Cognitive Radio Network . . . 6
2.2 Introduction to IEEE 802.11 Networks . . . 8
2.3 Cognitive Radio over IEEE 802.11 Networks . . . 10
2.4 Related Work . . . 11
2.4.1 Related Work I: On Synchronized Channel Sensing and Accessing for CR Users in IEEE 802.11 wireless Networks . . . 11
2.4.2 Related Work II: Enhanced MAC Protocol for Cognitive Radios over IEEE 802.11 Networks . . . 17
2.5 Problem Statement . . . 21
3 Proposed Bi-directional CR MAC Protocol 22 3.1 Motivation . . . 22
3.2.1 Motivation and Problem Elaboration . . . 23
3.2.2 Design of the BBi-MAC . . . 28
3.3 Proposed Advance Scheme of Bi-directional CR MAC Protocol (ABi-MAC) 30 3.3.1 Motivation and Problem Elaboration . . . 32
3.3.2 Design of Advance Scheme of Bi-directional CR MAC Protocol (ABi-MAC) . . . 36
4 Performance Evaluation and Discussion 51 4.1 Mathematical Analysis of the Achievable Throughputs of Uni-MAC and BBi-MAC . . . 51
4.2 Simulation Setup . . . 58
4.3 Numerical Evaluation of the BBi-MAC . . . 58
4.3.1 Simulation Results Without the Presence of PUs Traffic . . . 60
4.3.2 Simulation Results In the Presence of PUs’ Traffic . . . 63
4.3.3 Summary . . . 66
4.4 Numerical Evaluation of the ABi-MAC . . . 68
4.4.1 Simulation Settings . . . 69
4.4.2 Simulation Results of ABi-MAC . . . 70
4.4.3 Summary . . . 76
5 Conclusion 77 5.1 Final Remarks . . . 77
5.2 Future Work . . . 77
5.2.1 Cognitive Mesh Networks . . . 78
5.2.2 Cognitive Heterogeneous Networks . . . 79
Bibliography 80
List of Figures
1.1 Illustration of the Midband Spectrum Occupation . . . 1
1.2 Illustration of the Highband Spectrum Occupation . . . 2
1.3 Illustration of the Vertical and Horizontal Spectrum Sharing . . . 3
1.4 Example of the Vertical Spectrum Sharing . . . 3
2.1 Basic Operation of the CSMA/CA Protocol . . . 9
2.2 Illustration of Packets Transmission of [9] when Txop = 1 . . . 13
2.3 Illustration of Packets Transmission of [9] when Txop = 3 . . . 14
2.4 Illustration of data channel switching when a data channel is sensed busy . 15 2.5 Illustration of Hidden Terminals . . . 16
2.6 Calculation of the Availability Index (AI) . . . 18
2.7 Frame Format of the control packet REQCR . . . 19
2.8 Frame Format of the control packet GRANTCR . . . 19
2.9 Illustration of Message Exchanges on Data Channel of [10] when Txop = 2 20 3.1 Illustration of the best case of the TCP packets exchanges when Txop = 2 26 3.2 Illustration of a bad case of the TCP packets exchanges when Txop = 2 . 27 3.3 Illustration of Packets Exchanges on Data Channel of a)Uni-MAC and b)BBi-MAC, when Txop = 2 . . . 31
3.4 Illustration of Message Exchanges on Data Channel of BMAC with Bi-directional Bandwidth Reservation when Txop = 3 . . . 34
3.5 Illustration of inappropriate TI setting of BBi-MAC with Bi-directional Bandwidth Reservation . . . 35
3.6 Frame Format of the control packet REQCRof ABi-CR . . . 37
3.8 Possible values of BDsender and BDreceiver of ABi-MAC with uni-directional
heavy traffic . . . 39
3.9 Possible values of BDsender and BDreceiver of ABi-MAC with uni-directional light traffic flow . . . 39
3.10 Possible values of BDsender and BDreceiver of ABi-MAC when the traffic between a CRU pair is heavy . . . 41
3.11 Possible values of BDsender and BDreceiver of ABi-MAC when the traffic of CR receiver is heavier than that of CR sender . . . 42
3.12 Possible values of BDsender and BDreceiver of ABi-MAC when the traffic of CR sender is heavier than that of CR receiver . . . 44
3.13 Illustration of the conventional RTS-CTS two-way handshake . . . 46
3.14 Illustration of packet collisions at the CRU B due to incorrect TIrts . . . . 47
3.15 Illustration of the PUs’ right being violated due to incorrect TIrts . . . 48
3.16 Illustration of RTS-CTS-RTSe three-way handshake . . . 50
4.1 Analytical TCP Throughputs of Uni-MAC and BBi-MAC . . . 57
4.2 Analytical UDP Throughputs of Uni-MAC and BBi-MAC . . . 58
4.3 Analytical and Simulated TCP Throughputs of Uni-MAC and BBi-MAC . 60 4.4 Analytical and Simulated UDP Throughputs of Uni-MAC and BBi-MAC . 61 4.5 Aggregate TCP throughputs of CRUs over Txops (without PUs’ traffic) . . 62
4.6 Aggregate UDP throughputs of CRUs over Txops (without PUs’ traffic) . . 64
4.7 Aggregate TCP throughputs of CRUs over Txops (with PUs’ traffic) . . . 65
4.8 Aggregate UDP throughputs of CRUs over Txops (with PUs’ traffic) . . . 65
4.9 Aggregate TCP throughputs of CRUs over PU Loads . . . 67
4.10 Aggregate throughputs of PUs over PU Loads . . . 67
4.11 Aggregate throughputs of CRUs when PU load is light . . . 71
4.12 Aggregate throughputs of CRUs when PU load is medium . . . 72
4.13 Aggregate throughputs of CRUs when PU load is high . . . 72
4.14 Aggregate CRUs throughputs of ABi-MAC and Uni-MAC under different PU loads . . . 74
List of Tables
4.1 Fixed Network Parameters . . . 52
4.2 Transmission time of different types of packet . . . 53
4.3 Simulation Parameters . . . 59
4.4 Percentage of TCP Throughput Improvement of BBi-MAC as compared to
Uni-MAC . . . 68
4.5 Percentage of UDP Throughput Improvement of BBi-MAC as compared
to Uni-MAC . . . 68
4.6 Summary of Throughput Improvement of ABi-MAC as compared to
Chapter 1
Introduction
The success of wireless technology today has motivated the explosion of new wireless applications which creates an ever-increasing demand for more radio spectrum. How-ever, most of those easily accessed spectrum band have been statically allocated. This is because with the fixed spectrum allocation policies, the bandwidth spectrum used by different radio technologies are fixed and regulated by the authorities of each country (e.g., Federal Communications Commission of the United States and National Communi-cations Commission of Taiwan). Therefore, each statically allocated frequency band shall be accessed only by specific authorized users as shown in Fig. 1.1 and Fig. 1.2.
However, recent studies [1][2] have shown that under fixed spectrum allocation policies, most of the radio frequencies were inefficiently utilized. For example, from a measurement study conducted by FCC [1] in year 2002, it is found that at any given time and in any geographic locality, less than 10% of the available spectrum is being utilized. The FCC also highlighted that a large portion of the licensed spectrum is used sporadically and that geographical variations in the utilization of licensed spectrum portions oscillates from 15% to 85% with high variance in time. This report challenges for the first time the
Figure 1.2: Illustration of the Highband Spectrum Occupation
common belief of spectrum scarcity. To exploit underutilized portions of the spectrum (a.k.a., white spaces, spectrum holes and etc.), FCC recommended the deployment of wireless devices that can coexist with the licensed users (also called authorized users) to achieve a significantly greater spectral efficiency. Such findings and recommendation have motivated the search for breakthrough radio technologies that can scale to meet future demands both in terms of spectrum efficiency and application performance.
Cognitive Radios (CRs) thus emerged as a new generation of radio technology that will enable the future wireless world. CRs are smart, fully programmable radios that are capable of interference sensing, environment learning, and dynamic spectrum access. With these capabilities, a CR can adapt its transmission or reception parameters to communicate efficiently avoiding interference with licensed or unlicensed users. Therefore, it is anticipated that the CR technology can increase the bandwidth utilization of the radio spectrum in a global perspective while stimulate the deployment of new wireless applications.
The idea of CR was first presented by Dr. Joseph Mitola III [3][4] which is generally an evolved software-defined radio [5]. As compared to the software-defined radios, CR is smarter and possesses more intelligence through machine learning. The importance of this technology has been affirmed through the emergence of CR-related standards, namely the IEEE 802.22 [6] and ECMA-392 [7]. Both of these standards define the MAC and PHY operations in TV white space so that the unused TV channels can be utilized for data communications, provided that the licensed users’ operations can be protected. This type of CR is regarded as licensed band CR such that the CRs can use those spectrum bands that have been assigned to licensed users. This kind of spectrum sharing is also referred to as vertical sharing, as indicated in Fig. 1.3. CR operating in frequency bands of TV and radio broadcasts is a typical example of vertical spectrum sharing. Fig. 1.4 further
Figure 1.3: Illustration of the Vertical and Horizontal Spectrum Sharing
illustrates an example of vertical spectrum sharing such that CRs at different locations can identify different frequencies (i.e., TV frequency band I and TV frequency band II) as unused and regard them as spectrum opportunities.
Contrarily, unlicensed band CR is another type of CR which the CRs can only uti-lize unlicensed parts of radio spectrum, for example, the spectrum of the IEEE 802.11 networks. This kind of spectrum sharing is referred to as horizontal sharing as shown in Fig. 1.3. For horizontal spectrum sharing, the CRs are with limited coexistence ca-pabilities, enabling them to operate in spite of some interference from dissimilar radio
systems.
The analysis of the network traffic done by Yingxi Liu et al. [8] showed that un-saturated 802.11 networks stay idle as much as 50% of the time. This fact has hugely motivated proposals of CR MAC protocol over the 802.11 networks to form unlicensed band CR networks (CRNs). In such an 802.11 CRN, primary users (PUs) refer to 802.11 nodes authorized to use this frequency band. Contrarily, CR users (CRUs) are 802.11 nodes equipped with CRs who are unauthorized to use this frequency, hence could only access the 802.11 spectrum in an opportunistic manner without interfering with the PUs.
1.1
Problem Description
This thesis is an extension of the work done by [9] and [10]. TakChon Lou et al. [9] proposed a MAC protocol that allows CRUs to access the idle period of an IEEE 802.11 network opportunistically. Furthermore, these CRUs can flexibly abort their data transmissions once they detect that PUs intend to access the authorized frequencies. Shie-Yuan Wang et al. [10] further expanded the work done by [9] through proposing a Smart Channel Selection Scheme (SCSS) and addressing the problem of Hidden Ter-minals (HTs). Through extensive simulations, Shie-Yuan Wang et al. found that the Transmission Control Protocol (TCP) did not perform well under their extended work.
Since TCP has become that most widely used transport-layer protocol today, it is imperative that a proposed CR MAC protocol can well support TCP flows. Therefore, in this work, we first address the problem of the TCP performance degradation over [10] and propose a basic scheme of bi-directional CR MAC protocol (BBi-MAC) as a remedy. Follow on, we work on an advanced scheme of the bi-directional CR MAC protocol (ABi-MAC) with dynamic bandwidth allocation to support asymmetry two-way traffic flows.
1.2
Dissertation Organization
The remainder of this dissertation is organized as follows. In Chapter 2, we first present the related works. Specifically, we introduce the CR MAC protocol which was originally proposed by [9], then modified for better performance by [10]. Then, we address the problem of these related works in supporting TCP and bi-directional traffic flows. In Chapter 3, we explain both the proposed basic scheme and advanced scheme of
bi-directional CR MAC protocol for supporting bi-bi-directional and asymmetry traffic flows, respectively. In Chapter 4, the performances of the proposed bi-directional CR MAC protocols are evaluated using mathematical analysis and simulations and we discuss the achieved enhancements by comparing them to [9]. We finally conclude this dissertation and present our future work in Chapter 5.
Chapter 2
Background and Related Work
2.1
Introduction to Cognitive Radio Network
CR has emerged as a new design paradigm for next-generation wireless networks. It is also regarded as a recent breakthrough radio technology which can greatly increase utilization of the scarce radio spectrum (both licensed and unlicensed frequency) and to enable new wireless applications. It was observed that some frequency bands in the radio spectrum are largely unused, while some are heavily used. In particular, while a frequency band is assigned to a primary wireless system at a particular time and location, the same frequency band is unused by this wireless system in other times and locations. This results in spectrum holes (also called spectrum opportunities). Therefore, the spectrum utilization can be improved substantially by allowing secondary users, i.e., CR users, to utilize these spectrum holes.
The CR technology is evolved from the concept of Software Defined Radio (SDR) which was introduced to enhance the efficiency of frequency spectrum usage [5]. SDR improves the capability of a wireless transceiver by using embedded software to enable the radio transceiver to operate in multiple frequency bands. The CR, however, is a special type of SDR which is able to intelligently adapt itself to the changing environment. Therefore, learning and adaptation are two significant features of a CR transceiver.
In general, the major four components of a CR system includes: observation, learning, decision making and planning, and acting processes. The details of these components are elaborated as below:
and noise reduction mechanisms. It can be either passive or active. In a passive observation approach, a CRU silently listens to the environment. In contrast, in an active observation approach, a CRU measures the nearby signal level and transmits a special message. Through exchanging these special messages, CRUs can be updated on the information about the surrounding environment.
• Learning Process – This refers to the process of extracting useful information from collected data or messages. A learning process utilizes data from the observation process, and previous decisions and actions. For example, a CR sender can learn the network behavior (e.g., through interference or collision in PHY and MAC layers, respectively) to gain knowledge of the operating environment. There are two major types of learning algorithms, supervised learning and reinforcement learning. In a supervised leaning algorithm, a large set of training examples with known solutions are used to train the algorithm. This type of algorithm is more suitable for offline operation where sample data is available. On the other hand, the reinforcement learning algorithm learns by interacting with th environment. It is used when the correct solution is unknown. A reinforcement learning algorithm tries different ac-tions and observes the outcomes. The outcomes information is then used to optimize the action in the future. Because the actions through this learning algorithm can be adapted dynamically, the reinforcement learning algorithm can be used in an online manner in which the system can learn and adapt in real time.
• Planning and Decision Making Process – This refers to the process of using knowl-edge obtained from learning phase to schedule and prepare for the next transmission. If multiple choices of actions are available, a transceiver must decide to choose the best strategy to achieve the target objectives. For example, when a CR sender schedules a transmission based on the frequency usage of a PU, a decision on the transmission power needs to be made to achieve the acceptable level of interference caused to the PUs.
• Action Process – This refers to the process of responding to the environment. Gen-erally speaking, the action of a CRU is controlled by the planning and decision making process.
are dynamic spectrum allocation and opportunistic spectrum access [11]. For dynamic spectrum allocation, information on spectrum occupation is used for channel allocation and planning on a long-term basis. On the other hand, with opportunistic spectrum access, instantaneous information of channel usages by PUs is observed and CR is granted access to utilize the spectrum holes. This can effectively increase the spectrum utilization on a short-term basis. It is believed that the opportunistic spectrum access provides more agility, but at the expense of higher computational complexity.
2.2
Introduction to IEEE 802.11 Networks
The IEEE 802.11 MAC [12] has become ubiquitous and gained widespread popularity as a layer-2 protocol for wireless local area networks (WLAN). This MAC layer is re-sponsible for a structured channel access scheme and is implemented using a Distributed Coordination Function (DCF) based on the Carrier Sense Medium Access with Collision Avoidance (CSMA/CA) protocol. An alternative to the DCF is also provided in the form of a Point Coordination Function which is similar to a polling system for determining the users who have the right to transmit. In this section, we only describe the relevant details of DCF access method and refer the reader to [12] for other details on the IEEE 802.11 standard.
The CSMA/CA based MAC protocol of IEEE 802.11 is designed to reduce the collision due to multiple sources transmitting simultaneously on a shared channel. In a network employing the CSMA/CA MAC protocol, each node with a packet to transmit first senses the channel to ascertain whether it is in use. If the channel is sensed to be idle for an interval greater than the Distributed Inter-Frame Space (DIFS), the node proceeds with its transmission. In contrast, if the channel is sensed as busy, the node has to defer its transmission to prevent contention.
To do so, the node initializes its backoff timer with a randomly selected backoff interval and decrements this timer every time it senses the channel to be idle. The node is then allowed to transmit only when the backoff timer reaches zero. Since the backoff interval is chosen randomly, the probability that two or more stations will choose the same backoff value is very low. This can minimize the negative effects caused by channel contention.
Figure 2.1: Basic Operation of the CSMA/CA Protocol
(ACK) scheme. All the packets received by a node implementing 802.11 MAC must be acknowledged by the receiving MAC. After receiving a packet the receiver waits for a brief period, called the Short Inter-Frame Space (SIFS), before it transmits the ACK.
There is another particular feature of WLANs, known as the “Hidden Terminal” (HT) problem, that the 802.11 MAC specification addresses. Two stations that are not within hearing distance of each other can lead to collisions at a third node which receives the transmission from both sources. To take care of this problem, 802.11 MAC uses a reser-vation based scheme. A station with a packet to transmit sends an Ready to Send (RTS) control packet to the receiver and the receiver responds with a Clear to Send (CTS) con-trol packet if it is willing to accept the packet and is currently not busy. This RTS-CTS exchange, which also contains timing information about the length of the ensuing trans-action, is detected by all nodes within hearing distance of either the sender or receiver or both. Therefore, all of these nodes defer their transmissions till the current transmission is completed to avoid packets collision.
The basic operation of the CSMA/CA based MAC protocol of IEEE 802.11 is shown in Fig. 2.1. It shows the exchange of various packets involved in each successful transmission and the spacing between these packets.
2.3
Cognitive Radio over IEEE 802.11 Networks
Recently the Cognitive Radio (CR) technology has been applied to the ubiquitous 802.11 networks [9][10][13][14][15]. To fast respond to the dynamic uses of the authorized frequency of an IEEE 802.11 network, all of these cited works use an opportunistic spec-trum access approach to manage the channel accesses of CRUs without the control of a central unit (i.e., access point). [13][14][15] assume that CRUs can perfectly detect the end of a PU’s packet transmission.
In [13], the authors propose a novel sense-transmit-wait strategy of CR MAC protocol by considering unsaturated 802.11 networks. In their work, it is assumed that each CRU is equipped with a SDR that can detect the transmission activities of PUs and maintain the cumulative distributed function of primary network’s inter-packet arrival time. When a CRU detects that a channel is idle, it decides how long it can transmit such that the transmission time is as large as possible while the probability of collision satisfies the primary network’s quality of service (QoS) requirement.
[14] proposes an opportunistic CR MAC protocol that is able to predict the interval of spectrum holes to maximize the allowed transmission time of CRUs. Using their protocol, a pair of CRU can exchange data only if they have an available (i.e., idle) channel in common. Therefore, a handshaking process along with channel selection mechanism (on the control channel) before data transmission (on the data channel) is covered in this protocol. Similarly, it is assumed that each CRU is equipped with SDR which can provides the PUs’ information of channel utilization and average packet size in a specified time window periodically. Furthermore, each CRU also maintains a channel state table which records the system busy time. With all of these information, a CRU using the proposed opportunistic CR MAC protocol can estimate the primary utilization more accurately, thus can predict its average packet size for transmission in the next time slot.
Lastly, in [15], the proposed MAC protocol maintains a channel occupation ratio for each channel of the primary network (i.e., 802.11 network) to keep the communication quality of the primary system. The packet transmission control of the CRUs is then performed according to the channel occupancy ratios. This is done by first making a channel list in the order of the lowest channel occupancy ratio to the highest channel occupancy ratio, and then schedules the CRU’s transmissions in a probabilistic manner based on the most recent channel occupancy ratio of the selected channel.
Using the above proposals, a CRU schedules data transmissions for a variable-length interval. The length of the interval is adjusted only at the end of the previous interval. However, it is commonly known that IEEE 802.11 networks are open systems where accurate traffic prediction required by these proposals cannot be easily achieved. To address this problem, TakChou Lou et al. [9] proposed a MAC protocol that allows CRUs to flexibly abort their data transmissions when they detect that PUs intend to access the authorized frequencies. In this design, a PU has opportunity to advertise its intention of claiming the channel through broadcasting RTS and CTS control messages during the periods which CRUs are silent.
Although the MAC protocol in [9] provides scheduling flexibility for CRUs to prevent their transmissions from interfering with PUs’ transmission, its channel selection algo-rithm is inefficient for CRUs to quickly find an available channel to use. In addition, this protocol does not consider the impacts of HTs on network performances. To solve this problems, Shie-Yuan Wang et al. [10] further expanded TakChou Lou et al.’s work to address the above issues. They proposed 1) a Smart Channel Selection Scheme to reduce the time required by CRUs in finding an idle 802.11 channel for data transmission, and 2) an enhanced data transmission and channel evacuation approach to solve the HT prob-lems. Through extensive simulations, although [10] can effectively improve the overall bandwidth utilization as compared to [9], it is found that TCP flows did not perform well under [10].
2.4
Related Work
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.
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.
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.
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
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].
2.5
Problem Statement
Through both the proposed enhancements by [10], it is proven qualitatively through simulations that the overall bandwidth utilization of [10] outperforms [9]. However, when the TCP performance is compared against the UDP performance, it is found that the TCP flows obtained a low aggregate throughputs.
After a detailed study and investigation, we revealed that the TCP flows remained to perform poorer than that in conventional 802.11 networks even when PUs are absent in the CRN. A possible explanation for this finding is as follow: In [10], every successful
bandwidth negotiation procedure (i.e., exchange of REQCRand GRANTCR control
pack-ets) only reserves a one-way bandwidth for the CR sender to transmit a maximum of Txop packets. This protocol works fine when the considered traffic type is uni-directional, i.e., one-way UDP flow. However, in the presence of bi-directional traffic, such as TCP flows with reverse ACKs, the performance of this protocol was degraded due to its inadequate support to reserve bi-directional bandwidth.
Since TCP is the most widely used transport-layer protocol over the internet, it is imperative to design a CR-MAC protocol which can well support TCP flows. Therefore, in the following chapter, we first propose a basic scheme of bi-directional CR MAC protocol to overcome the limitation of [10] in supporting traffic flows with bi-directional packets, particularly the TCP flows. Next, we propose an advanced scheme of bi-directional CR MAC protocol which can dynamically reserve a short-term bandwidth for the CRU pair to carry asymmetry traffic flows. For brevity, in the following chapters, we denote the MAC protocol in [10] that favors the uni-directional traffic as “Uni-MAC”, the proposed basic scheme of bi-directional CR MAC protocol as “BBi-MAC” and the proposed advanced scheme of bi-directional CR MAC protocol as “ABi-MAC”.
Chapter 3
Proposed Bi-directional CR MAC
Protocol
3.1
Motivation
In Section 2, we have explained the CR MAC protocol which was originally proposed by by [9] and later enhanced by [10]. Although both of these related works have dra-matically improved the spectrum efficiency, their studies fail to address the performance degradation of their protocols in delivering internet applications with the characteristics of bi-directional packets transmission and variable packet sizes. The most common exam-ples of such internet applications include FTP flows which are transported through TCP and bi-directional UDP flows to carry conversational VoIP calls.
In addition, the main limitation of their protocols is that the short-term bandwidth allocation for the CRUs has to be done statically. Another way of saying, the bandwidth allocation for these previous works depends on a pre-defined network parameter, denoted as Transmission Opportunity (Txop), such that during every successful channel access, a CRU is permitted to transmit only a maximum of Txop packets. This, however, limits the protocol performance as the network traffic varies with time and therefore a fixed bandwidth allocation may not be able to meet the instantaneous traffic demand of CRUs optimally.
Therefore, we propose a bi-directional CR MAC protocol which is an extension of the CR MAC protocol proposed by [9] and [10]. In this proposal, we divide the development into two phases. In phase one, we focus on the basic scheme of bi-directional CR MAC
protocol (BBi-MAC) to better support TCP flows and bi-directional UDP flows. In phase two, we work on an advanced scheme of bi-directional CR MAC protocol (ABi-MAC) with short-term and smart dynamic bandwidth allocation.
3.2
Proposed Basic Scheme of Bi-directional CR MAC
Protocol (BBi-MAC)
3.2.1
Motivation and Problem Elaboration
The main idea of the proposed BBi-MAC is to better support traffic flows with bi-directional packets transmission, particularly the TCP flows and bi-bi-directional UDP flows such as conversational VoIP calls. To this end, we define two-way or bi-directional traffic as the traffic pattern resulting from: 1) one or more TCP connections transferring data between a CRU pair, 2) two or more UDP connections transferring data in opposite directions between a CRU pair, and 3) a combination of at least a TCP flow and at least an UDP flow between a CRU pair.
It is commonly known that for TCP flows, a congestion control mechanism is employed. The essence of this congestion control mechanism is the observation that data packets arrive at the receiving host at the rate that the bottleneck link will support. 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 send-ing more data than the network can accept, which could led to congestion and loss of efficiency. 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.
In addition, the throughput of a TCP flow could also be affected by its round-trip time (RTT). The RTT is the time between when a TCP data is being put on the wire and when its corresponding ACK is received. In TCP connections, every TCP receivers keeps a Receive Window (RWIN), which refers to the amount of data that the TCP receiver can accept without acknowledging the TCP sender. On the other hand, a TCP sender can transmit data up to the window size before waiting for the TCP ACKs. The TCP throughput T limitation caused by the TCP window size can then be calculated as follows:
T ≤ RW IN
RT T . (3.1)
In most of the system, the RWIN has a default size of 64KBytes. Therefore, it is obvious that when the RWIN is fixed, the variation of RTT can affect the TCP throughput. A smaller RTT can increase the maximum achievable throughput while a large RTT can decrease the TCP throughput.
From detailed observation, we have identified the occurrence of ack-compression effect in the Uni-MAC in transmitting TCP flows. Also, it is found that the RTT time of a TCP packet becomes longer due to the protocol design. These observations are further elaborated as follow.
Consider a CRN with only a single pair of CRUs, transmitting a TCP flow from CRU A to CRU B, and the Txop being set to two. As explained earlier, TCP’s self-clocking depends on the arrival of TCP ACKs at the same spacing with which the receiver generated them. This desire same spacing of TCP ACKs, however, is broken in the Uni-MAC as proposed by [10].
With the Uni-MAC, when the TCP data are transmitted, the TCP ACKs could not be replied immediately due to only one-way bandwidth reservation by the protocol. Instead, the TCP sender first sends Txop TCP data packets consecutively. After that, both CRU A and CRU B return to the control channel. At this time point, since both the CRUs have packets in queue to be transmitted (TCP data for CRU A and TCP ACK for CRU B), both of them have to compete for the next chance of bandwidth negotiation, i.e.,
transmitting an REQCR.
In the Uni-MAC, to ensure that the control channel is accessed fairly by the CRUs, every CRU has to defer for a random waiting duration (RWD), which is a factor of SIFS,
before it is allowed to transmit an REQCR. Such a design gives every CRUs an equal chance
to be a CRU sender. In the best case, the CRU B (denoted as TCP receiver hereafter) may defer for a shorter RWD as compared to CRU A (denoted as TCP sender hereafter).
Therefore, it will get a chance to transmit an REQCR before the TCP sender and switch
its role to be a CR sender. After a successful REQCR/GRANTCRhandshake at the control
channel and obtaining the channel access at the pre-negotiated data channel, the TCP receiver can transmit its accumulated TCP ACKs after some standard procedures.
The resulting TCP transmission sequence of the best case as elaborated above is shown in Fig. 3.1. However, one can see that such data transmission sequence is not favorable because it breaks the TCP self-clocking nature due to the ack compression effect. When this happens due to the deficiency of the protocol design, the TCP sender has to tune the interval it sends TCP data and thus degrades the TCP transmission rate.
In an unpreferable situation, the TCP sender may get a shorter RWD continuously as compared to the TCP receiver as shown in Fig. 3.2. Worst of all, this might happen repeatedly until the TCP sender has used up its TCP window size and thus can only transmit the next TCP data after it receives a TCP ACK. Therefore, the TCP sender will no longer compete for the next chance of bandwidth negotiation and provides the
TCP receiver a full opportunity to transmit an REQCR control packet after a RWD. As
a consequence, the TCP receiver could transmit the accumulated TCP ACKs only some time later and this results in a more severe TCP ACKs compression and degrades the TCP throughput drastically.
The TCP performance degradation problem will be further deteriorated if the con-sidered network consists of some other CRUs and PUs which are also competing for the bandwidth. In this situation, the TCP ACKs compression problem will get even more severe because (i) The TCP sender has to compete with others CRUs for the bandwidth negotiation on the control channel. Therefore, its chances of immediately transmitting
an REQCR becomes slimmer; and (ii) Even if the TCP sender has completed the
hand-shaking procedure with the TCP receiver and both have switched to the data channel, it might not be able to get an immediate chance of packet transmission if PU’s activities are sensed on that channel. Combination of these two factors can further prolongs the time between a TCP data is sent and the corresponding TCP ACK is received, i.e., the RTT.
3.2.2
Design of the BBi-MAC
To address the problem as elaborated in Section 3.2.1, the BBi-MAC is designed to reserve bandwidth according to the anticipated traffic type. In BBi-MAC, the control
packets, i.e., REQCR and GRANTCR are extended with additional 2-bit field. This
ex-tended field is named as Reservation Type (RT), which serves as an indicator for a CRU pair to reserve the bandwidth either uni-directionally or bi-directionally. Before
send-ing an REQCR or a GRANTCR, a CRU always scans its head of queue (HOQ) to check
whether there is any packet to be transmitted. If there is, the CRU first identifies the packet type and then fills in the RT field according to the principles as explained below.
As a CR sender, before transmitting an REQCR, if an UDP packet is identified as the
HOQ, the CR sender first assumes a uni-directional traffic from itself to the CR receiver.
In this case, it fills the RT of the REQCR(denoted as RTreq hereafter) with a value of 00
to indicate a single-way bandwidth reservation. In contrast, if the HOQ is a TCP packet, the CR sender would automatically assume a bi-directional traffic.
Such an assumption is valid because TCP is a reliable stream delivery service that guarantees delivery of a data stream through a technique known as positive acknowledg-ment with retransmission. This fundaacknowledg-mental technique requires the receiver to respond with a TCP ACK as it receives the data. Therefore, if a TCP flow is initiated by the CR sender, it is reasonable to anticipate a bi-directional traffic. In this case, it fills the
RTreq with a value of 01 to indicate a two-way bandwidth reservation. Once the RTreq is
determined, the REQCR is transmitted over the control channel after the RWD.
As a CR receiver, upon receiving the REQCR, it first checks if it has any queued
packets destined to the REQCR sender. If the queue is non-empty, apparently a
two-way bandwidth reservation is necessary so that both the nodes have the opportunity to transmit the queued packets once they successfully gain access to a data channel. In this
case, the RT field of the GRANTCR(denoted as RTgrt hereafter) is filled with a value of
10 which indicates that the CR receiver is demanding a reverse bandwidth reservation. In
contrast, if the queue is empty, the CR receiver simply copies the value of RTreq to RTgrt.
Finally, a GRANTCR is sent to the CR sender after the RTgrt and CHS are determined.
Upon receiving a GRANTCR, the CR sender performs a final check on the RTgrt value
to determine the bandwidth reservation type. In general, a single-way bandwidth
reservation would be performed by the CR sender if the RTgrt is filled with either 10 or
01.
On the data channel, the transaction interval (TI) to be filled in a transmitted RTS control packet is decided based on the bandwidth reservation type. In the basic scheme, we only consider a simple network case with either a TCP flow or bi-directional UDP flows with a uniform packet size between a CRU pair. With a single-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
RTgrt value. If the RTgrt is filled with 10, a TCP flow is anticipated. Therefore, the TI
will be set to a duration which is adequate for transmitting a TCP data, a TCP ACK and
two 802.11 ack packets. Alternatively, if the RTgrt 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.
In addition to differentiate the bandwidth reservation types through the exchanges of CR-related control packets, we also eliminate the transmission of SUS control packets in the BBi-MAC. Since the Txop is a fixed network parameter, the CRUs should always keep track of the number of transmitted or received packets whenever they are on the data channel. After every successful 802.11 ack packet reception (transmission), the CR sender (CR receiver) should automatically enter the QP if the recorded number of transmitted (received) packets is less than Txop. If the number of transmitted (received) packets is equal to the Txop, the CR sender (CR receiver) should return to the control channel immediately after it receives (transmits) an 802.11 ack packet. With this modification, the BBi-MAC can further reduce the overhead caused by transmitting the SUS control packets on the data channel.
Fig. 3.3 illustrates the packets exchanges on a data channel of Uni-MAC and BBi-MAC when the Txop is being set to two. In this example, we only consider a simple network topology with a CRU pair such that the CR sender is sending a TCP flow to the CR receiver. Fig. 3.3(a) depicts the packets exchanges of the CRU pair using the Uni-MAC under the best case scenario as elaborated in Section 3.2.1. Using the Uni-MAC, one can see that the TCP ACK cannot be replied immediately due to the one-way bandwidth
reservation. Instead, a TCP receiver could only reply the accumulated TCP ACKs only after going through a sequence of the following actions:
1. The TCP sender has transmitted Txop TCP data. 2. The CRU pair return to the control channel.
3. The TCP receiver has deferred for a RWD time period.
4. The TCP receiver has transmitted an REQCRand completed the handshaking
pro-cedure with the TCP sender.
5. The CRU pair switch to the data channel as pre-negotiated. 6. The data channel is sensed idle by the CRU pair.
7. The TCP receiver has completed the RTS-CTS handshake with the TCP sender. 8. Finally, the TCP receiver can transmit Txop TCP ACK.
Obviously, such a long sequence of inevitable actions in the Uni-MAC can cause an undesirable delay to the TCP ACKs and thus prolong the average RTT of a TCP flow. From the figure, one can see that even in the best case scenario, the RTT of a TCP data is several times larger than that using the BBi-MAC.
In contrast, due to the design of two-way bandwidth reservation when a TCP flow is detected, Fig. 3.3(b) shows that the BBi-MAC has effectively shorten the RTT of a TCP data. Therefore, it is believed that through the proposed BBi-MAC, better support can be offered to both uni-directional and bi-directional traffic flows in a CRN, particularly the TCP flows.
3.3
Proposed Advance Scheme of Bi-directional CR
MAC Protocol (ABi-MAC)
The main idea of the proposed ABi-MAC is to allocate bandwidth to the CRUs in a more dynamic manner. To this end, we propose a Dynamic Bandwidth Allocation (DBA) algorithm, which can reserve bandwidth to the CRU pair dynamically based on the queue status. With this proposed design, the ABi-MAC not only can support a more
Figure 3.3: Illustration of Packets Exchanges on Data Channel of a)Uni-MAC and b)BBi-MAC, when Txop = 2
complicated network cases, i.e., network with asymmetry two-way traffic with variable packet sizes, but also offers a better protection to both the CRUs and PUs. Also, the ABi-MAC can further utilize the “spectrum holes” in a more effective way and provide a better QoS to the CRUs in a CRN.
3.3.1
Motivation and Problem Elaboration
In Uni-MAC and BBi-MAC as elaborated in Section 2.4.2 and Section 3.2, Txop is adopted as a fixed network parameter. In Uni-MAC, Txop is defined as the number of packets that could be transmitted by a CR sender once it gains access to the data channel. In BBi-MAC, the definition of Txop is slightly ambiguous. Depending on the types of bandwidth reservation, the Txop is defined as:
• Uni-directional bandwidth reservation: The number of packets that could be trans-mitted by a CR sender once it gains access to the data channel.
• Bi-directional bandwidth reservation: The number of transmission turns for the CRU pair. For example, if Txop is set to a value of two, logically after every RTS/CTS handshake, CR sender and CR receiver each is given a transmission turn for sending a packet. However, if the queue of the CR receiver is empty during its turn, it could simply bypass its turn of packet transmission. When the timers expire, both the nodes will enter the QP. This shall be continued until they finish their Txop-th transmission turn.
Although the BBi-MAC gives flexibility for different bandwidth reservation types, the fixed value of Txop limits the protocol’s performances. Generally, a small value of Txop should be adopted when the network is busy and a large value of Txop is preferable when a network stays idle most of the time. However, since the network traffic varies across time, it is impossible for a pre-defined Txop to optimize the network throughput all the time.
In particular, a fixed value of Txop could affect the protocol’s performances in two ways. Firstly, when the Txop is set to a small value, i.e., one, it is considered as an appropriate setting when the network is in a busy condition. This is because with such setting, every CRU is given only one chance of packet transmission and after the packet
transmission it has to return to the control channel. Therefore, the PUs are given more chances to use the channel, especially when the CRUs are away from the data channel.
However, when the network is in an idle status, the protocol can result in a very high overhead if the Txop = 1 is set to a value of one. This high overhead is caused by the time wasted when (i) the CRU pair return to the control channel and repeat the bandwidth negotiation procedure by exchanging CR control messages and (ii) the CRU pair switch to the data channel, sense the channel for a pre-determined sensing period, and exchange the RTS and CTS control packets before the data transmission can formally take place. Therefore, this high overhead could severely limit the protocol’s performance in terms of the achievable maximum throughput.
Secondly, when the Txop is set to a large value, i.e., four, it is a suitable setting when the network is in an idle condition. With such setting, a CRU pair spend a longer time on the data channel for possible packets transmission. Furthermore, because of this protocol design, the PUs are still given chances to claim the channel when the CRUs enter the QP. However, when bi-directional bandwidth reservation is considered, overhead could be incurred when either one side of the CRU has no packet to send on their transmission turn.
Fig. 3.4 illustrates the message exchanges of a CRU pair on a data channel. They are operating using the BBi-MAC with bi-directional bandwidth reservation and the Txop is being set to a value of three. We consider a network scenario such that the CRU pair are transmitting asymmetry traffics (i.e., packets with variable sizes) over the CRN. One can see that initially both the CRUs have packets in queue to be transmitted. However, after the first transmission turn, the queue of the CR receiver becomes empty and re-mains empty even until the beginning of its second transmission turn. In this case, both the CRUs have to wait for a reasonable duration before their timers expire and both synchronously enter the QP. Obviously, the time spent waiting for the timers to expire has resulted in inevitable overheads and this negative impact might deteriorate if the CR sender remains to have an empty queue until its Txop-th transmission turn.
Such an undesirable phenomena not only increases the protocol overhead, but could also severely affects the PUs’ performances. The reason is explained as follow: The BBi-MAC is designed to carry either one TCP flow between a CRU pair or two UDP flows of opposite directions and with uniform size between a CRU pair. As such, in BBi-MAC the
Figure 3.4: Illustration of Message Exchanges on Data Channel of BMAC with Bi-directional Bandwidth Reservation when Txop = 3
Figure 3.5: Illustration of inappropriate TI setting of BBi-MAC with Bi-directional Band-width Reservation
TI to be carried in the RTS control packet is determined solely based on the RTgrt value
as elaborated in Section 3.2. However, when a CRU pair with asymmetry traffic flows are operating over the BBi-MAC, it is very likely that the situation as illustrated in Fig. 3.5 could happen.
Fig. 3.5 illustrates the negative impact which is caused by the TI setting in BBi-MAC when bi-directional bandwidth reservation is considered. In this example, the HOQ of the CR sender is an UDP packet with a size of 1450 Bytes. Also, the CR pair has reached a common agreement that a bi-directional bandwidth reservation is necessary because the CR receiver has a non-empty queue. With the current design of BBi-MAC, when
transmitting an RTS control packet, the CR sender automatically sets its TI (TIrts) to
a duration which is adequate for transmitting two UDP packets of 1450 Bytes and two 802.11 ack packets.
From the figure, it is apparent that such an inappropriate TI setting can result in a negative impact when the traffic between the CR pair is asymmetry. This is because when others station, particularly the PUs, listen to the wireless medium and read the
TIrts as transmitted by the CR sender, they will set their NAV such that they know how
long they must defer from accessing the medium. However, with asymmetry traffics, it is very likely that the CR receiver would send an UDP packet with smaller size (e.g., 200 Bytes) as illustrated in this figure. As a consequence, even when the CRU pair have finished their transmission turn and entered the QP, the PUs are still not able to claim the wireless channel because they are still in the process of deferring. From the continuous and
overlapped portion of TIrts for first and second transmission turn as shown in the figure,
one can see that the channel is being monopolized by the CRU pair “un-intentionally”. The same case happens when the CR receiver is running out of packets for the CR receiver, as shown in the CR receiver’s second transmission turn 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 overheard TIrts.
In either cases as elaborated above, the good intention of CRU pair entering the QP has been wasted because it does not provide the PUs any opportunity to claim the channel. Furthermore, one can see that eventually the CRU pair monopoly the data channel until they finish the Txop-th transmission turn. This is an undesirable situation which could severely affect the PUs’ performances. This is because in the occurrence of such situations, the PUs could possibly grab the channel only after the CRU pair return to the control channel.
3.3.2
Design of Advance Scheme of Bi-directional CR MAC
Protocol (ABi-MAC)
To address the two major deficiencies of BBi-MAC as unfolded in Section 3.3.1, in this section we propose an ABi-MAC, which serves as an extension of the BBi-MAC. The objective of the ABi-MAC is to better support the CRUs with asymmetry traffics, subjected that the PUs’ performances are protected. We further divide the design of
Figure 3.6: Frame Format of the control packet REQCR of ABi-CR
ABi-MAC into two phases as elaborated below.
Phase 1: Dynamic Bandwidth Assignment (DBA)
In phase one of the ABi-MAC, we propose a DBA such that the CRUs are not bounded to transmit only a pre-defined Txop packets. To this end, we define several new variations
of Txop, namely MAX P ACKET , bandwidth demand of CR sender (BDsender ) and
bandwidth demand of CR receiver (BDreceiver). Similarly, the MAX PACKET is a
pre-defined network parameter. However, instead of representing the number of packets that can be transmitted by each CRUs, it refers to the maximum number of packets that is allowable to be transmitted by a CRU pair when both CRUs are on the data channel.
On the other hand, the BDsender and BDreceiver refer to the number of packets to be
transmitted by the CR sender and CR receiver, respectively.
Considering that a CRN may carry asymmetry traffic flows between a CRU pair, the
values of BDsenderand BDreceiver are dynamically decided during the bandwidth negotiation
procedure on the control channel. Therefore, the determination of BDsender and BDsender
can reflect the instantaneous queue condition of the CRUs.
In the ABi-MAC, BDsender and BDreceiver are carried in the CR-related control
pack-ets, i.e., REQCR and GRANTCR, respectively. To this end, we replace the 2-bit field of
Reservation Type (RT) in BBi-MAC with a 5-bit field of BDsender or BDreceiver, as shown
in Fig. 3.6 and Fig. 3.7, respectively. With the allocation of 5-bit field, each CRUs can request up to a maximum of 31 transmission opportunities. The remaining three bits are left unused for possible future extension.
The DTA of ABi-MAC operates in the following way. Firstly, we assume that a CR
sender maintains a separate queue for every CR receiver. Before sending an REQCR,
the CR sender has to scan through its queue to identify the number of packets to be
transmitted for a specified CR receiver. This information is treated as the value of BDsender
![Figure 2.3: Illustration of Packets Transmission of [9] when Txop = 3](https://thumb-ap.123doks.com/thumbv2/9libinfo/8377415.178016/24.892.113.833.115.416/figure-illustration-packets-transmission-txop.webp)
![Figure 2.9: Illustration of Message Exchanges on Data Channel of [10] when Txop = 2](https://thumb-ap.123doks.com/thumbv2/9libinfo/8377415.178016/30.892.149.786.115.414/figure-illustration-message-exchanges-data-channel-txop.webp)
