ETSI TS 102 800 V1.1.1 (2011-01)

Technical Specification
Electromagnetic compatibility
and Radio spectrum Matters (ERM);
Cognitive Programme Making and Special Events (C-PMSE);
Protocols for spectrum access and sound quality control
systems using cognitive interference mitigation techniques

2 ETSI TS 102 800 V1.1.1 (2011-01)

Reference
DTS/ERM-TG17WG3-012
Keywords
PMSE, radio, SRD
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 102 800 V1.1.1 (2011-01)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 Refined C-PMSE Architecture . 9
4.1 Overview . 9
4.2 Radio Resource Manager (RRM) . 11
4.3 Cognitive Engine (CEN) . 11
4.4 Interfaces . 12
5 Technical Specification of the Cognitive Engine . 12
5.1 Functional architecture of the CEN . 12
5.1.1 Requirements on CEN Architecture . 13
5.2 Cyclic Unit: CYU . 13
5.2.1 C-PMSE initialisation process . 14
5.3 Fusion Engine: FEN . 15
5.4 Decision Engine: DEN . 15
5.4.1 Reasoning Module . 16
5.4.2 Learning Module . 16
5.4.3 Case Database (CDB) . 17
5.5 Optimisation engine (OEN) . 17
5.6 rmi API . 17
5.7 cmi API . 18
5.8 sci API . 18
5.9 sli API . 18
5.10 Functional Processing Flow . 18
6 Technical Specification of the Radio Resource Manager RRM. 19
6.1 Radio Resource Manager . 20
6.1.1 Action Sequencer . 20
6.1.2 Data storage Blocks . 20
6.1.2.1 Radio Environmental Map (REM) . 20
6.1.2.2 Link Parameter Set (LPS) . 21
6.1.2.2.1 Frequency Allocation Table (FAT) . 21
6.1.2.2.2 The Power Allocation Table (PAT) . 22
6.1.2.2.3 Device Allocation Table (DAT) . 22
6.1.2.2.4 Adaptive Modulation and Coding Table (AMCT) . 22
6.1.2.2.5 Interface cpi . 22
7 Technical Description of the Frequency Coordinator and the fci interface and Database Language . 23
7.1 Frequency Coordinator FCO . 23
7.2 Rationale for an hierarchical database approach . 23
7.3 Common database structure and language for FCO, REM, FEN, SCC. 24
7.3.1 Overview . 24
7.3.2 Definition of database language elements . 25
7.4 Processing of database language . 26
7.4.1 fci interface . 26
7.4.2 cpi interface . 27
ETSI
4 ETSI TS 102 800 V1.1.1 (2011-01)
8 Technical Specification of the Performance Monitor (PMO) . 28
8.1 Performance Monitor (PMO) . 28
8.2 Data tansfer from RRM to PMO (rpi) . 28
8.3 Data transfer from CEN to PMO (cmi) . 29
8.4 Logfile . 30
8.5 Visualization . 31
9 SLE / SLM . 31
9.1 Service Level Entry (SLE) . 31
9.1.1 Offline / Online . 31
9.1.1.1 Offline (GUI is not connected to the CEN) . 31
9.1.1.2 Online (CEN is connected) . 31
9.1.2 Quality thresholds . 31
9.1.3 SLE connected to SLM and DAT . 32
9.2 Service Level Monitor (SLM) . 32
9.2.1 Data received by SLM from SLE and PMSE link . 33
9.2.2 SLM data sent to CEN . 33
10 Technical Specification of Scanning Receiver Subsystem (SCS) . 33
10.1 Scanning Receiver Subsystem (SCR). 33
10.1.1 Overview . 33
10.1.2 Installation . 33
10.1.3 Connectivity . 34
10.1.4 Sharing of SCS . 34
10.2 Scanning Receiver (SCR) . 34
10.2.1 Location of SCRs . 34
10.2.2 Features . 35
10.2.2.1 Support for different measurement types . 35
10.2.2.2 Queuing of Jobs . 36
10.2.2.3 Antenna pattern control . 36
10.2.2.4 Automatic detection of location . 36
10.2.2.5 Automatic detection of time . 36
10.3 Scanning Receiver Controller SCC . 36
10.4 Interface sci between Cognitive Engine (CEN) and Scanning Receiver controller (SCC) . 37
10.5 Technical Specifications of the interface between Scanning Receiver Controller (SCC) and Scanning
Receiver (SCR) . 37
10.5.1 Interface between Scanning Receiver Controller (SCC) and Scanning Receiver (SCR) . 37
10.5.2 Scanning jobs . 38
10.5.3 Scanning report . 38
10.5.3.1 Frequency domain measurement report . 38
10.5.3.2 Time domain measurement report . 38
10.5.3.3 IQ samples measurement report . 38
10.5.4 Other commands . 39
11 RF Parameters & Service Levels . 39
11.1 Introduction . 39
11.2 Performance indicators . 39
11.3 Device Characteristics / Capabilities . 40
12 Spectral efficiency definitions . 41
12.1 Terminology . 41
12.1.1 Spectral efficiency of selected modulation scheme . 41
12.1.2 Spectral efficiency related to information source . 41
12.1.3 Spectral efficiency of a communication system . 41
12.1.4 Efficiency of spectrum usage . 42
12.2 Conclusion . 42
Annex A (informative): Bibliography . 43
History . 44

ETSI
5 ETSI TS 102 800 V1.1.1 (2011-01)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Electromagnetic compatibility and
Radio spectrum Matters (ERM).
Introduction
The present document focussed on audio link quality control; however the schemes depicted here are generic and can
also be applied for video and effect control links.
This technical specification will serve as basis for designing a C-PMSE demonstrator. The experience during design and
practical or virtual operation of the demonstrator will be summarized in the upcoming TR 102 801 [i.3].
PMSE systems are used to convey voice and music for live events such as conferences, concerts and theatrical
performances, or for recorded productions of film and television programs. In these applications, the highest attainable
level of sound quality and reliability is expected. Dropouts, noise and interference are not acceptable.
Protection
In order for PMSE devices to function properly, they must be protected from interference because they use very low
radiated power levels in comparison to most other radio communications systems. Up to now this has not been a
problem since PMSE equipment operated in locally unused TV channels that presented a very predictable RF
environment. In the future, many different kinds of new devices, the characteristics of which are difficult to fully
anticipate at this time, may be sharing this space. The question of how to protect PMSE equipment from interference
caused by these new devices has been the subject of much discussion and debate. Some of these devices will be used for
broadband data, and will occupy any spectrum which is available to them, i.e. from a few MHz to a multiple of
10 MHz. Other possible uses of the Digital Dividend may include emergency communications and other mobile
services. Traditionally, incompatible radio communications systems were assigned to operate in separate frequency
bands, but this scheme is becoming impractical in today's world of intensive spectrum use. A more dynamic solution is
needed, but it must be robust.
To address this problem, the concept of the Cognitive PMSE (C-PMSE) system is proposed herein. The C-PMSE
system is designed to respond dynamically to changes in the radio environment in order to maintain the quality of
service required by the PMSE user.
Spectrum efficiency
The regulations governing the operation of PMSE (Program Making and Special Events) systems are currently in flux
in Europe and elsewhere. As a result of the switchover from analogue to digital TV broadcasting, the amount of
spectrum allocated for television transmission below 790 MHz is being reduced. The spectrum between 790 MHz and
862 MHz is considered a Digital Dividend and has been reallocated for use by Electronic Communication
Networks [i.4]. These changes have resulted in a significant reduction in the amount of spectrum available for PSME
operation.
ETSI
6 ETSI TS 102 800 V1.1.1 (2011-01)
The adoption of the C-PMSE system offers a high potential for increasing overall spectrum efficiency and improving
coexistence between PMSE systems and local frequency management. This report describes various techniques that can
be used in such a system.
ETSI
7 ETSI TS 102 800 V1.1.1 (2011-01)
1 Scope
The present document defines the architecture and functional blocks for a C-PMSE system together with the protocols
and interfaces which link them. The findings are based on the technical recommendations in TR 102 799 [i.1].
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI EN 300 422-1 (V1.3.2): "Electromagnetic compatibility and Radio spectrum Matters (ERM);
Wireless microphones in the 25 MHz to 3 GHz frequency range; Part 1: Technical characteristics
and methods of measurement".
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 102 799: "Electromagnetic compatibility and Radio spectrum Matters (ERM); Operation
methods and principles for spectrum access systems for PMSE technologies and the guarantee of a
high sound production quality on selected frequencies utilising cognitive interference mitigation
techniques".
[i.2] ETSI TR 102 546 (V1.1.1): "Electromagnetic compatibility and Radio spectrum Matters (ERM);
Technical characteristics for Professional Wireless Microphone Systems (PWMS); System
Reference Document".
[i.3] ETSI TR 102 801: "Electromagnetic compatibility and Radio spectrum Matters (ERM); Test
reports from technology demonstrator implementing TS 102 800 on protocols for spectrum access
and sound quality control systems for PMSE applications using cognitive interference mitigation
techniques".
[i.4] Commission Decision 2010/267/EU of 6 May 2010 on harmonised technical conditions of use in
the 790-862 MHz frequency band for terrestrial systems capable of providing electronic
communications services in the European Union.
ETSI
8 ETSI TS 102 800 V1.1.1 (2011-01)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 102 799 [i.1] and the following apply:
Configuration File: file containing the PMSE setup/scene
NOTE: See clause 9.
C-PMSE link: wireless connection, which incorporates the content and control planes
Service Level Agreement (SLA): set of performance requirements a specific C-PMSE link has to achieve in order to
fulfil the requested Service Level Entries
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 102 799 [i.1] and the following apply:
ABT Ask Before Talk
AISG Antenna Interface Standards Group
AMCT Adaptive Modulation and Coding Table
API Application Programming Interface
ASCII American Standard Code for Information Interchange
ASQ Action Sequencer
BER Bit Error Rate
CDB Case Database
CEN Cognitive Engine
cmi interface between the cognitive engine and the performance monitor
cpi inter cognitive PMSE interface
C-PMSE Cognitive - Programme Making Special Event entity or system
CYU Cyclic Unit
DAT Device Allocation Table
DCF77 Radio clock signal
DEN Decision-Maker Engine
DiSEqC Digital Satellite Equipment Control
DVB-T Digital Video Broadcasting - Terrestrial
EIRP Equivalent Isotropic Radiated Power
ENG Electronic News Gathering
FAT Frequency Allocation Table
fci frequency coordinator interface
FEN Fusion Engine
FM Frequency Modulation
GNSS Global Navigation Satellite System
GSM Global System for Mobile Communications
HMI Human Machine Interface
ID Identifier
IQ Inphase Quadrature Components
KPI Key Performance Indicator
Link-ID Link IDentifier
NOTE: Tx ID + Rx ID = link ID.
LPS Link Parameter Set
LQI Link Quality Indicator
LTE Long Term Evolution
M2M Machine to Machine Interface
MIMO Multiple Input Multiple Output
MP3 MPEG-1 or MPEG-2 Audio Layer 3
NTP Network Time Protocol
ETSI
9 ETSI TS 102 800 V1.1.1 (2011-01)
OEN Optimisation Engine
PAR Peak to Average Ratio
PAT Power Allocation Table
PMO Performance Monitor
PMSE Programme Making Special Events
PWMS Professional Wireless Microphone System
QoS Quality of Service
RDS Radio Data System
REM Radio Environmental Map
RF Radio Frequency
rmi Interface between the cognitive engine and radio resource manager
rpi interface between radio resource manager and performance monitor
RRM Radio Resource Manager
RSSI Received Signal Strength Indication
SCC Scanning receiver controller
sci Scanning receiver interface
SCPI Standard Commands for Programmable Instruments
SCR Scanning receiver
SCS Scanning receiver subsystem
SLA Service Level Agreement
SLE Service Level Entry
Sli Interface between the service level monitor and the cognitive engine
SLM Service Level Monitor
SLQ Spherical Logarithmic Quantization
SNR Signal to Noise Ratio
TCP Transmission Control Protocol
WSD White Space Device
XML Extensible Markup Language
4 Refined C-PMSE Architecture
4.1 Overview
The refined functional architecture of C-PMSE is shown in figure 1. In comparison to the block diagram described in
TR 102 799 [i.1] the following differences are inserted:
• The RRM contains two more elements:
- Radio Environmental Map (REM);
- Action Sequencer (ASQ).
• Furthermore the CEN is depicted by its four main elements:
- Fusion Engine (FEN);
- Cyclic Unit (CYU);
- Decision-Maker Engine (DEN);
- Optimisation Engine (OEN).
ETSI
10 ETSI TS 102 800 V1.1.1 (2011-01)
Scanning Receiver
Regulatory
Subsystem (SCS)
Scanning
Receiver
(SCR) Frequency
coordinator
m
(FCO)
Scanning Receiver
sci
Controller (SCC)
Radio Resource Manager
CEN
(RRM)
Database
Service
Level Entry
(SLE)
REM
Cognitive Engine
(CEN)
Service
LPS
cpi RRM
Fusion Engine
Level
FAT PAT
sli
(FEN)
Monitor
(SLM)
AMCT DAT
rmi
Cyclic Unit
(CYU)
ASQ
Decision-
Optimisation
Maker Engine cmi
Engine (OEN)
(DEN) n
Performance
Monitor
(PMO)
Radio
Link
C-PMSE C-PMSE
1 2
Figure 1: Block diagram of C-PMSE
• Four more internal interfaces are introduced:
- sli: interface between SLM and CEN;
- rmi: interface between CEN and RRM;
- cmi: interface between CEN and PMO;
- rpi: interface between RRM and PMO.
• One new entity is the Scanning Receiver Subsystem (SCS) composed of:
- Scanning Receiver Controller (SCC);
- Scanning Receiver (SCR).
The four allocation tables of the RRM (i.e. FAT, DAT, PAT and AMCT) are combined to the Link Parameter Set
(LPS). LPS and REM build up the database of the RRM.
A C-PMSE is not connected directly with the scanning receivers but with a Scanning Receiver Controller (SCC) via the
sci interface. The combination of SCC and multiple SCRs is called Scanning Receiver Subsystem (SCS). The SCC is in
charge of managing the different scanning receivers connected to it. It schedules scanning jobs among the scanning
receivers and merges incoming data from different SCRs. The result of the merge process is sent to the asking CEN.
ETSI
sci
rpi
fci
fci
11 ETSI TS 102 800 V1.1.1 (2011-01)
Master slave scenarios between two different co-located C-PMSE are not supported, which means that every C-PMSE
can react only according to its own allocation tables like FAT, PAT and so on. An exchange of the neighbour's
allocation tables (minimum FAT and PAT) is possible, which can be used to recalculate a new REM by every C-PMSE.
It is optional to exchange the REM also which reduces the calculation effort of the C-PMSE which received the
configured REM.
One idea behind C-PMSE is prediction of interferer behaviour on the basis of grid sensing with a large number of low
cost scanning receivers. Due to this, there is the challenge to reduce costs of the scanning receivers. Other challenges
include:
• algorithm of the Cognitive Engine;
• costs and availability of reconfigurable radio link:
- signalling in-band or out-of-band;
- bidirectional signalling;
- robustness of signalling channel;
• availability of in-situ LQI.
4.2 Radio Resource Manager (RRM)
Two new elements are introduced in this clause (see figure 1):
• one storage block: Radio Environmental Map (REM);
• one executing block: Action Sequencer (ASQ).
The REM is a database that hosts a map of wider frequency range of interest in comparison to FAT, which lists
frequencies allowed by the regulator and frequencies actually allocated by C-PMSE; at least the frequency ranges the
FCO has granted for C-PMSE operation. This characterization of the radio environment is the outcome of the Fusion
Engine of the CEN. It is optional to exchange the REM between co-located C-PMSEs.
The DAT is filled during a plug and play process running over the complete operation time. Every time a radio link is
connected to C-PMSE, information of the connected radio link is stored inside DAT as long as it is connected to
C-PMSE.
The executing block ASQ is an excerpt of the Case Database (CDB), which is built up by the Decision Maker Engine
(DEN) of the CEN. The ASQ contains sequences of commands which should be carried out by the RRM if action is
required.
4.3 Cognitive Engine (CEN)
The CEN shall include the following main elements (see figure 1):
• Fusion Engine (FEN): The FEN merges all information about the environment coming from the Scanning
Receiver Controller (SCC), from the Frequency Coordinator (FCO), from own radio links and possibly from
RRMs of co-located C-PMSEs. The result of the merge process is stored in the REM, which is transferred to
the RRM.
• Cyclic Unit (CYU): The CYU acts as the central controller and scheduler of all processes inside C-PMSE: for
example at start up: triggers RRM to pull FCO, triggers RRM to start plug and play process for connecting
additional hardware, requests DAT and pushes it to SLM, initializes PMO, SLM, SLE.
• Decision Maker Engine (DEN): The DEN postprocesses the REM with the goal to make decisions about
which actions the CEN should take.
• Optimisation Engine (OEN): The OEN optimizes the parameter set of the RRM to maximize the performance
of the C-PMSE.
ETSI
12 ETSI TS 102 800 V1.1.1 (2011-01)
4.4 Interfaces
Three external interfaces are used for communication between C-PMSE and
• Scanning Receiver Controller: sci;
• Frequency Coordinator: fci;
• Co-located C-PMSE: cpi.
These external interfaces need a standardized format to support communication between SCC, FCO with C-PMSE of all
vendors, even communication between co-located C-PMSEs of different vendors.
In contrast, the internal interfaces are used for communication inside one C-PMSE only. Their format is vendor specific
and does not need to be standardized. The internal interfaces are:
• sli: interface between SLM and CEN;
• rmi: interface between CEN and RRM;
• cmi: interface between CEN and PMO;
• rpi: interface between RRM and PMO.
Table 1 gives a short summary of the external and internal interfaces of C-PMSE:
Table 1: External and Internal Interfaces of C-PMSE
Name Viewpoint Directivity Method Speed Service
External:
fci C-PMSE bidirectional asynchronous slow pull
sci C-PMSE bidirectional synchronous fast pull
cpi C-PMSE bidirectional asynchronous slow pull
Internal:
sli CEN bidirectional synchronous fast pull
rmi CEN bidirectional synchronous fast push / pull
cmi CEN unidirectional synchronous slow push
rpi RRM unidirectional synchronous slow push

5 Technical Specification of the Cognitive Engine
This clause presents the functional architecture of the CEN and its technical specification. Figure 2 depicts the
functional architecture of the CEN.
5.1 Functional architecture of the CEN
To develop the cognitive functionalities described in TR 102 799 [i.1], the CEN shall include the following
components:
• Cyclic Unit (CYU): This component acts as the central controller and scheduler of all processes in the CEN.
• Fusion Engine (FEN): This component extracts and merges information about the radio environment coming
from the SCC, the FCO and possibly from the RRMs of neighbour C-PMSE systems. The merged information
shall be stored in the REM.
• Decision-Maker Engine (DEN): This component understands the information stored in the REM and makes
decisions about which actions the C-PMSE system should take.
ETSI
13 ETSI TS 102 800 V1.1.1 (2011-01)
• Optimisation Engine (OEN): This component receives data from the RRM (LPS and REM) as well as from the
DEN to determine actions, i.e. the rearrangement of the RRM link parameters set (LPS), that will maximize
the performance of the C-PMSE system. Depending on the implementation, the OEN may generate a new set
of link parameters.
• rmi API: This component interfaces between the CEN and the RRM.
• sci API: This component interfaces between the CEN and the SCC.
• sli API: This component interfaces between the CEN and the SLM.
• cmi API: This component provides the user with control and monitor support to the CEN through the PMO.

Figure 2: Architecture of the CEN
5.1.1 Requirements on CEN Architecture
Each component shall constitute a separate software process (module) that interfaces and exchanges data with the other
components through some generic interface (e.g. TCP sockets, which would allow distribution of the components
among different networked hosts).
A modular architecture will allow replacement of any functional block with an equivalent processing element. As well,
it will allow for testing and evaluating different types of algorithms and implementations of the components. For
instance, different optimisation functions may be developed and compared.
A configuration file determines which components / algorithms should be loaded (launched) at each time.
When designing the components, the trade-off between performance and computation complexity is very important.
5.2 Cyclic Unit: CYU
This component is the core of the CEN. It schedules the call and timing processes of all other components.
Each component of the CEN should be defined around a basic state machine that interfaces with the CYU (see figure 3).
ETSI
14 ETSI TS 102 800 V1.1.1 (2011-01)
Generic command structure of the CYU:
:[parameters]

Figure 3: Basic state machine representing interaction between
CYU and the rest of components of the CEN
5.2.1 C-PMSE initialisation process
The CYU is in charge of initialising the C-PMSE. Therefore, the following actions are required:
• det initial cycle time;
• initialise interfaces, e.g. set update period for push/pull processes at the interfaces:
- sci API;
- rmi API;
- sli API;
- cmi API.
• request user to enter service level in the SLE;
• request RRM to upload radio data and fill into RRM (LPS tables): PAT, AMCT, DAT;
• request RRM to initialize fci;
• request RRM to query the FCO and fill FAT table;
• initialise DEN's case database with a set of already known (if any) reactive action sets, e.g. panic actions or
learned by initial training.
ETSI
15 ETSI TS 102 800 V1.1.1 (2011-01)
5.3 Fusion Engine: FEN
FEN extracts and merges information about the radio environment (figure 4) coming from:
• SCC;
• FCO;
• RRM: old state of the REM and current LPS;
• RRM of neighbour C-PMSEs (optional).

Figure 4: Input and output of the fusion process in the FEN
A standard approach for encoding the radio environment data in the FEN is required, e.g. XML.
The result of the merging process in the FEN is stored in the REM, therewith the REM is updated synchronously after
the observe stage of the cognitive cycle.
5.4 Decision Engine: DEN
DEN analyzes and classifies the current operation context of the C-PMSE given by:
i) its radio capabilities and constraints stored in the RRM (LPS); and
ii) the status of the radio environment stored in the RRM (REM), and determines an optimal response to the
current operation context.
The DEN should be built around a state machine process that listens for a request from the CYU. With the request, the
CYU provides the DEN with the information necessary to run a decision-making process. Each decision-making
process will require the subject of the decision process, and a different set of information depending on the decision to
take.
DEN consists of three functional blocks, which are depicted in figure 5:
• Reasoning Module;
• Learning Module;
• Case Database (CDB).
ETSI
16 ETSI TS 102 800 V1.1.1 (2011-01)

Figure 5: Functional Architecture of the DEN
5.4.1 Reasoning Module
The reasoning module classifies the C-PMSE operation context, in a first step into critical (reactive path) and uncritical
(proactive path) situations (see also figure 8), while in a second step it may break the operation context into different
use cases.
For the classification, the reasoning module has to compute the impact and interdependencies between intermodulation
products, neighbour channel selection and spectrum guard bands. Therefore, it has to make use of the hardware
performance parameters of the radios attached to the C-PMSE, which are stored in the RRM (i.e. in DAT within LPS).
The results of the computation of these RF issues shall be reflected in the REM.
Furthermore, it determines the time limit for the following reconfiguration (reactive path) or optimisation process
(proactive path).
In the reactive path, C-PMSE reconfiguration must rely on already known and well-proven actions, which we have
called "panic actions". Therefore, the DEN should store a panic action set, consisting of one action per link, specifically
designed for each use case that it has learned to differentiate. Certainly, the panic action sets can be continuously
refined through learning as the CEN gains experience regarding a particular use case.
In the proactive path, the DEN's reasoning module will select an appropriate objective function and provide this
together with the current content of the RRM databases (i.e. LPS and REM) to the OEN. The OEN implements a pool
of optimisation algorithms; the DEN's reasoning module selects one of the algorithms in the pool to be executed. The
result of the optimisation algorithm for each link describes how suitable different actions (e.g. channel switch, power
control, adaptive modulation and coding) are for the given optimisation context (Radio Environmental Map, goals,
radio capabilities). The reasoning module selects for each link the best action that could as yet be found for the specific
use case, i.e. the action with the highest ranking measured in terms of the objective function and pushes it into the ASQ
in the RRM.
5.4.2 Learning Module
The learning module continuously refines the classification of the operation context into use cases based on past
experience.
Training and learning are necessary for the CEN to achieve satisfactory performance.
ETSI
17 ETSI TS 102 800 V1.1.1 (2011-01)
5.4.3 Case Database (CDB)
The case database stores for each use case that the reasoning module has learned to differentiate:
• the panic action set;
• the result of the optimisation process.
Critical aspects of the decision-making process are convergence time, implementation complexity and stability.
5.5 Optimisation engine (OEN)
The OEN should be built around a state machine process that listens for a request to process some data from the CYU.
With the process request, the CYU provides the OEN with the information necessary to run the optimisation process.
Each optimisation algorithm will require the problem definition, i.e. the objective function of the optimisation (coming
from DEN), and a different set of algorithm parameters (stored in the RRM within the LPS). Moreover, the CYU can
provide the OEN with a suitable already known set of actions stored in the CDB to help speed up the optimisation
process.
Important aspects for algorithm selection are computational cost, time and convergence (global vs. local).
5.6 rmi API
This component controls the rmi interface that serves to transfer the RRM tables from the RRM to the CEN and vice
versa.
rmi API has to control two services:
• Push service (time critical): CEN transfer of data to the RRM (ASQ and REM), as shown in the left hand side
of figure 6. This service can overwrite the content of one or several tables and/or add new information to them.
• Pull service: CEN request for data from the RRM (REM, LPS, from other C-PMSE), as shown for start up and
update in the right hand side of figure 6. CEN could ask for the content of one particular table or for the whole
content of the RRM.
Figure 6: Push and Pull services at the rmi API
...