Cognitive Radio Cognitive Network Simulator

Cognitive Radio Cognitive Network Simulator Table of Contents: 1

2

INTRODUCTION to CRCN 1.1 BACKGROUND of COGNITIVE RADIO 1.2 MOTIVATION 1.3 WHY BASED on NS2? 1.4 CRCN SIMULATOR OVERVIEW FUNCTIONALITY OVERVIEW 2 2.1 DESIGN OVERVIEW 3 for CRCN 2.2 CR ROUTING 6

2.3 3

4

1 1.1

CR MAC 12 CRCN USER GUIDE 3.1 SOFTWARE and INSTALLATION 3.2 EXEMPLARY DEMONSTRATIONS 3.3 GUI USER GUIDE MISCELLANEOUS 4.1 REFERENCES 4.2 FAQ 4.3 Cognitive Radio Research Groups 4.4 Contact information

6 20

Introduction to CRCN

Background of Cognitive Radio Cognitive radio network is a new emerging research area recently. It enhances the existing softwaredefined radio [1], whose physical layer behavior is largely defined in software. Cognitive radio has

the following characteristics [2]. First, it is aware of its environment and its capabilities. Second, it is able to independently alter its physical layer behavior based on its previous experience and its current environment. Finally, it is capable of performing the complex adaptation strategies according to the cognitive cycle shown in [3]. With these capabilities, when spectrum environment changes around cognitive user, it is capable of sensing these changes and independently changing its physical layer settings such as transmission power, channel selection and etc to meet some constraints or QoS requirements of the users. Cognitive radio gains popularity in the research area because it enables the current fixed spectrum channel assigned by FCC to be utilized by the new users. For example, most of

the spectrums assigned to TV channels are idle most of the time, while wireless network users share a small range of spectrum, 2.4 G Hz and 5G Hz. When there are many wireless users at a time, the network is congested because of the limited channel. With the spectrum opportunities [4] provided by the cognitive radio network, the wireless network users are able to share the idle spectrum for TV channel, on the condition that it does not interfere with the normal TV channel.

1.2 Motivation As cognitive radio research is emerging, more and more researchers are looking forward to a simulator that is suitable for cognitive radio. However, there is no existing simulator that is suitable for the demand of cognitive radio simulations. Many researchers implemented their algorithms for cognitive radios on existing network simulator such as NS-2 [5], OPNET [8], QUALNET [11]. However, since these simulators are created for the ordinary wireless network, researchers can not easily implement their cognitive radio algorithms over those simulators. Hence, there is a demand to extend existing simulators to support cognitive radio simulators. We make use of existing NS-2 to extend it to support cognitive radio network simulation.

1.3 Why based on NS-2? There are several reasons to base on NS-2 for the development of cognitive radio simulators. First, NS-2 is open source software. Any contributions to NS-2 are accessible by people around the world. Second, NS-2 provides an interface for users to configure different network protocol at each network layers, which is essential for simulation. Third, NS-2 already provides many radio models, such as 802.11, 802.16, 802.15.3, 802.15.4. Users can make use of these radio models for cognitive radio network simulations. Finally, NS-2 has incorporated with different topology and traffic generators, which enable users to create different simulation scenarios.

1.4 CRCN Simulator Overview

NS2 TRAFFIC GEN

This cognitive radio cognitive network (CRCN) simulator is a software based network simulator for network-level simulations. It is based on open-source NS-2 (network simulator 2). CRCN simulator supports performance evaluations for the proposed dynamic spectrum resource allocation, power CR control Customized Routingalgorithms, and the adaptive Cognitive Radio (CR) networking protocols including the CR MAC and the CR Routing protocols. This simulator uses NS-2 toCustomized generateCRrealistic traffic and topology patterns. For MAC each node in this simulator, a reconfigurable multi-radio multi-channel PHY layer is available by customizing the spectrum parameters such as transmission power, DYNAMIC RADIO propagation and etc RECONFIGURING CR PHY GUI

NS2 TOPO GEN

API FREQ, SENSING POWER , MOD SCHEME , DATA RATE ...

Model

Model

CRCN SIM MODEL

… ...

Model

STAT DATA ANALYSIS

The architecture block diagram for this simulator is illustrated in Figure 1. CRCN simulator enables the interface parameters transmission CR TRANSCEIVER SET between different layers, as shown in arrows with blue color. Users just need to replace their own Routing and MAC NS2 Radio NS2 Radio NS2 Radio

Figure 1 Architecture of CRCN Simulator F

algorithms according to NS-2 protocol design requirements with the existing one in the CRCN.

2 Functionality Overview The functionality provided by this simulator is summarized as follows. Support for CR Routing • Multi-radio multi-channel support • Single-radio multi-channel support • Interface to select radio • Interface to select channel • Heterogeneous radio and spectrum environment • Information needed during routing process • Support for CR MAC • Single-radio multi-channel support • Multi-radio multi-channel support • Interface to select channel • Information needed during dynamic spectrum access • Support for CR PHY • Reconfigurable spectrum parameters and radio parameters • Interference information • SINR/SNR physical model • CR Routing/CR MAC algorithms Several exemplary algorithms for CR Routing and CR MAC are given in the CRCN simulators. These algorithms illustrate how to use the functionality provided by this simulator. Also, these algorithms provide simulation environment for CR networking protocols. Users can replace these components with their own algorithms, and test the performance of their designs. • Performance Evaluation for CR algorithms This simulator contains several evaluation metrics for performance evaluations of the algorithms at different layers. Currently, the evaluation metric include summate, interference. • Graphical User Interface (GUI) A user-friendly GUI is provided to define simulation scenarios. Users can select the different network protocols, different topology and traffic model and etc. Also, users can start simulation and see the simulation result through this GUI. •

1.1 2 DESIGN OVERVIEW FOR CRCN 1.1.1 2.1 SYSTEM REQUIREMENTS This simulator is based on NS-2 (version 2.31). All codes have been tested in ns-2.31 under Linux environment. To use the GUI provided by this simulator, it is required that your system is installed with java runtime environment (JRE) 6 or above. Also, gnuplot should be installed under Fedora. The GUI is tested under Fedora 4.

1.1.2 2.2 DESIGN OVERVIEW To support simulation in CR wireless network, several new frameworks and functions are added in NS-2 for the functionality provided in section 2. These frameworks and functions are summarized as follows. Design Overview for CR Routing Users create the TCL script to configure the number of radios and channels needed for simulations. The basic idea is to create multiple radios or channels through the TCL library according to user’s script, which invokes the creation of several copies of LL, queue, MAC, NetIf, and channels for each radio in C++ library. The design overviews are shown through the following figures. The blocks with darker color are modified by CRCN to provide a complete solution. A. Equal number of Radios and channels Figure 2(a) shows the design for routing when the radio and channel are equals. In this design, the channel is created for each radio.

B. Single radio multi-channel Figure 2 (b) shows the design structure for single-radio, multi-channel structures. Multiple channel copies are created for this structure. Although routing algorithms can still use the same design as shown in figure 2 (a) for single-radio multi-channel by checking the radios being used, existing MAC protocols in NS-2 need to be modified to support this checking. On the contrast, by adopting the design shown in figure 2 (b), new

introduced routing algorithms for multi-channel, single-radio can use the existing MACs in NS-2 protocol stack, which is convenient to users.

C. Unequal number of radios and channels Figure 2 (c) shows the design structure for multi-radio, multi-channel design with unequal number of radios and channels.

Due to the limitation of NS-2 design structure, the interface for routing and MAC algorithms to use the above structures are slightly different. Users can refer to the next following sections for more details. There are some existing works [6][7][9] to enhance the NS-2 to support multi-radio multi-channel based on the design as shown in figure 2. However, there are several disadvantages for this kind of design if we only adopt them for CR simulation, which are listed as follows. • MAC layer is not aware of multiple channels created for each radio. Channel selection must be made in routing layer instead of MAC layer, which is conflict with most current MAC protocol designs. Thus, additional work is required in MAC to support multiple channels in MAC, which can be found in next section 12. • MAC layer address confliction is introduced by the related works. • Since channels are created in the same way, these radios and channels have the same radio and spectrum characteristic, which is not sufficient to support the simulation in heterogeneous CR network. • The radio and channel number are equal. Some routing and MAC algorithms simulations such as common control channel based algorithms are not supported if we only adopt the previous contribution work alone. Design Overview for CR MAC/PHY The high level design for MAC share some similar design structures with routing. Since the multi-channel design as shown in Figure 2 (a) for routing is transparent to the MAC

and PHY layer, to provide MAC and PHY algorithm a multi-channel environment, multichannel is needed at each radio. The design includes single radio multi-channel and multi-radio multi-channel, which are visible to both MAC and PHY layers. In both designs, multiple channel objects are created through the TCL library. Nodes can be switched to different channel objects during the simulation process. A. Single radio multi-channel Figure 3 shows the high level software design for single radio multi-channel support for MAC and PHY layer. The components with blue color are modified in CRCN to support the functionality required.

B. Multi-radio, Multi-channel Figure 4 shows the high level software design for multi-radio multi-channel support for MAC and PHY layer. The components with blue color are modified in CRCN to support the functionality required. This design combines the design shown in Figure 2 (a) and Figure 3.

Interaction between the core of CRCN simulator and GUI In the CRCN simulator, the interaction between the core of CRCN simulator and GUI is enabled through the multi-threading mechanisms. The GUI process creates threads needed for the core of CRCN simulator. And share data area is used for the data sharing between different threads and GUI.

1.2 2.2 CR ROUTING This simulator provides simulation support for channel assignment and CR routing. The functionalities provided are listed as follow. • Create CR multi-radio/single-radio multi-channel simulation environment It includes the creation of radios with homogenous and heterogeneous radio parameters, as well as spectrum with homogenous and heterogeneous propagation property. Here, the radio parameter includes predefined transmission power on each radio. • Interface for radio and channel decision • Interference information • Traffic information • Channel Utilization information Also, a routing implementation example is shown to use the interfaces provided by this simulator. User can replace this example with their CR routing algorithms.

The supported functionality for CR routing in this simulator is shown in the diagram as follow in the darker color. Starting from the top, this figure is explained according to the interfaces parameters provided to the user. Details… • CRR(Channel decision/Radio selection/Route selection decision) CR Routing includes channel decision, radio selection, and route selection decision. • Channel decision includes channel number and transmission power on the selected channel. • Radio selection means which radio to use. • Route decision means which path for packet forwarding. These decision need to be sent down to the lower layer through the multi-channel, multiradio/single-radio support module provided by CRCN, which is included in the diagram with darker blue color. • STICR( Spectrum Utilization information, Traffic information and Interference information from the Channel and Radio selected by CR Routing) The lower layer collects the information needed by CR Routing and sends the information to the upper layers. The information needed by CR Routing includes spectrum utilization information, traffic information, and interference information. The information is processed at the Traffic estimation/Spectrum utilization estimation/Interference estimation functional block provided by CRCN.

1.2.1 2.2.1 CREATE MULTI-RADIO/SINGLE RADIO MULTICHANNEL ENVIRONMENTS A. Homogenous multi-radio multi-channel The radios and channels created in this section are homogenous. The homogenous radios and channels are configured through wireless TCL simulation script. According to the relationship between radio number and channel number, CRCN provides three kinds of structures to satisfy different requirements from users: (1) Equal number of radios and channels, (2) Single-radio multi-channel, (3) Unequal number of radios and channels. (1) Equal number of radios and channels The API to configure homogenous radios and channels in TCL script is shown in the following four components. These four components need to be added in the simulation script by the user. Please note that if GUI is used to generate the wireless simulation script, this section can be skipped. Component 1.Define the radio number in TCL script … set val(ni) 2 ;# 2 interface ... Component 2. New channel objects according to the interface number provided in 1 for {set i 0 } { $i < $val(ni)} {incr i} { set chan_($i) [new $val(chan)] ; # new channel objects } Component 3. Configure the radio and channel option through the API provided … $ns_ node-config -adhocRouting $val(rp) \ … -ifNum $val(ni)\ ; #configure the interface number for node -channel $chan_(0) ; # configure the first channel object … Component 4. Assign the channel objects to the simulator for {set i 0} {$i < $val(ni) } {incr i} { $ns_ add-channel $i $chan_($i) ; # pass the channel objects into channel array }

Through the script created as instructed in this section, the radio is associated with each channel. Only routing layer is aware of each radio/channel. Users can refer to section 2.2.2 Radio and Channel decision for the radio and channel decision. (2) Single-radio multi-channel For the creation of single-radio and multi-channel, user can refer to the details in CRMAC. The channel decision from the CR routing only need to be stored into the channelindex_ , which is newly added in packet header. The lower layer has been modified to support this decision.

(3)Unequal number of radios and channels If user wants to have unequal number of radios and channels, user can refer to the CR MAC detail 2.3.1(Part B. multi-radio, multi-channel) about how to create the TCL script. The channel created as in 2.3.1 can be visible to both routing and MAC layer. Here is an example script. Users should refer to section 2.2.2 about how to use the interface provided for radio and channel decision. B. Heterogeneous multi-radio and multi-channel Similar to the creation of homogenous radios and channels, heterogeneous radios and channels are created through wireless simulation script. The following four components should be added into the simulation script by the user. Component 1, 2 and 3 are the same in A. Component 4. Assign different channel objects with different spectrum parameters to the simulator as follow. # configure the ns channel… $ns_ add-channel-new-phy 0 $chan_(1) 0.4 Propagation/FreeSpace #update this information for node 1 set node_(1) [$ns_ node] #;apply the change on node … $ns_ add-channel-new-phy 0 $chan_(0) 0.4 default …

In the example above, add-channel-new-phy is the newly added API. 0 is the radio number. $chan_(1) is the channel object created in component 2. 0.4 is the transmission power of this channel. Propagation/FreeSpace is the propagation method of this channel, which is used to simulate the possible wireless environment. The transmission power and propagation method can be set to default if you want to use the default value provided by NS-2. 1.2.2 2.2.2 Radio and channel decision A. Radio decision In the routing modules, radio decision can be stored in the routing entry such as the rt>rt_if field in AODV routing packet header. When your routing protocol is going to send down the packet, the following code should be added. Example for modifying the routing module can be found in here. Example for the radio or channel decision used in AODV protocol. … Scheduler::instance().schedule(targetlist[rt->rt_if], p, 0.); ..

Downtarget array targetlist is created when the node is configured in TCL script. rt->rt_if is the radio decision specified by the routing packet.

The way to handle radio decision is the same for all of the three structures defined in section 2.2.1. B. Channel decision Equal number of radios and channels When the radio and channel are created as in 2.2.1 A, channel is tied with each radio, thus, the radio decision is equal to the channel decision in this case. Single radio multi-channel For single radio multi-channel or the channels that are only visible to MAC layer, user need to follow the method in Single-radio and multi-channel for the creation of TCL script. The channel decision from the CR routing only need to be stored into the channelindex_ , which is newly added in packet header. The low layer has been modified to support this decision. Unequal number of radios and channels The channel decision should be specified by routing algorithms through the channelindex_ of packet header. The low layer has been modified to support this decision. The design structure for single radio multi-channel and this part shares the common design at low layer. 1.2.3 1.2.4 2.2.3 INFORMATION NEEDED BY CR ROUTING AND CHANNEL ASSIGNMENT A. Interference information The interference information is associated with each node over each channel. Several kinds of interference information are provided: (1) Channel that has minimum interference, (2) Current interference value over a specific channel, and (3) Historical interference information of a specific channel. To access the above information, routing module should have a pointer which points to the current node object. The code highlighted in bold in components 1 to 4, which are illustrated through AODV routing protocol, should be added in your routing module. Component 1. Declare a Mobilenode pointer in routing module Class AODV{ … protected: MobileNode *node_; //pointer to mobilenode object … } Component 2. Initialize the Mobilenode pointer through in the command method of your routing module. int AODV::command(int argc, const char*const* argv) { …

// for the node agent else if(strcmp(argv[1], "node") == 0) { node_= (MobileNode*) TclObject::lookup(argv[2]); if (node_) { return TCL_OK; } return TCL_ERROR; } … } Component 3. Corresponding change should be made in ns-lib.tcl that creates routing agent if no such code exists. Simulator instproc create-aodv-agent { node } { # Create AODV routing agent set ragent [new Agent/AODV [$node node-addr]] $ragent node $node ; # to attach the node agent $self at 0.0 "$ragent start" ;# start BEACON/HELLO Messages $node set ragent_ $ragent return $ragent } Component 4. Option to select whether to record interference on all nodes for {set i 0} {$i < $val(nn) } {incr i} { set node_($i) [$ns_ node] $node_($i) set recordIfall 1 ; # enable interference information collection $node_($i) random-motion 0 ;# disable random motion }

If this option is added, the interference information about node i is provided. If the script is created through GUI, the interference information for all nodes is provided. After adding the components as shown above, the interference information can be obtained as follows. (1)Channel that has minimum interferences Interface for obtaining channel with minimum interference around one node. Module Mobilenode: use the following method to obtain channel number which has minimum interference. Class Mobilenode{ public: … // return the channel id that minimum interference int ChannelwithMinimumIf{ return chanwithminiIf;} … }

(2)Current interference value over a specific channel

Use the following method to obtain interference value. Please note the interference value is sometimes too small and you may need to scale it by some factor to see the result. This Module Mobilenode: obtaining interference Class PacketPr { … //obtain the interference information for current node double getInterference(int channelno); … }

(3)Historical interference information Besides obtaining the channel with minimum interference, the interference information over each channel around can be obtained through the ITfile generated by the simulator. The format of the ITfile is as follow. User can obtain their information through ITfile according to this format. ITfile format Timestamp node id

interference

channel id

B. Noise TCL command for setting noise for physical layer is as follow. This should be added in the simulation script if you want to define the noise. TCL command: setting noise for physical layer Phy/WirelessPhy noise_ 0.1 ;# 0.1 can be replaced by any other noise value

With the noise information and interference information, user can change the physical layer of NS-2 to use SINR/SNR reception model according to their needs. C. Traffic information For CR routing, it is necessary to use the sensing traffic information to predict the future traffic information in the neighborhood, and derive the best user strategy. The interface this simulator providing are in the two formats (1) obtaining the current traffic information (2) obtaining the historical traffic information. (1)Obtaining the current traffic information Module Mobilenode: use the following function in bold to obtain traffic information class PacketPr { public: … int getTrafficCount() {return trafficcount;} … }

User can access this function through the pointer to Mobilenode as in 1.4.3.A. For example, in the AODV, user can access traffic information like this way. Module Mobilenode: use the following function in bold to obtain traffic information

… int traffic= node_->PacketPr_.getTrafficCount(); …

(2)Obtaining the historical traffic information The historical traffic information is stored in the Trafficfile. User can obtain this information based on the format provided. Trafficfile format Timestamp node id

traffic information

D. Channel Utilization For some CR routing algorithms, they may need the channel utilization for routing decision. For users who need channel utilization information, users need to add the following codes in the MAC layer they are using. Step1: Add the timer definitions in the MAC you are using. Module Macxx.h: add timers for channel utilization //Timer for channel utilization class ChanUtil_Timer : public TimerHandler { public: ChanUtil_Timer(Macxx *a) : TimerHandler() { a_ = a;} void expire(Event *e); protected: Macxx *a_; }; Module Macxx.h: add timers for calculate channel utilization //Timer for Calculate channel utilization class CalChanUtil_Timer : public TimerHandler { public: CalChanUtil_Timer(Macxx *a) : TimerHandler() { a_ = a;} void expire(Event *e); protected: Macxx *a_; };

Step2: Add the timer functions’ implementation in the MAC you are using. Add the Module Macxx.cc: add timer functions’ implementation //Timer for recording channel utilzation void ChanUtil_Timer::expire(Event *) { a_->ChanUtil_Calculate(); //Traffic timer expires for every node or the node specified resched(0.01);

} //Timer for calculating channel utilzation void CalChanUtil_Timer::expire(Event *) { a_->CalChanUtil_Calculate(); //Traffic timer expires for every node or the node specified resched(1); }

Step3: Add the timer definitions in the MAC class you are using. Module Macxx.h: add timers variable in Macxx class Class Macxx{ … friend class ChanUtil_Timer; friend class CalChanUtil_Timer; … public: FILE *fp; ChanUtil_Timer ChanUtil_Timer_; CalChanUtil_Timer CalChanUtil_Timer_; void ChanUtil_Calculate(); //function for recording channel utilization void CalChanUtil_Calculate(); //function for calculating channel utilization void increaseChanUtil(){chanutilcount++;} void resetChanUtil() {chanutilcount=0;} int getChanUtil(){return chanutilcount;} … private: … int chanutilcount; … }

Step4: Add the timer functions’ implementation in the MAC class you are using. Module Macxx.cc: add the related function implementation as defined in Macxx class. void Macxx::ChanUtil_Calculate() { //if mac is not idle if(!is_idle()){ //increase channel utilization counter increaseChanUtil(); } }

void Macxx::CalChanUtil_Calculate() { if (((fp = fopen("Chanfile", "a")) != NULL) ) { fprintf(fp, "%lf %d %lf\n",NOW,((MobileNode*)(netif_->node()))>nodeid(),getChanUtil()/100); fclose(fp); resetChanUtil(); } else { printf("fail to open file"); } }

After finishing the above steps, users are able to obtain two kinds of channel utilization information: (1) Current channel utilization information (2) Historical channel utilization information. (1) Current channel utilization information The current channel utilization information can be obtained through function getChanUtil() defined in class Macxx. User can obtain this information based on the format provided. (2) Historical channel utilization information The historical channel utilization information is stored in Chanfile. User can obtain this information based on the format provided. Chanfile format Timestamp node id

channel utilization

1.3 2.3 CR MAC This simulator provides simulation support for CR MAC. The functionalities provided are listed as follows. • CR multi-radio/single-radio multi-channel simulation environment • Interface for channel decision • Interface for transmission power decision • Interference information • Traffic information Also, two example MAC algorithms are used to illustrate how to use the interfaces provided by this simulator. User can replace these examples with their CR MAC algorithms. The supported functionalities for CR MAC in this simulator are shown in the following diagrams based on the types of the MAC algorithms. Details… Contention based MAC

Figure 7 shows the high level designs for contention based MAC algorithms. Starting from the CR MAC, the interface parameters are as follows. • TC(Transmission power and Channel selection) After CR MAC makes the decision, which includes the transmission power and Channel selection, the simulator will send down the information through the multi-channel support functional block provided by CRCN. Before the multi-channel support functional block is introduced, the MAC layer is only aware of a single channel. • TICC(Traffic information, Interference information over specific Channel, Communication information over common control channel) The physical layer will provide the traffic information, interference information and communication information to the upper layer through the Information Block provided by CRCN simulator.

Collision free MAC Figure 8 shows the high level designs for contention based MAC algorithms. Starting from the DSA, the interface parameters are as follows. • TC(Transmission power and Channel selection) After DSA makes the decision, which includes the transmission power and Channel selection, the simulator will send down the information according the multi-channel support functional block provided by CRCN. The DSA decision will be verified by user defined metric, which is entered by user from GUI. If the DSA decision does not satisfy

the user defined metric, the user defined metric block will provide this information to DSA. • TIC(Traffic information, Interference information over data Channel) The physical layer will provide the traffic information, interference information to the upper layer through the Information Block provided by CRCN simulator. 1.3.1 2.3.1 CREATE CR MULTI-CHANNEL ENVIRONMENTS A. Single-radio multi-channel The following four components should be added by user to create the multi-channel environments. The channels created in this part have identical spectrum parameters. Please note that if you are using GUI provided by this simulator, this section can be skipped. Component 1.Define the channel number in TCL script set val(channum) 2 ;# 2 channels are available in the network Component 2. New channel objects according to the interface number provided in Component 1. for {set i 0 } { $i < $val(channum)} {incr i} { set chan_($i) [new $val(chan)] ; #new channel objects } Component 3. Configure the multiple channel option … $ns_ node-config -adhocRouting $val(rp) \ … -ChannelNum $val(channum)\ ;# configure channel number -channel $chan_(0) ;#configure the first channel object … Component 4. Assign the channel objects to the channel array of the simulator … for {set i 0} {$i < $val(ni) } {incr i} { $ns_ add-channel $i $chan_($i) ; # initialize the channel array with channel objects } …

B. Multi-radio multi-channel The following four components should be added by user to create the multi-radio, multichannel environments for MAC. The channels created in this part have identical spectrum parameters. Please note that if you are using GUI provided by this simulator, this section can be skipped. Component 1.Define the radio and channel number in TCL script set val(ni) 2 ;# number of radios set val(channum) 2 ;# 2 channels are available in the network Component 2. New channel objects according to the radio and channel number provided in Component 1.

for {set i 0} { $i < [expr $val(ni)*$val(channum)]} {incr i} { set chan_($i) [new $val(chan)] } Component 3. Configure the multiple radio and channel option $ns_ node-config -ifNum $val(ni) -channel $chan_(0) $ns_ node-config -ChannelNum $val(channum) Component 4. Assign the channel objects to the channel array of the simulator for {set i 0} {$i < [expr $val(ni)*$val(channum)] } {incr i} { $ns_ add-channel $i $chan_($i) }

1.3.2 2.3.2 CHANNEL/RADIO DECISION The channel decision from CR MAC or DSA algorithm should be set through the interfaces provided as follow, which reflects the channel that the receiver is using to receive packet. A new field channelindex_ is added into the packet header. After CR MAC or DSA make channel decision, this decision can be stored into this field. Module packet.h: struct hdr_cmn { … int channelindex_; … }

The code as follow should be added in the sendDown function for wirelessphy. In our design, multiple channel object pointer is used to index the channel object. Hence, it is appropriate to use channel index derived in CR MAC or DSA algorithms to differentiate channel, which helps to achieve conflict free or reduce interference among neighboring nodes. channelindex_ defined in the packet header can carry this information from CR routing, CR MAC or DSA to the wireless physical layer. Module WirelessPhy: Interface for channel decision in MAC void WirelessPhy::sendDown(Packet *p) { … // Send the packet //channel_->recv(p, this); //send packet over the channel specified by channel index. multichannel[hdr_cmn::access(p)->channelindex_]->recv(p, this); … }

If user’s MAC is for single-radio and multi-channel network, the above code change is enough to differentiate different channels for MAC protocols. However, users still need to design their own collision avoidance mechanism or DSA according to the NS-2 protocol design structures.

If user’s MAC is for multi-radio and multi-channel network, codes related to the radio selection is needed besides the channel decision code as above. Depending on the usages of each radio, users need to add code in the MAC to differentiate what current radio is for. For example, if each node has 2 radios: radio 1 is assigned to common control channel; radio 2 is assigned to data channel. In user’s code for MAC, user need to restrict the radio 1 only handle the control packets, and radio 2 only handle the data packets. To provide flexibility for this simulator, we do not add any restrictions for the multi-radio, multi-channel MAC. Users also need to choose appropriate routing protocol for their multi-radio, multi-channel MAC. To differentiate the current radio from one another, users can just use the index_, which is declared in Mac. 1.3.3 2.3.3 TXPOWER DECISION Packet will be transmitted using the default transmission power if transmission power is not specified in simulation script. However, as CR MAC and DSA algorithms may control the txpower over each channel to control the interference to primary users or nearing neighbors, it is necessary to provide an interface, which can control the txpower during the simulation. The DSA algorithm can be implemented in the following functions, which are in bold. Module Mobilenode: Interface for obtaining the transmission power from DSA algorithms. Class PacketPr{ public: … //Obtain DSA decision according to different input parameters. double getDSAPr(int receivernode); double getDSAPr(int receivernode, int channelindex); … }

Then, add the following interface for controlling the maximum transmission power and obtaining DSA power decision. Please note that other physical layer can be modified in the similar way. Module WirelessPhy: Interface for channel decision in MAC int WirelessPhy::sendUp(Packet *p) { … double DSAPr= (MobileNode*)node()->PacketPr_.getDSAPr(); //if the Pr is within the limit range of user, assign DSAPr to Pr. Pr=DSAPr; … }

To determine the txpower, the DSA algorithms need to know the identity of sender and receiver. In some DSA algorithms (such as game based), sender and receiver has

negotiated the channel decision, and thus the power control algorithm compute the txpower over the negotiated channel. 1.3.4 2.3.4 INFORMATION NEEDED BY CR MAC A. Interference information The interference information is associated with each node over each channel. Several kinds of interference information are provided: (1) Channel that has minimum interference, (2) Current interference value over a specific channel, and (3) Historical interference information. Users can use the corresponding API into their algorithm to obtain the information. (1)Channel that has minimum interferences Interface for obtaining channel number with minimum interference around one node. Use the following method to obtain channel number which has minimum interference. Module Mobilenode: obtain channel with minimum interference Class PacketPr{ … //return the channel id with minimum interference. int ChannelwithMinimumIf{ return chanwithminiIf;} … }

(2)Current interference value over a specific channel. Use the following method to obtain interference value. Please note the interference value is sometimes too small and you may need to scale it by some factor to see the result. Module Mobilenode: Interface for channel decision in MAC Class PacketPr { … //obtain the interference information for current node double getInterference(int channelno); … }

(3)Historical interference information To obtain the historical information of node i, the following option to select whether to record interference on node i should be added in simulation script by the user. TCL script: add the interference option for {set i 0} {$i < $val(nn) } {incr i} { set node_($i) [$ns_ node] $node_($i) set SingleIfMultiChan 1 ; $node_($i) set recordIfall 1 ; # enable interference information collection $node_($i) random-motion 0 ;# disable random motion }

If this option is added, the interference information about node i is provided. If using GUI, the interference information for all nodes is provided by default. Besides obtaining the channel with minimum interference, the interference information over each channel around can be obtained through the ITfile generated by the simulator. The format of the ITfile is as follow. User can obtain their information through ITfile according to this format. ITfile format Timestamp node id

interference

channel id

B. Noise TCL command for setting noise for physical layer is as follow. This should be added in the simulation script if you want to define the noise. TCL command: setting noise for physical layer Phy/WirelessPhy noise_ 0.1 ;# 0.1 can be replaced by any other noise value

C. Traffic information For intelligent based MAC, it is necessary to use the sensing traffic information to predict the future traffic information in the neighborhood, and derive the best user strategy. The interface this simulator providing are in the two formats (1) obtaining the current traffic information (2) obtaining the historical traffic information. (1)Obtaining the current traffic information Use the following function in bold to obtain traffic information. Module Mobilenode: obtain traffic information class PacketPr { public: … int getTrafficCount() {return trafficcount;} … }

Users can access this function through the pointer to mobilenode. For example, in the MAC for 802.11, users can access traffic information like this way. Module Mobilenode: obtain traffic information … int traffic= ((MobileNode*)(netif_->node()))->PacketPr_.getTrafficCount(); …

(2)Obtaining the historical traffic information The historical traffic information is stored in the Trafficfile. User can obtain this information based on the format provided. Trafficfile format

Timestamp

node id

traffic information

D. Packet based primary user detection As MAC/DSA algorithms may need to know the existence of primary user, we also introduce how to implement the packet based primary user detection. The primary user sends out a primary user packet to indicate its existence. Other users that receive this packet can distinguish the existence of primary user from this packet. The primary user packet is controlled by a broadcast timer. As the primary user packet can collide with normal data packet, thus the sending and controlling of this packet should be done in the MAC layer. The primary user mechanism is implemented in the Macngenhanced module. User can add the similar code in other MAC protocol. Here is just an example. User need to define whether to send the packet according to movements of primary user or use timer to control. The packet module is modified to contain information about primary user. A new broadcast timer primaryusertimer is added in MAC to control the broadcast of this packet. The sendprimaryuserpacket is added to send primary user packet. The recv function is changed to handle the primary user packet. User can refer to Macngenhanced for more detail

1.4 3 CRCN USER GUIDE 3.1 Installation 1.4.1 3.1.1 NS2 COMPONENTS Step 1: Make sure your system meets the system requirements. Step 2 : Download crcn.zip. (update on 7/27/2009) Step 3 : Change your working directory to XXX/ns-allinone-2.31/ns-2.31/ Step 4: Unzip the crcn.zip. Copy the files under each subfolders in crcn into the corresponding folders in XXX/ns-allinone-2.31/ns-2.31/. For example, copy the files under crcn/mac/ into XXX/ns-allinone-2.31/ns-2.31/mac/. Please note that it will overwrite some of your ns file in the same directory. Thus, backup the ns directory before executing this command. Step 5: Add the following three lines in the Makefile, which is under XXX/ns-allinone2.31/ns-2.31/. wcett/wcett_logs.o wcett/wcett.o \ wcett/wcett_rtable.o wcett/wcett_rqueue.o \ mac/macng.o mac/maccon.o\ mac/macngenhanced.o\ Step 6: Run the following commands under XXX/ns-allinone-2.31/ns-2.31/ directory: make clean make depend make Users can use the NS2 components without using the GUI.

1.4.2 3.1.2 GUI Step 1: Install the java JDK version 6 or above under linux from http://www.java.com/en/download/manual.jsp . Step 2: Install the gnuplot from http://www.gnuplot.info/ . Step 3: Put throughput.pl and throughputcbr.pl under your ns working directory XXX/nsallinone-2.31/ns-2.31/. Step 4: Run CRCN.jar. (updated) Step 5: Refer to CRCN GUI guide to run the GUI if you want to use this GUI.

1.5 3.2 EXEMPLARY DEMONSTRATIONS 1.5.1 3.2.1 CR ROUTING The folder wcett[10] provides an implementation example for using the interface provided by this simulator. The implementation is based on [10] with some simplification. The script file testwcett.tcl (with random.tcl ) provided with the patch is a demonstration about how to run the multi-channel routing protocol. This section illustrates how this routing protocol can be embedded into the simulator Exemplary implementation for CR Routing (1)TCL Library Modification Module ns-lib.tcl: invoke create-wcett-agent in function create-wireless-node as other routing protocols Simulator instproc create-wireless-node args { … switch -exact $routingAgent_ { … WCETT { set ragent [$self create-wcett-agent $node] } …. } … } Module ns-lib.tcl: add the create-wcett-agent procedure Simulator instproc create-wcett-agent { node } { # Create wcett routing agent set ragent [new Agent/WCETT [$node node-addr]] $ragent node $node $self at 0.0 "$ragent start" $node set ragent_ $ragent return $ragent }

(2) C++ code change Define the interface queue and targetlist for multiple interfaces. Module wcett: define the interface queue and targetlist for multiple interfaces class WCETT: public Agent { …

Protected: int nIfaces; //total interfaces per node NsObject *targetlist[MAX_IF]; PriQueue *ifqueuelist[MAX_IF]; MobileNode *node_; Module wcett: add the following codes in the command method Int WCETT::command(int argc, const char*const* argv) { … Else if(argc = = 3) { //create pointer to mobilenode object … else if(strcmp(argv[1], "node") == 0) { node_= (MobileNode*) TclObject::lookup(argv[2]); if (node_){ return TCL_OK; } return TCL_ERROR; } } else if (argc = = 4){ //create pointer to ifqueue object if(strcmp(argv[1], "if-queue") == 0) { ifqueue = (PriQueue*) TclObject::lookup(argv[3]); int temp_=atoi(argv[2]); if (temp_==nIfaces){ nIfaces++; } ifqueuelist[temp_]= ifqueue; if (ifqueuelist[temp_]){ return TCL_OK; } return TCL_ERROR; } //create pointer to downtarget objects if (strcmp(argv[1],"target")==0 ){ int temp=atoi(argv[2]); if (temp == nIfaces){ nIfaces++; } targetlist[temp]=(NsObject *) TclObject::lookup(argv[3]); if(targetlist[temp]){ return TCL_OK; } return TCL_ERROR; } … }

Next, when sending the packets over the specific interfaces, just using the interface number as an index to send the packet as follow.

Module wcett: example about how to use the interface if(nIfaces) { //if multiple interfaces are defined. for(int i=0;icopy(); Scheduler::instance().schedule(targetlist[i], p_copy, 0.01 * Random::uniform()); } } else { //if only one interface is defined Scheduler::instance().schedule(target_, p, 0.01 * Random::uniform()); }

1.5.2 3.2.2 CR MAC The files maccon and macng in the mac folder provide implementation examples for using the interface provided by this simulator. This section illustrates how these MAC protocols can be embedded into the simulator. Please note that these MAC protocols are only for demonstration and testing purpose. Users need to design their own collision avoidance scheme or DSA according to the NS-2 protocol design structures. A. Contention based MAC The file maccon.h and maccon.cc in folder mac is an example implementation for contention based MAC. In this Maccon, each node randomly selects a channel from a predefined channel list. Since each node is not aware of what channel being used by other node, collision is still existed for this random channel selection. The channel information selected by each node is passed to PHY layer through the packet header. In this Maccon, the channel list array number is equal to the number of nodes in the simulation script test4maccon.tcl. Nodes randomly select the channel based on this channel array. In the topology and traffic file topo4.tcl, 3 pairs of nodes are transmitted simultaneously. Since the channel decision of this MAC depends on specific transmission scenario, users need to add change to make Maccon adapt to other scenarios. Besides the code change in MAC, the following code should be added in the sendDown function of wirelessphy. Module wirelessphy: example about how to use interface for MAC void WirelessPhy::sendDown(Packet *p){ … // Send the packet //channel_->recv(p, this); multichannel[hdr_cmn::access(p)->channelindex_]->recv(p, this); … }

Here is the simulation result for Maccon. B. Collision free MAC The file macng.h and macng.cc in folder mac is an example implementation for collision frees MAC. In intelligent based and schedule based MAC, they both require negotiation about channel decision and transmission parameters. Most of the current intelligent based and schedule based MAC are negotiated over common control channel. In this example, we illustrate the how to negotiate through common control channel and make the channel decision. The operation of Macng is divided into two phases. In the first phase, each node sends out strategy packet with preferred receiving channel. If there is an empty channel available, then it is selected as the preferred receiving channel. If there is no empty channel, node shares the channel with the node that is furthest away from it. In the second phase, node will use the channel selected during the first phase to send and receive data. The channel selection algorithms we are using is a simple rule, which is for the demonstration purpose, hence, collision still exists. Besides the code change in MAC, the following code should be added in the sendDown function of wirelessphy. Module wirelessphy: example about how to use interface for MAC void WirelessPhy::sendDown(Packet *p){ … // Send the packet //channel_->recv(p, this); multichannel[hdr_cmn::access(p)->channelindex_]->recv(p, this); … }

The simulation script for this MAC can be found in test4macng.tcl. Here is the simulation result for Maccon and Macng. The second example Macngenhanced illustrates how to implement a DSA based MAC through multiple rounds of negotiation. This MAC example shows the power adaptation process of each node. Each node adjusts its transmission power according to the equation in [12]. In this example, each node runs a DSA algorithm to calculate its transmission power. The DSA algorithm is run on each node whenever it has packet to send. In order to have enough information for the DSA algorithms, each node needs to negotiate with each other about the transmission power they are adopting. During negotiation phase, each node broadcast a strategy packet to its neighbors. Each node calculates the SINR based on the information from the strategy packet, and stores the related SINR information of send. During the data transmission phase, each node looks through its database to find the

related SINR information for the receiver and run the DSA algorithm. For simplicity, the equation from [12] is adopted for the transmission power calculation. From the simulation result, it is found that the performance is greatly affected by period of negotiation. If the broadcast period is short, the performance is not as good as when the period is longer. The reason is that control packets collide more frequently with the data packets. This problem can be avoided if multiple channels are used. Users can implement similar DSA-driven MAC following this example. Please note that the purpose of this implementation is not towards the good performance, as good performance needs careful selection of broadcast period and etc, which is beyond the scope of this simulator design. The implementation of Macenhanced is also based on Mac-simple. Thus, the packet sending and receiving model is still the same as Mac-simple. Function sendStrategy() is used during the negotiation process to send the strategy packet. getInterference() function provided by this simulator is used to obtain the SINR in the receive handler, which handles the receiving packet. As stated above, the transmission power is calculated before sending out the packet to the downtarget. Please note that this MAC only acts as an example for implementation. Performance is not the focus of this example.The purposed of Macngenhanced is to show users how he/she can implement a DSA-based MAC with multiple rounds of negotiation. Thus, the test focuses on whether this Macngenahanced can run the correct simulation with a given topology and traffic pattern. The purposed of Macngenhanced is to show users how he/she can implement a DSAbased MAC with multiple rounds of negotiation. Thus, the test focuses on whether this Macngenahanced can run the correct simulation with a given topology and traffic pattern. The purposed of Macngenhanced is to show users how he/she can implement a DSAbased MAC with multiple rounds of negotiation. Thus, the test focuses on whether this Macngenahanced can run the correct simulation with a given topology and traffic pattern. The purposed of Macngenhanced is to show users how he/she can implement a DSAbased MAC with multiple rounds of negotiation. Thus, the test focuses on whether this Macngenahanced can run the correct simulation with a given topology and traffic pattern. The purposed of Macngenhanced is to show users how he/she can implement a DSAbased MAC with multiple rounds of negotiation. Thus, the test focuses on whether this Macngenahanced can run the correct simulation with a given topology and traffic pattern. The purposed of Macngenhanced is to show users how he/she can implement a DSAbased MAC with multiple rounds of negotiation. Thus, the test focuses on whether this Macngenahanced can run the correct simulation with a given topology and traffic pattern. The purposed of Macngenhanced is to show users how he/she can implement a DSAbased MAC with multiple rounds of negotiation. Thus, the test focuses on whether this Macngenahanced can run the correct simulation with a given topology and traffic pattern. The simulation script for this MAC can be found in test4macngenhanced.tcl.

1.5.3 3.2.3 DESIGN TEST CASE STUDY This section illustrates how we test the functionality provided by CRCN simulator 3.2.3 Design test case studies

To test and verify the framework provided by CRCN simulator, demos and debug code test are used together to test and verify the functionality. Section A compares the methods used for testing. Section B introduces the test process. A. Comparisons between the demo method and debug code method For the demos, they can provide direct performance comparisons to users, however, the performance of demo is hard to analyze for the following reasons. • The performance of demos depends on the algorithm design. • The performance analysis of demos involves analysis of topology, traffic, and interaction with other layers. Thus, it makes the analysis is complex and not so accurate. • For each demo, it can only adapt to one kind of simulation setting, such as single radio, multi-channel, or multi-radio, multi-channel. For the debug code test, it is the most accurate and direct way to test the framework. The only disadvantage is that it is hard to understand by people other than the designers and NS-2 users. However, the debug code is not included in the release code to avoid confusing to users. B. Test process (1) Test the multi-radio provided by design structure figure 2 (a) Specific topology as follow is designed to test whether multi-radio is worked under this design structure. Each node is forced to make the channel selection as shown in figure 1 in the routing module. Every node has 2 radios, but only node 2 has more chance to use 2 radios at the same time. Then we can check at node 2 whether multi-radio is used through simulation.

Figure 1. Test topology for multi-radio From the snapshot of a trace file about the radio usages in table 1, two MACs associated with 2 radios of node 2 are busy at the same time. Thus, the multi-radio functionality is proved. Users can also write their simple debug code to test the functionality. Table 1. Radio usages at node 2 format 0.010000 2 4 busy 0.010000 2 5 busy 0.020000 2 4 busy 0.020000 2 5 idle 0.030000 2 4 idle

0.030000 2 5 idle 0.040000 2 4 idle 0.040000 2 5 idle 0.050000 2 4 busy 0.050000 2 5 idle 0.060000 2 4 idle 0.060000 2 5 idle 0.070000 2 4 busy 0.070000 2 5 busy 0.080000 2 4 idle 0.080000 2 5 idle 0.090000 2 4 idle 0.090000 2 5 idle 0.100000 2 4 idle 0.100000 2 5 idle (2) Test the multi-radio multi-channel provided by design structure figure 2 (a) Since the multi-channel provided through this design is only visible to routing, WCETT is used to test the multi-channel provided by figure 2(a). However, this implementation is a simplifier version. With the design structure in figure 2 (a), channel is tied with each radio, thus, the corresponding radio and channel relationship is fixed. For example, radio 1 is always on Channel 1; radio 2 is always on Channel 2. Figure 2, figure 3 and figure 4 compare the performance of WCETT when the radios or channel numbers are different. The simulation settings, topology and traffic for these simulations are the same except the radio and channel number. The throughput is increased nearly by half when the radios and channels are increased from 1 to 2. But the performance is not increased significantly when the radios and channels are increased from 2 to 3. The reason is that not all the radios are being used all the time. Table 2 is the snapshot of a trace file that shows the radio usage at node 2 when it has 3 radios. Users can also write their simple debug code to test the functionality.

Figure 2. WCETT with number of radio=1 and number of channel=1

Figure 3. WCETT with number of radio=2 and number of channel=2

Figure 4. WCETT with number of radio=3 and number of channel=3 Table 2. Radio usages at node 2 format 2.700000 2 6 busy 2.700000 2 7 busy 2.700000 2 8 idle 2.710000 2 6 busy 2.710000 2 7 busy 2.710000 2 8 idle 2.720000 2 6 busy 2.720000 2 7 busy 2.720000 2 8 idle 2.730000 2 6 busy 2.730000 2 7 busy 2.730000 2 8 idle (3) Test the single radio, multi-channel in figure 2 (b) Since the multi-channel in this design structure is only visible to MAC, we design some simple MAC algorithms to test this functionality. This simple mac are based on the existing mac-simple in NS-2. Routing layer can just pass the channel decision to lower layer when routing algorithm is responsible for making channel decision. Maccon Based on mac-simple, Maccon has random channel selection to make use of the multichannel provided. Maccon is designed for specific topology, since our purpose is just to

test multi-channel. Figure 2 and figure ? compare the throughput under mac-simple and maccon with the same simulation settings except channels.

Figure 5. Throughput for mac-simple

Figure 6. Throughput for Maccon when channel number is two Macng Macng is used to test single radio, multi-channel functionality. The operation of Macng is divided into two phases. In the first phase, each node sends out strategy packet with preferred receiving channel. If there is an empty channel available, then it is selected as the preferred receiving channel. If there is no empty channel, node shares the channel with the node that is furthest away from it. In the second phase, node will use the channel selected during the first phase to send and receive data. From figure 7 and figure 8, when the numbers of channels increase from 2 to 3, the throughput also increases. However, as we increase the number of channels to 4 or 5, the throughput is not increased significantly. The reason is that only 3 pairs of nodes are used under this simulation.

Figure 7 . Test for Macng and the number of available channel are 2 3 pairs of nodes; topology and traffic file: topo4.tcl

Figure 8.Test for Macng and the number of available channel are 3 3 pairs of nodes; topology and traffic file: topo4.tcl If we use another simulation setting, the throughput change for Macng can be observed. With more nodes and more simultaneous transmissions in the random topology and traffic scenario, more channels are used. Thus, the increase of throughput can be observed when the number of channels increases from 5 to 8. The drop of performance from 30 seconds in figure 9 is due to too many collisions. As Macng is just used to provide example for the user, collisions introduced in mac-simple still exist. In comparison, when channel is increased to 10, the throughput is increased. Thus, multichannel functionality is correct here since increasing the channel will increase the throughput, since the same simulation setting is used.

Figure 9. Test for Macng with random topology and traffic channel number =5

Figure 10. Test for Macng with random topology and traffic channel number =10 In sum, the functionalities are tested through the debug code and demos. However, as explained in section A, to obtain an accurate result, the performance analysis of demos test need to involve the consideration of topology and traffic pattern, and the design of the algorithms. (4) Test the multi-radio, multi-channel in figure 2 (c) This structure is a combination of figure 2 (a) and figure (b). Because of this combination, the supported functionalities in figure 2 (a) and figure (b) are included in figure2 (c). But still, some tests are done to make sure the reliability of this structure. Users need to carefully design MAC and choose an appropriate multi-radio routing to use this structure. The simulation settings are as follows. Random topology and traffic is used. Routing protocol is WCETT. 802_11 is used as the MAC protocol. Each node has 2 radios and 3 channels per radios. Since 802_11 is default to channel 0, thus only channel 0 will be used in this case. The Maccon, Macng won’t work since they are not designed for this structure. The test result is shown as follow. This result is to make sure no other framework change is needed. It is protocol designer’s responsibility to implement their MACs. The simulation result shown in figure 11 demonstrates that the multi-radio, multichannel structure is correct.

Figure 11. Test for the structure in figure 2 (c)

HELP for CRCN GUI Copyright: SNR lab/Michigan Technological University  http://www.mtu.edu

1. Simulation Process Tutorial 1.1 Simulation Process 1.2 Generate a topology and traffic file 2 Simulation Environment Setting 2.1 Physical Layer Setting 2.2 MAC layer Setting 2.3 Routing Setting 2.4 Other Simulation Setting 2.5 Simulation Result

3. Random Topology/Traffic Generators 3.1 Random Topology Generator 3.2 Random Traffic Generator

2 1. Simulation Process Tutorial 2.1 1.1 Simulation Process Under main tab as shown in the following figure, Step 1: Select the simulation setting in the corresponding PHY/Channel/Spectrum Parameters/MAC/Routing setting. For the user defined Routing and MAC protocols, several default names such as Mac3/Routing1/Routing2 are reserved for the user defined protocols in the GUI. Users only need to use these names for their MAC or Routing protocols.

Step 2: Under Other Simulation Setting, define or specify the number of nodes, simulation stop time, and mobility and traffic file. Then specify the ns working directory in Work Dir and file name of the simulation script in Output sim setting file. The traffic and mobility file can be generated under Topology /Traffic Generator tab. The traffic and mobility file will be stored under the Work dir. After click “Confirm” button, the simulation script will be generated under the Work dir.

Step 3:Under Simulation File dir and Name, choose a simulation script from “Open file from…”, or just type in the simulation file with directory as shown in the following figure, then click “StartSim”, which starts the simulation process. When the simulation is ongoing, the “StartSim” will have a darker color.

Step 4: After the simulation finish, click the Interference or Throughput button, then you  can see the simulation result.

2.2 1.2 Generate a topology and traffic file This GUI is incorporated the topology and traffic generator provided by NS2. Please note  that the topology and traffic file are written into directory specified by Work Dir. Step 1: Under Random Topology Generator, fill in the parameters for defining the  topology and mobility model. The Work Dir under the “Main” tab should be changed to  your ns directory.

  Click “Confirm Topology Setting” once you finish. Step 2: Under Random Traffic Generator, fill in the parameters required to generate the  traffic, and then click “Confirm Traffic Setting”. The topology and traffic file is  generated onto the directory specified by Work Dir. They are merged into the same file.  Step 1 should be executed before Step 2 is executed.

3 2 Simulation Environment Setting This GUI provides the cognitive wireless simulation selection based on the wireless  simulation TCL script for NS­2 [1].

3.1 2.1 Physical Layer Setting

A. Physical Layer Under PHY setting, several options are provided to configure the wireless physical layer. Propagation There are several selections for Propagation: TwoRayGround/FreeSpace. Antenna The default selection is OmniAntenna, which is the only supported antenna type in NS2.  Option is provided here for future extension. The above options are equivalent to the following code in TCL simulation script: #Define Options set val(prop) Propagation/TwoRayGround ;# radio-propagation model set val(ant) Antenna/OmniAntenna ;# antenna model

B. Channel/Spectrum Parameter Setting This section defines the number of interfaces per node and number of channels in the  network.

No. of Interfaces: This field indicates the number of interfaces per node. Default is 1 interface for each  node. When this field is larger than 1, the field No. of Channels should be set value equal  or larger than the value of No. of Interfaces. No. of Channels: This field indicates the number of channels to use in the network.  This section defines some spectrum parameter setting. Channel Decision Maker: The option routing means the multi­channels are only visible to routing layer. The option  routing/DSA means the multi­channels are visible to both routing and MAC layers. MaxTxPr:       This field defines the maximum transmission power for the Dynamic Spectrum Access  algorithm. NS2 C++ library is changed to read this filed. If MaxTxPr is empty, this  option will not affect the simulation. There is no equivalence to the TCL simulation script for MaxTxPr options.

3.2

2.2 MAC layer Setting

Several MAC protocols are provided as a selection options: 802_11/Maccon/Macng. Mac3 can be replaced by users’ new MAC protocol.  The detail TCL setting for CR MAC can be referred to this link.

3.3

2.3 Routing Setting

Routing Protocol The routing protocol selection includes AODV/DSR/WCETT[1].  Interface queue type It has two options DropTail/PriQueue,  Interface queue length This length can be variable. Default is 50. Routing1 and Routing2 can be replaced by users’ new routing protocol.  The detail TCL setting for CR Routing can be referred to this link.

3.4 2.4 Other Simulation Setting

No. of mobile nodes This field indicates the number of mobile nodes in the simulation scenarios. Please note  that this number should be consistent with the number defined in topology and traffic file. Simulation Stop Time This field indicates the time when simulation stops. Work Dir It   is   the   current   NS   working   directory:   XXX/ns­allinone­2.31/ns­2.31.   All   tcl   files  generated by this GUI will be stored under this directory. Output sim setting file(.tcl)          This field saves the simulation setting file into a .tcl file. This simulation file will  append with the topology and traffic file defined by user when the confirm button is  clicked. After the file appending   action, the complete simulation file has the same  name. This file will be generated under the directory specified by Work dir.

        Mobility & Traffic file This field specifies the location of topology and traffic file. User can provide topology  and   location  file  or generate  it under  Topology/Traffic Generator. This  topology  and  traffic file will be appended to the final executable file, whose name is given in Output sim setting file(.tcl).  Simulation File dir and name This field selects the simulation file. The simulation file can be the one provided by the  user or generated through the confirm action.             

3.5 2.5 Simulation Result Interference When this button is pressed, a figure will pop up showing the interference information on  the selected node and channel, which are selected in the fields of Show interference on   Node and On Channel. Note: When only one channel or one radio is defined, there is no interference   information recorded for this situation. Hence, there will be no figure showing up for   single channel network scenario.  Throughput When this button is clicked, the end to end throughput will display. User should specify  the traffic type according to the traffic file used in the simulation.

4 5 3. Random Topology/Traffic Generators The Topology/Traffic Generator incorporated in this GUI is described in the NS2 tutorial  [2], which is a component released with NS­2.

5.1 3.1 Random Topology Generator

This GUI contains version 2 topology generator under NS­2. The version 2 is enhanced  on version 1.  Node Num This field defines the number of nodes that have topology and movement information. PauseSel This field indicates whether the pause time is a constant, or it is uniform random between  [0, 2*pausetime].    PauseTime This field indicates the average pause between movements. SpeedSel This field indicates whether the speed is uniform random or just normal. MinSpeed

This field indicates minimum moving speed of a node. MaxSpeed This field indicates maximum moving speed of a node. SimTime This field defines the simulation stop time. MaxX It defines the maximum X coordinates among all the nodes. MaxY It defines the maximum Y coordinates among all the nodes. OutFileName It defines the output directory and topology file name, which will be used by in the main  window. It should be in the same directory as the Workdir.

5.2 3.2 Random Traffic Generator

TafficType It has two traffic types: CBR and TCP.

Seed The seed value for this random Traffic Generator. Connection This field specifies the maximum number of connections. Rate This field specifies the rate of packets. User should generate the topology file first, then generate the traffic file.

References: [1] Friedrich K. Jondral, “Software-defined radio: basics and evolution to cognitive radio,” EURASIP Journal on Wireless Communications and Networking, v.5 n.3, p.275283, 1 August 2005. [2] J. Neel, J.H. Reed, R.P. Gilles. "Convergence of Cognitive Radio Networks," Wireless Communications and Networking Conference 2004. [3] J. Mitola III and G.Q. Maguire Jr., “Cognitive radio: making software radios more personal,” IEEE Personal Communications, 6(4):13--18, August 1999. [4] C. Xin, “A novel layered graph model for topology formation and routing in dynamic spectrum access networks,” in Proc. IEEE DySPAN 2005, November 2005, pp. 308–317. [5] NS-2 www.isu.edu [6] http://www.ecsl.cs.sunysb.edu/multichannel/ [7] http://www.cse.msu.edu/~wangbo1/ns2/nshowto8.html [8] www.opnet.com [9] Ramon Aguero Callvo, Jesus Perez Campo, University of Cantabria, Adding Multiple Interface Support in NS-2. [10]1. R. Draves, J. Padhye, and B. Zill, “Routing in Multi-Radio, Multi-Hop Wireless Mesh Networks,” in ACM Annual Int'l. Conf. Mobile Comp. and Net. (MOBICOM), 2004, pp. 114-128. [11] www.qualnet.com [12] F. Wang and M. Krunz, “GMAC: A game-theoretic MAC protocol for mobile ad hoc networks,” in WiOpt’06, 2006.

FAQ 1. Complier error at NS-2

Recheck the Makefile under your ns directory. Make sure the newly added files are added in the Makefile. 2. Error in the cmu-trace.o You will meet the following error when the wcett is not compiled. Please make sure that the Makefile under the ns directory is added with newly added files. Refer to step 5 on the following link for the problem: http://stuweb.ee.mtu.edu/~ljialian/installation.htm

trace/cmu-trace.o: In function `hdr_wcett::access(Packet const*)': cmu-trace.cc:(.text._ZN9hdr_wcett6accessEPK6Packet[hdr_wcett::access(Packet const*)]+0x7): undefined reference to `hdr_wcett::offset_' collect2: ld returned 1 exit status make: *** [ns] Error 1

3. I have added the codes in the Makefile,but after running the commands in step6, the codes I added disappeared. Please do not run ./configure. Just run the following command: make clean make configure make 4. When a channel receives a packet, to which interface or radio the channel should forward the packet? The packet will be only forwarded to the interface associated with the channel. 5. How to handle the situation when the number of channels a node wants to access is dynamic? During the configuration for the TCL script, the channel number should be defined to the maximal number the simulation required. During the simulation, how many channels a node can access totally depends on user's algorithm.

6. Error when run crcn.jar Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException at javax.swing.ScrollPaneLayout.preferredLayoutSize(ScrollPaneLayout.java:495) at java.awt.Container.preferredSize(Container.java:1670) at java.awt.Container.getPreferredSize(Container.java:1655) at javax.swing.JComponent.getPreferredSize(JComponent.java:1646) at java.awt.FlowLayout.preferredLayoutSize(FlowLayout.java:415) at java.awt.Container.preferredSize(Container.java:1670) at java.awt.Container.getPreferredSize(Container.java:1655) at javax.swing.JComponent.getPreferredSize(JComponent.java:1646) at java.awt.FlowLayout.preferredLayoutSize(FlowLayout.java:415) at java.awt.Container.preferredSize(Container.java:1670) at java.awt.Container.getPreferredSize(Container.java:1655) at javax.swing.JComponent.getPreferredSize(JComponent.java:1646)

You need to install JDK 1.6 or above

7. Why there is nothing shown on the interference graph with the GUI? You need to specify the node and channel as shown in red in the following graph. Also, interference information is also related to your topology setting. Make sure that nodes are within the communication range.

8. How to set datarate in different channels in CRN

There are two ways to do this. (1) It is implemented through the TCL script. You can check the mac-802_11.cc file to see how they get the datarate from the TCL and write the similar code. You need to pass two variables from TCL: datarate and channel index. (2) Another way easy is to just add the code in the macxx.cc, judge what current channel is at the run time, and assign the corresponding data rate 9. How is the sensing of primary user being done? It is not included in CRCN. 10. In the MAC for CRCN, there is a MAC called Maccon. In maccon.cc, I find the code as follows: Maccon::Maccon() : Mac() { rx_state_ = tx_state_ = MAC_IDLE;

tx_active_ = 0; waitTimer = new MacconWaitTimer(this); sendTimer = new MacconSendTimer(this); recvTimer = new MacconRecvTimer(this); // Added by Sushmita to support event tracing ([email protected]) et_ = new EventTrace(); busy_ = 0; bind("fullduplex_mode_", &fullduplex_mode_); //randomly assigned channel usages chan[0]= 1; chan[1] = 0; chan[2] = 1; chan[3] = 2; chan[4] = 2; chan[5] = 0; } I do not quite understand this part. //randomly assigned channel usages chan[0]= 1; chan[1] = 0; chan[2] = 1; chan[3] = 2; chan[4] = 2; chan[5] = 0; What does these "1,0,1,2..." mean? First of all, I want to clarify that this MAC is just to show how to use the interfaces (functions) provided by this simulator. Coming to the questions, usually the channel assignment will be decided by algorithms. Here we just simply assign specific channel to each radio. chan[0] and etc is the radio. The number after that is the channel. 11. Is there a MAC for each interface? Or for all interfaces? (In case you choose more than one interface). Based on the NS-2 software structure and our enhancement, a MAC can handle the data in each interface. For example, one of the interfaces is reserved for the control information, and the other interface is used for data information. However, the MAC algorithms need to handle their collision scheme. But the following scenarios are not supported. For example, use 802.11 and 802.16 at the same time in NS-2.

12.Why there is no throughput shown up in the GUI? According to the traffic type, you will need to select the “Traffic type” in the GUI to tcp or cbr as shown in the following graph. Different perl script will be used for the traffic calculation according to the selection. Besides, you can look at the trace file to see whether your transmission is successful with your script.

13. There is nothing happen when I hit the” Throughput” button on the GUI. Please make sure the “Work Dir “ has the directory path to your NS-2 directory, assuming that you put all of your scripts under the NS-2 root directory (e.g./root/nsallinone-2.31/ns-2.31).

14. Is the GUI working together with NS-2? Yes. As the GUI will call some functions in the NS-2. However, you can run the ns-2 part independently. 15. Is the cygwin version supported? This simulator has not been tested under the cygwin environment. However, the NS-2 portion can be used under the cygwin environment. 16. How could I see channels' switching? The channel switching is indicated by the channel array switching at the Physical layer. 17. How to implement the primary user sensing? There are two simple ways: a) Specify a node as a primary user and broadcast the packet (with some primary user information in a packet) b) Use a random generator to simulate the channel usage.

18. In Trafficfile, what is meant by Traffic information column? In other words, what do values in this column mean? Is it a ratio of something, how does the simulator derives this number? It is the number of how many packets have been successfully received by a node during a period. 19. In ITfile, what is meant by interference column? What i am asking is how does the simulator derive this number? Could you mention about how can I interpret this value? Does it have a unit? The value is the receive power from other nodes that are not the current communication source/destination. 20. Again in ITfile there exists a column (rightmost) which is not mentioned in the manual on web that you introduce ITfile format. So what does this column stand for? It is the channel with minimum interference. 21. I have to put these lines in makefile but where exactly and where in makefile or makefile.in or makefile.vc . You can add it in the makefile under OBJ_CC = \