Stevens Institute of Technology

RF Spectrum Analysis
Simulation of a Cognitive Radio Environment for Frequency Allocation in MATLAB
Suraj Chokshi (surajyanknets@gmail.com) May Chum (may.chum@gmail.com) Angela Dorstek (adorstek@gmail.com) Research Mentor: Professor Yu-Dong Yao, Ph.D Student Nansai Hu

REU 2010

TABLE OF CONTENTS
Abstract Introduction System Model GUI Development Machine Learning Process Policing Policy User Statistics Challenges Further Improvements Conclusion Acknowledgements References Appendix I Source Code Appendix II Weekly Reports I. May Chum II. Angela Dorstek III. Suraj Chokshi 51 81 106 3 4 7 13 15 19 20 21 22 23 24 25 26

2|Page

ABSTRACT

The radio frequency spectrum is composed of licensed and unlicensed bands that are allocated by the Federal Communications Commission (FCC) for various communication activities. The spectrum is highly congested and calls for a new method to optimize the use of spectrum to accommodate additional users such as secondary users (users beyond primary users). This project utilizes the mathematical computing software Matrix Laboratory (MATLAB) to simulate a cognitive radio environment, which is a radio that is learning based on environmental factors. The purpose of the research is to find a way that optimizes all users operation within the spectrum with minimal interference and noise levels. The designed program aims for efficient collaboration between secondary users by incorporating machine learning behavior through analyzing user statistics. The resulting system architecture satisfies the objective with a simple cognitive radio implementation. The computer program works best with small number of user inputs relative to the total number of channels and threshold value. With a high number of users, the results become inconclusive due to excessive amounts of collisions between secondary users.

3|Page

INTRODUCTION

The FCC is in charge of the distribution of the radio frequency spectrum. There are many frequency bands that are congested because of the amount of users such as cellular phones and WiFi. Users in these bands are being dropped because of the overcapacity of the bands. A potential solution to the limited spectrum access problem is through spectrum sharing [1]. There are under utilized bands such as amateur radio where users in congested bands can take advantage of to decrease the congestion and accommodate new wireless technologies.

http://i155.photobucket.com/albums/s302/JigsOldSaws/allocation.jpg

Software Defined Radio A software defined radio is a traditional radio that replaces hardware components with software components with the same or better functionality.

4|Page

Cognitive Radio A cognitive radio is a radio that tries to optimize spectrum usage between authorized and unauthorized users through machine learning behavior. Primary and Secondary Users The distribution of the radio spectrum is done by the FCC. Primary users are licensed users within licensed bands. Secondary users are unlicensed users that are trying to access the licensed band without interfering with primary users. [2] Spectrum Holes Spectrum holes are white spaces within under utilized licensed bands. These are the channels that have a low enough interference and noise level that still allows secondary user to operate satisfactorily. [3]

Threshold Value The threshold value, also known as the interference temperature, is the amount of noise and interference such that any value below it will be considered a spectrum hole and everything above the value is considered non viable for spectrum sharing. Slow Frequency Hopping Secondary users can remain in the channel that they have successfully entered into for multiple time steps without hopping to an alternate open channel. Fast Frequency Hopping Secondary users randomly pick a white space because they want to transmit a message. After each time step, secondary users scan the radio frequency spectrum for white spaces and randomly choose one to send another message. [3]

5|Page

MATLAB Programming For this project, two components were essential to the MATLAB simulation: the graphic user interface (GUI) and the source code. The GUI is what the audience sees when they use the program. program needs to be user-friendly and easily understood. The

The source code is where the specific

implementation of the cognitive radio environment takes place. When the written source code is executed, the calculated information is displayed in the GUI.

6|Page

S Y S T E M M O DE L
Model Overview When developing the MATLAB simulation of the cognitive radio environment, the research team determined a set of rules and assumptions that would form the basis for the research model. One of the main goals when designing the model was defining the key components that would form the traffic data within the radio spectrum. The traffic data consists of primary users, authorized users, unauthorized users, and police/administrator. In addition, the research team made a set of assumptions or rules that each of these users would follow. Time Steps During a simulation, each unit of time was referred to as a time step. When the program started, it ran through one time step. The user could change the input for the number of time steps in the GUI and could run the simulation for that period of time. Primary Users The traffic data consisted of primary users that were occupying channels within the radio spectrum band. In the MATLAB simulation model, the number primary users generated when the program started was determined by the input parameter for traffic threshold. The simulation generated a random number between 0.0 and 1.0 for each channel within the radio spectrum. Whether the randomly generated number for a particular channel was larger than the set traffic threshold determined if there was a primary user occupying that channel. The input parameter for traffic threshold could be set to be 0.1 to .06. The lower the traffic threshold, the more likely a larger number of primary users would be generated causing higher congestion within the radio spectrum. This input variable could allow the user to test various different congestion levels that could occur within the radio spectrum. Furthermore,

each time step after the program started, a total of zero to two primary users could enter or leave the radio spectrum band. The program randomly chose two channels from the band and re-generated traffic data for those channels following the same process as when the program started. In the GUI a primary user was represented by a black bar within a particular channel. Any channel that did not have a primary user was considered unoccupied or a white space.

7|Page

Authorized Users Authorized users were secondary users and consisted of users that were authorized /licensed to use any unoccupied channel within the radio spectrum band. The number of authorized users that attempted to enter the spectrum was determined by the user input in the GUI. The total number of authorized users could be changed throughout the simulation and can range from zero and twenty users. During each time step, each authorized would randomly select an open channel, individually, within the band. In the GUI an authorized user occupying a particular channel was represented by a blue bar within that channel. Unauthorized Users Unauthorized users were also secondary users and consisted of users who were unauthorized/ unlicensed to use certain channels within the radio spectrum. However, despite being unauthorized, these users would also attempt to use any unoccupied channel within the radio spectrum band. The number of unauthorized users that attempted to enter the spectrum was also determined by the user input in the GUI. Similarly, the number of unauthorized users could change throughout the simulation and can range from a total zero to twenty users. Like the authorized user, each unauthorized user would randomly select and open channel, individually, during each time step. In the GUI an unauthorized user occupying a particular channel was represented by a red bar within that channel. User Collisions and Interference: User collisions occurred when multiple secondary users attempted to use to the same channel during a particular time step causing interference. This could occur because secondary users were not able to communicate with each other and were unaware about what channels other users would decide to use. During a user collision, each secondary user involved in the collision was unsuccessful in completing their particular task and resulted in a bad event for these users. Furthermore, when a collision occurred, each secondary user involved in the collision must wait till the next time step to find another open channel to use. In the GUI, user collisions within the band were displayed in the Collision Data plot during each time step. A collision in a particular channel was represented by a black bar in that channel. 8|Page

Administrator/Police Collisions: The administrator/police monitors a particular band of channels within the radio spectrum. The policing band is determined by the input parameter for policing band in the GUI. The main function of the police is to punish unauthorized users that attempt to use restricted channels. The police punishes an unauthorized by jamming the user causing a collision and bad event for that user. In addition, the unauthorized user does not know which channels are being monitored by the police and cannot distinguish between a collision between the police or other secondary users. In the GUI a police collision within the radio spectrum band was also displayed in the Collision Data plot during each time step. A police collision in a particular channel was represented by a blue bar in that channel. The administrator/police is further explained in the Policing Policy section. Fast Frequency Hopping: This model of the cognitive radio environment used the assumption of fast frequency hopping. In this assumption, each secondary user randomly selected a new open channel each time step. Each secondary was assumed to be sending only one packet of information, thus only requiring the particular channel for one time step. In contrast, in a more generic case, each secondary user may want to send more than one packet of information thus requiring more than one time step to complete this task. The generic case was explored by the other cognitive radio research team that is working with Java simulation. Logic Diagrams/Flowcharts The diagrams below further explain the rules and assumptions that each user follows during the simulations. During the development process these flowcharts were crucial in designing the overall system model.

9|Page

Authorized User:

10 | P a g e

Unauthorized User:

11 | P a g e

Police:

12 | P a g e

G R A P H I C US E R I N T E R F A C E ( G U I ) D E V E L O P M E N T

The GUI started as a simple MATLAB window with one graph that illustrated the two bands, twenty channels. Originally, all the information was going to be on set of axes because it seemed to be the best way to display all the data without confusion. However, as the system model was improved throughout the ten weeks, the GUI needed to be changed.

The final version of the GUI included two graphs that were used to simulate a cognitive radio environment. The first graph displayed the randomly generated signals for each channel and the locations of secondary users. Primary, authorized, and unauthorized users were color coded with black, blue, and red bars respectively. There was a color bar right next to the main graph that told the audience what each color represented. The second graph showed where collisions between secondary users and police collisions occurred. There were two panels that included entry and drop down boxes that allowed for users to input their desired parameters. Some of the parameters available for change were: total number of channels, number of authorized and unauthorized users, policing band, and threshold value. There were three other minor plots that display user statistics. Users could choose to add a best fit line using the polyfit button to see the trend of the radios learning behavior.

13 | P a g e

After deciding the placement of the axes, user entry boxes, and buttons, MATLAB auto-generated a code for the GUI. The programmer then had to write a source code that when evaluated, would display all calculated information on the GUI. The following is the final version for the GUI in MATLAB:

14 | P a g e

MACHINE LEARNING PROCESS

In order to improve overall allocation efficiency of open white space among users a basic machine learning/cognitive behavior was implemented with all authorized and unauthorized users. Allocation efficiency was improved by decreasing the probability of user and police collisions, bad events, that occurred within the radio spectrum. This was achieved by allowing each secondary user to keep an individual memory of when and where bad events occurred. A different machine learning behavior was applied to authorized and unauthorized users, which both helped improve the overall spectrum sensing performance for all users after running the simulation for a long time period.

Authorized User:

Each authorized user stored an individual memory of pervious events that occurred within the traffic band. If a bad event occurred 3 consecutive times at a particular channel, the authorized user would consider this channel as unreliable and a bad channel. The authorized user would only use this channel if all other channels were occupied. This allowed authorized users to avoid channels that were highly congested and try to occupy other channels first.

Unauthorized user:

Similarly, each unauthorized user also stored an individual memory of pervious events that occurred within the traffic band. In contrast, for the unauthorized user, if a bad event occured 4 consecutive times at a particular channel, the authorized user would always avoid that channel in the future. Since the unauthorized user could not distinguish between secondary user collisions and police collisions, it would assume these bad channels were being monitored by the police because the probability of bad events was so high. Thus, after a long time period, each unauthorized user would learn to avoid the police monitored band of channels. However, if an unauthorized user was able to successfully use a channel once they would remember not to avoid that channel and consider it a good channel. Furthermore, every 50 time steps, each unauthorized user would try to enter any open channel regardless of its previous punish memory. It does this to check whether police monitoring has stopped.

15 | P a g e

Improved Allocation Performance:

After running various simulations the research team concluded that this machine learning behavior was more effective when the number of secondary users was low relative to the number of open channels. As a result, the input parameters for number of channels in radio spectrum band and traffic threshold were key variables when testing the machine learning behavior. In addition, the allocation performance was much more effective when running the simulation with unauthorized users because these users eventually learned not to use certain channels. Nonetheless, the cognitive behavior of the secondary users did improve performance over time in most situations.

In the figures below, the graphs display Probability of Bad Events vs. Time for the authorized users and unauthorized users.

Simulation 1:

Number of Channels: 20 Traffic Threshold: 0.5 Authorized Users: 3 Unauthorized Users: 3 Policing Band: Channels 1-10 Simulation Length: 250 Timesteps The Number of secondary users was not too high compared to the number of open channels, thus machine learning behavior improved overall spectrum sensing efficiency for all users. Downward slope of best fit curves demonstrates this behavior.

16 | P a g e

Simulation 2:

Number of Channels: 30 Traffic Threshold: 0.5 Authorized Users: 4 Unauthorized Users: 6 Policing Band: Channels 1-15 Simulation Length: 400 Timesteps In this simulation there was a moderate level of secondary users compared to open channels within the band. Results were more conclusive for unauthorized user probability of bad events.

Simulation 3:

Number of Channels: 10 Traffic Threshold: 0.2 Authorized Users: 2 Unauthorized Users: 1 Policing Band: Channels 1-5 Simulation Length: 300 Timesteps In this simulation even though the number of secondary users was very low, the traffic threshold of .2 and small number of channels caused very high congestion of primary users within the radio spectrum band and very little unoccupied white space. As a result, overall performance improvement was not significant. However, authorized user performance did improve slightly.

17 | P a g e

Channel Sharing:

Enabling Channel sharing within the cognitive radio environment allowed two secondary users to share a channel within the traffic band without triggering a collision or a bad event. The user could enable channel sharing before running a simulation within the GUI. By enabling channel sharing it decreased the number of bad events that occurred within the radio spectrum. However, if more than two users tried to access the same channel it would cause high interference and would trigger a collision.

18 | P a g e

POLICING POLICY

The program contained a feature, a police, that would maintain order within the simulation. As previously stated, the three types of users were Primary, Authorized and Unauthorized Users. The Primary User was allowed to use whatever band they wanted, whenever they wanted. The Authorized Users were allowed to use any band provided that they avoided the Primary User. Finally, the Unauthorized Users were limited to certain bands. Depending on what is set on the GUI, the

Unauthorized Users were blocked from either bands 1-5, 1-10 or 1-15. The function of the Police User was to monitor that certain range of bands (pre-set on the GUI) to be sure the Unauthorized User was not using a restricted band. If the Unauthorized User was on a restricted band, the Police would step in and collide with the user on this band. The Unauthorized User would not see this as a Police Collision, but just a collision in general. As long as there was no collision on the band already, the Police will step in to create a collision for the Unauthorized User, so the Unauthorized User could not access that band.

19 | P a g e

USER STATISTICS

Unfortunately, the program started off with a high count of bad events occurring. As the Users learned and became smarter, the bad events would decrease. As more Users were added (these users have not learned yet) the bad events would increase, because the users have not learned what channels to avoid. Also, as there were more users, there was more traffic in the simulation, which increased the probability of collisions between users. The program recognized this, and displayed a percentage of the average number of bad events per user over the number of times the program had run with that number of users. Each time the program was run, the graph would change, displaying a different (although it might be similar) number along the x-axis (which is number of users). After the program was run many times, the graph showed that when there are more users, there were inevitably more collisions, but if a user watched the graph plotting, it could be observed that the percentage of bad events per user over time was decreasing in the number of user slots. An observer could also change the graph to display: the average number of bad events per authorized user over time, or the average number of bad events per unauthorized user over time. When the user manually changed the graph, the graph was displayed as a line plot, but when the program automatically graphed the data after each time step, the graph was displayed as a bar graph.

20 | P a g e

CHALLENGES

Along the way, there were many challenges that the group had to overcome. The group members were not familiar with the programming interface within MATLAB and had to learn the syntax within the software. The computer program started as a simplified model of a cognitive radio environment, and was slowly built upon. As new ideas started to form for how to improve the simulation, the code needed to be reorganized. Originally, everything was hard-coded, but currently, the program utilizes the calling of functions. It became more organized and efficient. The major challenge in the whole research project was defining our system model and clarifying what was the desired behavior of each user. The system model was the foundation for the cognitive radio and was repeatedly enhanced.

21 | P a g e

FUTURE IMPROVEMENTS

The computer program in MATLAB uses a random number generating function to generate signals for all the channels within the two bands. It would be more realistic if the program is able to input real time signal from the environment. A cognitive radio is able to learn by gathering information from the changing environmental factors and reacting to it with an appropriate response. The computer program can only produce theoretical data, but with real time data, it would produce accurate results. Secondary users are randomly picking white spaces within the two bands. To optimize spectrum usage, the computer program should allocate incoming secondary users to specific channels. If consecutive channels are occupied, the signals for the users within those channels may interfere. To enhance the efficiency of the computer program, the computer program should be able to separate them far enough such that their signals will not affect each other. Throughout the whole research project, the group has been trying to incorporate game theoretic aspects into the program. There is a lack of communication between the users and competition within the program which makes implementation of game theory difficult.

22 | P a g e

CONCLUSION

Based on the established system model for our research project, the MATLAB programmed simulation of a cognitive radio was done successfully. Our defined user behavior for the primary, secondary and police users were implemented as indicated of the logic diagrams. Each user was programmed with a simple level of machine learning which optimized spectrum usage to a greater level. The GUI allowed the user to define their desired set of parameters. The varying input variables let the user observe different scenarios. The GUI was created such that it was user friendly and easy to understand. There are labels for each plot and color coded graphs to make it more visually appealing for the audience.

As the user statistics illustrate, the optimal scenario is when there are a low number of secondary users. As the amount of secondary users increase, the number of collisions increases. Unauthorized users are dropped from one of three possibilities: user collision, police collision, or when there are no white spaces available. If there are a high number of unauthorized users in a time step, there is a higher chance that more collisions occur. Despite this setback, the concept of spectrum holes does prove to be a potential solution to the radio spectrum congestion problem. There are too many bands that are under utilized and congested wireless bands should take advantage of these available white spaces to use the RF spectrum to its full capacity.

23 | P a g e

ACKNOWLEDGEMENTS

We would like to thank the National Science Foundation Research Experience for Undergraduates and the Stevens Institute of Technology for this opportunity. A special thanks to Dr. Yu-Dong Yao, Professor and Department Director of Electrical and Computer Engineering, Nansai Hu, Dr. Hong Man, Professor Bruce McNair, Maria Toloza, and Cecilia Jololian. And of course, a thanks to all the REU students for making this summer a wonderful journey.

24 | P a g e

REFERENCES

[1] Haykin, Simon. Cognitive Radio: Brain Empowered Wireless Communications. Selected Areas in Communications, Vol. 23, No. 2, February 2005. Page(s): 201-220.

IEEE Journal on

[2] Cabric, Danijela. Mishra, Shridhar M. Brodersen, Robert W. Implementation Issues in Spectrum Sensing for Cognitive Radios. Berkeley Wireless Research Center, University of California, Berkeley. [3] Singh, Santosh K. Roy, Krishna C. Pathak, Vibhakar. Channels Reallocation in Cognitive Radio Networks Based on DNA Sequence Alignment. International Journal of Next-Generation Networks (IJNGN) Vol.2, No.2, June 2010. Page(s): 23-34

25 | P a g e

APPENDIX I SOURCE CODE

function varargout = Cognitive_Radio_Simulation_Matlab_Final_Version(varargin) gui_Singleton = 1; gui_State = struct('gui_Name', mfilename, ... 'gui_Singleton', gui_Singleton, ... 'gui_OpeningFcn', @Cognitive_Radio_Simulation_Matlab_Final_Version_OpeningFcn, ... 'gui_OutputFcn', @Cognitive_Radio_Simulation_Matlab_Final_Version_OutputFcn, ... 'gui_LayoutFcn', [] , ... 'gui_Callback', []); if nargin && ischar(varargin{1}) gui_State.gui_Callback = str2func(varargin{1}); end if nargout [varargout{1:nargout}] = gui_mainfcn(gui_State, varargin{:}); else gui_mainfcn(gui_State, varargin{:}); end % End initialization code - DO NOT EDIT

function Cognitive_Radio_Simulation_Matlab_Final_Version_OpeningFcn(hObject, eventdata, handles, varargin) handles.output = hObject; guidata(hObject, handles);

function varargout = Cognitive_Radio_Simulation_Matlab_Final_Version_OutputFcn(hObject, eventdata, handles) varargout{1} = handles.output; % Initialize variable to default value when program start handles.start = 0; handles.nchannels =20; handles.numchannels = handles.nchannels; handles.threshold =0; handles.timestep = 1; handles.numauth = 0; handles.numunauth = 0; handles.csharing = 1; handles.time_two =0; %Matrix dimensions are 20 X number of channels in band %There are max of 20 Authorized Users and 20 Unauthorized user %Rows represent different Users %Columns represent different channels

26 | P a g e

handles.traffic = zeros (20, handles.numchannels); handles.punishmemory = zeros(20, handles.numchannels); handles.punishmemorytwo = zeros(20,handles.numchannels); handles.accessmemory = zeros (20, handles.numchannels); handles.policeband = 10; handles.pband = 10; handles.plot = 1; %Set the probability matrices handles.probunauth = zeros(1,40); handles.probtotal = zeros(1,40); handles.runtimeall = zeros(3,40); handles.badall = zeros(3,40); %Update gui handles values guidata(hObject, handles);

function scantraffic_Callback(hObject, eventdata, handles) %if start==2, program is at 2nd timestep call all functions if handles.start == 2 %this will reset the tally of bad events each timestep for i = 1:handles.timestep [handles] = runtime(handles); [handles] = bad(handles); [handles] = primaryuser(handles); [handles] = totaltraffic(handles); [handles] = authuser(handles); [handles] = unauthuser(handles); [handles] = collide(handles); [handles] = police(handles); [handles] = collidemain (handles); [handles] = probability(handles); [handles] = statistics(handles); [handles] = graphdata (handles); [handles] = tryagain_unauth(handles);

27 | P a g e

guidata(hObject, handles); pause(.1) end end %if start==1, program is at 1st timestep call all functions except primary %user function if handles.start == 1 for i = 1:handles.timestep [handles] = runtime(handles); [handles] = bad(handles); [handles] = totaltraffic(handles); [handles] = authuser(handles); [handles] = unauthuser(handles); [handles] = collide(handles); [handles] = police(handles); [handles] = collidemain(handles); [handles] = probability(handles); [handles] = statistics(handles); [handles] = graphdata (handles); [handles] = tryagain_unauth(handles); guidata(hObject, handles); pause(.1) handles.start = 2; end end guidata(hObject, handles); % Generate random traffic data function [handles] = trafficgen (handles) %If User did not select traffic threshold set .4 as default threshold if handles.threshold == 0

28 | P a g e

handles.threshold = .4; end %Set Traffic Matrix to zero handles.traffic = zeros(20,handles.numchannels);

for n = 1:handles.numchannels %For each Channel generate random nummber between 0 and 1 %If random number is less than traffic threshold, set traffic in that %channel to 0 %If random number is more than the traffic threshold, set traffic in %that channel to 1 r = rand; for i = 1:20 if r < handles.threshold handles.traffic(i, n) = 0; else handles.traffic(i, n) = 1; end end end %Find and Save the Total amount of Primary Users during TimeStep function [handles] = totaltraffic (handles) %Variable for the total amount of Priamry Users handles.Ttraffic = 0; for n = 1:handles.numchannels; handles.Ttraffic = handles.Ttraffic + handles.traffic(1, n); end

function [handles] = primaryuser(handles) generate = floor(3*rand + 1); %Run for loop for random number of times between 1 and 3 %For (1 to 3) random channels generate random number again. If random %number is less than 0 set traffic in channel to 0 else set traffic to 1 for i = 1:generate

change = floor(handles.numchannels*rand + 1); r = rand; for n = 1:20 if r < handles.threshold handles.traffic(n, change) = 0; else

29 | P a g e

handles.traffic(n, change) = 1; end end end

%Authorized User find white space function [handles] = authuser(handles) handles.authdata = zeros(20, handles.numchannels); handles.authdata_graph = zeros(1,handles.numchannels); for i =1:20 for n =1:handles.numchannels if (handles.failmemory_auth(i, n) > 2) handles.failmemory_auth_save(i, n) =1; end end end %handles.open combines traffic and failmemory for each user handles.open_auth = handles.failmemory_auth_save + handles.traffic;

if handles.Ttraffic < handles.numchannels for i = 1:handles.numauth AUspot = floor(handles.numchannels*rand + 1); handles.Topen_auth = 0; for n = 1:handles.numchannels; handles.Topen_auth = handles.Topen_auth + handles.open_auth(i, n); end if handles.Topen_auth < handles.numchannels while handles.open_auth(i, AUspot) ~= 0 AUspot = floor(handles.numchannels*rand + 1); end else while handles.traffic(i, AUspot) ~= 0 AUspot = floor(handles.numchannels*rand + 1); end end handles.authdata(i, AUspot) =1; handles.authdata_graph(AUspot) = handles.authdata_graph(AUspot) + 1; end end %Unauthorized User find white space

30 | P a g e

function [handles] = unauthuser(handles) handles.unauthdata = zeros(20,handles.numchannels); handles.unauthdata_graph = zeros(1,handles.numchannels);

%Check which channels consecutive punishmemory is more than 2 %if more than 2 set that channel in punishmemorytwo to 1 (User will not use %that channel anymore) %If Accessmemory is more than 2 clear punish memories for i =1:20 for n =1:handles.numchannels if (handles.punishmemory(i, n) > 3) handles.punishmemorytwo(i, n) =1; end if (handles.accessmemory(i, n) == 1) handles.punishmemory(i,n) = 0; handles.punishmemorytwo(i, n) = 0; end end end %handles.open combines traffic and punishmemory for each user handles.open = handles.punishmemorytwo + handles.traffic;

%If there are any white spaces randomly find and use a white space if handles.Ttraffic < handles.numchannels for i = 1:handles.numunauth UNspot = floor(handles.numchannels*rand + 1);

handles.Topen = 0; for n = 1:handles.numchannels; handles.Topen = handles.Topen + handles.open(i, n); end if handles.Topen < handles.numchannels while handles.open(i, UNspot) ~= 0 UNspot = floor(handles.numchannels*rand + 1); end %else % while handles.traffic(i, UNspot) ~= 0 % UNspot = floor(handles.numchannels*rand + 1); % end %end handles.unauthdata(i,UNspot) = 1; handles.unauthdata_graph (UNspot) = handles.unauthdata_graph(UNspot) + 1; end

31 | P a g e

end end

%Check and punish if unauthorized user is using a channel in policemonitored band function [handles] = police (handles) handles.policedata = zeros(20,handles.numchannels); %If unauthorized user is using a channel in police monitored band set %police data to 1 in that spot for i = 1:handles.policeband if handles.unauthdata_graph(i) <= handles.channel_sharing && handles.unauthdata_graph(i) > 0 for n = 1:20 if (handles.unauthdata_graph(i) == handles.channel_sharing && handles.unauthdata(n, i) == 1 && handles.authdata_graph(i) ==0) handles.policedata(n, i) = 1; elseif (handles.unauthdata_graph(i) < handles.channel_sharing && handles.unauthdata(n, i) == 1 && handles.authdata_graph(i) ==1) handles.policedata(n, i) = 1; end end end end %If policedata is 1 for user in a certain channel, increment the %punishmemory for that user in that channel %If unauthorized user successfully gets into a channle increment %accessmemory for that channel for i = 1:20 for n = 1:handles.numchannels if handles.policedata(i,n) == 1 handles.punishmemory(i,n) = handles.punishmemory(i,n) + 1; handles.unauthbad = handles.unauthbad + handles.unauthdata_graph(n); elseif handles.collision(i,n) == 1 handles.punishmemory(i,n) = handles.punishmemory(i,n) + 1; elseif (handles.collision(i, n) == 0) && (handles.unauthdata(i, n) == handles.channel_sharing) && (handles.policedata(i, n) == 0); handles.punishmemory(i, n) = 0; handles.accessmemory(i, n) = 1 ; end end end

%Check for Collisions between Unauthorized vs Unauthorized and Authrorized vs Unauthorized Users %Collision matrix used whithin Police function

32 | P a g e

function [handles] = collide (handles) handles.collision = zeros(20,handles.numchannels); for i = 1:handles.numchannels if (handles.unauthdata_graph(i) > handles.channel_sharing && handles.authdata_graph(i) <1) for n =1:20 if handles.unauthdata (n,i) ==1 handles.collision(n, i) = 1; end end elseif (handles.unauthdata_graph(i) >= handles.channel_sharing && handles.authdata_graph(i) >= 1) for n =1:20 if handles.unauthdata (n,i) ==1 handles.collision(n, i) = 1; end end elseif (handles.unauthdata_graph(i) >= 1 && handles.authdata_graph(i) >= handles.channel_sharing) for n =1:20 if handles.unauthdata (n,i) ==1 handles.collision(n, i) = 1; end end end end

%Check for Collisions between Authorized vs Authorized, Authorized vs Unauthorized, and Unauthorized vs Unauthorized function [handles] = collidemain (handles) handles.collisionmain = zeros(1,handles.numchannels); for i = 1:handles.numchannels if (handles.unauthdata_graph(i) > handles.channel_sharing && handles.authdata_graph(i) < 1) handles.collisionmain(i) = 1; handles.unauthbad = handles.unauthbad + handles.unauthdata_graph(i); elseif (handles.unauthdata_graph(i) >= handles.channel_sharing && handles.authdata_graph(i) >= 1) handles.collisionmain(i) = 1; handles.unauthbad = handles.unauthbad + handles.unauthdata_graph(i); handles.authbad = handles.authbad + handles.authdata_graph(i);

33 | P a g e

elseif (handles.authdata_graph(i) > handles.channel_sharing && handles.unauthdata_graph(i) < 1) handles.collisionmain(i) = 1; handles.authbad = handles.authbad + handles.authdata_graph(i); elseif (handles.authdata_graph(i) >= handles.channel_sharing && handles.unauthdata_graph(i) >= 1) handles.collisionmain(i) = 1; handles.authbad = handles.authbad + handles.authdata_graph(i); handles.unauthbad = handles.unauthbad + handles.unauthdata_graph(i); end end

for i = 1:handles.numauth for n =1:handles.numchannels if (handles.collisionmain(n) == 1) && (handles.authdata(i, n) == 1) handles.failmemory_auth(i ,n) = handles.failmemory_auth(i ,n) + 1; elseif (handles.collisionmain(n) == 0) && (handles.authdata(i, n) == 1) handles.failmemory_auth(i ,n) = 0; end end end

%Compute statistics for Probabilty of Bad events vs Time plots function [handles] = statistics(handles)

if handles.time == 20 || handles.time == 0 handles.time = 0; handles.events_unauthuser =0; handles.badevents_unauthuser = 0; handles.events_authuser =0; handles.badevents_authuser =0; end if handles.time_two == 50 handles.time_two = 0; end handles.time_two = handles.time_two +1; handles.time = handles.time +1; for i = 1: handles.numchannels if handles.unauthdata_graph(i) == 1 && handles.authdata_graph(i) == 1 handles.badevents_authuser = handles.badevents_authuser + 1; end

34 | P a g e

if handles.authdata_graph(i) > 1 handles.badevents_authuser = handles.badevents_authuser + handles.authdata_graph(i); end if handles.unauthdata_graph(i) == 1 && handles.authdata_graph(i) == 1 handles.badevents_unauthuser = handles.badevents_unauthuser + 1 ; end if handles.unauthdata_graph(i) > 1 handles.badevents_unauthuser = handles.unauthdata_graph(i) + handles.badevents_unauthuser; end for n = 1:20 if handles.policedata (n, i) ==1 handles.badevents_unauthuser = handles.badevents_unauthuser + 1; end end end

%for i =1:handles.numchannels % handles.events_unauthuser = handles.unauthdata_graph(i) + handles.events_unauthuser; %end handles.events_authuser = handles.numauth + handles.events_authuser; handles.events_unauthuser = handles.numunauth + handles.events_unauthuser;

if handles.events_unauthuser ~=0 handles.badstat_unauthuser(handles.time) = handles.badevents_unauthuser / handles.events_unauthuser; end if handles.events_authuser ~=0 handles.badstat_authuser(handles.time) = handles.badevents_authuser / handles.events_authuser; end

if handles.time == 20 handles.timestep_interval = handles.timestep_interval + 1; handles.twenty_timestep_interval = handles.twenty_timestep_interval +20; if handles.events_unauthuser ~=0 handles.badstat_unauthuser_graph(handles.timestep_interval) = handles.badstat_unauthuser(handles.time); handles.badstat_unauthuser_graph_two(handles.timestep_interval) = handles.twenty_timestep_interval;

35 | P a g e

end if handles.events_authuser ~=0 handles.badstat_authuser_graph(handles.timestep_interval) = handles.badstat_authuser(handles.time); handles.badstat_authuser_graph_two(handles.timestep_interval) = handles.twenty_timestep_interval; end

end

function [handles] = bad(handles) handles.authbad = 0; handles.unauthbad = 0; handles.badevents = 0;

function [handles] = runtime(handles) handles.totalusers = handles.numauth + handles.numunauth; if handles.numauth ~= 0 && handles.numunauth ~= 0 handles.runtimeall(1, handles.numauth) = handles.runtimeall(1, handles.numauth) + 1; handles.runtimeall(2, handles.numunauth) = handles.runtimeall(2, handles.numunauth) + 1; handles.runtimeall(3, handles.totalusers) = handles.runtimeall(3, handles.totalusers) + 1; elseif handles.numauth ~= 0 || handles.numunauth ~= 0 handles.runtimeall(3, handles.totalusers) = handles.runtimeall(3, handles.totalusers) + 1; end %Compute probabilty for Average number of bad events vs Number of Users plot function [handles] = probability(handles) handles.badevents = handles.authbad + handles.unauthbad; if handles.numauth ~= 0 && handles.numunauth ~= 0 handles.badall(1, handles.numauth) = handles.badall(1, handles.numauth) + handles.authbad; handles.badall(2, handles.numunauth) = handles.badall(2, handles.numunauth) + handles.unauthbad; handles.badall(3, handles.totalusers) = handles.badall(3, handles.totalusers) + handles.badevents;

36 | P a g e

%authorized user probability handles.probauth(handles.numauth) = (handles.badall(1, handles.numauth))/(handles.numauth)/handles.runtimeall(1, handles.numauth); %unauthorized user probability handles.probunauth(handles.numunauth) = (handles.badall(2, handles.numunauth))/(handles.numunauth)/handles.runtimeall(2, handles.numunauth); %total probability handles.probtotal(handles.totalusers) = (handles.badall(3, handles.totalusers))/(handles.totalusers)/handles.runtimeall(3, handles.totalusers);

bar(handles.axes3,handles.probtotal, 'b'); set(handles.axes3,'XGrid','on') set(handles.axes3,'YGrid','on') xlabel(handles.axes3,'Number of User', 'FontSize',10) ylabel(handles.axes3,'Average Number of Bad Events Per User', 'FontSize',10) xlim (handles.axes3, [0 40]) elseif handles.numauth ~= 0 && handles.numunauth == 0 handles.badall(1, handles.numauth) = handles.badall(1, handles.numauth) + handles.authbad; handles.badall(3, handles.totalusers) = handles.badall(3, handles.totalusers) + handles.badevents; handles.probauth(handles.numauth) = (handles.badall(1, handles.numauth))/(handles.numauth)/handles.runtimeall(1, handles.numauth); handles.probtotal(handles.totalusers) = (handles.badall(3, handles.totalusers))/(handles.totalusers)/handles.runtimeall(3, handles.totalusers);

bar(handles.axes3,handles.probtotal, 'b'); set(handles.axes3,'XGrid','on') set(handles.axes3,'YGrid','on') xlabel(handles.axes3,'Number of Users', 'FontSize',10) ylabel(handles.axes3,'Average Number of Bad Events Per User', 'FontSize',10) xlim (handles.axes3, [0 40]) elseif handles.numauth == 0 && handles.numunauth ~= 0 handles.badall(2, handles.numunauth) = handles.badall(2, handles.numunauth) + handles.unauthbad; handles.badall(3, handles.totalusers) = handles.badall(3, handles.totalusers) + handles.badevents;

37 | P a g e

handles.probauth(handles.numunauth) = (handles.badall(2, handles.numunauth))/(handles.numunauth)/handles.runtimeall(2, handles.numunauth); handles.probtotal(handles.totalusers) = (handles.badall(3, handles.totalusers))/(handles.totalusers)/handles.runtimeall(3, handles.totalusers); bar(handles.axes3,handles.probtotal, 'b'); set(handles.axes3,'XGrid','on') set(handles.axes3,'YGrid','on') xlabel(handles.axes3,'Number of Users', 'FontSize',10) ylabel(handles.axes3,'Average Number of Bad Events Per User', 'FontSize',10) xlim (handles.axes3, [0 40]) elseif handles.numauth == 0 && handles.numunauth == 0 bar(handles.axes3,handles.probtotal, 'b'); set(handles.axes3,'XGrid','on') set(handles.axes3,'YGrid','on') xlabel(handles.axes3,'Number of Users', 'FontSize',10) ylabel(handles.axes3,'Average Number of Bad Events Per User', 'FontSize',10) xlim (handles.axes3, [0 40]) end %Allow unuathorized users to look in any channel despite any previous %punishmentmemory every 50 timesteps %Check if certain channels have opened up function [handles] = tryagain_unauth(handles)

if

handles.time_two == 50; for i = 1:handles.numunauth change = floor(handles.numchannels*rand + 1); handles.punishmemory(i,change) = 0; handles.punishmemorytwo(i, change) = 0; end

end %Graph data for all plots in GUI function [handles] = graphdata (handles) handles.authdataone = zeros(1,handles.numchannels); handles.authdatatwo = zeros(1,handles.numchannels); handles.authdatathree = zeros(1,handles.numchannels); handles.authdatafour = zeros(1,handles.numchannels); handles.authdatafive = zeros(1,handles.numchannels); handles.authdatasix = zeros(1,handles.numchannels); handles.authdataseven = zeros(1,handles.numchannels);

38 | P a g e

handles.unauthdataone = zeros(1,handles.numchannels); handles.unauthdatatwo = zeros(1,handles.numchannels); handles.unauthdatathree = zeros(1,handles.numchannels); handles.unauthdatafour = zeros(1,handles.numchannels); handles.unauthdatafive = zeros(1,handles.numchannels); handles.unauthdatasix = zeros(1,handles.numchannels); handles.unauthdataseven = zeros(1,handles.numchannels);

for i = 1: handles.numchannels if handles.authdata_graph(i) >= 1 handles.authdataone(i) = 1; end if handles.authdata_graph(i) >= 2 handles.authdatatwo(i) =1; end if handles.authdata_graph(i) >= 3 handles.authdatathree(i) = 1; end if handles.authdata_graph(i) >= 4 handles.authdatafour(i) = 1; end if handles.authdata_graph(i) >= 5 handles.authdatafive(i) =1; end if handles.authdata_graph(i) >= 6 handles.authdatasix(i) =1; end if handles.authdata_graph(i) >= 7 handles.authdataseven(i) = 1; end end

for i = 1: handles.numchannels if handles.unauthdata_graph(i) >= 1 handles.unauthdataone(i) = 1; end if handles.unauthdata_graph(i) >= 2 handles.unauthdatatwo(i) =1; end if handles.unauthdata_graph(i) >= 3

39 | P a g e

handles.unauthdatathree(i) = 1; end if handles.unauthdata_graph(i) >= 4 handles.unauthdatafour(i) = 1; end if handles.unauthdata_graph(i) >= 5 handles.unauthdatafive(i) =1; end if handles.unauthdata_graph(i) >= 6 handles.unauthdatasix(i) =1; end if handles.unauthdata_graph(i) >= 7 handles.unauthdataseven(i) = 1; end end

for i = 1:handles.numchannels handles.traffic_graph(i) = handles.traffic (1, i); end

handles.stackg = [handles.traffic_graph; handles.authdataone; handles.authdatatwo; handles.authdatathree; handles.authdatafour; handles.authdatafive; handles.authdatasix; handles.authdataseven; handles.unauthdataone; handles.unauthdatatwo; handles.unauthdatathree; handles.unauthdatafour; handles.unauthdatafive; handles.unauthdatasix; handles.authdataseven; zeros(1,handles.numchannels);]; bar (handles.axes18, handles.stackg', 1, 'stack'); set(handles.axes18,'XTick',1:handles.numchannels); set(handles.axes18,'XGrid','on') set(handles.axes18,'YGrid','on') xlabel(handles.axes18,'Channels', 'FontSize',12) ylabel(handles.axes18,'Users', 'FontSize',12) colormap([ 0 0 0; 0 0 1; 0 0 1/2; 0 0 1/2.4; 0 0 1/2.8; 0 0 1/3; 0 0 1/3.2; 0 0 1/3.4; 1 0 0; 1/2 0 0; 1/2.4 0 0; 1/2.8 0 0; 1/3 0 0; 1/3.2 0 0; 1/3.4 0 0]) colorbar( 'YTickLabel', {'Primary User', '', '', 'AU User',' ', ' ', ' ','UA User';}) handles.policedata_graph = zeros (1,handles.numchannels); for i = 1:handles.numchannels for n = 1:20 if handles.policedata (n, i) ==1 handles.policedata_graph(i) = handles.policedata (n, i); end end end

40 | P a g e

handles.totalbad = [handles.collisionmain; handles.policedata_graph; zeros(1,handles.numchannels); zeros(1,handles.numchannels); zeros(1,handles.numchannels); zeros(1,handles.numchannels); zeros(1,handles.numchannels); zeros(1,handles.numchannels); zeros(1,handles.numchannels);]; bar (handles.axes2, handles.totalbad', 1, 'stack'); set(handles.axes2,'XTick',1:handles.numchannels); set(handles.axes2,'XGrid','on') set(handles.axes2,'YGrid','on') xlabel(handles.axes2,'Channels', 'FontSize',12) ylabel(handles.axes2,'Collisions', 'FontSize',12) legend(handles.axes2, 'User Collision', 'Police Collision');

if handles.plot == 1 plot (handles.axes4, handles.badstat_authuser_graph_two,handles.badstat_authuser_graph, 'o'); set(handles.axes4,'XGrid','on') set(handles.axes4,'YGrid','on') ylim (handles.axes4, [0 1]) xlabel(handles.axes4,'Timestep', 'FontSize',10) ylabel(handles.axes4,'Probability (%)', 'FontSize',10)

plot (handles.axes5, handles.badstat_unauthuser_graph_two, handles.badstat_unauthuser_graph, 'o'); set(handles.axes5,'XGrid','on') set(handles.axes5,'YGrid','on') ylim (handles.axes5, [0 1]) xlabel(handles.axes5,'Timestep', 'FontSize',10) ylabel(handles.axes5,'Probability (%)', 'FontSize',10) end

function axes2_CreateFcn(hObject, eventdata, handles)

function Startprogram_Callback(hObject, eventdata, handles) %Reset variable values to default values handles.policeband = handles.pband; %set band that police will montitor based on user input handles.numchannels = handles.nchannels; %set number of channels based on user input handles.channel_sharing = handles.csharing; handles.traffic = 0; handles.numauth = 0; handles.numunauth = 0; handles.timestep = 1; handles.time =0; handles.start = 1; handles.timestep_interval =0; handles.twenty_timestep_interval = 0;

41 | P a g e

handles.time_two =0;

%Reset matirx dimensions to 0 handles.punishmemory = 0; handles.punishmemorytwo = 0; handles.accessmemory = 0; handles.authdata = 0; handles.authdata_graph = 0; handles.unauthdata = 0; handles.unauthdata_graph = 0; handles.failmemory_auth = 0; handles.open_auth =0; handles.failmemory_auth_save =0; handles.Topen_auth = 0; handles.Topen = 0;

%Set matirx dimensions based on number of channels selected by user handles.punishmemory = zeros(20,handles.numchannels); handles.punishmemorytwo = zeros(20, handles.numchannels); handles.accessmemory = zeros (20,handles.numchannels); handles.authdata = zeros(20,handles.numchannels); handles.authdata_graph = zeros(1,handles.numchannels); handles.unauthdata = zeros(20,handles.numchannels); handles.unauthdata_graph = zeros(1,handles.numchannels); handles.failmemory_auth = zeros(20, handles.numchannels); handles.open_auth = zeros(20, handles.numchannels); handles.failmemory_auth_save = zeros(20, handles.numchannels); %Reset Statistic Variables handles.events_unauthuser = 0; handles.badstat_unauthuser = zeros(1,5); handles.badevents_unauthuser = 0; handles.badstat_unauthuser_graph = zeros(1,5); handles.badstat_unauthuser_graph_two = zeros(1,5); handles.events_authuser = 0; handles.badstat_authuser = zeros(1,5); handles.badevents_authuser = 0; handles.badstat_authuser_graph = zeros(1,5); handles.badstat_authuser_graph_two = zeros(1,5); %handles.bestfit_badstat_unauth = zeros(1,50); %Reset Matrixes used for Graphing Authorized and Unauthroized Users to 0 handles.authdataone = 0; handles.authdatatwo = 0; handles.authdatathree = 0; handles.authdatafour = 0; handles.authdatafive = 0; handles.authdatasix = 0; handles.authdataseven = 0; handles.unauthdataone = 0;

42 | P a g e

handles.unauthdatatwo = 0; handles.unauthdatathree = 0; handles.unauthdatafour = 0; handles.unauthdatafive = 0; handles.unauthdatasix = 0; handles.unauthdataseven = 0; handles.traffic_graph = 0; handles.collisionmain = 0; handles.policedata_graph = 0; handles.authdata_graph = 0; handles.unhauthdata_graph = 0;

handles.probunauth = zeros(1,40); handles.probtotal = zeros(1,40); handles.runtimeall = zeros(3,40); handles.badall = zeros(3,40);

%Call functions to genrate and plot traffic data when the start button is pressed [handles] = runtime(handles); [handles] = bad(handles); [handles] = probability(handles); [handles] = trafficgen(handles); [handles] = totaltraffic(handles); [handles] = authuser(handles); [handles] = unauthuser(handles); [handles] = collide(handles); [handles] = police(handles); [handles] = collidemain (handles); [handles] = graphdata (handles); guidata(hObject, handles);

function Startprogram_CreateFcn(hObject, eventdata, handles)

function thresholdtraffic_Callback(hObject, eventdata, handles)

43 | P a g e

switch get(handles.thresholdtraffic,'Value') case 1 handles.threshold = .4; case 2 handles.threshold = .1; case 3 handles.threshold = .2; case 4 handles.threshold = .3; case 5 handles.threshold = .4; case 6 handles.threshold = .5; case 7 handles.threshold = .6; otherwise end guidata(hObject, handles); function thresholdtraffic_CreateFcn(hObject, eventdata, handles) if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor')) set(hObject,'BackgroundColor','white'); end

function settimestep_Callback(hObject, eventdata, handles) switch get(handles.settimestep,'Value') case 1 handles.timestep = 1; case 2 handles.timestep = 5; case 3 handles.timestep = 10; case 4 handles.timestep = 20; case 5 handles.timestep = 40; case 6 handles.timestep = 50; case 7 handles.timestep = 100; otherwise end guidata(hObject, handles);

function settimestep_CreateFcn(hObject, eventdata, handles)

44 | P a g e

if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor')) set(hObject,'BackgroundColor','white'); end function NumberChannels_Callback(hObject, eventdata, handles) switch get(handles.NumberChannels,'Value') case 1 handles.nchannels = 20; case 2 handles.nchannels = 10; case 3 handles.nchannels = 15; case 4 handles.nchannels = 20; case 5 handles.nchannels = 25; case 6 handles.nchannels = 30; otherwise end guidata(hObject, handles); function NumberChannels_CreateFcn(hObject, eventdata, handles) if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor')) set(hObject,'BackgroundColor','white'); end

function Police_Band_Callback(hObject, eventdata, handles) switch get(handles.Police_Band,'Value') case 1 handles.pband = 10; case 2 handles.pband = 5; case 3 handles.pband = 10; case 4 handles.pband = 15; end guidata(hObject, handles);

function Police_Band_CreateFcn(hObject, eventdata, handles)

45 | P a g e

if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor')) set(hObject,'BackgroundColor','white'); end

function NumUnAuthorizedUsers_Callback(hObject, eventdata, handles) switch get(handles.NumUnAuthorizedUsers,'Value') case 1 handles.numunauth = 0; case 2 handles.numunauth = 1; case 3 handles.numunauth = 2; case 4 handles.numunauth = 3; case 5 handles.numunauth = 4; case 6 handles.numunauth = 5; case 7 handles.numunauth = 6; case 8 handles.numunauth = 7; case 9 handles.numunauth = 8; case 10 handles.numunauth = 9; case 11 handles.numunauth = 10; case 12 handles.numunauth= 11; case 13 handles.numunauth = 12; case 14 handles.numunauth = 13; case 15 handles.numunauth = 14; case 16 handles.numunauth = 15; case 17 handles.numunauth = 16; case 18 handles.numunauth = 17; case 19 handles.numunauth = 18; case 20 handles.numunauth = 19; case 21 handles.numunauth = 20; otherwise end guidata(hObject, handles);

46 | P a g e

function NumUnAuthorizedUsers_CreateFcn(hObject, eventdata, handles) if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor')) set(hObject,'BackgroundColor','white'); end

function NumAuthothrizedUsers_Callback(hObject, eventdata, handles) switch get(handles.NumAuthothrizedUsers,'Value') case 1 handles.numauth = 0; case 2 handles.numauth = 1; case 3 handles.numauth = 2; case 4 handles.numauth = 3; case 5 handles.numauth = 4; case 6 handles.numauth = 5; case 7 handles.numauth = 6; case 8 handles.numauth = 7; case 9 handles.numauth = 8; case 10 handles.numauth = 9; case 11 handles.numauth = 10; case 12 handles.numauth= 11; case 13 handles.numauth = 12; case 14 handles.numauth = 13; case 15 handles.numauth = 14; case 16 handles.numauth = 15; case 17 handles.numauth = 16; case 18 handles.numauth = 17; case 19 handles.numauth = 18; case 20 handles.numauth = 19; case 21 handles.numauth = 20; otherwise

47 | P a g e

end guidata(hObject, handles);

% --- Executes during object creation, after setting all properties. function NumAuthothrizedUsers_CreateFcn(hObject, eventdata, handles) if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor')) set(hObject,'BackgroundColor','white'); end

% --- Executes on button press in unauthcoll. function unauthcoll_Callback(hObject, eventdata, handles) % hObject handle to unauthcoll (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) plot(handles.axes3,handles.probunauth); set(handles.axes3,'XGrid','on') set(handles.axes3,'YGrid','on') xlabel(handles.axes3,'Number of User', 'FontSize',8) ylabel(handles.axes3,'Average Number of Bad Events Per User', 'FontSize',8) xlim (handles.axes3, [0 40]) % --- Executes on button press in authcoll. function authcoll_Callback(hObject, eventdata, handles) % hObject handle to authcoll (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) plot(handles.axes3, handles.probauth); set(handles.axes3,'XGrid','on') set(handles.axes3,'YGrid','on') xlabel(handles.axes3,'Number of User', 'FontSize',8) ylabel(handles.axes3,'Average Number of Bad Events Per User', 'FontSize',8) xlim (handles.axes3, [0 40])

% --- Executes on button press in totalcoll. function totalcoll_Callback(hObject, eventdata, handles) % hObject handle to totalcoll (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) plot(handles.axes3, handles.probtotal); set(handles.axes3,'XGrid','on') set(handles.axes3,'YGrid','on') xlabel(handles.axes3,'Number of User', 'FontSize',10) ylabel(handles.axes3,'Average Number of Bad Events Per User', 'FontSize',10) xlim (handles.axes3, [0 40])

48 | P a g e

%form polyfit line for Probabilty of Bad events vs Time plots on GUI % --- Executes on button press in pushbutton9. function pushbutton9_Callback(hObject, eventdata, handles) if handles.plot == 1 x = handles.badstat_authuser_graph_two; y = handles.badstat_authuser_graph; p = polyfit(x, y, 4); f = polyval(p,x); plot(handles.axes4, x,y,'o',x,f,'-', 'LineWidth',2) ylim (handles.axes4, [0 1]) set(handles.axes4,'XGrid','on') set(handles.axes4,'YGrid','on') xlabel(handles.axes4,'Timestep', 'FontSize',10) ylabel(handles.axes4,'Probability (%)', 'FontSize',10)

x = handles.badstat_unauthuser_graph_two'; y = handles.badstat_unauthuser_graph'; p = polyfit(x, y, 4); f = polyval(p,x); plot(handles.axes5, x,y,'o',x,f,'-','LineWidth',2) ylim (handles.axes5, [0 1]) set(handles.axes5,'XGrid','on') set(handles.axes5,'YGrid','on') xlabel(handles.axes5,'Timestep', 'FontSize',10) ylabel(handles.axes5,'Probability (%)', 'FontSize',10) end % --- Executes during object deletion, before destroying properties. function NumberChannels_DeleteFcn(hObject, eventdata, handles) % hObject handle to NumberChannels (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA)

% --- Executes on selection change in Channelsharing. function Channelsharing_Callback(hObject, eventdata, handles) % hObject handle to Channelsharing (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % Hints: contents = get(hObject,'String') returns Channelsharing contents as cell array % contents{get(hObject,'Value')} returns selected item from Channelsharing switch get(handles.Channelsharing,'Value') case 1 handles.csharing = 1; case 2 handles.csharing = 2;

49 | P a g e

end guidata(hObject, handles);

% --- Executes during object creation, after setting all properties. function Channelsharing_CreateFcn(hObject, eventdata, handles) % hObject handle to Channelsharing (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called % Hint: popupmenu controls usually have a white background on Windows. % See ISPC and COMPUTER. if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor')) set(hObject,'BackgroundColor','white'); end

% --- Executes on button press in stop_plotting. function stop_plotting_Callback(hObject, eventdata, handles) handles.plot = 0; guidata(hObject, handles); % hObject handle to stop_plotting (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA)

% --- Executes during object creation, after setting all properties. function stop_plotting_CreateFcn(hObject, eventdata, handles) % hObject handle to stop_plotting (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called

% --- Executes on button press in resume_plot. function resume_plot_Callback(hObject, eventdata, handles) % hObject handle to resume_plot (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) handles.plot =1; guidata(hObject, handles);

% --- Executes during object creation, after setting all properties. function resume_plot_CreateFcn(hObject, eventdata, handles) % hObject handle to resume_plot (see GCBO) % eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called

50 | P a g e

APPENDIX II WEEKLY REPORTS May Chum

Week 1
Monday May 24th, 2010. Orientation Dr. Yao introduced us to the four projects with brief descriptions of what each will entail. Each topic are all under the umbrella topic of software defined radio and cognitive radio. The four projects include: 1) GNU Radio + USRP, algorithms, protocol 2) Using Matlab - simulations, GUI 3) Java - simulations, GUI 4) Ipad App - Spectrum Monitoring Each team is made up of 2 or 3 people and will work on one project. I will be working on the Matlab project involving simulations and GUIs. I have a basic understanding of how Matlab operates and can read/write simple codes. I will have to learn how to create and code a GUI from scratch and also add in our own code for our specific set of data. I will begin finding tutorials for Matlab's GUI environment and understand how it works. After Wednesday when we get more information on the projects, I can begin figuring out what type of simulation I should be aiming towards. Dr. Yao also spoke of example Matlab codes that I can look at. I will also try to take a look at the previous Matlab project to gain a bit of background information on what the expectations are. By the end of this week, I should have a clear objective of what I should be aiming to demonstrate by the end of the ten weeks.

Wednesday May 26th, 2010. Matlab Project Dr. Yao gave a brief presentation on the definitions and details in regards to SDR (Software Defined Radio), CR (Cognitive Radio), and DSA (Dynamic Spectrum Access). Our project entails simulating a radio that will be able to act based on environmental factors. The radio can decipher what available frequencies in the spectrum there are and be able
51 | P a g e

to determine the amount of interference there is in that available spectrum. In essence, it will be able to find the most suitable spectrum. Through Matlab's GUI program, we plan to generate a code that will take as input a signal frequency. Then the program will find available spaces in the spectrum. Then it will proceed to determine the amount of interferences there are in that space. If it is above a certain amount, it will not be appropriate and will be discarded as an option. It will continue to search and scan the spectrum for other available frequencies. This process has to be repeated at regular time intervals to ensure that that spectrum space is still available. As a start, instead of having user input, we may code a random signal generator instead. We received an M-File from Dr. Yao. Looking at it, the code seems a bit confusing because of the lack of background knowledge of Matlab of all the members of the project. We will ask Dr. Yao for assistance in deciphering what the code is doing. Thursday May 27, 2010 Today we spoke with Dr. Yao about what the Matlab project should entail. The most basic form of the GUI that we should begin working with consists of two components. Suppose there are ten channels. Each channel has a certain amount of traffic. The amount of traffic will be determined by a random number generator through the rand function in Matlab which generates a number between zero and one. We will make a code such that it will produce ten numbers, all of which are 0's or 1's. A zero will represent a viable channel and a one will represent a channel that is occupied. If the numbers that the random number generators are below a certain threshold value that is predetermined, the code will "floor" the value to 0. Any numbers above this threshold value will be "ceil"-ed to 1. The first graph on the GUI will consist of a bar graph type like window. It will show channel vs. traffic. There will be black bars that represent occupied channels and white areas that represent open channels. We will add a button on the GUI such that whenever it is pressed, the program will run again and new numbers will show up. The second window in the GUI will represent a second user that is trying to search for an open channel. The program will be able to find all the open channels through choosing all the 0's. The program will be able to randomly pick one of the 0's and will retrieve which channel it originated from. The second window will show that chosen channel as a green bar. This will change every time the program is run.
52 | P a g e

Further Add-ons to the Project: Adding more users - being able to throw out previously open, but now chosen by first/second users and choosing a new open channel Having an outside user that is a "bad guy" , has more abilities to take up more than one channel, etc. - being able to search for this type of user and limit their "power". Reading Realistic Radio Waves - instead of having a random number generator, we can work with realistic data. Have Gray Areas - instead of just having black and white, we need to define "gray areas" because realistically, there will be noise and interference. It will not be just be occupied or not occupied. We need to define a threshold value - a value of noise/interference that will still be a viable open channel. We will begin the coding of the first window and we should be able to come up with a simple code for that by Tuesday. Everyone should have Matlab on their laptops by then. We also created a Google Docs group so that we can keep in contact with each other and show each other what is being done. Tabs are being kept on what each week's plan and progress is. Friday May 28, 2010 I started making a GUI today. I first created the graph with frequency versus traffic. I added the code that would randomly generate occupied channels with black bars and open channels with white spaces. The following images are from the GUI that I made:

Every time the push button is pressed, the graph would change and would be rerandomized. There are small white bands between each channel, but it is only where there is a wide white band space where it is an open channel.
53 | P a g e

In the program, the threshold value was set to .3. Each number generated that is less than .3 would automatically become 0. Next step: Add in another user window that would be able to pinpoint the existing open channels and be able to pick one. Plan of Attack: The 'y' variable in the program defines if the channel is occupied or not. For example, the 'y' matrix may look like this: [ 1 1 0 0 1 0 0 0 1 1]. This means that channels 3,4,6,7,8 are open. I will try to create a mask and filter out the 1's in this matrix and keep the 0s. There can be another random generator such that it will generate only integers (I can do this by creating a function rand*10 which will only generate integers from 0-10). The random generator will represent the index of the chosen 0 from the original y matrix (with both 1s and 0s) which in turn will return the original channel number. Current Existing Problems with the GUI: After designing what the GUI should look like, Matlab auto-generated a code for the design. I wrote a code for the frequency versus traffic graph, but I did not know which section I should put it in. I experimented with different sections and I found a section that worked. However, when I placed the second user window into the GUI without adding more outside codes, there would be problems. I can click on one of the axes and press the button and it would generate the freq/traff graph. If I click on another axes, and press the button, nothing should happen to the second axes. Only the first axes should change, but the code made it such that when you click a specific set of axes, the push button would only apply to that one.

Week 2
Tuesday June 1, 2010 We created the GUI with two axes, one for the primary user and one for the secondary user. The first graph is of traffic versus channel. The second user's graph shows a randomly chosen open channel from the original primary user graph. Despite the auto-generated code from the GUI, the code for the specific data is as follows: x = 1:10; for n=1:10 z = rand; if (z < .3) y(n) = 0; else y(n) = 1; end
54 | P a g e

end bar(handles.axes1,y,1,'k') The above code is able to generate a bar graph with black bars that represents the occupied channels. The white spaces represent the open channels. k = zeros(1,10); m = floor(10*rand+1) while y(m)~=0 m=floor(10*rand+1) end k(m)=1 bar(handles.axes2,k,'g') I created a 1 by 10 zero matrix defined as 'k'. The 'm' function generates a random integer between 1 and 10. Then it looks at the y(m) which is the m'th number in the y matrix. In other words, m is the index. It checks to see if y==0. Once y(m)==0, it breaks out of the loop. The code sets k(m) = 1 so now the 1 by 10 matrix has nine 1s and one 1. The index of would represent the channel number from the original 'y' matrix. Then a second bar graph is graphed with one single green bar to represent which open channel the second user chose. Screenshots:

55 | P a g e

I added the second image also because it shows that the program randomly picks an open channel, and not the first open channel only.

Next Step: Implement a third user that is able to choose an open channel amongst the remaining open channels. Plan of Attack: After finding which open channel the second user chose, we can set the value to 1 in the original y matrix. Then the program will search through the remaining zeros and randomly choose one. This is a similar idea to the second user, except we have to factor in the chosen open channel. Further Implementation: See if it is possible to make the code work for a max of ten users. The maximum amount of open channels for outside users (excluding the primary user) is 10. Thus, the max number of outside users is also 10. We can implement a loop such that it will keep randomly choosing open channels for outside users until all 10 are filled up.

Wednesday June 2, 2010 We edited the current GUI and added a "good user" and "bad user". The bad user's capabilities to choose an open channel are limited. We set it such that the bad user can only use an open channel from channels 1-3. If only one of the channels from 1-3 are open, the good user gets priority. When the good user chooses it, the bad user cannot choose any of them because there are no open channels from 1-3. If the bad user comes first and there is an open channel, they can use it. But if a good user comes
56 | P a g e

after the bag user and wants to choose that channel that they are on, the bad user will automatically get booted off the channel. Screenshots:

To Do: Dr. Yao showed us a website with some publications on SDR and CR. I will take a look at those papers to gain a higher understanding of the project in addition to editing the matlab file and including more details. Thursday June 3, 2010 We thought about what to do for further improvement on this project. We came up with two things so far: 1) We want to expand the amount of users that can access these channels. In other words, we want to make it more dynamic. Plan of Attack: Add two more push buttons, one for the "good user" and one for the "bad user". Both push buttons would say "Add user". There can be multiple good users and multiple bad users. The program would run the same way except there would be multiple green bars and multiple red bars. The maximum amount of red bars though, will be 3 because the "bad users" are limited to channels 1-3.
57 | P a g e

2) We want the users to be able to stay on their channel if it is still open after data is re-generated and not have to choose again. Another thing to consider is whether or not the good guy should have priority over the bad guy in channels 1-3. If channels 1 and 5 are open and the bad guy is on channel 1, should the good guy be able to kick the bad guy off the channel or should he automatically choose 5 instead? If all channels are taken up except for channel 1 which the bad guy is on, then should the good guy be able to boot him off? We are still in progress of discussing the limitations and capabilities of each "player". Friday June 4, 2010 http://www.youtube.com/watch?v=yvUUON5u6qM The above is a video capture of the matlab program. The GUI has been edited to be more user friendly through the use of color coding styles and push button schemes. Also, the multiple authorized users has been implemented through two push buttons, one that allows for an addition of an authorized user and one that allows for the removal of an authorized user. The push buttons for the addition and removal of unauthorized users have not been implemented yet. The program is more cognitive now since the authorized and unauthorized users choose automatically what channels to go to once the legacy user/traffic data is altered.

Week 3
Tuesday June 8, 2010 Dr. Yao listened to our presentation on Monday and commented on the validity of the scenario in our first Matlab program. He commented that it does not seem realistic when an authorized user wants to use an open channel that was previously occupied by a restricted user that the restricted user gets kicked off. He suggested that we try other scenarios. We started creating a GUI such that there are two bands, in other words, there are twenty channels. The authorized user is able to choose from any open channel as well as the restricted user. However, there will be another push button that states "police" which will take all the restricted users and put them in channels 11 and above because that is the open access band whereas the first band is restricted access (only for
58 | P a g e

authorized users only). There will also be push buttons to add and remove authorized and restricted users. Instead of having three plots, there will only be one plot on this GUI. We will also keep track of the different scenarios that we are test for a more dynamic study of what is the most efficient, realistic, and user-friendly GUI. Everyone attempts to code the proposed case on their own and then we come together to share our findings and learn from each others programs to see where there should be improvements, where there are unnecessary codes, and the methodology of matlab coding. So far, I have coded the first part of the GUI where there are twenty channels. Both the authorized users and unauthorized users have access to all the open channels. Dr. Yao says that the incoming users should not know their limitations and restrictions. In this case, the unauthorized user comes in being able to choose any open channel, but there will be a police button which causes the program to be more cognitive that "corrects" the restricted user's action. Screenshots:

Additionally, we need to come up with a long term plan and establish what we want to get done by the end of the ten weeks. We also need to understand the game theory behind SDR/CR/SDA. We cannot just code the program that simulates certain actions, but rather we need to understand the engineering aspects behind our codes. Thursday June 10, 2010 We've established several aspects of our program that we want to enhance. The program has heavily relied on the user in commanding the program. We want to make the program more dynamic such that with the minimum amount of user input and effort, the program would still
59 | P a g e

work effectively.

Dr. Yao mentioned several aspects that can be changed. 1) The random traffic generator can be altered such that there can be some channels that are "permanent" and there can be small changes of traffic within 1 or 2 channels at a time. In other words, instead of making it completely random, have a bit of "sudden activity". 2) Change the way the police works. Possibly create a separate window for the police to show where they kick the restricted user off. The restricted user should be able to learn cognitively and remember what channels he cannot take. 3) Make the program time dependent and randomly demonstrates different scenarios. For the time being, the members of the group need to do more research to find out how to make a Matlab program vary over time. My GUI and Matlab code has been improved. Screenshots:

60 | P a g e

Friday June 11, 2010

I worked on the program a bit more. I implemented the police aspect of the program. http://www.youtube.com/watch?v=zdPaBAW2q_I Above is a video of the working program Updated Change: Instead of having a message box come up saying "Input Error", the program will just graph the traffic data assuming authorized and restricted users are 0. The user will have to input new numbers in order for the program to work. Problem: If bad users > open spots in second band, all bad users in first band are dropped. I need the program to figure out how many open spots there are left in the second band and then have all the unauthorized users take up the open spots first if the amount of bad users > open spots. The users that are left will have to be dropped unless Dr. Yao proposes an alternative suggestion. The first part of the program is working perfectly fine. The police aspect of the program is still being worked on. Another next step: Create another way of randomizing the data so dramatically.

61 | P a g e

Week 4
Monday June 14, 2010 Plans: - Add a "Time Step", similar to the Java Groups program. - Have collisions show through graphing multiple matrices of different colors on one window. - Correct the police implementation - Have the restricted user get jammed multiple times before "machine learning" - Do not have completely random data - Make a flow chart! Tuesday June 15, 2010 Everyone in our group drafted a flow chart. We went to the conference room and discussed the similarities, differences, and questions that we had for our flow charts and we combined everything and made one flow chart. Dr. Yao took a look at our flow chart, but commented that it was too broad because it included everyone. He suggested that we should make three separate flow charts, one for each type of user: authorized user, unauthorized user, and the police.

62 | P a g e

Authorized User

63 | P a g e

Unauthorized User

64 | P a g e

Police User

Now we have to figure out how to create and call functions in matlab so that the program will be shorter, more user friendly, and can be distributed/shared. Thursday June 17, 2010 We created a new GUI and reused a lot of the logic from our old programs in this new program. We are currently trying to implement all the small details as to what happens in each scenario. We included a statistical aspect to the program. It records the number of bad events and the number of total packets of arrival. We ratio of these two numbers for each user determines the quality of service. Right now, our program has separate axes for each set of data, but our ultimate goal is to minimize the amount of graphs that we need to make, but there are problems with the "hold" function and we are trying to figure out the best way around this problem.
65 | P a g e

So far, the program looks as follows:

Week 5
Monday June 21, 2010 Plans For This Week: We need to reorganize the GUI such that the overlaying bar graphs are more visually appealing. There cannot be white spaces between the occupied channels/traffic. We need to find a way such that the bars will be stacked with dividing lines for collisions so we can differentiate collisions between occupied channels by secondary users/unauthorized users and police collisions. The program is now completely dependent on creating and calling functions which will make the program easily manipulated when we want to implement any big changes. Currently the program does not record the data separately for each individual user, but acts as one big memory. We need to implement each individual machine learning because each radio cannot communicate with each other and it needs to act on an individual basis. A big project happening right now is being able to tell the military that malicious users can pose a big threat because they have the ability to jam/interfere with many authorized users at once. We need to show that a small amount of malicious users can cause a big impact on the band activity. There will be malicious user(s) that will jam an arbitrary number of channels at once.

66 | P a g e

Our first priority though is being able to alter the memory of each individual user and to make the GUI more user friendly and clearer. We do not need to show the "Traffic Results" graph because it does not happen like that in reality. It just refreshes after each time step. We just need the graph for the original situation including all users and collisions. The second graph will show where the different collisions or drops occur. Wednesday June 23, 2010 We edited the current GUI such that there is a gradient stack instead of just one bar that changes height, but stays the same color. We used a built in colormap in Matlab and now the bar separates into different colors when there are collisions. However, there is a very big limitation to using the colormap this way. The colormap can be separated into a finite amount. This means that the user entry for the number of authorized and unauthorized user has to be limited to the amount that the colormap is divided into. If the user entry is greater than this limit, then the GUI comes up with problems. We have been trying to contact professional Matlab users through Matlab Newsreader and also trying to research for a better way to present our GUI. Thursday June 24,2010 Another problem we are having is the punish memory for the unauthorized user. Right now it is serving as one big memory for all the unauthorized users, but we need and individual memory for each user. We are trying to accomplish this by either using a for loop to include all the users and have an individual punish memory for each one or we can try to learn how to use object orientation so that we can define each user with a characteristic.

Week 6
Monday June 28, 2010 Plans For This Week: -Alter the program from being centralized controlled to distributed control -Change the input box for the authorized and unauthorized user to a drop down box so there can be a limit to the amount of users -Correct the statistics for the authorized and unauthorized user Wednesday
67 | P a g e

June 30, 2010 Professor Hong Man came in today to speak about network security. The following are my notes: Network Security Seminar by Professor Hong Man Problems with network security: peoples email privacy, stealing data, embezzlement, etc. Its not about the system, but the user (conman, spies, terrorists)

- Security Issues: secrecy (prevent unauthorized users from reading and modifying confidential info), authentication (determining the true identity of user), nonrepudiation (using electronic signature), integrity control (verify that the message is not altered since its creation) - Security in Protocol Stack: physical layer (enclosing transmission lines in sealed tubes), data link layer (link encryption), network layer (firewalls, IP layer), transport layer (end to end encryption), Application Layer (user authentication and nonrepudiation) Security Facts: 1) Most security failures are due to human misconducts and errors rather than clever criminals 2) Most network security is based on cryptographic principles. 3) Security needs to be addressed in OS and software design - Cryptography: the source = plaintext (P), it goes through an encoding mechanism (encryption, E), Ciphertext (public, hopefully no one breaks the text), Decryption method (D), the end needs to be the same as the beginning. Passive Intruder Just listens Active Intruder Alters message and puts it back The art of breaking ciphers is called cryptanalysis. The number of good encryption methods are limited C = Ek(P): The encryption off the plaintext P using key K and producing C

- Encryption methods are public, while keys are secret. People need to analyze the Strength of the method and then start to use it. If they dont know how to use it, they do not
68 | P a g e

have the confidence to use it. - Three levels of attack: 1) Ciphertext only attack, 2) known plaintext attack (knows C and P), 3) chosen plaintext attack Substitution Ciphers: symbol for symbol substitution = monoalphabetic substitution

- Transposition cipher transposing the horizontal message into vertical ciphertext with a key that determines the number of columns and the order - Problem with transposition cipher can always break it by using brutal force attack (trying every combination) Principles all encrypted message must contain some redundancy

- An m byte file = m*8 bits -> 2*(8m) possibilities only a subset of these possibilities can be valid messages - Principles should prevent a playing back attack cannot break the ciphertext, but will be sent back to you (a message should carry timestamp or random number or ID) Symmetric Key Algorithms: using the same key for encryption and decryption DES (Data Encryption Standard) Public Key Algorithm D(E(P))=P, E = public key, D = private key, P = plaintext It should be difficult to deduce D from E. E cannot be broken by a chosen plaintext attack RSA algorithm generates two keys, one private, one public

Friday July 2, 2010 The program is now updated such that the punish memory for the unauthorized user is working. Currently, the programs works when the authorized and unauthorized user is limited to 20 users. There is a 20X20 matrix and the users manipulate this matrix for their own identity. We also created an option box for the user to choose how many time steps they want to see. I tried running the program on my laptop but it is giving me errors, but it has been working on my group members laptop. Hopefully I can fix this error soon and be able to upload screenshots.

69 | P a g e

Plans for next week: - Decide which statistics are most important to display - Think of a way the police and hit and miss. - Add a malicious user with more power We will also be having a meeting with the Java group on Tuesday to discuss the project. We need to take notes on the following things: - Pros and Cons of the project - Plausibility - Further Improvements - Efficiency - Which is a better method to demonstrate the project - Other details that can be included in our final report

70 | P a g e

Week 7
Tuesday July 6, 2010 Edits Number of channels (10-30, increments by 5) Number of users Number of time steps Set traffic threshold Comment the program well/Use user-friendly names.

Stats Bad events/Total events (one for good and one for bad) Measurement of quality of service Value of QOS should be decrease

- Weighted Channels for the Authorized User (maybe UA too) and Punish Memory for Unauthorized User Further Improvements - Have an option for the user to choose if they want a punish memory or weighted channels (by probability)

Suraj will be making edits, Angela will be working on the statistics, and I will start gathering data to write the paper (the general ideas of what we want to include).

Wednesday July 7, 2010

71 | P a g e

We had a seminar with Professor Bruce McNair today. The following are my notes from his lecture:

Radio Propagation and Diversity HF Ionospheric Radio Propagation

- Ionosphere - a ring of the Earths atmosphere where the sun ionizes the molecules creates conductivity Transmit signals by reflecting signals off the ionosphere (long distance transmittance) Double bouncing by hitting it off of salt water

- Problem radio signals leave the antenna at different angles creating multiple reflected signals (multipath) Multipath creates fading UHF No ionospheric frequencies, but LOS communication Usually we do not have a LOS path We get the same problem multipath Tropospheric Ducting VHF UHF SHF Generally caused by regional weather conditions

- Military uses this method when they have no other way for long distance communication Same problem multipath Multipath Transmitter and receiver one signal of wavelength lamda Two paths, d1 and d2

72 | P a g e

- Complete destructive interference same amplitude and distances are odd multiples of one half wave length difference Multipath fading, channel dispersion Doppler shift

- Relative motion of transmitter/receiver creates an apparent frequency offset due to Doppler shift

Friday July 9, 2010

We had a meeting today with the Java group to determine the specifics for the program. We wanted to figure out what the authorized user's machine learning capabilities. Currently, the Java group's program has it set such that when a user enters a channel, they get to keep that white space until the end of a certain number of time steps. I have been reading up on the articles that Dr. Yao have posted up on the Stevens Institute of Tech website (www.stevens.edu/sss) The article that I have been reading mentioned that CRs can be defined by certain characteristics. I was thinking that we should create an evaluation chart where we can rate our programs (both the Java and Matlab group) and see what the quality of our programs are. Things written within brackets ( [[ ]] ) are my notes for what we can do for our project. The following are my notes so far: Cognitive Radio Empowered Wireless Communications - The problem is more related to limited spectrum access rather than scarcity of spectrum space Studies have found:

1) some frequency bands in the spectrum are largely unoccupied most of the time; 2) some other frequency bands are only partially occupied;

73 | P a g e

3) the remaining frequency bands are heavily used. spectrum holes a band of frequencies assigned to a primary user, but at a particular time and location is not utilized by that user Computational View of Cognition:

1) Mental states and processes intervene between input stimuli and output responses. 2) The mental states and processes are described by algorithms. 3) The mental states and processes lend themselves to scientific investigations. Cognition learning by understanding

Cognitive radios two objectives: 1) highly reliable communications whenever and wherever possible, 2) effective utilization of the RF spectrum Six words that define cognitive radios awareness, intelligence, learning, adaptivity, reliability, and efficiency, also endowed with reconfigurability. [[ Notes for project: we should define/assess our programs based on the objectives/six words. Also, mention the fact that it should be reconfigurable. Like Joe Mitolas project with programming languages/semantics study, make it more diverse/adaptable/efficient/universal]] Cognitive tasks: 1) radio-scene analysis [[scanning for white space]], 2) channel-state identification (CSI) [[finding an open one and being able to access it based on probability of success]], 3) transmit power control and dynamic spectrum management [[ ??? ]] Cognitive radio could enhance the flexibility of personal wireless services through a new language called radio knowledge representation language (RKRL). Interference temperature limit worst case RF environment where the user can still operate satisfactorily Being dependent on space and time the stimuli are nonstationary spatio-temporal signals Detection of Spectrum Holes 1) black spaces, 2) grey spaces, 3) white spaces [[corresponds to what our programs are doing]]

Our program right now is all cooperative. If the program is a totally cooperative program, then the game theoretical aspects of the program can be eliminated. [[ We need to add some non cooperative aspects to the program ]]

Traffic Considerations When the band is occupied continuously by users (ie, four spaces and they are all occupied) their signals will interfere with each other. The way that people deal with this problem is through cell allocation. By allocating new incoming users to farther white spaces, their interferences will decrease. [[This can be a further improvement for our programs where the program can scan the spectrum for the new

74 | P a g e

incoming user and then see if there are any spots where there will be a white space on either side . If not, choose one that has one white space on one side. If none of those exist, then as a last resort, go into a white space between two occupied frequencies]]

Week 8
Monday July 12, 2010 Suraj and Angela are still working on the program in Matlab. They successfully added a pause button and the statistics graph is looking good. There are still slight problems, but it's on the way to working. The number of bad events go up when there are a lot of users which means it is optimal if there are less users than the number of white spaces available.

The Java group and the Matlab group came together once again to discuss the problems and the working parts of our programs. We came up with a list of questions that we wanted Professor Yao to clarify. We sent him an email and he responded saying that we would discuss the problems on Thursday.

Wednesday July 14, 2010 After reading several articles related to software defined radio and cognitive radios, I proposed several ideas that can be further improvements to our programs. For example, currently our programs lack game theoretic aspects because of the lack of competition. I pitched the idea to the group that during the collisions between users, someone can "win" in the battle and then they can occupy the white space that they were fighting
75 | P a g e

for. This creates competition and there's more game theory present. The problem is how we can determine who wins and who loses. In an article that I read, the primary users allow secondary users to use their bandwidth by paying them a certain price per unit bandwidth. If we go with the above idea, we can have a bidding system such that whoever bids the highest amount of money for the bandwidth is able to use it. Another possible further improvement is that if the program sees that a certain area of consecutive frequencies is congested/crowded, new incoming users can be allocated to a farther away white space so that the signals do not interfere with each other that much. This allows for the maximum amount of signal strength and least interference. Thursday July 15, 2010 Today we met with Dr. Yao for the grand review of the past two and a half weeks. We spoke with him about the problems that we encountered and I recorded some notes about some things he took note of that we should change. Notes: Firstly, we were wondering how we were going to implement the game theoretic aspects into our programs. Both groups spoke with Nansai and he said that it is alright for us to assume that everyone knows about each other and the users can share their information. I know that the primary user's information is the global information that is available to everyone, but the authorized users and unauthorized users cannot communicate with each other in reality. Secondly, the Java group's program has it such that if an authorized/unauthorized user successfully gets into a channel, they stay in that channel until the end of the program/certain number of time steps unless a primary user wants to use that channel. The Matlab group's program has it such that the authorized/unauthorized users have to rescan the spectrum for white spaces after every time step and try to enter a white space again. Should we just have the two different ways to do it or should either one of the two groups change the way they are doing it? Thirdly, we were also wondering what you wanted the authorized user's learning capabilities to be...What should they be learning and remembering?

Dr. Yao - Simple scenario ideal scenario where everyone knows each others information [[what kind of info would be shared?]]

76 | P a g e

Capture factor if signal A is higher than signal B then signal A wins.

- The ratio between the two signals if it is higher than 2db or w/e then signal A can win, else they both drop. Note: this is not game theory, but physics. - Frequency Hopping slow and fast hopping the two approaches are feasible and possible - Dr Yao: VERY slow frequency hopping does not hop until they have the need to yield - Stats plot probability of bad events against number of total users [[ the numbers should go up]]

Week 9
Monday July 19, 2010 Plans for this Week: - Create an outline for the paper and brainstorming the ideas for each section - Begin working on individual poster - Possibly have three statistics graphs that shows the probability of bad events for authorized, unauthorized , and total number of users. For the presentation, we will be capturing the program actually working and then presenting the video. Tuesday July 20, 2010 The program has been updated and revised. The bugs are gone and we will be making the video of the program soon for presentation purposes. We added a polyfit button where the user can find the best fit line using a polynomial fit for the data points. Here are some screenshots:

77 | P a g e

As for me, I have started writing the paper, mainly the Abstract and the Introduction. Also, I've
78 | P a g e

laid out the outline for my poster. Wednesday July 21, 2010 We had a meeting with Dr. Yao about the outline of the project. I also had him read my drafted abstract and I made some corrections. Here is the following outline that we will be following for the final report: I. Abstract II. III. Problem Statement

Table of Contents Introduction Problem Statement restated

IV.

System Model Our Assumptions

V. TOPIC SECTIONS 1) GUI Development, 2) Stats and Probability, 3) Policing Policy, 4) Learning Process, 5) Challenges and Further Improvements [[ANYTHING ELSE?]] VI. VII. VIII. IX. Conclusion Acknowledgements Bibliography/Works Cited/References Appendices source code and GUI design weekly reports

I began making my poster. I can hopefully finish it by Thursday night. Thursday July 22, 2010
79 | P a g e

I've updated the outline of the final report and I have started writing the introduction. I have most of my poster done, but I am waiting for the final changes in the program. I will be taking screen shots of the program and then I will add it to my poster and add the text to the results section. After I edit my poster a bit, I will be done with it. I can probably email it to Dr. Yao by Friday night. The outline for the paper is now: Abstract Introduction System Model GUI Development Machine Learning Process Policing Policy User Statistics Challenges and Further Improvements Conclusion Acknowledgements References Appendix I Source Code and GUI Design Appendix II Weekly Reports Friday July 23, 2010

I finished my poster and I am continuing to write the final paper. We have split up all the parts and we will be emailing each other back and forth making edits.

Week 10
Sharing of posters. Awards. Tears and goodbyes.

80 | P a g e

Angela Dorstek

Week 1 - Project Selection, Learning Matlab and Randomly Generating Basic Channels
May 24th - May 28
th

Monday -- Monday was our first day meeting the full group, and learning about the project possibilities. We were presented with multiple subjects for our research, all set in SDR (Software-Defined Radio), CR (Cognitive Radio) and DSA (Dynamic Spectrum Access), These topics were: 1. 2. 3. 4. GNU Radio/USRP - Algorithms, Protocol Matlab - Simulations, GUI Java - Simulations, GUI iPad Application - Spectrum Monitoring

Our task was to choose a project and find teammates interested in the same project to work with. These teams were to be made up of two to three students. My group included May Chum, Suraj Chokshi and myself working on project #2, Matlab. Tuesday -- Tuesday gave me the opportunity to get a first look at Matlab. I had never used the program before, so I took the time to watch the introduction and demonstration videos for using Matlab. We were told we would receive more details on the project at the Wednesday meeting, so after playing with Matlab briefly, I decided to wait until Wednesday before trying anything complicated. Wednesday -- After our meeting, we felt as though we had a stronger understanding of what we were to do for the project. Our main intent for our project is to design a radio that will identify a "free" frequency (free meaning no or minimal noise and interference), and select this free frequency for a user to broadcast on. The radio will also repeatedly check the frequency while the user is working on the chosen frequency, to be sure the noise and interference levels have not become unfavorable. If this is the case, the radio will automatically switch the broadcasting frequency for the user to continue working with minimal interruption. We discussed our plans for the project in our group and decided that since we were designing a simulation, we should program the frequencies to randomly generate noise and interference levels, ideally on a timer, to simulate a realistic and natural environment. As a group, we examined a sample code using Matlab, and it seemed quite complicated. We decided that we should individually spend some more time with the program before we try to create anything ourselves. Thursday -- I spent the majority of Thursday morning teaching myself how to work in Matlab; defining variables within our project and setting up parameters. I took a mathematical approach as my first attempt to solving this project so I would have some sort of an idea to start on when I met with my group later that day. We met in the lab and discussed our own personal progress with the assignment. We realized we all had varying ideas on where to begin, so we met with Dr. Yao to get a clearer picture of the project. He told us to keep it simple at the start and once we have a simple, working program, we can add in more variables and more complicated ideas. He explained that we have a finite number of channels, and for our purposes, each channel is defined by either a 0 or a 1. These 0's and 1's are randomly generated to simulate traffic on a channel (a channel with a 1 is a full channel, and a channel with a 0 is an empty channel). While keeping it simple, we chose to use 10 channels. The program is to search these channels for a 0 and then assign it as the user's output (or broadcasting)

81 | P a g e

channel. By the end of the week, we wanted our program to be able to randomly generate the 0's and 1's assigned to each of our 10 channels, and to post a bar graph with either a dark bar over the channel (to signify a full channel) or white (no bar) above the channel (to signify an empty channel). That night I worked on programming a random generator that has a 50% chance to produce a 1 or a 0. Each time the program is run, it will generate a new traffic pattern for the same 10 channels. A sample bar graph of the traffic vs. channels is below:

Friday -- May sent out the GUI she programmed for this project. It used the same idea that I used, but instead of running the program again to re-generate the numbers, she programmed it to re-generate the traffic whenever a button is pressed. After examining her coding, I came to the conclusion that a GUI is certainly a more sophisticated way of accomplishing our task, and my goal for the beginning of next week is to learn more about coding and producing GUIs.

Week 2 - Selecting Open Channels for Use, Multiple Users, Limiting Users and Adding/Subtracting Users
June 1 - June 4 Tuesday -- Since Monday was Memorial Day, we had our first meeting of the week on Tuesday. After sharing our progress with the group and viewing the other groups' progress, I met with my group to discuss our goals for the week. We have a primary user displaying the channels as open or closed with the bar graph, and we would like to be able to add a second user that will select one of the open frequencies for the user to broadcast on. We need to then block that frequency from being chosen by a third or fourth user so that the program does not put all the users on the same channel (which would defeat the purpose of selecting it as an "open" channel).

82 | P a g e

I looked into creating a GUI and was able to add a pushbutton to my bar graph generator from last week. A sample of this new generator is below:

This graph shows that channels 1, 6, and 10 are open and can be chosen by the program for the user. The next step is to program the computer to choose one of these channels and output it for the user to work on. Wednesday -- Today we accomplished a lot. We added a bar graph displaying the chosen user's frequency. This frequency is chosen by checking the generated data and randomly choosing an open channel for the user to work on. There is a second bar graph next to the Traffic graph with a green bar indicating the chosen user's frequency. We then added a second user who is assigned a random channel to work with, keeping in mind that the channel the first user is working on is now closed. There is a third bar graph to indicate the second user's channel. From there, we named the two users 'good guy' and 'bad guy.' The first user, 'good guy', has all the channels open to him, and he has the first pick of open channels. The second user, 'bad guy', is limited to only channels 1-3 and gets to pick a channel after the 'good guy' picks. This often results in the 'bad guy' having no channels to work on. Below is an image of what happens when there are no channels for the 'bad guy' to work on:

83 | P a g e

When there is an available channel between 1 and 3 and the 'good guy' is not already assigned to it, the 'bad guy' is assigned to one of those three channels. A sample of this is below:

This is effective in practice, because all users over a certain amount of power could be filtered out as 'bad guys' and limited to only the first three channels. This does two different things, one, it limits the number of channels that can be used by the 'bad guys,' and two, it informs anyone monitoring these channels that the first three are being used by high-powered 'bad guys', that might need to be monitored more closely than the other channels. Our next step is to add more buttons so that the users can manually change their channel if necessary. We would also like to allow the users to use multiple channels; for example, the 'good guy' could use up to 10 channels, if there are 10 open channels, but the 'bad guy' could only use up to 3 channels, if they are available. Friday -- Today, when we met with Dr. Yao, we discussed our next steps in our progression. We renamed the 'good guy' to 'authorized users' and the 'bad guy' to 'unauthorized users.' We also wanted to allow the different users to change the channel they are working on, and also we wanted to be able to add multiple 'authorized' and 'unauthorized' users. We spent some time programming this, and I had a bit of trouble making the add and remove user buttons work. My plan for this weekend is to work on making those buttons work effectively. For now, the program looks like this:

84 | P a g e

And then when the +1 or -1 buttons are pressed, it should add a user on a different channel than the channels that are already full. This part is not completed, but an example of this is here:

Our final result from the week's work looks like this:

85 | P a g e

Our next step is to add more channels (we want to use 20 channels); allow the Authorized Users to use channels 11 - 20 and the Unauthorized Users to use channels 1 - 10. We also want to implement the use of a "Police" button, which will take an unauthorized user who is in channels 11 - 20 and move that user back to the proper channels, 1 - 10.

Week 3 - Police Function, Creating/Calling Functions in Matlab and Organizing Code

June 7 - June 11 Monday -- Today, during our meeting we received feedback on our work from Dr. Yao. To update our work from last week, he wants us to add a text box into our GUI to allow for a specified number of users. For example, under the Authorized User graph, we want to place an open box for someone to type a number in to specify the number of Authorized Users working at any specific time. The same goes for Unauthorized Users. He also wants us to add a 'Police' button that will regulate the channels an unauthorized users is allowed to use. Tuesday -- To keep up with the rest of my group members, I spent today reading tutorials and working in Matlab to ensure I could keep up with the more complex programming we have to do to further update our project. Wednesday -- My plan for the rest of the week is to learn how to create, implement and call functions within a Matlab program. This will make our code more organized, which will, in turn, make any searching for errors easier and also allow for a simple changing of coding. I do not how to do any of this yet, so while my group members are working on inserting more channels, users, and the police user into our already existing GUI, I have been reading and watching tutorials, practicing coding within Matlab, and trying new things on our previous GUIs to make the coding more efficient and organized.

86 | P a g e

Thursday -- Today, I worked on programming each section of our project - generating the random traffic data, assigning authorized users to a random channel, assigning unauthorized users to a random channel, and limiting unauthorized users to certain channels - separately to attempt to create different functions for each of them. What I want to do is call these different functions when different pushbuttons are pressed so that there is less coding underneath each pushbutton, and we do not have to re-code every time we want to re-use one of the functions.

Week 4 - Flow Charts, Organizing Code and Defining/Calling Functions

June 14 - June 18 Monday -- I am continuing my work on learning how to program and call functions in Matlab. I have figured out how to declare functions and call them, now I just need to write them in the program so that they will work. I wrote and successfully called the function to generate the random traffic data:

And the call function is:

Tomorrow I am going to continue writing and calling functions so our code will be shorter and more efficient.

87 | P a g e

We were also given the task of creating a flow chart depicting the rules for our simulation. I will continue to work on this flow chart today.

Tuesday -- This morning I met and worked with my group on the flow chart. Our completed flow chart is as follows:

Dr. Yao looked over our flow chart, and asked us to create multiple flow charts for each user (Authorized, Unauthorized, Police). Our results for this are as follows: Authorized Users

88 | P a g e

Unauthorized Users

89 | P a g e

Police

90 | P a g e

Wednesday -- I returned to my work with functions in order to organize the code we are using for the simulation. I discovered that I need to use sub functions in order to make this work, and I spent a lot of time coding, and recoding to figure out how they work. All GUIs in Matlab use a structure called 'handles' which stores and retrieves data. Instead of labeling global variables in order to be able to access them between functions, I just placed the variables in the handles function so I can retrieve and alter them from any point in the GUI (as long as they have been defined). This way, instead of listing all the input and output variables the function needs, I can input and output the entire handles structure. This way I can access and change any variable within the handles structure in any function that I am defining. Once I figured this out, declaring and calling functions became much easier. I was able to change all of the different events in our code into functions and then call them when necessary. An example of the coding follows:

91 | P a g e

This is a declaration of the function "trafficgen" which inputs and outputs the 'handles' structure. Each variable is defined as handles.'some_variable' in order to place it in the handles structure. The call functions are below:

92 | P a g e

Each different function ("primaryuser," "totaltraffic," etc.) are called and used, and at the end, all the variables defined or changed are placed into the 'handles' structure, which is done by the last line, "guidata(hObject, handles);" My work today has produced a GUI that incorporates everything we have done so far, and begins to add a few more things, such as punishment data for the unauthorized user, and any sort of collisions between users.

In this simulation, a number is input to declare how many Authorized and Unauthorized users exist. Also, both the Authorized and Unauthorized users can chose any channel that is not already full with traffic (Being used by the Primary User). The Police exist because the Unauthorized user is not allowed to use channels 1 - 10, and the Police punishes the Unauthorized user if he is caught using channels 1 - 10. This simulation is not complete yet, because a collision between an Authorized user and an Unauthorized user causes both users to be dropped, and when the Unauthorized user is punished by the Police, he is dropped and also remembers that he was dropped on that channel once before. When the Unauthorized user remembers being dropped from a channel a certain number of times (let's say 3 or more), the user will avoid using that channel. None of these things have been implemented into the above simulation. Also, there seems to be a bit of an issue with the "punishmemory" because it resets sometimes. Next, I tried to add in a few things that were missing, and I also added in a collision graph that indicates which channel(s) had collisions.

93 | P a g e

In this instance, there were collisions on channels 2, 3, 11 and 16. All of these users were removed from their channels. There was also an unauthorized user that experienced no collision on channel 1. He was removed by the police. My next step is to fix up the code (punishment data and such) and to graph the traffic, authorized users, and unauthorized users all on the same graph (the one at the bottom of the GUI).

Week 5 - Punishment Memory and Structures

June 21 - June 25

Monday -- In our meeting today, we were told to change our flow charts to have more standard symbols. We were also told that the program is not smart enough to immediately kick off the user when a collision occurs, the user must be removed at the next time stop. We updated our flow charts to the standards given to us by Dr. Yao. These are shown below. Authorized User:

94 | P a g e

Unauthorized User:

95 | P a g e

Police:

96 | P a g e

Tuesday -- We are still having an issue with the punishment data. As of right now, the program is only logging punishment data for channels 1 - 10 because the unauthorized users are remembering police collisions and other collisions as a punishment. The issue with this is that the unauthorized users do not know which channels they are restricted to, therefore the punishment memory should teach them this. In this case, it should be logging collisions for channels 1 - 20, but there is the possibility that an unauthorized user may collide with an authorized user or another unauthorized user in channels 11 - 20. In this case, the unauthorized user will log punishment data in channels 11 - 20 and if that data gets up to whatever number we defined (currently 4), the unauthorized user will think he cannot use that channel. My first attempt to remedy this was to add this to the punishment code: elseif (handles.collision(i) == 0) && (handles.unauthdata(i) == 1) && (handles.policedata(i) == 0); handles.punishmemory(i) = 0 This adds the aspect that if there is no collision on a channel (which will give the unauthorized user +1 punishment on that channel), and there is no police collision on a channel (which will give the unauthorized user +1 punishment on that channel), then the unauthorized user will have successfully commandeered the channel, and therefore the punishment data will reset to 0 on that channel. This helps and is realistic because every time the unauthorized user accesses a channel, it will think that it is a channel it can use (which it is), and it will forget (or not care) that it was knocked off previously. This works a bit better, but once all the unauthorized users are

97 | P a g e

pushed off channels 1 - 10, they are experiencing many more collisions in the 11 - 20 range, which will result in 4 collisions before a user can access the channel freely, and thus more channels will be blocked off and then even more collisions will happen. I want to figure out some way to have the user remember a channel that they successfully accessed and then even if they experience a collision on that channel, they still remember it as a channel they were able to access and therefore it will always stay as a 0.

Wednesday -- By adding an extra matrix to our code called 'handles.goodchannels,' I created a place where the unauthorized users can log their memory when they access a channel. If an unauthorized user has successfully accessed a channel, they can assume it is a "good channel" and they will continue to try to use it. This is more effective as it does not eventually completely block the unauthorized users out of all the channels, but it will still block unauthorized users out of some channels 11 - 20 sometimes. Thursday -- Our next step is to define the authorized and unauthorized users as specific users with their own personal memory. The purpose of this is for each unauthorized user to have their own punishment memory. This will make the simulation more realistic because there is no collective memory between a group of users. My idea of how to do this is to create a structure with authorized users, unauthorized users and each matrix of punishment data for each unauthorized user set within the structure. This way, we can set each user in the structure to have their own memory. This will also define each user as a unique user instead of part of a whole. This way, if a user is on a channel, they will try to continue using that channel.

Week 6 - Updating Punishment Memory

June 28 - July 2 After presenting my findings from last week to the class, Dr. Yao said that the unauthorized user should not assume that a channel is "good" unless they access it multiple times (in case the police makes a mistake). I decided to change my coding a bit to make the 'accessmemory' similar to the 'punishmentmemory.' If a user successfully accesses a channel, 'handles.accessmemory = handles.accessmemory + 1' just as if a user experiences a collision, 'handles.punishmemory = handles.punishmemory + 1.' If the punishmemory is > 3, the unauthorized users will block out that channel completely, but if the accessmemory > 3, the unauthorized users will remember that channel as a "good channel" and will continue trying to access it. This way, it is still possible that an unrestricted channel will be blocked out, but it makes it more realistic. Unfortunately, with a lot of users, it will likely block out most of the channels. I think that defining each user as a separate entity will minimize this problem, so for the rest of the week I intend to research, comprehend and then create a structure for the program to use.

98 | P a g e

In the above simulation, channels 1 - 11 are blocked off (the punishment memory has reached 4), and so are channels 15 and 20. Channels 12, 13, 14, 16, 17, 18 and 19 are remembered as accessible channels since the unauthorized users have been successfully able to access them more than 3 times. The accessmemory (bottom center graph) logs how many times a channel has been accessed by the unauthorized users. For example, channel 11 was successfully accessed once, but the unauthorized users experienced collisions 4 times on that channel before accessing it successfully 4 times, and as such it has become a channel the unauthorized users avoid. Channel 14 has been successfully accessed 21 times by unauthorized users. Once they successfully accessed it 4 times, they concluded that it was a safe channel, marked it as such, and stop logging collisions in that channel (as such they just assume collisions are unfortunate coincidences instead of punishments). I believe this will work more effectively when each user has his own memory, which is what I will be working on this week. Dr. Yao also requested that we make our flow charts even more standard. The updated flow charts are below. Authorized Users:

99 | P a g e

100 | P a g e

Unauthorized Users:

Police:

101 | P a g e

Week 7 - Probability
July 5 - July 9 Last week we accomplished adding in identities for each user, so each unauthorized user has his own set of punishment data to reference, and the unauthorized users are not accessing some non-existent database to see the punishment data of all the unauthorized users. We also accomplished each user having a different color on the GUI traffic data graph. Our next step, this week, is to add in the Time Steps and the probability to show the efficiency of the program. Suraj worked on fixing the GUI to make it more user friendly, and making the Time Step work. I worked on adding in the probability to our existing GUI. Each time there was a collision I tallied it in two or three of three separate variables (authbad, unauthbad, badevents). If the collision only affected authorized users, it was marked as an Authorized User Bad Event (authbad) and a Bad Event (badevents). If the collision only affected

102 | P a g e

unauthorized users, it was marked as an Unauthorized User Bad Event (unauthbad) and a Bad Event (badevents). If the collision affected both Authorized and Unauthorized Users, it was tallied in all three variables. In a Probability function, I used three different matrices, that I created at the beginning of the program, to mark the number of collisions per authorized user (in the first), per unauthorized user (in the second), and per total users (in the third). I set each of these to graph at the bottom of the GUI. The graphs did not display a clear pattern. This is shown below.

My next idea is to scatterplot these points and then find a line of best fit for the points, which should, in the Unauthorized User graph, show a negative slope (and thus show that the bad events per Unauthorized User is decreasing since the Unauthorized Users are learning over time) and in the Authorized User graph, show a slope which is almost zero (since the Authorized User is not changing his behavior). There was talk about having some sort of Game Theory where the Authorized Users work together and thus generally avoid collisions between each other, but we have not implemented that yet. Our next step is to find a way to create a probability graph that is showing that the unauthorized user is learning and thus the graph will display a negative slope that is approaching zero.

Week 8 - Probability
July 12 - July 16 My goal this week was to organize our GUI so that there was only one graph to display Probability and that there would be buttons to press to switch between the three probability graphs (Collisions Per Authorized User Over Time, Collisions Per Unauthorized User Over Time, Collisions Per User Over Time). I implemented this into the GUI. The way I included this was that the GUI would automatically display the graph of Collisions Per User Over Time, and then the other graphs will display when the other buttons are pressed. Whenever the timestep button is pressed, the graph will switch back to the Collisions Per User Over Time.

103 | P a g e

After speaking with Dr. Yao, upon his return, our next step was to change the Probability graphs. He requested that we show the number of Collisions Vs. the number of Users instead of the number of Collisions per User vs. Time. I implemented this immediately. The way this probability works is that each time the timestep runs with the same number of users, it logs the number of times the timestep has run with that number of users and also tracks the number of collisions that have occurred during that number of timesteps (it does this for Authorized, Unauthorized, and Total). It then divides the number of collisions by the number of times the timestep has run (so we're taking an average of the number of collisions per timestep for each type of user). The program then logs this number in a matrix in the slot that coincides with the number of users that have been run. Finally, the program graphs this matrix. It works the same way as the previous probability function, that it automatically displays the probability for total users, and the user can switch between the type of users.

There's a bit of a problem with the current probability graphs, which sets my goals for next week. The first problem is that when a user switches back to a previously used number of users, the number of times that user has been run resets. This can be fixed by adding a matrix to keep track of how many times the user has been run. The next problem is that running the program with a certain number of users 25 times does not produce an accurate depiction of the users learning. Theoretically, we would like the graph to display percentages (between 0 and 1), but since the total number of collisions is very likely to be greater than the amount of times the program has been run until the program has been run an extreme amount of times (say 1000 -- this will display the learning of the unauthorized users), and that's not even guaranteed, we might have to figure out a better probability to display. This is a print of the matrix that contains the number of bad events per number of users:

104 | P a g e

The columns indicate the number of users. The top row is authorized users, the middle row is unauthorized users, and the bottom row is total users. For example, when there was only one authorized user there were no collisions, so for one user, in the authorized user column, there is a 0. Also, in the total user column, when there is only one user, there is also a 0. But when there was one authorized user and one unauthorized user, the total users were two and there were 10 collisions, this was marked in column one of the unauthorized user row, but then the next time 1 unauthorized user was run (1 unauthorized, 2 authorized), there were five collisions involving unauthorized users. That totaled to 15 collisions when there was only 1 unauthorized user. Tomorrow I will be working on adding a 3-D graph with average number of collisions vs. number of users vs. time. Wednesday -- My work for today was to change my probability graph to display an actual probability instead of a number. I averaged the number of collisions per user and then divided that number by the number of times the program has run for that number of users. This produced a percentage (number between 0 and 1) for our probability.

For the rest of this week, we worked on writing our final report for the assignment.

105 | P a g e

Suraj Chokshi
Week 1: During the 10 week Stevens REU research program our task is to find a method of testing various type of radio frequencies such as CDR, SR, and DSA. During the first week our main goal was to determine which tool to use to accomplish this task. Me and a group of 2 other students have decided to use Matlab to solve this problem. Our goal is to design a GUI program on Matlab that will easily allow the user to test various radio frequencies. The program will take in an input signal and allow the user to visualy see on the GUI which radio frequencies are the most busy and have the most amount of noise. Based on this input the user will be able to determine which is the optimal frequecy to use. Description of Radio Signal Types: 1. SDR: All functions, modes and applications can be configured and reconfigured by software (frequency range, modulation type, maximum output power,) 2. CR: A radio that can change it transmitter parameters based on interaction with the environment in which it operates. 3. DSA: Key function in implementing DSA include sensing the radio frequency (RF) environment, identifying available channel resources, and adapting transmissions through the available channels

Brainstorming First, to become familiar with the Matlab software Professor Yao sent us a test .m and .fig file for a sample GUI. We played around with the GUI to learned how to make a basic GUI and use some of the important features of Matlab. The sample GUI had two graphs that graph random data when a button on the GUI was pressed. When playing around with the file, our goal was to try and think of the best way to use this software to accomplish our task. Next, we sat down with Professor Yao and discussed exactly what he wanted us to work on and shared our own ideas. At first he said was to create a very simple GUI that performed only 2 tasks. We had to develop a GUI that incorporated 2 users (primary and secondary). The primary user will be a graph showing traffic vs. channel. To make it easy at first, we will have only 10 channels and each channel can be either open or closed (0 or 1). We thought that using a bar graph would be the easiest way of displaying this situation to the user. In addition, we will have a button on the GUI that will randomly generate 0's and 1's and determine which channels are open and closed. We use the random number function to accomplish this and if the number generated is less than .3 it is set to 0 and if it is higher than .3 it is set to 1. The secondary user will consist of a good guy and bad guy. Our goal is to design this code like a game. The good guy should be able to look at the primary user and figure out which channels are open and use these open channels. The bad guy should not be able to see the primary user and figure out which channels are being used and should be given less power than the good guy.
106 | P a g e

Progress So far we were able to create a basic GUI that shows the primary user and generates 10 random numbers (either 0 or 1) and displays the result in bar graph showing traffic vs. channel. A black bar at 1 represents that the channel is busy and can not be used by the secondary user. No bar at a particular channel represents that the channel is open and can be used by the secondary user. We still are thinking how to design the interface for the secondary user. In addition, as we progress in the project we will make the program more realistic and differentiate between levels of traffic between 0 and 1 and represent medium traffic by maybe a gray bar. We will also incorporate more users to the design. Below is an image of the first GUI we created. In the window we have a traffic vs. channel graph and button that generates random traffic data. When we click the button it generates random data each time its clicked for 10 channels. Right now if the number generated is less that .3 the traffic will be set to 0 and anything else will be set to 1.

Week 2 During the Tuesday meeting we discussed our weeks progress and discussed solutions for implementing the second user. We had to figure out away to filter out the data from the random traffic generator to find out which channels were busy and which were open. We decided to check each channel to see which ones were open and then random select an open channel. If all the channels were full the secondary user would not be able use any channel. We implemented the same logic for a 3rd user that can select any open channel after the 2nd user goes. Below is an image of the 2nd GUI design. This was our first design to implement the second user. The blue graph represents the 2nd user which is allowed to randomly select any open channel that the primary user isn't using. The green graph represents the 3rd user that is allowed to pick any empty channel after the 2nd user goes,

107 | P a g e

This is still basic and simplified design. One of our goals is to restrict the 3rd user and give it limited power. Also we would like to implement additional buttons for the good guy and bad guy that will allow them to change to other open channels if they want too. In addition, we would like to improve the design of the GUI and think of better names for each user and the over program. Improved Design and Features Below is an image of the further developed GUI design that we worked on during the past week. 1. We added restrictions to the bad guy that only allows it to choose an open channel if it is between channel 1-3. 2. The good guy and bad guy can also change the their channel by clicking the buttons 'good guy' and 'bad guy.' If the good guy chooses a channel that the bad guy is using it will kick the bad guy off that channel and use that that channel. The bad guy will then be automatically shifted to any other open channel or kicked off completely if there are no open channels. 3. In addition we added the capability of having up to 10 good users. The number of good guys can be added by clicking the buttons for 'add user' and 'remove user.'

108 | P a g e

Designing the GUI Below is an image the GUI editor. We further improved the overall design of the GUI. We added colors to the buttons and gave the buttons better names. We changed 'good guy' and 'bad guy' to to 'authorized user' and 'restricted user.'

Accomplishments and Future Improvements So far we successfully are able to have up to 10 users and 11 including the restricted user. There are still a few small bugs in the programs but we will hopefully be able to fix them soon. We would like to increase the then number of channels for the primary user from 10 to 20 and have certain channels have a high probability of being busy than others. Maybe we could have channels 1-10 have a higher prob of being full than 11-20. In addition we may want to implement a police user that kick off the restricted user if it manages to hack and use a restricted channel.

Week 3 Accomplishments:

109 | P a g e

During the week we were successfully able to incorporate user inputs for the number of authorized and restricted users and implement a basic police player into the program. The user can input any number of users and the program will determine the amount of open channels and plot the most possible users. GUI version 1: In this version of the GUI there is a police on/off button and input ares for number of restriced and authorized users. Every time i click the genrate data button it generates the graphs for each primary auth and restriced users. If police is on the restriced user can only go to channels 11-20. There is also a window that shows the primary user data.

Improvements: After designing this GUI i showed it to Professor Yao and discussed possible improvements and flaws in the program. The main issue was to make the program more cognitive. Meeting notes: -The Primary user should not be completely random like we have...each time we press it there should maybe be random deaths and bursts (so maybe there are a couple of new channels being used and some go away but the rest stay the same). - Have a sep button for genrating overall data and another for just chagning the primary user -Do the police a diff way...create window for police ( if restrited user is using 1-10 police plots a bar at that spot and and restriced user will plot somewhere else). we may not necessarily have police on/off button. -Authorized user is not allowed to kick off the restriced user. if authorized user wants to use a channel the restricted user is using police must first clear that spot for auth user. -once restriced is kicked off of one channel he should remeber that he cant take that one -Eventually make the GUI dynamic...meaning that once we click genrate data, it plots multiple situations by itself on diff plots without clicking any buttons (plot diff things based on time passed)..i have no clue how to do this
110 | P a g e

Gui Version 2: In the second version of the GUI i implemented a window for a police and successfully implemented a memory/cognitive type behavior for the restricted user. If the the bad user selects a channel between 1-10 the police removes the user and places a police marker at that channel. Next time the data is generated the restricted user will remember that that channel cannot be used and choose another channel. eventually the restricted user will remember that channels 110 cannot be used and will only choose between 11-20. However, is the police is turned off he will be able to choose any channel that he between 1-20 that he had not been punished for by the police yet. For example, if he was removed from channels 2, 4, and 5, he will pick any channel besides those 3. As a result, the restricted user does not know when the police is on/ off but remembers each channel where he was punished. In addition, now the primary user data is only random the first time the data is generated. After that, there will be a total of 3 deaths or births each time the primary user is button is clicked.

Goals: - Determine the rules whether the primary user can kick off the authorized user if the auth user is using a particular channel. - Make the program more cognitive. - Eventually make the GUI more dynamic. Week 4 During the past week our team successfully agreed on specific rule set for our program. We created flow charts for the main functions required for the program (primary user, auth/unauth user, and police) and discussed the rules with Professor Yao. Below are the final flow charts we created that describe the logic used in the matlab code.

111 | P a g e

112 | P a g e

After we determined the rules, Angela was able to learn how to call specific function in matlab using the handles class, which enabled us to write a much more efficient and easy to understand
113 | P a g e

code. As a result, we rewrote the entire code based on the new rules using function and have completed the logic required the for project for now. In addition, after working on the logic portion of the code i also worked on making an easy to understand gui. Right now the gui has 4 windows. The three windows on the left show the traffic channels after the primary, authorized, and unauthorized choose their channels, the final traffic results after considering collisions, and collisions results between auth/unauth, auth,auth, unauth,unauth, and police/unuath. This makes it easy to see whats going on to the user. The 4th window show the statistic of bad events per number users over time. Right now each time step corresponds to each time we click the generate traffic button. Eventually we want to make each time step automatic making the program dynamic. Below is an image of my latest gui design.

Goals: -Implement learning behavior capability for the authorized user like we did for the unauthorized -dynamic time step -improve gui -add game aspect to program implementing game theory. Week 5: During the past week we worked on developing a more intuitive gui. We were able to improve the graphs for displaying traffic data using a stacked graphing function in matlab and winter and autumn color maps. -We would like to create our own color maps for the specif colors we need.

114 | P a g e

-We also want to improve the display for showing more than one user by maybe having all the bars be the same height and different colors instead of having different height for diff number users. -We are also working on improving the displays for the statistics plots.

Goals: We have now become more adept at using the graphing function in matlab. Now we have to work on a few problems in our matlab code. -We want to implement a class for unauthorized and unauthorized user to give each user their own identity which we do not have right now. -This will allow us to implement the punish memory function properly for each individual user. -Currently we are looking at all unauth/auth users as the same entity which is false. Week 6 and 7
115 | P a g e

During week 6 and 7 we addressed various problems dealing with the GUI layout and the Program Logic. For the GUI layout we addressed various goals of having user inputs for the traffic threshold level, number of channels in the band, length of time step, and a better input for number of users. We organized the inputs accordingly on the bottom of the GUI in two Panels. -The inputs for traffic threshold and number of channels are located next to the START PROGRAM button. -The inputs for time step and inputs for number of users are located next to the TIME STEP button. In addition, we improved the color scheme for the authorized and unauthorized users. -The authorized user ranges from different shades of blue. -the unauthorized user ranges from different shades of red. On the Right Side of the GUI there are 2 axes for various Statistic Plots for the User to monitor the behavior changes of the authorized and unauthorized users. -The plot on the top right displays the percentage of a bad event occurring for the unauthorized user. -As the Time Step increases fewer bad events occur because the unauthorized user begins to learn which channels are good and bad. Thus, the line begins to slope downward as shown in the picture below. -We have not complete a Statistic plot for the authorized user yet. -One of our main goals is to improve the Statistic aspect of the GUI during the last 3 weeks of the REU program. Theses Improvements can be shown image below.

116 | P a g e

Regarding the Program logic, we successfully program and identity for each user. This solved our previous problem and now each user has their own punish memory. Rules -Each Unauthorized User will learn that a channel bad if they are punished or have a collision three consecutive times. -If the successfully get on channel 2 times in a row this is saved in their access memory matrix and will remember to check in that channel even if they get a bad event three times. -Eventually they will learn which channels are good and which are bad. These Rules are very simple but they as can be seen by the graph over time the Overall Behavior of the unauthorized User improves. We would like to implement a similar type of learning behavior for the authorized user. -For the authorized user he may choose the the channels where bad events occur least often first to improve success rate of finding a white space. Goals: -Improve GUI display for Statistics and add user inputs for statistics. -Implement Learning behavior for Authorized User. Week 8 So far during the first half of the week I was successfully able to use the pause function in matlab and the timestep is now more dynamic for the user. In addition, we added a user input for the police controlled band. Goals -During the week is to determine a set of rules, or game that can be applied the authorized user and improve learning behavior. -Learn how to use best fit line to display statistics more intuitively. -Organize and comment code to make easier to understand.
117 | P a g e

Authorized User learning behavior -During the week added a basic learning behavior for each authorized user. Each time a collision occurs the authorized user remembers this event during the next time step. If a collision occurs more than three times in row the authorized will save that channel in failmemory and will avoid looking there during the next time time step. They will only check there next time if all other channels are busy. -This will decrease the number of collision in the second band because after the unauthorized user learns that the police band was bad it made the second band too crowded. -This Should improve the performance for both authorized and unauthorized users and decrease the probability of bad events. Statistics -We created a graph of Probability of Collisions vs Number of users -This graph constantly updates each time step and as the user changes the inputs for the number of users. -This graph demonstrates that the probability increase as number of users increase. -As the graph shifts downward as time increases because performance improves due to learning behavior. -The 3 pushbuttons to view this plot for unauthorized, authorized, or combined user performance. Goals -We would like to save the statistics graphs after running alot of simulations with a many different users and use the hold function to just show new data points when open the GUI and running simulations -This would make the project seem more professional during our final presentation.
118 | P a g e

-We would also like to add another statistic plot showing total probability of bad events to time similar to what we had before. -However this time we would like to only plot one data point for each 10 timesteps, showing the probability of bad events during that 10 step time period. -Maybe add a third dimension to the Probability of Collisions vs Number of Users plot. This will be able to show the improvement of behavior over time per number of users. Week 10 During the past week we finished and cleaned an almost final version of the program. Additions: -We have 3 statistic plots. -The first statistic plot shows the average number of collisions per number of users. This graph demonstrates that as the total number of users increase the average number of collisions increases. - The next 2 plots display the probability of collisions over time for authorized and unauthorized users. It graphs plots a point each 20 time steps. Eventually after time the probability of bad events decreases. The user can add a best fit line to show the improvement in performance and learning behavior. However, this statistic is more accurate when the number of users relative to the number of channels is low. When there are too many users the collision rate is too high and it is difficult to show improvement in performance. -Channel Sharing -There is a user option to allow 2 users to share a channel without considering it as a collision of 'bad event'. This decreases the number of bad events but we are not sure how realistic this idea is so we left it as a user selected option.

119 | P a g e