Shie-Yuan Wang, Po-Fan Wang, and Pi-Yang Chen Department of Computer Science
National Chiao Tung University, Taiwan Email: {shieyuan, bfwang, bychen}@cs.nctu.edu.tw
Abstract—In this paper, we optimize the performance of a cloud platform to effectively support cooperative spectrum sensing in a cognitive radio (CR) cloud network. This cloud uses the Apache Hadoop platform to run a cooperative spectrum sensing algorithm in parallel over multiple servers in the cloud. work, we first measured the execution time of such an algorithm over our own cloud and the Amazon EC2 public cloud, using the original Hadoop platform design and implementation. We found that the original Hadoop platform has too much fixed overhead and incurs too much delay to the cooperative spectrum sensing algorithm, which makes it unable to update the primary user database in just a few seconds. Therefore, we studied the source code and the design and implementation of the Hadoop platform to improve its performance. Our experimental results show that our improvement of the Hadoop platform can significantly reduce the required time of the cooperative spectrum sensing algorithm and make it more suitable for large-scale CR networks.
I. IN T RO D U CT I O N
Recently, the concept of cognitive radio (CR), which was first introduced by Joseph Mitola III [1], has become more and more popular and important due to the limitation of wireless bandwidth. In [2], the authors show that the usage of licensed spectrum is less than 25%, which is very inefficient. In a CR network, the secondary/unlicensed users (SUs) are allowed to use the empty spectra in frequency, time and space under the constraints of not interfering with the primary/licensed users (PUs). The CR approach has a great potential to improve the utilization of licensed spectrum.
The Federal Communication Commission (FCC) of the U.S. has approved unlicensed radio transmitters to operate in the broadcast television spectrum at locations where that spectrum is not being used by licensed services (this unused TV spectrum is often termed as ”white spaces” ) [3] and has granted field trials of CR networks. With this opportunity, many international organizations have defined CR standards on TV white spaces (TVWS), such as IEEE 802.22, IEEE 1900, IEEE 802.16m and ECMA 392.
To avoid a SU from interfering with the signal quality of TV sets, the FCC requires that CR operators in TVWS be
should also provide a database that maintains the geographical locations of TV base stations (BS) and their radiation powers, antenna heights, and numbers of channels, etc. To help achieve these goals of spectrum sensing in TVWS, the SUs of a CR network in TVWS are suggested to provide their sensing data and geographical locations for the CR operators to perform cooperative spectrum sensing. Cooperative spectrum sensing will reconstruct the power propagation map (PPM) and peri- odically update the PPM in a database.
A SU may operate either as a Mode I device (which operates only on the channels identified by either a fixed device or a Mode II personal/portable device) or as a Mode II device (which relies on geo-location and database access to determine available channels at its location) [3]. Due to the variation of time and space, TV sets and wireless microphones may occasionally be turned on to use the TV spectrum that was previously unused. If the SUs and database cannot quickly discover that PUs have become active and are using their al- located spectrum, a severe interference between PUs and SUs might occur. FCC requires that a Mode II personal/portable more than 100 meters from the location where it lastly checked into the database, a reconfirmation to the database is required.
A Mode I device has to check the availability of spectrum every 60 seconds through Mode II devices. The above rules are set up for avoiding the interference between PUs and SUs.
The information of PUs database plays a very important role in the TVWS CR network. The reconstruction of PPM and the update of PUs information in the database must be done as fast as possible. Real-time updates of the PPM database based on periodic sensing data from SUs can greatly reduce the interference between PUs and SUs.
In [4], the authors proposed a Cognitive Radio Cloud Network (CRCN) architecture to address the needs of a CR network. Their cloud used the public Windows Azure cloud as the computing platform to execute the spectrum sensing (SS) algorithm. They implemented the sparse Bayesian learning (SBL) [5] algorithm for cooperative SS using a MapReduce- like method over the SQL Azure and Windows Azure. Since
附錄四
To appear in IEEE WCNC 2012, 1-4 April 2012, Paris, Francethe order of 3 by the number of SUs, they implemented a hierarchical parallelization method with Microsofts dotNet 4.0 using a MapReduce-like programming model to reduce the execution time.
Despite their efforts, their experimental results show that when the measurement rate is 0.15 (their definition of mea- surement rate is the number of SUs divided by the region in units of K m2 ), the SBL algorithm still needs 24.5 seconds to finish over Window Azure, which is far from meeting the real- time requirement of a CR network. Therefore, in this paper we focus on reducing the execution time of the SBL algorithm to only a few seconds to make the CR approach more effective.
To do so, we improved the design and implementation of the Apache Hadoop platform [6] and had successfully reduced the execution time of the SBL algorithm to only 5.89 seconds under the 0.15 measurement rate.
The rest of the paper is organized as follows. In section II, we briefly introduce Hadoop, the reason why we chose to use it as the CRCN computing platform, and the problem we encountered with it. In section III, we present our study results about Hadoop and propose solutions to these encountered problems. Experimental settings are presented in section IV and various experimental results are then presented in section V. Finally, we conclude the paper in section VI.
II. US I N G HA D O O P F O R CRCN A. Background
Hadoop is an open source project composed of Hadoop MapReduce, an implementation of MapReduce designed for large clusters, and Hadoop Distribution File System (HDFS), a file system that provides high-throughput access to application data. It allows users to process a large data set with distributed processing without fully knowing the knowledge of distributed computing and without using expensive computing servers.
Hadoop is compatible with Hadoop database (HBase) [7], which can perform random, real-time read/write accesses to Big Data. HBase is suitable for the CRCN database, which needs to store a very large number of sensing data from SUs.
A Hadoop system consists of a single master node and many worker nodes. The master, called the Job-Tracker, is responsible for accepting jobs from clients, dividing a job into tasks, and assigning these tasks to worker nodes to execute them. Each worker runs a Task-Tracker process that manages the execution of the tasks currently assigned to that worker node. Each Task-Tracker has a fixed number of slots for executing tasks (there are two map slots and two reduce slots by default).
A Hadoop job consists of two major phases, the map phase and the reduce phase. Each phase has key-value pairs as input and output and the types of key-value pairs may be chosen by the user. The user also specifies the map function and the reduce function that perform the data processing work defined by the user.
1) Map: Each map task (mapper) is assigned a portion of the input file called a split. By default, a split contains a single HDFS block (64 MB by default). A mapper will read
the task’s split from HDFS, parse it into records (key/value pairs), process the records by the user-defined map function, and then generate intermediate data as the input of the reduce tasks. After all of the input records have been processed by the user-defined map function, the mapper generates its final output. The mapper then registers the final output with the Task-Tracker. Finally, the TaskTracker informs the Job-Tracker that the map task has been finished.
2) Reduce: The execution of a reduce task (reducer) is divided into three phases:
I) The shuffle phase: In this phase, a reducer fetches its
II) The sort phase: In this phase, a reducer groups together the records from each mapper’s output with the same key to form a list of values headed by the same key.
III) The reduce phase: In this phase, a reducer applies the user-defined reduce function to each key and its corresponding list of values. The output of the reduce function is written to a temporary location on HDFS.
After the reduce function has been applied to each key in the reducer’s partition, the reducer’s HDFS output file is atomically renamed and moved from its temporary location to its final location.
B. Why Using Hadoop for CRCN
In a CRCN, the execution time of the SS algorithm on the cloud determines the delay of updates of the PPM database of PUs. To make the CR approach effective, the execution time of the SS algorithm must be as small as possible to reflect the activities of PUs in real time. Table I shows the execution time of the SS algorithm reported in [4]. The machine that they used was Windows Azure large instance (See the machine specification information in Table II). One can see that the execution time of the SS algorithm under higher measurement rates is still very large. The measurement rate is defined as the number of SUs divided by the region in units of km2 . As the measurement rate grows, the correctness of the PPM database increases. However, one can see that the execution time grows very fast as the measurement rate grows due to the O(n3 ) complexity of the SS algorithm. These execution time results are only for a small 60 (Km) by 60 (Km) region. For a real-world large region, the execution time of the SS algorithm will grow up further and needs a parallel computing platform to reduce it. To achieve this goal, we decided to use Apache Hadoop to build our own cognitive radio cloud to reduce the execution time of the SS algorithm.
We chose Hadoop as the computing platform of CRCN for the following reasons:
1) Hadoop is a mature and reliable platform. It is widely used and supported. For example, Amazon EC2 cloud
Computer instance size CPU RAM Storage IO
Measurement Rates 0.05 0.075 0.1 0.125 0.15
Execution time 6.5 8.9 12.5 14.6 24.5
TABLE II
3) Hadoop is an open-source project. Thus, one can study its source code and change its internal design and imple- mentation to meet one’s special requirements.
With Hadoop MapReduce, one can easily use the region- division method to run the SS algorithm in parallel. However, we found that the fixed overhead of Hadoop is always greater than 20 seconds, which means that no matter how small the data set is, any program running on Hadoop always needs 20 seconds or more to finish. This is a very serious problem when one wants to use Hadoop to run a SS algorithm in real time for CRCN. To overcome this problem, we studied the Hadoop source code to realize how a job is processed over Hadoop and successfully found methods to reduce its fixed overhead.
In the following, we describe our discoveries and solutions.
III. IM P ROV E M E N T S MA D E TO HA D O O P will issue a setup-task request to a Task-Tracker that has a free slot for execution. A setup task will be created to initialize the environment for the job, which includes creating a temporary output directory for the job. Once the setup task is completed, the state of the job is switched to the RUNNING state.
2) Map and Reduce Step: After the setup task is finished, the Job-Tracker starts assigning tasks to a Task-Tracker. The Task-Tracker sends a heartbeat message periodically to the Job-Tracker informing the Job-Tracker that the Task-Tracker is still alive. A heartbeat message also contains the information that indicates whether the Task-Tracker is ready to run a new
Fig. 1. The Heartbeat Design in Hadoop
return message to assign it a new task for execution. Fig. 1 shows the heartbeat design in Hadoop.
3) Cleanup Step: This step is used to clean up the job environment after a job has completed. For example, the temporary output directory created during the job execution should be removed after the job is completed. Job cleanup is done by a separate task at the end of the job. A job will be declared SUCCEEDED, FAILED, or KILLED after the cleanup task completes.
B. Main Sources of Hadoop Fixed Overhead
We found that the major sources of the Hadoop fixed overhead come from 1) Heartbeat interval, 2) Reduce sleep time, and 3) Commit sleep time. In the following, we explain these sources in details.
1) Heartbeat Interval: If we consider a small job that is processed by only 1 map task and 1 reduce task, the job execution flow in Hadoop is as follows:
1. The Job-Tracker receives a job submission and issues a setup-task request within a heartbeat return message to a Task-Tracker.
2. The Task-Tracker executes and completes a setup task and then reports to the Job-Tracker in its next heartbeat.
3. The Job-Tracker then asks the Task-Tracker to start a map task right after the completion of the setup task via a heartbeat return message.
4. The Task-Tracker completes the map task and reports to the Job-Tracker in its next heartbeat.
5. The Job-Tracker then asks the Task-Tracker to start a reduce task right after the completion of the map task via a heartbeat return message.
6. The Task-Tracker completes the reduce task and reports to the Job-Tracker in its next heartbeat.
7. The Job-Tracker then asks the the Task-Tracker to start a cleanup task right after the completion of the reduce
As one can see in the above execution flow, the Job-Tracker
Default sleep time = 5 sec Modified sleep time = 0.05 sec
Execution time (secs) Execution time (secs)
heartbeat to inform it that the Task-Tracker has a free slot for execution. Also, the Task-Tracker reports the completion of a task to the Job-Tracker only through the periodic heartbeats, which means that if a task’s execution time (assuming it is 1 second) is smaller than the default heartbeat interval (which is 3 seconds), the Task-Tracker will sit idle in the remaining
Therefore, in this example case, one will waste 8 seconds (i.e., 2 seconds ∗ 4) doing nothing in the heartbeat periods. If one wants to run a real-time job such as the SS algorithm in CRCN, the 8-second latency is a very large fixed overhead. estimated result. There are two parameters of a Pi job. The first one specifies the number of map tasks while the second one specifies how many sample points a map task should generate.
Because the Pi job is a very small job needing very little computing time, we ran it to measure the fixed overhead of Hadoop. Table III and Fig. 2(a) show that, after we reduce the heartbeat interval from the default 3 seconds to 0.05 second, the execution time of a small job can be reduced by 11 seconds on average. The specification of the machine used for this Pi experiment is listed in Table VII under the “Our own machine”
column. Hadoop can be further reduced by about 1 second. Table V and Fig.3(a) show the execution time of the Pi job under different settings of this parameter.
TABLE V
EX E C U T I O N TI M E O F PI U N D E R DI FF E R E N T CO M M I T SL E E P
TI M E
2) The Sleep Time of A Reduce Task: In addition to the heartbeat interval, we also found that when a reduce task starts up, it polls the intermediate results generated by the map tasks that have completed. If a reduce task finds that there is no result to collect, it will sleep 5 seconds and then try the polling again. Using 5 seconds as the default sleep time is for saving the number of polling in a large job. This is because in such a job a map task may take tens of minutes or even hours to finish and it is reasonable that a reduce task uses a large sleep time between polling the output of map tasks. However, when a job can be effectively parallelized to make the computing time of a map task small, the default 5 seconds sleep time becomes a large fixed overhead for real-time applications. To see the effectiveness of the sleep time of a reduce task, we to help CRCN achieve high spectrum utilization.
TABLE VI
EX E C U T I O N TI M E O F PI U N D E R T H E D E FAU LT A N D A L L M O D I FI E D S E T T I N G S (S E C )
Default settings All modified settings
Pi 1 100 22.362 4.361
The Hadoop fixed overhead results presented in the previous section were measured when the simple Pi job was executed.
Heartbeat 0.05s, commit sleep time = 1s
Heartbeat 0.05s, commit sleep time = 0.05s Hadoop original
Hadoop modified
Execution time (secs) Execution time (secs)
12 30 45), (45, 15) and (45, 45), respectively. We randomly selected some coordinate points and denoted them as the locations of SUs. The number of SUs used in an experiment is determined by the used measurement rate, which has been defined before in the paper.
We computed the RSSI (received signal strength indication) of each coordinate point where a SU resides and randomly added a Gaussian noise to it to represent the effect of signal noise in the real world. These sensing data represent the signal power sensed and reported by SUs in CRCN. The sensing data are saved in a file in the format of (x-position, y-position, RSSI) and the file is stored on the HDFS. We wrote a Hadoop MapReduce program to estimate the positions of PUs and their transmit powers using the SS algorithm. The map step of this SS algorithm first separated the SUs sensing data into 4 groups by their locations in order to run the SS algorithm in parallel.
After the map step is finished, a total of 4 reduce tasks were then launched to process these data.
We ran the SS algorithm case under different measurement rates, which are 0.05, 0.075, 0.1, 0.125, and 0.15, respectively.
As defined before in the paper, the measurement rate is defined as the number of SUs divided by the region in units of K m2 . composing of one i7 machine acting as the Hadoop master and two i7 machines acting as the Hadoop workers. The second one is composed of 3 Amazon EC2 [9] “large instances,” with one playing the role as the Hadoop master while the others playing the role as the Hadoop workers. The third one is composed of 3 Amazon EC2 “extra large instances,” with one being the Hadoop master while the others being the Hadoop
V. EX P E R I M E N TA L RE S U LT S
Table VIII and Fig.4(a) show that our modifications to the original Hadoop platform can successfully reduce the execution time of the SS algorithm by 23 seconds on our own machine platform. This improvement is very important to a large-scale cognitive radio network as now the SS algorithm can be finished in only a few seconds, which makes the cognitive radio approach much more effective.
TABLE VIII
EX E C U T I O N T I M E (S E C ) O F T H E SS A L G O R I T H M O N O U R OW N M AC H I N E
Measurement Rates Hadoop Original Hadoop Modified
0.05 26.777 3.35
The EC2 cloud already provides the original Hadoop platform
The EC2 cloud already provides the original Hadoop platform