ETSI TS 103 095 V1.1.1 (2013-01)

Reconfigurable Radio Systems (RRS); Radio Reconfiguration related Architecture for Mobile Devices

DTS/RRS-02007

General Information

• Status: Published
• Publication Date: 10-Jan-2013
• Technical Committee: RRS 2 - REA - Reconfigurable Radio Equipment Architecture
• Current Stage: 12 - Completion
• Due Date: 14-Jan-2013
• Completion Date: 11-Jan-2013

Standards Content (Sample)

Technical Specification
Reconfigurable Radio Systems (RRS);
Radio Reconfiguration related Architecture for Mobile Devices

2 ETSI TS 103 095 V1.1.1 (2013-01)

Reference
DTS/RRS-02007
Keywords
architecture, mobile, SDR
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 2013.
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 TS 103 095 V1.1.1 (2013-01)
Contents
Intellectual Property Rights . 4
Foreword . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions, symbols and abbreviations . 5
3.1 Definitions . 5
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Overview of Radio Reconfiguration related Architecture Reference Model for Mobile Devices . 8
4.1 Reconfigurable Mobile Device Architecture for Multiradio Applications . 8
4.2 Software Architecture for Radio Processor . 10
4.3 Operational Structure of URA . 11
5 Reference Points . 14
5.1 Reference Point 1: Interfaces for installation/uninstallation and creating/deleting instance of RA . 15
5.1.1 List of Reference Point 1 . 15
5.1.2 Reference Point 1 Requirements . 16
5.2 Reference Point 2: Interfaces for list checking of RA(s) . 16
5.2.1 List of Reference Point 2 . 16
5.2.2 Reference Point 2 Requirements . 16
5.3 Reference Point 3: Interfaces for activation/deactivation of RA . 17
5.3.1 List of Reference Point 3 . 17
5.3.2 Reference Point 3 Requirements . 17
5.4 Reference Point 4: Interfaces for transferring context information . 17
5.4.1 List of Reference Point 4 . 17
5.4.2 Reference Point 4 Requirements . 17
5.5 Reference Point 5: Interfaces for creating data flow and sending/receiving user data . 18
5.5.1 List of Reference Point 5 . 18
5.5.2 Reference Point 5 Requirements . 18
6 Procedures . 19
6.1 Procedures for installation/uninstallation and creating/deleting instance of RA . 19
6.2 Procedures for list checking of RA(s) . 22
6.3 Procedures for activation/deactivation of RA. 22
6.4 Procedures for transferring context information . 24
6.5 Procedure for creating data flow and sending/receiving user data . 25
7 Conclusion . 28
History . 29

ETSI
4 ETSI TS 103 095 V1.1.1 (2013-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://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 Specification (TS) has been produced by ETSI Technical Committee Reconfigurable Radio Systems
(RRS).
ETSI
5 ETSI TS 103 095 V1.1.1 (2013-01)
1 Scope
The scope of the present document is to define the radio reconfiguration related architecture for mobile devices. The
work will be based on the Use Cases defined in TR 103 062 [i.1], TR 102 839 [i.2] and TR 102 944 [i.3] and on the
system requirements defined in TS 102 969 [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
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.
[1] ETSI TS 102 969 (V1.1.1): "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
Requirements for Mobile Devices".
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 103 062: "Reconfigurable Radio Systems (RRS) Use Cases and Scenarios for Software
Defined Radio (SDR) Reference Architecture for Mobile Device".
[i.2] ETSI TR 102 839: "Reconfigurable Radio Systems (RRS); Multiradio Interface for Software
Defined Radio (SDR) Mobile Device Architecture and Services".
[i.3] ETSI TR 102 944: "Reconfigurable Radio Systems (RRS); Use Cases for Baseband Interfaces for
Unified Radio Applications of Mobile Device".
[i.4] Joseph Mitola III (2000): "Software Radio Architecture", JOHN WILEY & SONS, INC.
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Application Processor (AP): part of mobile device hardware working under OS control and on which User
Applications, among others, are executed
communication services layer: layer related to communication services supporting generic applications
NOTE: Communication services layer supports generic applications like Internet access. In the present document,
it consists of Administrator, Mobility Policy Manager (MPM), Networking stack and Monitor.
ETSI
6 ETSI TS 103 095 V1.1.1 (2013-01)
configcodes: result of compiling source codes of Radio Application (RA), which is either configuration codes of Radio
Virtual Machine (RVM) or executable codes for a particular target platform
NOTE: In the case when RA provider makes a high level code based on a target platform, a result of compiling
RA source codes is configcodes which is executable on the target platform. In the other case, when RA
provider makes a high level code without considering a target platform, a result of front-end compiling of
RA source codes is Intermediate Representation (IR) which should be back-end compiled for operating
on a specific target platform.
Radio Application (RA): software which enforces RVM or particular radio platform to generate the transmit RF
signals or decode the receive RF signals
NOTE: Radio Applications might have different forms of representation. They are represented as:
� source codes including Radio Library calls of Radio Library native implementation and Radio HAL
calls;
� IR including Radio Library calls of Radio Library native implementation and Radio HAL calls;
� executable codes for particular radio platform.
Radio Control Framework (RCF): control framework which, as a part of OS, extends OS capabilities in terms of
radio resource management
NOTE: RCF is a control framework which consists of Configuration Manager (CM), Radio Connection Manager
(RCM), Flow Controller (FC) and Multiradio Controller (MRC). The Resource Manager (RM) is
typically part of OS.
Radio Lib: library of Standard Function Block (SFB)
NOTE 1: SFBs implement reference codes of functions which are typical for radio signal processing. They are not
atomic and their source codes are typed and visible for Radio Application developers.
NOTE 2: SFB is implemented through Radio HAL when the SFB is to be implemented on dedicated HW
accelerators.
NOTE 3: Radio HAL is part of ROS.
Radio Operating System (ROS): any appropriate OS empowered by RCF
NOTE: ROS provides RCF capabilities as well as traditional management capabilities related to management of
radio processor such as resource management, file system support, unified access to hardware resources,
etc.
Radio Processor (RP): part of mobile device hardware working under ROS control and on which Radio Applications
are executed
NOTE: RP is hardware which is capable to generate RF signals or receive RF signals. By nature, it is
heterogeneous hardware including different processing elements such as fixed accelerators,
e.g. Application-Specific Integrated Circuit (ASIC), or reconfigurable accelerators, e.g. microprocessors,
FPGAs, etc.
Radio Virtual Machine (RVM): abstract parallel machine capable to execute computations specific for radio signal
processing
NOTE: RVM provides abstract vision of radio platform. To be efficient in different implementations it should
represent specific features inherent to radio signal processing. Particularly RVM is capable to generate or
receive RF signals.
ETSI
7 ETSI TS 103 095 V1.1.1 (2013-01)
3.2 Symbols
For the purposes of the present document, the following symbols apply:
M Number of SFBs implemented on core processor
M Number of SFBs implemented on dedicated hardware logic accelerators
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AOT Ahead-Of-Time
AP Application Processor
ASIC Applications-Specific Integrated Circuit
BBI BaseBand Interface
BPA Baseband Parameter Aggregation
CM Configuration Manager
FC Flow Controller
FEC Forward Error Correction
FFT Fast Fourier Transform
FM File Manager
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
GPS Global Positioning System
HAL Hardware Abstraction Layer
ID Identification
IP Internet Protocol
IR Intermediate Representation
ISA Instruction Set Architecture
JIT Just-In-Time
MD Mobile Device
MIMO Multi-Input-Multi-Output
MPM Mobility Policy Manager
MRC MultiRadio Controller
MURI MUltiRadio Interface
OS Operating System
RA Radio Application
RAP Radio Application Package
RC Radio Controller
RCF Radio Control Framework
RCM Radio Connection Manager
RF Radio Frequency
RM Resource Manager
ROS Radio Operating System
RP Radio Processor
RRFI Reconfigurable Radio Frequency Interface
RVM Radio Virtual Machine
SDR Software Defined Radio
SFB Standard Function Block
UDFB User Defined Function Block
URA Unified Radio Applications
URAI Unified Radio Applications Interface
WLAN Wireless Local Area Network
XCVR Transceiver
ETSI
8 ETSI TS 103 095 V1.1.1 (2013-01)
4 Overview of Radio Reconfiguration related
Architecture Reference Model for Mobile Devices
4.1 Reconfigurable Mobile Device Architecture for Multiradio
Applications
Figure 4.1: Reconfigurable Mobile Device (MD) architecture for multiradio applications
Figure 4.1 illustrates conceptual diagram of Reconfigurable MD architecture for multiradio applications. The
Reconfigurable MD architecture shown in Figure 4.1 consists of Application Processor (AP) and Radio Processor (RP).
Note that the red-dotted part might belong to RP instead of AP depending on each vendor.
Operation of AP is performed by a given Operating System (OS), which is in many cases performed on non-real-time
bases, whereas RP's operation is performed by another OS, which should support real-time operations of RA. The OS of
RP is referred to as ROS in the present document.
The AP includes the following components as shown in Figure 4.1.
• Driver activates hardware devices (such as camera, speaker, etc.) on a given MD.
• OS denotes a non-real-time operating system that operates in MD. As discussed in [i.3], the OS includes
Administrator, Networking stack, Mobility Policy Manager (MPM) and Monitor. In clause 5 of the present
document, Communication services layer as represented in [i.4] is introduced to represent the four entities of
the OS [i.3]. In addition, for multiradio applications, the OS may include Radio Control Framework (RCF)
(AP part) as well as the four entities [1].
ETSI
9 ETSI TS 103 095 V1.1.1 (2013-01)
• Radio Controller (RC) in Radio Application (RA) sends context information to the Monitor or sends/receives
data to/from Networking stack.
The components of the RCF are classified into two groups. One group interfaces with the AP part and the other group
with the RP part as shown in Figure 4.1. Which components of RCF interface to RP and which interface to AP, in
real-time and in non-real-time, respectively, can be determined differently by each vendor.
• The RCF includes the following 5 components for managing RA(s) [i.2]:
1) Configuration Manager (CM) provides for installation/uninstallation and creating/deleting instance of
RAs into RP as well as management of and access to the radio parameters of the RAs.
2) Radio Connection Manager (RCM) provides activation/deactivation of RAs according to user requests,
and overall management of user data flows, which can also be switched from one RA to another.
3) Flow Controller (FC) is responsible for sending and receiving of user data packets and controlling the
flow of signalling packets.
4) Multiradio Controller (MRC) schedules the requests for radio resources issued by concurrently executing
RAs and detects and manages the interoperability problems among the concurrently executing RAs.
5) Resource Manager (RM) manages the computational resources to share them among simultaneously
active RAs, and to guarantee their real-time requirements.
The RP includes the following components as shown in Figure 4.1.
• ROS is a real-time OS that includes RCF (RP part).
• Radio platform driver is a hardware driver for the ROS to interact with the Radio platform hardware.
• Radio platform hardware typically consists of core(s) and baseband accelerator(s). Baseband accelerator
implementing the Standard Function Block(s) (SFB) might be provided in a form of an Application-Specific
Integrated Circuit (ASIC).
ETSI
10 ETSI TS 103 095 V1.1.1 (2013-01)
4.2 Software Architecture for Radio Processor

Figure 4.2: Software architecture for RP
The software architecture of RP is illustrated in Figure 4.2. The RP provides communication capabilities for MDs and
consists of:
• ROS including RCF.
• Radio Virtual Machine (RVM) implementation if Shadow radio platform is equal to RVM.
• Radio Lib native implementation if Shadow radio platform is equal to RVM.
• RAs configuration codes (configcodes).
Multiradio Interfaces (MURI) and Unified Radio Application Interfaces (URAI) are interfaces of RCF. As described
in [i.2], MURI are interfaces between component of Communication services layer and that of RCF and URAI are
interfaces between URA and component of RCF.
The Shadow radio platform can be either RVM or a target radio platform.
• If the Shadow radio platform is equal to the target radio platform, then front-end compiler will generate
executable code for the target radio platform and configcodes is equivalent to the executable code for that
radio platform.
• The RVM is Abstract Machine which is capable of executing configcodes. It is independent of the hardware.
Implementation is a specific RVM implementation on the target radio platform. This implementation includes
the Back-end Compiler which might provide Just-in-Time (JIT) or Ahead-of-Time (AOT) method for
compilation of configcodes into executable codes.
ETSI
11 ETSI TS 103 095 V1.1.1 (2013-01)
The Radio Lib consists of function blocks representing the computational basis. The RA can be expressed as a set of
these interconnecting function blocks. Function blocks from the Radio Lib are represented in the normative language of
the radio platform. Native implementation of Radio Lib provides executable codes of function blocks from the library
for the target platform. Radio Lib is extendable.
RAs configcodes are interpreted by RVM when Shadow radio platform is equal to RVM, or are equal to executable
codes when RVM is equal to target radio platform.
As illustrated in Figure 4.2, the access to a RadioApp Store is expected to require an interface. This is out of scope of
the present document.
4.3 Operational Structure of URA
In this clause, operational structure of Unified Radio Applications (URA) is presented considering 2 different cases.
One case is when RA configcodes are executable on a target radio platform and the other case is when RA configcodes
are Intermediate Representation (IR) that is to be back-end compiled at a given MD.

Figure 4.3: Operational structure of URA when RA configcodes are executable on a target platform

Figure 4.4: Operational structure of URA when RA configcodes are IR to be back-end compiled
ETSI
12 ETSI TS 103 095 V1.1.1 (2013-01)
Figure 4.3 illustrates an operational structure of URA when RA configcodes are executable on the target radio platform.
Note that the Radio Lib and User Defined Function Blocks (UDFBs) needed to perform a given RA(s) are already
bound in the executable configcodes of RA. Figure 4.4 illustrates an operational structure of URA when RA
configcodes are IR that should be back-end compiled at a given MD. In this case, the UDFBs needed to perform a given
RA(s) are included in the configcodes of RA and should be back-end compiled by RVM as shown in Figure 4.2. Note
that the native implementation of Radio Lib should be prepared in a given MD separately because the Radio Lib cannot
be contained in RA configcodes in this case. Generally, the native implementation of Radio Lib is provided by the core
chip vendor because Radio Lib includes SFB(s) that is(are) implemented on core processor. Basically, Radio Lib
(native implementation) shown in Figure 4.4 is needed for speed up of the SFBs that can be implemented without using
dedicated hardware accelerator(s) or for combining accelerator(s) and program code to generate another SFB(s).
In either case when the RA configcodes are executable or IR, as shown in both Figures 4.3 and 4.4, Radio Hardware
Abstraction Layer (HAL) includes hardware abstraction for SFB implementation using dedicated hardware logic
accelerator(s). It particularly means that, whenever the SFB(s) to be implemented using dedicated hardware
accelerator(s) is(are) called in a given RA code, it is implemented directly on a corresponding dedicated hardware logic
accelerator(s) via the Radio HAL in either case when the RA configcodes are executable or IR.As will be discussed
later in this clause, Radio HAL also includes hardware abstraction for interfaces prepared for UDFB Library(-ies).
Function blocks that are used in many RAs in common, e.g. Fast Fourier Transform (FFT), and/or some function blocks
that should be implemented very efficiently using special-purpose accelerator(s) in a given radio platform, e.g. Turbo
coder, are also to be defined as SFB(s).
Meanwhile, UDFB Set shown in Figure 4.4 includes all the UDFBs to be used in a given RA(s). It is important that any
SFB can be modified and/or extended by replacing it with proper UDFB(s) which is a modified and/or extended version
of the SFB to be replaced. Therefore, some UDFB(s) can be good candidate(s) for SFB extension, which means they
might be added as SFB(s) later. In that case, after addition, they will become atomic as the normal SFBs. Since UDFB
rd
Set is to be provided by RA provider, i.e. 3 party, instead of radio platform vendor, in order for RCF to be able to
perform basic controls of every UDFB's event and/or command, a standard set of control interfaces such as "start",
"stop", "pause", "get_port" and "initialize" may have to be specified for the corresponding UDFB(s). For this purpose,
if necessary, a dedicated deliverable will specify a standard set of control interfaces for each UDFB to be implemented
properly via the standard set of control interfaces. Specification of the standard control interfaces for UDFB(s) as well
as SFB(s) will be given in the document of Protocol/Interface TS. Recall that radio platform shown in Figures 4.3 and
4.4 generally consists of both core(s) and dedicated hardware accelerator(s) for implementing each of function blocks.
Operational structure of URA includes the following components as shown in Figure 4.4.
• RA includes SFB(s) and UDFB(s) in accordance with the contents of metadata in a given Radio Application
Package (RAP). Recall that Baseband Interface (BBI) represents each function block itself by specifying the
name of the corresponding function block. It also specifies interface related to the corresponding function
blocks as mentioned earlier [i.3].
• Radio Lib (normative implementation) contains configcodes of SFBs that are to be implemented on core
processor(s) while the SFBs that are to be implemented using dedicated hardware logic accelerator(s) are
supported by Radio HAL.
• UDFB Set includes all the UDFBs to be used in a given RAP and is in general provided by RA provider.
UDFB is included in RAP together with metadata and RC code [i.3]. Since UDFB is in general modified
and/or extended version of SFB, UDFB shall have a dependency on SFB library(-ies).
• Radio HAL is to abstract radio platform. Note that Radio HAL supports SFB to be implemented using
dedicated hardware logic accelerator in order for each of those SFBs to be implemented directly on
corresponding dedicated hardware logic accelerator(s).
• Radio platform driver is for ROS to recognize radio platform.
• Radio platform in general consists of both core(s) and dedicated hardware accelerator(s).
ETSI
13 ETSI TS 103 095 V1.1.1 (2013-01)
Figure 4.5 illustrates implementation of function blocks on a given radio platform which consists of core(s) and various
kinds of peripheral devices. In the example shown in Figure 4.5, the number of SFBs implemented on core processor
has been set to M and the number of SFBs implemented on dedicated hardware logic accelerators has been set to M .
1 2
As mentioned earlier in this clause, SFBs that are to be implemented using dedicated hardware logic accelerator such
as, for example, FFT, Turbo decoder, Multi-Input-Multi-Output (MIMO) decoder, etc., can be implemented directly on
the corresponding dedicated hardware logic a
...