ETSI TR 103 063 V1.1.1 (2011-07)

Reconfigurable Radio Systems (RRS); Use Cases for Reconfigurable Radio Systems operating in IMT bands and GSM bands for intra-operator scenarios

DTR/RRS-01007

General Information

• Status: Published
• Publication Date: 30-Jun-2011
• Technical Committee: RRS 1 - RRS System Aspects & Cognitive functionalities
• Current Stage: 12 - Completion
• Due Date: 13-Jul-2011
• Completion Date: 01-Jul-2011

Standards Content (Sample)

Technical Report
Reconfigurable Radio Systems (RRS);
Use Cases for Reconfigurable Radio Systems
operating in IMT bands and GSM bands
for intra-operator scenarios
2 ETSI TR 103 063 V1.1.1 (2011-07)

Reference
DTR/RRS-01007
Keywords
CRS, GSM, IMT, SDR, use case
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI 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 TR 103 063 V1.1.1 (2011-07)
Contents
Intellectual Property Rights . 4
Foreword . 4
Introduction . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 5
3.1 Definitions . 5
3.2 Abbreviations . 6
4 Motivation and goals . 7
5 Use Cases . 7
5.1 Overview . 7
5.2 Detailed Use Cases . 8
5.2.1 Radio Resource optimization . 8
5.2.1.1 General Use Case Description. 8
5.2.1.2 Stakeholders . 8
5.2.1.3 Scenario . 8
5.2.1.4 Information Flow . 11
5.2.2 Spectrum refarming . 14
5.2.2.1 General Use Case Description. 14
5.2.2.2 Stakeholders . 14
5.2.2.3 Scenario . 15
5.2.2.4 Information Flow . 16
5.2.3 Upgrading a pre-existing RAT and deploy of a new RAT to a pre-existing network . 17
5.2.3.1 General Use Case Description. 17
5.2.3.2 Stakeholders . 17
5.2.3.3 Scenario . 17
5.2.3.4 Information Flow . 18
5.2.4 Addition of multiple standards modes . 25
5.2.4.1 General Use Case Description. 25
5.2.4.2 Stakeholders . 25
5.2.4.3 Scenario . 25
5.2.4.4 Information Flow . 26
5.2.5 LTE pico/femto cell reconfiguration. 28
5.2.5.1 General Use Case Description. 28
5.2.5.2 Stakeholders . 28
5.2.5.3 Scenario . 29
5.2.5.4 Information Flow . 30
5.2.6 Cognition enabler . 31
5.2.6.1 General Use Case Description. 31
5.2.6.2 Stakeholders . 31
5.2.6.3 Scenario . 31
5.2.6.4 Information Flow . 31
6 Potential System Requirements . 33
History . 36

ETSI
4 ETSI TR 103 063 V1.1.1 (2011-07)
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://ipr.etsi.org).
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 Report (TR) has been produced by ETSI Technical Committee Reconfigurable Radio Systems (RRS).
Introduction
The present document describes how Reconfigurable Radio Systems can be exploited in IMT bands and GSM bands to
increase the efficiency of the radio resource management in the intra-operator scenarios for which the spectrum
resources are assigned to and managed by a single operator.
ETSI
5 ETSI TR 103 063 V1.1.1 (2011-07)
1 Scope
The present document collects operating network scenarios - to be described in the form of system use cases - for
Reconfigurable Radio Systems operating in IMT bands and GSM bands i.e. licensed spectrums allocated to IMT and
GSM systems.
Use cases will focus on intra-operator scenarios for which the spectrum resources are assigned to and managed by a
single operator.
Use cases will be described at the system functionality level and do not have to be confused with the
features/requirements of the system under consideration. A use case may be related to one or more
features/requirements, a feature/requirement may be related to one or more use cases. Moreover, the use cases will
identify actors and information flows, and will form the basis of system requirements work at TC RRS for Software
Defined Radio (SDR) systems and Cognitive Radio (CR) systems.
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
referenced 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.
Not applicable.
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 683: "Reconfigurable Radio Systems (RRS); Cognitive Pilot Channel (CPC)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Cognitive Radio System (CRS): radio system employing technology that allows the system to obtain knowledge of its
operational and geographical environment, established policies and its internal state; to dynamically and autonomously
adjust its operational parameters and protocols according to its obtained knowledge in order to achieve predefined
objectives; and to learn from the results obtained
Reconfigurable Radio Systems (RRS): generic term for radio systems encompassing Software Defined and/or
Cognitive Radio Systems
ETSI
6 ETSI TR 103 063 V1.1.1 (2011-07)
Software Defined Radio (SDR): radio transmitter and/or receiver employing a technology that allows the RF operating
parameters including, but not limited to, frequency range, modulation type, or output power to be set or altered by
software, excluding changes to operating parameters which occur during the normal pre-installed and predetermined
operation of a radio according to a system specification or standard
use case: description of a system's behaviour as it responds to a request that originates from outside of that system
NOTE: In other words, a use case describes "who" can do "what" with the system in question. The use case
technique is used to capture a system's behavioural requirements by detailing scenario-driven threads
through the functional requirements.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3GPP Third Generation Partnership Project
BCCH Broadcast Control Channel
BSC Base Station Controller
CPC Cognitive Pilot Channel
CRS Cognitive Radio System
DSP Digital Signal Processor
ETSI European Telecommunications Standards Institute
FDD Frequency Division Duplex
FFR Fractional Frequency Reuse
FPGA Field Programmable Gate Array
GPRS General Packet Radio Service
GSM Global System for Mobile communication
HPR Hardware Processing Resources
HSPA High Speed Packet Access
IMB Integrated Mobile Broadcast
IMT International Mobile Telecommunications
ISM Industrial, Scientific and Medical
LTE Long Term Evolution
MD Mobile Device
MNO Mobile Network Operator
O&M Operation & Maintenance
PS Packet Switch
QoS Quality of Service
RAT Radio Access Technology
RBS Reconfigurable Base Station
RF Radio Frequency
RNC Radio Network Control
RRM Radio Resource Management
RRS Reconfigurable Radio Systems
RU Radio Unit
SDR Software Defined Radio
TC Technical Committee
TDD Time Division Duplex
TR Technical Report
TS Time Slot
UE User Equipment
UMTS Universal Mobile Telecommunication System
VHO Vertical Hand-Over
ETSI
7 ETSI TR 103 063 V1.1.1 (2011-07)
4 Motivation and goals
Due to the rapidly increasing of the Internet/data traffic and the need for broader bandwidths, IMT bands and GSM
bands are getting heavily used. RRS may in the future be used as one method to address such problem by facilitating
e.g. a more efficient use of the Radio Resources owned and managed by the operators. In fact, exploiting RRS
capabilities, a network operator owning two or more RATs could utilise the new opportunity to dynamically and jointly
manage the resources of the deployed RATs, in order to adapt the network to the dynamic behaviour of the traffic and
to globally maximize the capacity. On these bases, different Use Cases, describing how RRS can be exploited in IMT
bands and GSM bands in intra-operator scenarios, will be depicted.
5 Use Cases
5.1 Overview
Use Cases according to the definition in clause 3.1 will describe the system behaviour according to the specific Scenario
considered. Use Cases and related Scenarios are then used for deriving the potential System Requirements. For this
purpose each Use Case described in the following clauses is documented in the same way by using the same structure:
• General Use Case Description
• Stakeholders
• Scenario
• Information Flow
An initial set of potential System Requirements is grouped in a dedicated clause.
Hereafter the list of Use Case (described in detail in the next clauses) with the aim to serve as a short summary is
reported. The Use Cases considered in the present document are the following:
• Radio Resource optimization
• Spectrum refarming
• Upgrading a pre-existing RAT and deploy of a new RAT to a pre-existing network:
- Upgrade of an existing RAT
- Deploy a new RAT in frequency bands already supported by the RBS
- Deploy a new RAT in frequency bands currently not supported by the RBS
• Addition of multiple standards modes
• LTE pico/femto cell reconfiguration
• Cognition Enabler
ETSI
8 ETSI TR 103 063 V1.1.1 (2011-07)
5.2 Detailed Use Cases
5.2.1 Radio Resource optimization
5.2.1.1 General Use Case Description
Considering a cell set in a certain area, the traffic of different services on a specified RAT may change from one sub-
area to the other according to the day period. It could then happen that some cells may be congested (high blocking
percentages) in some particular area (typically these portions are called hot-spots) in which the traffic is more
consistent, while surrounding cells are less loaded or characterized by low blocking percentages. Moreover, in case of
deployment of two or more RATs in the same area, the offered traffic of different services on each deployed RAT may
also be differently distributed in time and space with respect to the ones of the other deployed RATs. Last but not least,
due to the fact that some IMT bands are very close to license exempt bands (e.g. the 2,4 GHz ISM band), it could
happen that in a certain area Mobile Devices may experience interference problems (reported to the network). In such
contexts, in the longer term, RRS will give the MNOs the means for managing in an efficient way the radio resources
(e.g. reducing of radio access blocking percentages, redistributing resources among different RATs and/or minimizing
system interference problems) within its own licensed frequency bands.
5.2.1.2 Stakeholders
Mobile Network Operator (MNO): operates and maintains an heterogeneous mobile network deployed using
reconfigurable radio nodes (e.g. RBSs) and provides mobile services (voice and data) to its customers.
Infrastructure Providers: provides the hardware and software of the radio nodes (e.g. RBS) (see note).
User: performs voice and/or data traffic through his/her Mobile Device.
Mobile Device Manufacturer: provides hardware and software of Mobile Devices and software components needed
for the upgrade (see note).
NOTE: Actually for multi-standard radio nodes is assumed a vertical market (i.e. same provider for the hardware
and software).
5.2.1.3 Scenario
A deployment of different RATs in a geographical area with a network deployed using reconfigurable nodes is
considered. It is supposed that each reconfigurable node is equipped with a certain amount of Hardware Processing
Resources (HPR) (see note) that are shared between the different managed RATs. On these bases, it is possible to
perform two different typologies of reconfiguration according to the specific contexts: an intra-system reconfiguration
that involves only one single RAT and/or an inter-system reconfiguration that involves two or more different RATs. For
example, an intra-system reconfiguration could be necessary when the traffic on a specified RAT drastically changes
from one sub-area to the other (e.g. some cells may be congested while the surrounding ones not). On the other side, the
inter-system reconfiguration could be needed when different traffic loads are experienced by each RAT, in order to
increase the percentage of Radio Resources (RR) devoted to the over-loaded system while decreasing the ones used by
the others (supposed under-loaded). It should be noted that intra-system and inter-system reconfigurations can be
simultaneously performed.
NOTE: HPR indicates the hardware of the reconfigurable node (e.g. constituted by DSPs and FPGAs) that is used
to run the software that implements the specific RATs functionalities (e.g. Base Band operations). The RF
part is supposed to be separate and managed by specific modules (e.g. Radio Units (RUs)) able to support
more RATs at the same time with sufficient power capacity in order to respect the RF requirements of
any single RAT.
In general, HPRs are shared among the different RATs whose cells are managed by a certain reconfigurable node. It is
then not possible to share HPRs among RATs whose cells are managed by different reconfigurable radio nodes
(e.g. RBSs). On the contrary, RRs can be shared among cells managed by different reconfigurable radio nodes.
ETSI
9 ETSI TR 103 063 V1.1.1 (2011-07)
As an example of intra-system reconfiguration, a GSM deployment is considered. In particular, a RBS uses its HPRs to
manage the different cells in terms of RRs (e.g. carriers) allocated to each cell. Figure 1a depicts a possible initial
configuration that foresees 3 cells (numbered from 1 to 3) initially configured by 3 carriers each for a total of 9 different
frequencies (numbered from 1 to 9). Starting from this situation, let us suppose to have a high offered traffic situation in
Cell1 (i.e. high blocking probability on new connections) and, at the same time, a low offered traffic situation for the
other two cells (i.e. null blocking probability on new connections). In this context, it is then possible to reconfigure the
RBS in order to add to the congested Cell1 more RRs (for example 3 more carriers) borrowed from Cell2 and Cell3
(being supposed under-loaded) performing all the controls needed in order to avoid interference problems to the system.
Figure 1b shows a possible final configuration that foresees Cell1 with 6 carriers in total, Cell2 with 2 carriers and Cell3
with 1 carrier. More in general, RRs to be added to the congested cell can be borrowed also from cells managed by
other RBSs. Finally, this example can be extended also to intra-system reconfiguration for UMTS and LTE systems
taking into account their peculiarities such as the scrambling codes for UMTS and sub-carriers orthogonality for LTE.
Figure 2 depicts an example of an LTE intra-system reconfiguration. In particular, the left part of figure 2 depicts a
possible initial configuration in which each cell uses the whole band with a limited output power in the areas closer to
the RBS, while the band is separated into different smaller parts with a higher output power for each cell (this has been
studied in the framework of 3GPP as the Fractional Frequency Reuse concept). In this context, the RRS can exploit the
FFR concept in a dynamic manner, for example according to the traffic variations, and reconfigure accordingly the LTE
RRs between the different cells (right part of figure 2).
200 kHz
a)
6 7 8 9
1 2 3 4 5
GSM
MHz
200 kHz
Cell1
b)
Cell3
Cell2
6 7 8 9
1 2 3 4 5
GSM
MHz
Figure 1: Example of GSM intra-system RRs reconfiguration
15MHz 15MHz
5MHz 10MHz
Cell 1
Cell 1
5MHz
3MHz
Cell 1
Cell 2 Cell 2
5MHz 2MHz
Cell 3
Cell 2
Cell 3 Cell 3
Before Reconfiguration
After Reconfiguration
Figure 2: Example of LTE intra-system RRs reconfiguration
ETSI
10 ETSI TR 103 063 V1.1.1 (2011-07)
As an example of inter-system reconfiguration, let us consider a portion of a geographical area covered with two RATs
such as GSM and UMTS. The initial configuration foresees a given percentage of HPRs devoted to UMTS system, a
given percentage of HPRs is devoted to GSM system and the remaining HPRs are currently not used and free to be
assigned. Depending on the quantity of HPRs devoted to the two systems, a certain related amount of RRs can be
managed and assigned to UMTS (e.g. 5 MHz channel per carrier; one carrier per cell) and to the GSM (e.g. 200 kHz
channel per carrier; one or more carriers per cell). Figure 3 shows an initial allocation (before reconfiguration) of the
RRs assigned to the two systems.

200 kHz
5 MHz
GSM UMTS
MHz
Figure 3: Example of RRs allocation of the GSM and UMTS systems before reconfiguration
Starting from the situation reported above, let us suppose to have an high offered traffic situation (i.e. overloading and
congestion situation with high blocking probability on new connections) experienced by the UMTS system and, at the
same time, a low offered traffic situation (i.e. null blocking probability on new connections) for the GSM system. In this
context, it is then necessary to reconfigure accordingly the HPRs and RRs of the cells managed by the reconfigurable
node in order to reserve to the UMTS system more processing capacity and, consequently, more RRs (e.g. one or more
5 MHz channels). It is possible to depict different ways to act for the reconfiguration depending, for example, on the
amount of currently unused HPRs. Figure 4 shows the RRs allocation after the reconfiguration in the case of sufficient
free HPRs to activate new UMTS channel. In this case the reconfiguration involves only the hardware part of the
reconfigurable node, leaving the RRs assigned to the two systems unmodified. On the contrary, in the case there are not
sufficient free HPRs, it is then necessary to free additional HPRs by reconfiguring also the GSM system. Being the
GSM system under-loaded (as supposed), some RRs can be released leaving free HPRs that, added the ones already
available, can be used in order to activate a new UMTS channel (figure 5). In this case the reconfiguration implicates to
modify also the RRs assigned to the considered systems.
200 kHz
5 MHz
GSM UMTS UMTS
MHz
900 2100
Figure 4: RRs allocation after reconfiguration in the case of sufficient free HPRs
to activate a new UMTS channel
200 kHz
5 MHz
GSM UMTS UMTS
MHz
900 2100
Figure 5: RRs allocation after reconfiguration in the case of not sufficient free HPRs
to activate a new UMTS channel in which some RRs of the GSM system have been released
in order to free the necessary additional HPRs
ETSI
11 ETSI TR 103 063 V1.1.1 (2011-07)
In addition to the examples reported above, more complex scenarios can be drawn, considering reconfigurations that
implicate modifications to both HPRs and RRs, and, last but not least, taking into account also new RAT deployment
such as LTE. As an example, figure 6a reports an initial RRs allocation considering GSM, UMTS and LTE systems
where the LTE has a 5 MHz channel active at 2 600 MHz (GSM and UMTS have the same allocation reported in
figure 3). According to the MNO needs (e.g. traffic variations, RRs reallocations, interference problems, etc.), the nodes
can be accordingly reconfigured in order to add RRs to the LTE system (for a resulting 10 MHz channel), reallocate the
UMTS ones releasing some RRs of the GSM system (figure 6b), supposing to have the sufficient HPRs to manage the
reconfiguration.
a)
200 kHz
5 MHz 5 MHz
GSM UMTS UMTS LTE
MHz
900 2100 2600
b)
200 kHz
5 MHz*
5 MHz 10 MHz
GSM UMTS UMTS LTE
MHz
900 2600
* Release of 25 x 200 KHz GSM channels

Figure 6: Example of a reconfigurations that implicates modifications to both HPRs and RRs
5.2.1.4 Information Flow
In this clause a high level information flow during a reconfiguration process is presented. As a simplified example, the
information flow depicts a GSM intra-system RRs reconfiguration in the cases of i) adding a new carrier in a cell and ii)
releasing a carrier in a cell.
The information flow considers the following logical/physical entities:
• Reconfigurable Base Station, that can be reconfigured in terms of percentage of HPRs devoted to each
supported RAT and in terms of active RRs (e.g. frequency carriers) for each supported RAT.
• Radio Controller that includes the RRM (Radio Resource Management) entity which aim is to manage the
request and the assignment of a radio channel to the Mobile Devices, and the Reconfiguration Entity that is
running the Reconfiguration Algorithm devoted to monitor the activity status of the cells (for each supported
RAT) in terms of number of the requests to the different systems; to execute the Reconfiguration Algorithm
that decides which RBS are to be reconfigured; to control the reconfiguration by sending appropriate
reconfiguration commands. Other secondary mechanisms for evaluating the need of a network reconfiguration
could be possible (e.g. based on the reports sent by the Mobile Devices). Finally, it should to be noted that in
the traditional systems (e.g. GSM and UMTS), the Radio Controller can be intended as the BSC (GSM) or the
RNC (UMTS). In addition, in case of flat-architectures, the Radio Controller tasks could operate inside each
eNodeB (LTE) or in a higher-order node (e.g. O&M).
ETSI
12 ETSI TR 103 063 V1.1.1 (2011-07)
Figure 7 shows the high level information flow occurring in the case of adding a new GSM carrier in a cell. In
particular:
• The RRM indicates to the Reconfiguration Entity the results of the different Channel Requests coming from
the Mobile Devices.
• At the end of the monitoring period T (see note), the Reconfiguration Entity runs the Reconfiguration
Algorithm in order to evaluate a possible reconfiguration: in this case the algorithm decides to add a new GSM
carrier in the cell having performed all the controls needed in order to avoid interference problems to the
system. Such controls can be based on different possible approaches (e.g. exhaustive approach based on the
application of real-time planning algorithms, fast approach based on a heuristic check of the reuse distances,
physical approach based on RBS and Mobile Device measurements, etc.).
NOTE: Performing too many reconfigurations in a short time (e.g. small values of T) could require to send too
many signalling messages for configuring and further reconfiguring RBSs and could lead the system to a
unstable situation due to too fast modifications of the planning; performing too few reconfigurations in a
long time (e.g. high values of T) could not be much effective, since the time elapsed between the need of
a reconfiguration and the time of the reconfiguration itself could be too long. The MNO should then take
into account said factors and evaluating the trade-off of them when setting the value of T.
• The Reconfiguration Entity sends to the RRM an Add Carrier Command indicating the carrier to be added in
the cell.
• The RRM sends to the Reconfigurable Base Station the RBS Reconfiguration Command.
• Upon the reception of the RBS Reconfiguration Command, the RBS performs the reconfiguration by
activating the new carrier in the cell and updating its operational parameters.
• After the reconfiguration is performed, the RBS sends to the RRM the RBS Reconfiguration Confirmation.
• Upon the reception of the RBS Reconfiguration Confirmation, the RRM updates accordingly the Cell Context
and informs the Mobile Devices about the new cell configuration (e.g. updating the System Information on
BCCH, sending the Frequency Redefinition message to the Mobile Devices with an ongoing voice call,
sending a Reconfiguration Channel Command to the Mobile Devices having an active GPRS data connection).
• The RRM sends to the Reconfiguration Entity the Add Carrier Completed message.
ETSI
Monitoring period T
13 ETSI TR 103 063 V1.1.1 (2011-07)
Radio Controller
Reconfiguration
RBS RRM
Entity
Assigned
Channel Request
Assignment Ind
Rejected
Channel Request
Reject Ind
Rejected
Channel Request
Reject Ind
Reconfiguration
Add new GSM carrier
Algorithm
Add Carrier
Command
RBS Reconfiguration Command
Reconfiguration
RBS Reconfiguration
Confirmation
Cell Context
Update
Inform the mobile
devices about the new
cell configuration
Add Carrier
Completed
Figure 7: High level information flow related to the case of adding a new GSM carrier in a cell
Figure 8 shows the high level information flow occurring in the case of releasing a GSM carrier in a cell. In particular:
• The RRM indicates to the Reconfiguration Entity the results of the different Channel Requests coming from
the Mobile Devices.
• At the end of the monitoring period T, the Reconfiguration Entity runs the Reconfiguration Algorithm in order
to evaluate a possible reconfiguration: in this case the algorithm decides to drop a GSM carrier and sends to
the RRM a Drop Carrier Command.
• Upon the reception of the Drop Carrier Command, the RRM perform the decision on which carrier to drop
according to specific criterions. Having identified the carrier to be removed, the RRM commands the handover
to the Mobile Devices allocated on that carrier. After the completion of the handovers, the RRM updates
accordingly the Cell Context and informs the Mobile Devices about the new cell configuration (see the
previous example for the details).
• The RRM sends to the Reconfigurable Base Station the RBS Reconfiguration Command.
• Upon the reception of the RBS Reconfiguration Command, the RBS performs the reconfiguration by releasing
the carrier in the cell and updating its operational parameters.
• After the reconfiguration is performed, the RBS sends to the RRM the RBS Reconfiguration Confirmation.
• Upon the reception of the RBS Reconfiguration Confirmation, the RRM sends to the Reconfiguration Entity
the Drop Carrier Completed message.
ETSI
Monitoring period T
14 ETSI TR 103 063 V1.1.1 (2011-07)
Radio Controller
Reconfiguration
RRM
RBS
Entity
Assigned
Channel Request
Assignment Ind
Assigned
Channel Request
Assignment Ind
Assigned
Channel Request
Assignment Ind
Reconfiguration
Drop a GSM carrier
Algorithm
Drop Carrier
Command
Evaluation of
the GSM carrier
to be removed
Handover of mobile
devices allocated on
the carrier to be removed
Cell Context
Update
Inform the mobile
devices about the new
cell configuration
RBS Reconfiguration Command
Reconfiguration
RBS Reconfiguration
Confirmation
Drop Carrier
Completed
Figure 8: High level information flow related to the case of releasing a GSM carrier in a cell
As already reported, the information flows presented are just high level examples that refer to GSM intra-system RRs
reconfiguration cases. The information flow may vary according to the RATs considered, to the heterogeneity of the
system and to the type of reconfiguration.
5.2.2 Spectrum refarming
5.2.2.1 General Use Case Description
A particular situation is that of spectrum refarming in the context of technology evolution and periodical emergence of
new families of standards. This implies their progressive introduction/coexistence in the legacy "bands" rather than a
simple and quick switchover which is not appropriate due to the large amount of legacy Mobile Devices and the
corresponding investments. RRS can allow a smooth refarming transition period in this case taking into account the
traffic constraints and user requirements.
5.2.2.2 Stakeholders
Mobile Network Operator (MNO): operates and maintains an heterogeneous mobile network deployed using
reconfigurable radio nodes (e.g. RBSs) and provides mobile services (voice and data) to its customers.
Infrastructure Providers: provides the hardware and software of the reconfigurable radio nodes.
ETSI
15 ETSI TR 103 063 V1.1.1 (2011-07)
User: performs voice and/or data traffic through his/her Mobile Device.
Mobile Device Manufacturer: provides hardware and software of Mobile Devices and software components needed
for the upgrade.
5.2.2.3 Scenario
In this intra-operator scenario, the operator wants to update its network with a new RAT (RAT2) which is progressively
introduced in the frequency band of the previous technology (RAT1), transparently and with no constraint for the
customers. The deployment roadmap of this new technology is under CAPEX constraints and therefore progressive in
terms of geographic coverage, targeting some specific "island" areas to begin with. During the refarming period (several
months, more.), legacy Mobile Devices that only have access to RAT1 coexist with multi-mode Mobile Devices that
are progressively introduced in the market. The multi-mode devices can access both RAT1 and RAT2.
The curves in figure 9, corresponding to the global network situation, propose a possible evolution of RAT2 coverage
together with the dedicated spectrum/radio resources within the considered frequency band under refarming process.
The appropriate route (global resource management illustrated by the two curves) to evolve the global network from
situation A (only RAT1 before starting refarming process) to situation B (only RAT2 after finishing refarming process)
may be affected by many unpredictable factors (e.g. market, environment/terrain or technology related) and may also be
impacted by unexpected situations that may occur during the refarming period. This is the reason why the red and blue
curves show some flexibility by intentionally being decreased at some point in time even if they follow a general
increasing trend from point A to point B. Once the transforming process has reached point B, the refarming is
completed and no base stations still operates RAT1 (Mobile Device supporting only RAT1 cannot get any connection).
There is no reason to come back to a previous situation with both technologies.

Figure 9: Global refarming process totally replacing RAT1 by RAT2
within a limited frequency band
Reconfigurable Base Stations (RBSs) can allow this kind of flexible evolution, provided that appropriate mechanisms
are implemented to manage the radio resources.
In general, this evolution needs to be managed in accordance with the MNO strategy and in a transparent way for the
customers with neither harmful interference occurrence nor capacity/throughputs bottlenecks resulting from the phased
resource reallocations within the same frequency band (as described in figure 10).
ETSI
16 ETSI TR 103 063 V1.1.1 (2011-07)
RRAATT11 onl onlyy
FrFreq.eq.
RARAT1T1 + + RA RAT2T2
FrFreq.eq.
Figure 10: Local replacement of RAT1 channels by RAT2 resources in the same frequency band
To guarantee QoS, optimize the refarming route towards situation B and timely trigger activation/deactivation of the
radio resources for RAT1/RAT2, reconfigurable elements are needed to introduce flexibility both at the Base Stations
and Mobile Devices levels.
In other words, it is needed to match the activation/deactivation of RAT1/RAT2 resources to local cell load variations
taking into account:
• The proportion of legacy and multi-mode Mobile Devices in the cell, and the Vertical Hand-Over (VHO)
strategy.
• The type of service demand (if it impacts the choice between RAT1 and RAT2).
• Unexpected big events (or global customer movement) that may locally impact spectrum demand and cell
loads.
5.2.2.4 Information Flow
This clause presents a high level information flow (depicted in figure 11) for the spectrum refarming scenario that
involves two radio access technologies, namely RAT1 and RAT2.
The following nodes are considered:
• Reconfigurable Base Stations that can be reconfigured in terms of percentage of active Radio Resources (RR)
from RAT1 and RAT2. Once the RBS has received the reconfiguration command and before performing the
reconfiguration, all the Mobile Devices (including those in idle mode) are informed (if needed) of the new
configuration (e.g. when removing a carrier).
• After reconfiguration, the Mobile Devices in the cell are informed by the RBS about the new configuration
(e.g. update of the neighbouring list, in particular for the mobile in idle mode).
• The Reconfiguration Entity receives and analyses the refarming decisions and triggers the corresponding
reconfigurations of the Base Stations that are concerned by the refarming process. Once all the
reconfigurations are completed, the reconfiguration Entity is informed by each affected RBS that the process is
completed.
• The Refarming Strategy Entity is a generic entity in the network forwarding the refarming step decisions to the
Reconfiguration Entity. These decisions that follow a general scheduled roadmap can also be triggered by
other reasons. As indicated in the scenario description, multiple factors may affect the refarming global
process that can relate to market, technical or environmental context as well as unexpected specific events that
may temporarily impact the capacity needs. When a refarming step is completed, the Refarming strategy
Entity received an acknowledgement from the Reconfiguration Entity.
ETSI
PowPoweerr PowPoweerr
17 ETSI TR 103 063 V1.1.1 (2011-07)
RReeccoonnffigigururatatiion on RefaRefarmrmining Sg Sttrarategtegyy
MDMD RBSRBS
EntiEntityty EnEntitytity
ReReRefffaaarrrmmmiiinnng Stg Stg Steeeppp De De Deccciiisssiiiononon
MMDD are are iinnforformmeded
RRBBSS R Reeccoonfnfigigururaattioion n CoCommmmaanndd
ofof ththe ne neew cw confonfigigururaattiioonn
RReeccoonfnfiigguurratatioionn
RRRBBBSSS R R Reeecococonfignfignfiguraurauratttiiion on on CoCoConfirmatinfirmatinfirmationonon
IInnfoformrm th the Me MDD
in thein the cecellll
ababoutout th the e nneeww
AcAckknnowlowleeddggmmeenntt of of R Reeffaarmrmining g ccoommpplleettiionon
ccoonfnfiigguurratatiioonn
Figure 11: High level information flow related to the case of Spectrum Refarming
5.2.3 Upgrading a pre-existing RAT and deploy of a new RAT to a
pre-existing network
5.2.3.1 General Use Case Description
This Use Case refers to two different possibilities for a Mobile Network Operator that operates and maintains an
heterogeneous mobile network deployed using Reconfigurable Base Stations:
• To upgrade an existing RAT to include new functionalities (e.g. to add uplink HSPA+ to an UMTS network)
• To deploy a new RAT to a pre-existing network (e.g. to add LTE network to a 2G-3G network already
deployed) and to commission and optimize it. Commission works include all activities, after equipment
installation that should be done to make a node available to provide all specified functionalities, suitable
connectivity with other RAT and PS nodes have to be included. Optimization refers to works needed to
achieve the best performance of equipment inside de network.
In this context it is also supposed that Mobile Devices in the network are also reconfigurable and that their software can
be upgradable from a network node that stores it.
5.2.3.2 Stakeholders
Mobile Network Operator (MNO): operates and maintains an heterogeneous mobile network deployed using
reconfigurable radio nodes (e.g. RBSs) and provides mobile services (voice and data) to its customers.
Infrastructure Providers: provides the hardware and software of the reconfigurable radio nodes.
User: performs voice and/or data traffic through his/her Mobile Device.
Mobile Device Manufacturer: provides hardware and software of Mobile Devices and software components needed
for the upgrade.
5.2.3.3 Scenario
Starting from the general Use Cases description reported above, three different scenarios can be depicted.
Upgrade of an existing RAT
The MNO upgrades a RAT managed by a RBS by downloading the necessary software packages from a network node,
instead of changing the RBS hardware. A possible example could be the addition of HSPA+ functional
...