Although the proposed MCRN protocol for decentralised CRNs was discussed in depth in chapter 3, it is entirely revisited in this chapter with some additional factors belonging to the security procedures. The additional aspects can be highlighted into two sides. The first is a cooperative dedicated server that is engaged for the authentication purpose and providing the security key management to end users through registering CUs for controlling the entire network. The second belongs to the additional security frames required to provide the necessary security demands, including the authentication and users’ validation, as well as secure communications among incorporating entities. These additional aspects are applied to both DSMCRN and SSMCRN equally with the same added frames and server involvement. However, the main difference between them is that some of the frames have different sizes compared to each other in both protocols. This is because of the required security information exchanged between CUs and the server.
79
Thus in Figure 3-10, a dedicated server is incorporated within the communication over only the dedicated CCC, which is allocated to the server and CUs only for exchanging the security frames and control information belongs to the sensing channels results (Free channels List, FCL, or white spaces) and the most reliable selected licensed data channel (SLDCH) for the aim of exchange data between a pair of CUs within the same range.
Therefore, case 1 refers to two different situations in which the CUs perform the contention method to access the CCC in order to communicate with the server for the registration process to gain authorised access to network information, or authentication procedure to send a request for validating CUs. This case is only used for security purposes, and is considered an initial stage in which a CU exchanges registration and security frames before initiating the process of control information exchange. This aims to control the network, so that it can only be utilised by authorised CUs. Once the CUs are successfully authenticated and permitted to continue communicating with each other, then case 2 is begun to exchange the FCL and SLDCH information over the CCC, and to perform the switching procedure to the SLDCH. Therefore, the same discussion about the network scenario as raised in section 3.2.3 is applied in DSMCRN and SSMCRN protocols, to exchange control information and initiate data transmission. Thus, the complete framework of both DSMCRN and SSMCRN is demonstrated in Figure 3-11.
80
LU LU A dedicated Common Control Channel (CCC)
Data Channel 1 Data Channel 2 Data Channel 3
X
A dedicated Common Control Channel (CCC)
√
CUCU
X
Case 1. A CU communicates with the dedicated server over the CCC
Case 2. A CU communicates with another CU over the CCC
Case 3. A CU select an available data channels CU CU CU CU CU A dedicated server
X
CH 2 CH 2 FCL CH 3 SLDCH81 CU-A
CU-A CU-BCU-B
Server Server ITA CTS RTA CUA2 CUA1 RTS Server Server CU-A CU-B CU-A CU-B RTR CTR IOR COR CU-A
CU-A CU-BCU-B
Data ACK
A) Phase 1: Registration Frames
B) Phase 2: Authentication and Control information Frames
C) Phase 3: Data transmission Frames
Figure 3-11: DSMCRN and SSMCRN architecture
The assumed authentication server involved in the network and shown in Figure 3-11 is a layer 2 device which can be an AP or a mobile device. It is assumed that the device is capable for providing the required associated transparent security functions related to the encryption and decryption. This differentiates the operation of the assumed authentication device in the proposed protocols from the other existing authentication servers that operate in the application and transport layers such as RADIUS and TACACS+ respectively. Therefore, the proposed protocols integrate all the required security features in a single layer instead of relying on multiple layers this avoiding complexity and
82
possible additional overhead that might occur that lead to the decrease in network efficiency. Accordingly, the proposed security protocols are simple in their structure and operation, since the assumed layer 2 authentication server has less complexity in terms of performing authentication processes without the need of access credentials which are required for RADIUS. Moreover, since the CRNs are self-organised, self-configured and can be deployed anywhere and anytime free of cost, the use of existing authentication server will have additional costs that can affect the deployment of CR technology. Therefore, the proposed security protocols use the authentication server for both registering CUs and authentication purposes. In addition, the use of the associated security at the MAC layer ensures the protection and confidentiality for the information presented in the MAC frames related to the message transmission between two CUs in decentralised CRNs. Thus, the security issues related to the PHY and MAC layers in decentralised CRNs, such as jamming attacks, Spectrum Sensing Data Manpulation/Falsefication, MAC address Spoofing, and Primary User Emulation (PUE) and Primary User Interference (PUI) attacks, are handled by offering the security at these layers.