Cognitive Manager for Hierarchical Cluster Networks Based on Multi-Stage Machine Method

Abstract

Apart from efficient use of assigned spectral resources as a primary user, Cognitive Radio (CR) has the ability to act as a secondary user, utilizing available radio resources, which are not used by primary users for a certain period of time. This paper refers to mobile CR network management, based on multi-stage machine method. The article shows the idea of the Cognitive Manager (CM), consisting of three logical modules: Clustering (CL), Clusters Graph Coloring (CGC) and Supervisor (SP) with Sensing Client (SC). SP is responsible for management of all other cognitive manager blocks. This paper describes the SP structure and its cooperation with other CM modules. Prepared simulation scenarios take into account the propagation phenomena and presence of other users and jammers, that can use the same frequency channels as CR network. The events like lack of communication between nodes, bad links quality and presence of jamming, cause the appropriate reaction of SP. In such cases, SP performs analysis of current situation, and if necessary, it changes actual used frequency (color) using backup channels list, which is permanently updated. The presented idea has been implemented in the CORASMA (COgnitive RAdio for dynamic Spectrum MAnagement) simulator.

Full text

Authors: Krzysztof Malon, Paweł Skokowski, Piotr Marszałek, Jan M. Kelner,
Jerzy Łopatka
Title: Cognitive manager for hierarchical cluster networks based on
multi-stage machine method
Proceedings: Proceedings of MILCOM-2014
Volume: –
Pages: 428-433
Conference: 2014 IEEE Military Communications Conference, MILCOM-2014
Location: Baltimore, MD, USA
Date: 06-08 Oct. 2014
DOI: 10.1109/MILCOM.2014.77
INSPEC Accession Number: 14773816
Print ISBN: –
Publisher: IEEE
Original Source: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6956798
Copyright Notice
©2014 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this
material for advertising or promotional purposes or for creating new collective works for resale or
redistribution to servers or lists, or to reuse any copyrighted component of this work in other works
must be obtained from the IEEE.

Cognitive Manager for Hierarchical Cluster
Networks Based on Multi-Stage Machine Method
Krzysztof Malon, Paweł Skokowski, Piotr Marszalek, Jan M. Kelner, Jerzy Lopatka
Institute of Telecommunications, Faculty of Electronics
Military University of Technology
Warsaw, Poland
{kmalon, pskokowski, pmarszalek, jkelner, jlopatka}@wat.edu.pl
Abstract — Apart from efficient use of assigned spectral
resources as a primary user, Cognitive Radio (CR) has the ability
to act as a secondary user, utilizing available radio resources,
which are not used by primary users for a certain period of time.
This paper refers to mobile CR network management, based on
multi-stage machine method. The article shows the idea of the
Cognitive Manager (CM), consisting of three logical modules:
Clustering (CL), Clusters Graph Coloring (CGC) and Supervisor
(SP) with Sensing Client (SC). SP is responsible for management
of all other cognitive manager blocks. This paper describes the
SP structure and its cooperation with other CM modules.
Prepared simulation scenarios take into account the propagation
phenomena and presence of other users and jammers, that can
use the same frequency channels as CR network. The events like
lack of communication between nodes, bad links quality and
presence of jamming, cause the appropriate reaction of SP. In
such cases, SP performs analysis of current situation, and if
necessary, it changes actual used frequency (color) using backup
channels list, which is permanently updated. The presented idea
has been implemented in the CORASMA (COgnitive RAdio for
dynamic Spectrum MAnagement) simulator.
Keywords — cognitive radio, cognitive manager, cognition
cycle, state machine, resource management
I. I
NTRODUCTION
In modern radio communications systems intelligent radio
technology, also called CR [1],[2],[3], is increasingly used. A
method of CR idea implementation in radio networks depends
on their size and nature. In the case of the cellular networks,
CR can be used locally, with respect to one or several
neighboring cells. In addition, some elements of the cellular
networks are stationary, e.g. base stations and network
management centers. Thus, creation of situational awareness
and Radio Resource Management (RRM) are much easier in
this type of networks.
The implementation of CR idea is much more difficult in
the fully mobile radio networks, which are used e.g. for
military purposes. It is due to the large spatial range of the
network and the fact that all elements of the network can be on
the move. Another complication is the need for radio
communications to be operated in combat or crisis situations,
while intentional jamming of used frequency bands may
occur. A central management of the network and its resources
is not possible in such situations, and therefore it requires the
use of distributed, decentralized management.
Most of the available publications, which discuss methods
and applications in CR networks, concern the civil radio
networks. In this case, usually the occurrence of other nodes,
which can also use the available radio resources, should be
taken into account, however in the military networks, the
potential presence of intentional jammers may also take place.
This paper refers to the use of CR in the mobile military
networks. The presented results were obtained during the
development of CORASMA simulator.
The paper consists of six sections. The second part is an
introduction to CORASMA simulator. In the third section, the
structure of the radio network in a simplified manner is
presented. The next two sections comprise main part of the
paper and present ideas of CM and SP proposed by authors
during the CORASMA project.
II. CORASMA
S
IMULATOR
CORASMA is the cognitive radio simulator, which was
developed, from 2010 to 2013, within the "Cognitive Radio
for Dynamic Spectrum Management" project conducted under
the auspices of European Defence Agency (EDA). This
project was realized by an international consortium included
the following companies and institutions: Thales
Communications from France (leader), Italy and Belgium,
Thales Defence Deutschland from Germany, SAAB from
Sweden, SELEX from Italy, Tekever from Portugal, and
Institute of Telecommunications from Military University of
Technology (MUT) Poland.
The idea of the CORASMA project was preparation of
European industry to develop the next generation military
radio systems, which will be based on CR and Software
Definition Radio (SDR) technology [3],[4],[5]. This will allow
more efficient use of networks and radio resources in the
Network Centric Warfare (NCW) [6],[7]. The aim of the
project was to develop appropriate methods of spectrum
management with the use of the ability of systems to adapt in
a complex electromagnetic environment. The final result of
the project is developed demonstrator of technology–
CORASMA simulator.
CORASMA simulator was developed to evaluate the
efficiency of cognitive solutions at the operational level.
OMNeT++ [8] is the simulation environment, which allows
creation of High Fidelity simulator (HiFi), covering the first

three layers of the Open Systems Interconnection (OSI)
[9],[10]:
1) physical layer (PHY),
2) data link layer, or medium access control (MAC),
3) network layer (NET),
as well as Radio Environment Modelling (REMO) module to
simulate multidimensional (in space, time and frequency)
physical phenomena.
HiFi simulator means that OMNeT++ allows faithful
reproduction behavior of these three layers in relation to real
systems. This type of simulations are becoming more and
more popular, therefore the possibility of MAC and PHY
modeling are more advanced [9], [10], [11].
The REMO goal is to calculate the effect, at receiver side,
of multiple radio transmissions taking place simultaneously
and potentially occupying (or overlapping) the same frequency
bands in a mobile environment over digitally defined terrain
and ground clutter (e.g. buildings). To attain this goal REMO
takes into account the large and small scale propagation
effects, as well as geometry of radio links and surrounding
environment (e.g. rural or urban). Large scale path loss
attenuation is calculated by mixing two point-to-point models:
ITU-R P.1411 [12] and ITM Longley Rice [13], for short and
long transmitter-receiver separation distances respectively.
Small scale fading due to multipath reception is modelled by
tapped delay line with 6 taps – this statistical approach is
based on COST207 [14]. In terms of signal processing REMO
performs frame based calculations over I/Q samples tagged by
additional data (timestamps, power level and center
frequency). As a result the following effects can be modelled:
inband interferences like jamming, frequency shifts due to
nodes mobility, received SNR variation due to path loss and
noise generation, time shifts in due to physical separation of
nodes in space.
PHY is responsible for the following tasks: channel
coding, modulation, demodulation and decoding in the
baseband, i.e. I/Q samples of the complex signal are analyzed
in simulation. MAC allows the use of standard data protocols,
including providing signaling messages in the system. Thus it
can evaluate the redundancy of signaling information and the
system sensitivity in case of signaling loss. The NET layer
provides an implementation of routing protocols, IP signaling
and simulation of any lower layers of the OSI model [10].
CORASMA simulator also contains: application layer
(APP), i.e. seventh layer of OSI model, and the layer of
cognitive management of the resources (CMR) [15]. CMR is
described below in this paper, while APP is implemented
using traffic generators to simulate the telecommunications
traffic of the network users.
III. N
ETWORK
T
OPOLOGY
CORASMA simulator enables static and dynamic Ad-Hoc
networks analysis. All information about simulation
parameters e.g. nodes positions, traffic generators, available
frequency channels etc. are included in an XML scenario.
The spatial configuration changes of radio network, and
the associated radio propagation conditions variations, impose
permanent situation awareness update by individual node. Due
to the different networks dimensions (sizes), the analysis of all
network in each node is often impossible or may be
unnecessary (e.g. because of the additional signaling traffic
related to information exchange between nodes). Therefore,
network analysis is often limited only to the nearest
neighborhood.
In the CORASMA simulator, networks has functional and
hierarchical structure. The whole network is divided into
smaller parts called clusters. There are three nodes types:
• CH (Cluster Head), which is responsible for resources
management within its cluster,
• GW (Gateway), which provides communication
between neighboring clusters,
• RN (Regular Node), without any special functionality.
External components, simulating other systems and
sources of interferences are called NcN (Non-cooperative
Nodes).
Fig. 1 presents example network divided into nine clusters.
Fig. 1. Example clustered network topology
In order to create the clustered network structure, a
Clustering (CL) algorithm is used. The CL main principle is
that in each cluster there is only one CH and all other nodes
are RN or GW type. Each node has a direct connection with its
CH i.e. CH is their one hop neighbor.
Another important issue is an effective allocation and
management of available resources, which is realized by the
Radio Resource Management algorithms. In CORASMA,
there are two basic RRM algorithms: Cluster Graph Coloring
(CGC) and Slots Allocation (SA). CGC is responsible for
frequency channels (colors) allocation to each cluster, while
the SA for allocation of data slots. It is required that
neighboring clusters should use different frequency channels.
Additionally the transmitted RF power should be limited to
avoid interferences with another clusters working on the same

channel. It enables effective spectral resource utilization,
which is shown in Fig. 1, where each color represents a
different channel. For presented scenario with nine clusters
only three frequency channels are necessary, to operate the
network, however in the current version of the simulator, only
manual power selection is implemented.
IV. C
OGNITIVE
M
ANAGER
Testing and effectiveness studies of cognitive solutions,
placed in Cognitive Plane (CP), were realized in relation to the
Basic Waveform (BW). Relationships between these two
blocks are presented in Fig. 2. The structure is implemented in
each network node, but particular elements can have different
functionality depends on the node type (CH, GW or RN). The
most cognitive solutions concern Cluster Head nodes.
Fig. 2. Basic Waveform and Cognitive Plane
Basic Waveform consists of two main parts:
• Data Plane, which includes three lowest OSI layers
implemented in OMNet++ environment,
• Control Plane, composed of non-cognitive solutions:
o proactive Optimal Link State Routing
(OLSR),
o Retransmission Manager (RM),
o Random Access Slots Manager (RASM),
responsible among others for data
broadcasting in the control channel in order
to create and update the network structure
awareness,
o and three previously mentioned algorithms:
Slots Allocation, Clustering and Clusters
Graph Coloring.
The main part of Cognitive Plane is Basic Waveform
Mirror Block (BWMB) which includes cognitive algorithms
that can replace their counterparts from BW. Additional
elements are: Supervisor (SP) with Sensing Client (SC),
Sensing Block (SB) and Data Base (DB). All Cognitive Plane
elements create Cognitive Manager. Two-way communication
between BW and CP is realized by Cross-Layer Interface
(XLI).
During the CORASMA project, each consortium member
developed own cognitive solutions, except the Sensing Block
which was common. Several detectors types and sensing
methods gave the opportunity to configure this block [16]. In
MUT three cognitive elements were developed: CL, CGC and
SP with SC. The following part of this paper concerns the
Supervisor with Sensing Client block.
V. T
HE
MUT
S
UPERVISOR
The Supervisor module is implemented in each host and
controls the following cognitive plane modules: Clustering,
Cluster Graph Coloring and Sensing Block, and works as a
state machine with eight stages (Fig. 3):
• temporary states (yellow):
1) SP_NULL,
2) SP_WAITING_FOR_CL,
3) SP_WAITING_FOR_CGC,
4) SP_WAITING_FOR_SENSING,
• normal, stable states (green):
5) SP_ORDINARY,
6) SP_CLUSTERHEAD,
• emergency states (red):
7) SP_ORDINARY_EMERG,
8) SP_CLUSTERHEAD_EMERG.
SP_NULL
SP_WAITING_FOR_CL
SP_WAITING_FOR_CGC SP_ORDINARY
SP_CLUSTERHEAD
Is Cluster
head?
NO YES
SP_WAITING_SENSING
SP_ORDINARY_EMERG
SP_CLUSTERHEAD_EMERG
Fig. 3. The stage diagram of the Supervisor
The SP_NULL is an initial stage of the Supervisor. In this
stage Supervisor immediately sends a start request to the
Clustering module and then goes to the
SP_WAITING_FOR_CL stage. After reception the result of
clustering procedure, the Supervisor checks whether it is
cluster head. If not, it goes to the SP_ORDINARY. Otherwise
it sends a start request to the Cluster Graph Coloring module,
and goes to the SP_WAITING_FOR_CGC stage. The end of
CGC algorithm, causes generation of the first sensing task to
all regular nodes in the cluster and transition to the
SP_WAITING_FOR_SENSING stage. After reception of the
assumed number of messages with sensing results, which are

sufficient for the backup channels prioritization, Supervisor
goes to the SP_CLUSTERHEAD. These state transitions are
presented in Fig. 3 as black solid lines and this process can be
considered as the ideal initialization phase, leadings to one of
two so-called stable states: SP_ORDINARY or
SP_CLUSTERHEAD. After initialization phase, Supervisor
goes to the operational phase in which emergency situations
can occur. In such cases, Supervisor changes its state to
SP_ORDINARY_EMERG or SP_CLUSTERHEAD_EMERG
and takes actions in order to return to the normal (stable) state,
e.g. changing of used frequency channel according to
previously determined backup channels list. In both,
initialization and operational phases, there are also another
possible transitions caused mainly by the Clustering algorithm
(e.g. need to change CH) which are marked by dashed lines in
Fig. 3. In the next two subsections, the Supervisor cooperation
with Clustering and Coloring algorithms are described and
then OTA (Over-The-Air) communication between
Supervisors is presented. Detailed collaboration with Sensing
Block can be found in [16].
A. Supervisor – Control of CL Module
The cooperation between the Supervisor and the Clustering
module during the initialization phase for Ordinary node is
presented in Fig. 4. The first action which is taken by the
Supervisor in the SP_NULL stage is to send a start request to
Clustering (SP2CL_START message). This message starts the
clustering process and after the competition of this algorithm
the message CL2SP_FINISHED, which contains information
about the node status (Ordinary, Cluster Head or Gateway), is
sent. In the case presented in Fig. 4, according to the
Clustering result, the Supervisor goes to SP_ORDINARY
stage.
Clustering
Supervisor
initialization phase
SP2CL_START
process
clustering
CL2SP_FINISHED
Stage: SP_WAITING_FOR_CL
Stage: SP_NULL
state=1 (Ordinary) or
state=3 (Gateway) or
state=4 (Cluster Head)
Stage: SP_ORDINARY
Fig. 4. Cooperation between Supervisor and Clustering in the initialization
phase for Ordinary node
Fig. 5 shows exchange of the Supervisor messages with
Clustering in the example scenario. The first part of this
scenario is the same as in Fig. 4. CL2SP_FINISHED message
causes change the Supervisor state from
SP_WAITING_FOR_CL to SP_ORDINARY. During the
clustering process in passive mode (internal Clustering stage),
in some cases (for example: the need for Cluster Head re-
election or low battery level), Clustering module can send
CL2SP_REBUILD message. If Supervisor accept this rebuild
proposition, it sends SP2CL_START and goes to
SP_WAITING_FOR_CL stage. In the example presented in
Fig. 5, the Clustering decides that the new node state is Cluster
Head and sends CL2SP_FINISHED message.
Clustering
Supervisor
SP2CL_START
process
clustering
CL2SP_FINISHED
Stage: SP_WAITING_FOR_CL
Stage: SP_NULL
state=1 (ordinary) or
state=3 (gateway)
Stage: SP_ORDINARY
process
clustering
CL2SP_REBUILD
SP2CL_START
process
clustering
CL2SP_FINISHED
Stage: SP_WAITING_FOR_CL
state=4 (Cluster Head)
Fig. 5. Cooperation between Supervisor and Clustering in the example
scenario
Supervisor which is in the SP_CLUSTERHEAD stage can
sends requests SP2CL_RN_REQ to Clustering module in order
to maintain the actual information about the number of regular
nodes in its cluster. After that, the Clustering response by
sending the regular nodes MAC addresses (CL2SP_RN).
B. Supervisor – Control of CGC Module
The example messages exchange between the Supervisor
and the Cluster Graph Coloring is presented in Fig. 6. It
shows a part of initialization phase which concerns the
Coloring process. If the node after the Clustering algorithm
become a Cluster Head, it sends SP2CGC_START message to
CGC module and goes to SP_WAITING_FOR_CGC stage. In
some cases, it may be necessary to restart the Coloring using
messages which are depicted inside the rectangle with blue
dashed lines in Fig. 6 (SP2CGC_CLEAR and
SP2CGC_START). Transition to the next Supervisor state
occurs after the CGC2SP_FINISHED reception.
During the operation phase, it is possible that Supervisor
updates the node colors in Coloring module. This may occur
in two main cases. The first case is the emergency state, within
that Supervisor changes the node color. After this change it is
necessary to update own color in the CGC block. The second

one is reception of OTA message from the Supervisor of
neighbor Cluster Head. It also causes sending the
SP2CGC_COLOUR_UPDATE message which contains MAC
address of node and its new colors.
Clustering
Supervisor
initialization phase
CL2SP_FINISHED
state=4 (Cluster Head)
Stage: SP_WAITING_FOR_CGC
Coloring
SP2CGC_START
process
coloring
CGC2SP_FINISHED
Stage: SP_WAITING_FOR_SENSING
SP2CGC_CLEAR
SP2CGC_START
In case of timeout elapsed
SP2SP OTA messages
Stage: SP_WAITING_FOR_CL
Fig. 6. Cooperation between Supervisor and Coloring in the initialization
phase for Cluster Head node
C. Supervisor – OTA Communication
In this section over the air communication between
Supervisors is presented. Fig. 7 shows the last stages of the
initialization phase in the Cluster Head node.
Supervisor
Stage:
SP_WAITING_FOR_CGC
Stage:
SP_ORDINARY
Node A (CH) Node C (RN)
SP2SP_START_SENSING (case A)*
* messages which are sent to all nodes within a cluster (broadcast)
SP2SP_SENSING_RESULTS
initialization phase
SP2SP_MY_COLOUR_UPDATE*
SP2SP_NEIGHBOURS_COLOURS_UPDATE*
SP2SP_SENSING_RESULTS
…
SP2SP_BACKUP_COLOURS_UPDATE
*
Supervisor
Coloring
CGC2SP_FINISHED
Legend:
– internal message
Stage:
SP_WAITING_FOR_SENSING
Stage:
SP_ORDINARY
Node D (RN)
Supervisor
…
SP2SP_START_SENSING (case B)*
– OTA message
Stage:
SP_CLUSTERHEAD
Fig. 7. Supervisor in the initialization phase
After the end of CGC algorithm (CGC2SP_FINISHED),
CH Supervisor sends the set of messages
(SP2SP_MY_COLOUR_UPDATE, SP2SP_NEIGHBOURS_
COLOURS_UPDATE and SP2SP_ START_SENSING) to the
Supervisors in all nodes in its cluster. These messages convey
information about the assigned colors (own and neighbors)
and start the first sensing process. After reception sufficient
sensing results, Supervisor determines backup channels list,
which should be used in case of emergency situation, and
sends SP2SP_BACKUP_COLOURS_UPDATE. The last
operation before transition to SP_CLUSTERHEAD stage is
sending SP2SP_ START_SENSING which causes periodically
sensing in all regular nodes. For a detailed description of
sensing process (cases A and B) in Regular Nodes please
refer to [16].
During the operational phase, Supervisor in CH cyclically
requests all nodes for last sensing results (Fig. 8). This process
is performed in order to achieve two goals. Firstly, it updates
occupancy of sensing channels what is needed to actualize the
channels ranking list and consequently, backup channels.
Additionally, these periodically messages (SP2SP_
SENSING_RESULS_REQ and SP2SP_SENSING_RESULTS),
help to maintain the awareness about the connection, or lack
of it, with other nodes.
Supervisor
Stage:
SP_CLUSTERHEAD
Node A (CH)
* messages which are sent to all nodes within a cluster (broadcast)
operational
phase
Stage:
SP_ORDINARY
Node C (RN)
Supervisor
Stage:
SP_ORDINARY
Node D (RN)
Supervisor
…
SP2SP_SENSING_RESULTS_REQ*
SP2SP_SENSING_RESULTS
SP2SP_SENSING_RESULTS
…
Fig. 8. Supervisor in the operational phase – periodically requests for last
sensing results
Fig. 9 shows the example scenario in emergency situation.
Nodes A and B are Cluster Heads, while nodes C and D
represents regular nodes which belongs to CH A. In case of
bad link quality (e.g. high value of Frame Error Rate) or
connection interrupted, the nodes decide to change their states
to SP_CLUSTERHEAD_EMERG and SP_ORDINARY_
EMERG, depending on the node status. Node D in Fig. 9
represents regular nodes in which this situation occurs.
Supervisor in CH, which also detects this emergency state,
changes its cluster color, using backup channels list, and sends
SP2SP_MY_COLOUR_UPDATE to all nodes in cluster and
to neighbors of the CH. The regular nodes, that receive this
message, change their color (for example Node C in Fig. 9).
On the other hand, regular nodes which are in the emergency
state, like Node D, set their channels themselves using the
same backup channels list as in the Cluster Head. If this
process is successful, all nodes going back to the stable states.

Supervisor
Node A (CH)
* messages which are sent to all nodes within a cluster (broadcast)
operational phase
Supervisor
Node B (CH)
Stage:
SP_CLUSTERHEAD
Stage:
SP_ORDINARY
Node C (RN)
Supervisor
Stage:
SP_ORDINARY
Node D (RN)
Supervisor
…
Emergency situation
decision (CH)
Stage:
SP_CLUSTERHEAD_EMERG
Emergency situation
decision (RN)
Stage:
SP_ORDINARY_EMERG
SP2SP_MY_
COLOUR_UPDATE*
SP2SP_MY_
COLOUR_UPDATE
End of emergency
situation decision (CH)
End of emergency
situation decision (RN)
Stage:
SP_CLUSTERHEAD
Stage:
SP_CLUSTERHEAD
Stage:
SP_ORDINARY
Colour change
(use backup channels)
Colour change
(u
se backup channels)
Bad link quality or connection interrupted
Fig. 9. Supervisor in the operational phase – example scenario in case of
emergency situation
VI. C
ONCLUSIONS
This paper presents CORSMA simulator with CR elements
developed by MUT. The main emphasis is placed on the
Supervisor with Sensing Client module, which is responsible
for management of other Cognitive Manager blocks (in this
case Clustering and Clusters Graph Coloring). Another task of
this element is a reaction to an emergency events e.g. lack of
communication between nodes or bad links quality. In these
situations, Supervisor changes actually used channel (color)
using backup channels list, which is permanently updated. The
backup channel list is periodically shared between nodes in the
cluster, so in case of jamming disabling the communications
all nodes are searching the CH independently.
A
CKNOWLEDGMENT
This research work was carried out in the framework of the
CORASMA EDA Project B-0781-IAP4-GC.
R
EFERENCES
[1] J. Mitola, "Cognitive radio architecture the engineering foundations of
radio XML", Wiley-Interscience, 2006.
[2] F. R. Yu, "Cognitive radio mobile ad-hoc networks", New York:
Springer, 2011.
[3] H. Arslan, "Cognitive radio, software defined radio, and adaptive
wireless systems", Dordrecht: Springer, 2007.
[4] J. Mitola, "Software radio architecture: object-oriented approaches to
wireless systems engineering", New York: Wiley, 2000.
[5] E. Grayver, "Implementing software defined radio", New York:
Springer, 2013.
[6] D. S. Alberts, J. J. Garstka, and F. P. Stein, Network centric warfare:
Developing and leveraging information superiority. CCRP, 1999.
[7] M. Amanowicz, Ed., "Zaawansowane metody i techniki tworzenia
świadomości sytuacyjnej w działaniach sieciocentrycznych", Warszawa:
Wydawnictwo PTM, 2010.
[8] “OMNeT++ Network Simulation Framework.” [Online]. Available:
http://www.omnetpp.org/.
[9] R. Massin, C. Lamy-Bergot, C. L. Martret, and R. Fracchia,
"OMNeT++-Based Cross-Layer Simulator for Content Transmission
over Wireless Ad Hoc Networks", EURASIP Journal on Wireless
Communications and Networking, vol. 2010, no. 1, p. 502549, Jan.
2010.
[10] L. Rose, R. Massin, L. Vijayandran, M. Mérouane, and C. J. Le Martret,
"CORASMA program on cognitive radio for tactical networks: High
fidelity simulator and first results on dynamic frequency allocation", in
IEEE Military Communications Conference, MILCOM-2013, San
Diego, USA, 2013, pp. 360–368.
[11] J. Mittag, S. Papanastasiou, H. Hartenstein, and E. G. Strom, "Enabling
Accurate Cross-Layer PHY/MAC/NET Simulation Studies of Vehicular
Communication Networks", Proceedings of the IEEE, vol. 99, no. 7, pp.
1311–1326, Jul. 2011.
[12] Recommendation ITU-R P.1411, Available: http://www.itu.int/rec/R-
REC-P.1411
[13] Irregular Terrain Model (ITM) (Longley-Rice) (20 MHz – 20 GHz),
Available: http://www.its.bldrdoc.gov/resources/radio-propagation-
software/itm/itm.aspx
[14] Failli, M. "Digital Land Mobile Radio Communications: Final Report
(14 March 1984-13 September 1988)", Luxembourg: Commission of the
European Communities, Directorate-General Telecommunications,
Information Industries and Innovation, 1989. Print
[15] "CORASMA Project (Contract N° B-781-IAP4-GC) COgnitive RAdio
for dynamic Spectrum MAnagement", D4.4: Final report for Task T4.4.
Validation and performance evaluation Version 3.0.
[16] P. Skokowski, K. Malon, J. M. Kelner, and J. Łopatka, "Realizacja
sensingu radiowego w symulatorze CORASMA", in XIV Krajowa
Konferencja Radiokomunikacji, Radiofonii i Telewizji, KKRRiT-2014,
11-13.06.2014, Warszawa, article accepted.