ETSI TR 102 839 V1.1.1 (2011-04)

Reconfigurable Radio Systems (RRS); Multiradio Interface for Software Defined Radio (SDR) Mobile Device Architecture and Services

DTR/RRS-02004

General Information

• Status: Published
• Publication Date: 07-Apr-2011
• Technical Committee: RRS 2 - REA - Reconfigurable Radio Equipment Architecture
• Current Stage: 12 - Completion
• Due Date: 13-Apr-2011
• Completion Date: 08-Apr-2011

Standards Content (Sample)

Technical Report
Reconfigurable Radio Systems (RRS);
Multiradio Interface for Software Defined Radio (SDR)
Mobile Device Architecture and Services

2 ETSI TR 102 839 V1.1.1 (2011-04)

Reference
DTR/RRS-02004
Keywords
architecture, radio
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 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 TR 102 839 V1.1.1 (2011-04)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Use scenarios for SDR based mobile devices . 8
4.1 Mobile device functionality . 9
4.1.1 Power on . 9
4.1.2 Context provisioning. 9
4.1.3 Link selection . 9
4.1.4 Sensing request and delivery of sensing results . 9
4.1.5 Change of remote (base station or mobile device) configuration . 9
4.1.6 Installing new software components for support of novel standards . 10
4.1.7 Addition of new functionality on top of SDR subsystem . 10
4.2 Architecture implications . 10
5 Mobile device SDR operating environment . 11
5.1 Radio computer concept . 11
5.2 SDR value network . 13
5.3 Radio computer capabilities . 14
5.4 Radio computer deployment scenarios . 14
5.4.1 Scenario 1: Radio access technologies are legacy implementations . 14
5.4.2 Scenario 2: Radio applications use pre-defined fixed resources . 15
5.4.3 Scenario 3: Radio applications have fixed resource requirements . 15
5.4.4 Scenario 4: Radio applications have dynamic resource requirements . 15
5.4.5 Scenario 5: Radio applications come from third-party vendors . 15
6 SDR mobile device reference architecture overview . 15
6.1 SDR control framework . 16
6.2 Unified radio applications (URA) . 17
6.3 Key interfaces . 18
6.3.1 Multiradio interface (MURI) . 18
6.3.2 Unified Radio Application Interface (URAI) . 18
7 Multiradio interface design goals . 19
8 Multiradio interface concept definitions . 19
9 Information model . 21
9.1 Radio application package . 22
9.1.1 Capabilities . 22
9.1.2 Executable components . 22
9.2 Radio application instances . 23
9.3 Measurement information from radio applications . 24
9.4 Connectivity elements . 25
10 Service description . 25
10.1 Administrative services . 26
10.1.1 Install radio application . 27
10.1.2 Uninstall radio application . 27
10.1.3 Create radio application instance . 28
10.1.4 Delete radio application instance . 28
ETSI
4 ETSI TR 102 839 V1.1.1 (2011-04)
10.1.5 Get radio application parameters . 29
10.1.6 Set radio application parameters . 30
10.1.7 List radio applications . 30
10.2 Access control services . 31
10.2.1 Activate a radio application instance . 31
10.2.2 Deactivate a radio application instance . 31
10.2.3 Start radio environment measurements . 32
10.2.4 Stop radio environment measurements . 33
10.2.5 Radio environment measurement indication . 33
10.2.6 Create association with peer, mobile device originated . 34
10.2.7 Create association with peer, peer device originated . 35
10.2.8 Terminate association, mobile device originated . 36
10.2.9 Terminate association, peer device originated . 36
10.2.10 Create data flow into association, mobile device originated . 37
10.2.11 Create data flow into association, peer device originated . 38
10.2.12 Terminate data flow, mobile device originated. 39
10.2.13 Terminate data flow, peer device originated . 39
10.2.14 Move data flow from association into another . 40
10.3 Data flow services . 40
10.3.1 Send user data . 40
10.3.2 Receive user data . 41
History . 42

ETSI
5 ETSI TR 102 839 V1.1.1 (2011-04)
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 Report (TR) has been produced by ETSI Technical Committee Reconfigurable Radio Systems (RRS).
ETSI
6 ETSI TR 102 839 V1.1.1 (2011-04)
1 Scope
The present document is a study item that can be used in the normative process within ETSI TC RRS, when defining
normative system requirements, architecture, and interfaces for Mobile Device (MD) Software Defined Radio (SDR).
The TR 102 680 [i.1] presents a reference architecture for Software Defined Radio (SDR) mobile devices from a radio
computer viewpoint. Such a device can run radio applications on shared platform resources, and install new ones even
during run-time, much like a personal computer with regular computer programs. The reference architecture details the
internals of a possible mobile device SDR subsystem, but is not meant to be a normative architecture. Instead, it
identifies various key interfaces that may be generalized in order for the multiradio computer vision to be realized.
These interfaces may be normative.
SDR can be on one hand considered as an implementation technology that replaces legacy ASICs when suitable cost
and power tradeoffs can be found; this track is not in the scope of ETSI TC RRS. On the other hand, SDR can be
considered as an enabling technology for Cognitive Radio (CR) systems. It is in the scope of ETSI TC RRS to define
the responsibilities of various subsystems in a complete CR system. The TR 103 062 [i.2] lists high level use scenarios
for SDR based mobile devices, to be used in this process.
The two approaches meet at the interface to the SDR subsystem. This is called the Multiradio Interface (MURI) in the
reference architecture. The purpose of this technical report is to outline the functionality at this interface, both from
SDR technology and CR system perspectives. The use scenarios are analyzed first, in order to partition the
responsibilities between the SDR subsystem and the CR entities on top of it. Then the SDR subsystem is taken a deeper
look, based on TR 102 680 [i.1] and technology deployment scenarios. Finally the MURI functionality is sketched from
these basis.
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 680: "Reconfigurable Radio Systems (RRS); SDR Reference Architecture for
Mobile Device".
[i.2] ETSI TR 103 062: "Reconfigurable Radio Systems (RRS) Use Cases and Scenarios for Software
Defined Radio (SDR) Reference Architecture for Mobile Device".
[i.3] IEEE 802.11: "Standard for Information Technology-Telecommunications and Information
Exchange Between Systems-Local and Metropolitan Area Networks-Specific Requirements -
Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".
ETSI
7 ETSI TR 102 839 V1.1.1 (2011-04)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
mobile device: personal communication device (e.g. mobile phone, PDA, laptop PC, etc.) capable of communicating
either locally (e.g. Bluetooth), through a network (e.g. GSM) or both by using one or more radio technologies
radio application: software application executing in a software defined multiradio equipment
NOTE: Radio application is typically designed to use certain radio frequency band(s) and it includes agreed
schemes for multiple access, modulation, channel and data coding as well as control protocols for all
radio layers needed to maintain user data links between adjacent radio equipments, which run the same
radio application.
radio equipment: equipment using radio technology
radio system: system which consists of a number of radio equipments using at least one common radio technology
software defined multiradio: device or technology where multiple radio technologies can coexist and share their
wireless transmission and/or reception capabilities, including but not limited to regulated parameters, by operating them
under a common software system
NOTE 1: Examples of the regulated parameters are frequency range, modulation type, and output power.
NOTE 2: Common software system represents radio operating system functions.
NOTE 3: This definition does not restrict the way software is used to set and/or change the parameters. In one
example, this can be done by the algorithm of the already running software. In another example, software
downloading may be required.
software defined radio: radio in which the RF operating parameters including, but not limited to, frequency range,
modulation type, or output power can be set or altered by software, and/or the technique by which this is achieved
NOTE 1: Excludes changes to operating parameters which occur during the normal pre-installed and predetermined
operation of a radio according to a systen specification or standard.
NOTE 2: SDR is an implementation technique applicable to many radio technologies and standards.
NOTE 3: SDR techniques are applicable to both transmitters and receivers.
software defined radio equipment: radio equipment supporting SDR technology
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASIC Application Specific Integrated Circuit
BB BaseBand
CF Cognitive Functionality
CM Configuration Manager
CR Cognitive Radio
DVB: Digital Video Broadcasting
EMC Electro-Magnetic Compatibility
FC Flow Controller
FEM: Front End Module
FM: Frequency Modulation
GGSN Gateway GPRS Support Node
GPRS General Packet Radio System
GPS: Global Positioning System
GSM Global System for Mobile communications
ETSI
8 ETSI TR 102 839 V1.1.1 (2011-04)
HSxPA: High Speed Packet Access
HW HardWare
IP Intellectual Property
NOTE: As in semiconductor IP.
IP Internet Protocol
NOTE: As in TCP/IP.
LTE Long Term Evolution
MAC: Medium Access Control
MD Mobile Device
MRC MultiRadio Controller
MURI MUltiRadio Interface
NOTE: Renamed from "Multiradio Access Interface" in [i.1].
PDA Personal Digital Assistant
PDP Packet Data Protocol
RAT Radio Access Technology
RCM Radio Connection Manager
RF Radio Frequency
RFFI Reconfigurable RF Interface
RM Resource Manager
RPI Radio Programming Interface
RRS Reconfigurable Radio System
SDR Software Defined Radio
SMS Short Message Service
SSID: Service Set Identifier
SW: Software
TCP Transport Control Protocol
TRx: Transceiver
UMTS: Universal Mobile Telecommunications System
URA Unified Radio Application
URAI Unified Radio Application Interface
WCDMA Wideband Code Division Multiple Access
WLAN Wireless Local Area Network
4 Use scenarios for SDR based mobile devices
High level use scenarios for SDR based mobile devices have been collected in [i.2]. These use cases are used to define
system requirements for SDR mobile devices but not in the scope of the present document; the focus here is in drawing
the mobile device SDR architecture and responsibilities for the architectural components. The high level use scenarios
are:
• Terminal-centric configuration in a heterogeneous radio context. In this scenario, the mobile device is able
to detect a heterogeneous wireless framework, consisting of cellular systems, wireless local area networks,
wireless personal area networks, etc. Based on its configuration capabilities, it selects a single RAT or multiple
RATs to camp on.
• Network driven terminal configuration in a heterogeneous radio context. Similarly as in the previous
scenario, the mobile device operates on a heterogeneous wireless framework, but here a network decides
which RATs the mobile device uses.
• Addition of new features, such as support for novel radio systems, to mobile devices. In this scenario, the
mobile device is being updated with a new radio application, to support e.g. a novel radio standard.
• Provision of a new cognitive feature. In this scenario, the mobile device is being updated with a new
cognitive feature, such as cross-technology spectrum measurement.
ETSI
9 ETSI TR 102 839 V1.1.1 (2011-04)
4.1 Mobile device functionality
Each of the use scenarios is analyzed, and the functionality in the scenario description and the information flow
diagrams is expanded from the mobile device perspective.
4.1.1 Power on
Applicable to all usage scenarios.
The mobile device activates suitable RATs for the scenario. Not all RATs may be needed in all scenarios so they may
remain inactive. The RATs that are activated start operating as per their radio standard.
The RATs that are not needed may be later deactivated, so they stop consuming power and platform resources.
4.1.2 Context provisioning
Applicable to the terminal and network centric configuration of mobile device scenarios.
The mobile device uses one or more of the active RATs to receive context information from a network (Cognitive Pilot
Channel) or by inter-mobile communication. For this the mobile device needs to detect the availability of the network or
other suitable mobile devices.
NOTE: Context information within integrated framework (such as 3GPP GSM, UMTS, HSxPA, LTE,
LTE-Advanced) is not in the scope of the present document and the information exchange is handled by
the corresponding RAT without implications on the SDR architecture.
4.1.3 Link selection
Applicable to the terminal and network centric configuration of mobile device scenarios.
The mobile devices selects one or more of the active RATs in order to form a communication link with a network or
other mobile devices. For this the mobile device needs either up-to-date context information or its own sensing results.
The selection criteria may include both network centric control schemes as well as autonomous operation by the mobile
device.
NOTE: Only the selection of links between distinct systems which are not within an integrated framework (such
as 3GPP GSM, UMTS, HSxPA, LTE, LTE-Advanced) is in the scope of the present document. Link
selection within such an integrated framework is handled by the corresponding RAT according to the
relevant standards, without implications on the SDR architecture.
4.1.4 Sensing request and delivery of sensing results
Applicable to the terminal and network centric configuration of mobile device scenarios.
The mobile device receives from a network or other mobile devices a request to perform sensing. The mobile device
may do the sensing, aggregate the results, and send them back to the requester. The sensing may include RAT specific
operations (e.g. finding networks or other mobile devices using specific technologies), feature detection using generic
spectrum sensors (e.g. location of specific technologies on certain frequencies), and general spectrum measurements
(e.g. detected power levels on certain frequencies).
NOTE: The present document considers only the sensing across distinct technologies that are not designed within
an integrated framework (such as 3GPP GSM, UMTS, HSxPA, LTE, LTE-Advanced). Sensing or
measurements within such an integrated framework is handled by the corresponding RAT according to
the relevant standards, without implications on the SDR architecture.
ETSI
10 ETSI TR 102 839 V1.1.1 (2011-04)
4.1.5 Change of remote (base station or mobile device) configuration
Applicable to the terminal and network centric configuration of mobile device scenarios.
The base station that the mobile device has a connection to changes its configuration and requires that the mobile device
is also reconfigured. This may also happen with a local connection between two mobile devices. The base station
provides corresponding reconfiguration information such as the newly used RAT, frequencies, etc., and the mobile
device may the reconfigure itself in order to maintain the connection.
NOTE: Configuration changes within systems in an integrated framework (such as 3GPP GSM, UMTS, HSxPA,
LTE, LTE-Advanced) are not in the scope of the present document. They are handled by the
corresponding RATs autonomously according to the relevant standards, and do not have implications on
the SDR architecture.
4.1.6 Installing new software components for support of novel standards
Applicable to the addition of new radio software scenario.
New software components to be used by the SDR subsystem are available for the update of the mobile device. These
components may be delivered for example using an active RAT. The mobile device (e.g. the SDR subsystem) checks
the sanity and compatibility of the new components and may install them to be taken into use. The software components
may be new or updated radio applications for the support of novel standards, for instance.
The addition of new software components after the manufacture of a mobile device may have implications on
regulatory framework concerning SDR equipment.
4.1.7 Addition of new functionality on top of SDR subsystem
Applicable to the provision of new cognitive features scenario.
New software components are available for the update of the mobile device. These components may be delivered for
example using an active RAT. The mobile device checks the sanity and compatibility of the new components and may
install them to be taken into use. The software components may be e.g. cognitive control functions for new CR
functionality.
As the software components are not used by the SDR subsystem, this use scenario has no impact on the SDR
architecture, apart from the delivery of the components using a wireless interface. From the complete mobile device
point of view this is important, and should be handled on the higher layers.
4.2 Architecture implications
The functionality outlined above may have the following implications on the mobile device and SDR architecture.
Many of the cross-technology cognitive features can be seen as non-SDR related functionality. For example, initial
scanning of available communication partners, possible context information reception using any of the available RATs,
and the selection of links are independent of the implementation of the underlying radios. Such intelligence can be built
on top of the SDR subsystem.
Any functionality internal to a RAT (individual radio standard or e.g. integrated 3GPP framework) is not in the scope of
the present document. Examples of such functionality are searching of beacons or control channels of access points or
base stations, message exchange procedures for joining a found network, etc. However, for the cross-technology
cognitive features to function, some information from the RATs may be provided. This can include found networks,
receive signal strength of these networks, and details of the provided services, for instance. Even if the RATs are not
fully configurable by software, providing such information to the layers above can be used to realize a variety of
cognitive functionalities.
Finally, as the set of available (i.e. installed) RATs and the cognitive functions may change during the lifetime of the
mobile device, the interface between these should be generic. This means, that commonalities between specific RATs
are abstracted. Within the present document, these relate to administration functions (i.e. installation and removal of
RATs), control (i.e. requests of sensing, establishing connections), and user plane data transfer.
ETSI
11 ETSI TR 102 839 V1.1.1 (2011-04)

Figure 1: SDR and Cognitive Functionality in reconfigurable radio equipment
Figure 1 shows an example of how the SDR and cognitive functionalities may be split within the reconfigurable radio
equipment, in order to enable independent development of both sides.
5 Mobile device SDR operating environment
This clause collects some of the main topics of [i.1], such as the radio computer concept, SDR value network, and the
most relevant interfaces.
5.1 Radio computer concept
SDR equipment will operate in the same kinds of networking environments as today's mobile phones, PDAs and
laptops. Both licensed and unlicensed frequency bands will remain in use. SDR equipments will be used in user
terminals in operators' networks as well as peer equipments in short range, personal and ad hoc networks. Radio and TV
broadcasting stations and geopositioning satellites will also be used as distant communication peers of SDR
equipments.
Besides existing radio technologies new radio technologies and frequency bands will become available to SDR
equipments. Therefore the design of SDR equipment architecture will be prepared for new frequency bands and radio
systems – among them especially the ones supporting introduction of cognitive radio systems. More flexible schemes to
use available radio frequencies will also emerge by introduction of spectrum sensing techniques, distribution of
cognitive control information and use of commonly agreed spectrum etiquettes. From the SDR equipment architecture
point of view both network-centric control schemes and autonomously operating mobile devices are equally valid in
such future spectrum utilization cases.
Instead of engineering radios as embedded systems on RFICs, special-purpose digital signal processors and ASIC
accelerators, future software defined multi-radio equipment may be seen as a computer where individual radio
applications are engineered as software entities to run on more general-purpose computing elements. Such a radio
computer is capable to run multiple radios simultaneously and can change this set of radios by loading new radio
application software even at run-time. All radio applications exhibit a common behaviour from the radio computer point
of view.
In order to share the available computing, memory, communications and RF resources the radio computer has a radio
operating system, just like desktop computers have their operating system. Such a radio operating system supports
coexistence of multiple radios even if they are operating on same or adjacent frequency bands. Radio operating system
also provides run-time reconfiguration by installing, loading and activating new radio applications.
ETSI
12 ETSI TR 102 839 V1.1.1 (2011-04)

Figure 2: Radio computer concept
This parallelism to desktop computing leads to architecting the functionalities of a multiradio equipment as three
horizontal layers: physical radio computing platform, operating system and radio applications as shown in Figure 2.
The decoupling of the radio applications from the physical hardware platform and the user entities requires the
definition of four generalized interfaces. The first important system-wide interface needs to be specified at the boundary
between the common radio computer platform and the specific radio applications. This Unified Radio Application
Interface (URAI) is used to adapt and align all kinds of radio applications under the common reconfiguration,
multiradio execution and resource sharing framework of the SDR reference architecture.
The second key interface relates to the independent and uniform production of radio applications as software entities.
This can be achieved by introducing as part of the architecture a Radio Programming Interface (RPI). This is both a
radio software development time concept as well as a run-time interface between radio software entities and the radio
computer platform. This interface needs to include a uniform radio programming model that combines required
run-time dynamism with real-time guarantees and efficiency. The programming model needs to be platform neutral and
allow multiple radio compilers to be used for generating run-time radio packages for different platforms from the same
source program. Additional aspects to be taken into account in the radio programming interface are virtualization of
hardware peripherals of the radio computer such as reconfigurable RF devices.
The third common interface may be defined due to the foundational role of RF circuitry in any radio equipment. We
anticipate the emergence of a more generic Reconfigurable RF Interface (RFFI), which will support multiple radio
applications and may even support sharing of the same circuitry among simultaneously active radio applications with
similar enough RF properties.
Finally, because the software defined radio subsystem is also decoupled from the higher layer network protocol stacks
(e.g. TCP/IP) and associated cognitive entities, the SDR equipment provide a service interface to its user entities. Such
a Multiradio Interface (MURI) provides a uniform way to access all radio applications in the SDR equipment.
ETSI
13 ETSI TR 102 839 V1.1.1 (2011-04)

Figure 3: Compile-time and run-time functions of a radio computer
Figure 3 illustrates a scenario, where a radio compiler is employed to support this kind of programming model. Radio
programs are built into radio packages in compile-time. Radio package contains not only the binary code of the radio
program components but also metadata about the radio system. Included into such metadata descriptions are the
structure of the radio application program, radio system parameters (e.g. modes or frequency bands of multi-mode or
multi-band radio systems) and also the pre-calculated run-time resource requirements, which are expressed as resource
budgets.
During run-time (or if so selected already at manufacturing time) the loader component of the radio operating system
will install and load radio packages into the execution environment of the radio computer. Binary code is loaded into
memories available to processing elements. Radio applications are initialized with the provided radio system parameters
and resource budget data is made available to the resource manager components of the radio operating system.
5.2 SDR value network
Figure 4 below outlines potential business relationships between different mobile device SDR stakeholders.
Consumer
markets
Figure 4: Future SDR value network
ETSI
14 ETSI TR 102 839 V1.1.1 (2011-04)
With the introduction of the SDR technology the radio chipset vendors will become responsible for integration of
complete radio computers. They may use separate manufacturing companies (semiconductor foundries) and integrate
also IP blocks from other semiconductor vendors e.g. outer modem HW accelerators. Such radio computers, which may
include some built-in radio applications, are provided as radio platforms to mobile device manufacturers. Mobile device
manufacturers develop their consumer products, like mobile phones, multimedia computers and PDA devices, which
use the radio computers as subsystems for communications purposes. Mobile device manufacturer may also choose to
implement itself some radio applications into the radio computer platform. While radios continue to be used for
multiple different purposes and new radio technologies continue to emerge development of radio applications as
software entities may become a business of own. Such radio application providers may develop and market their radio
applications to multiple radio computer vendors and mobile device manufacturers. This kind of value network may also
allow some software companies to become radio software tool vendors having multiple radio developer companies as
their customers.
To have potential for wide adoption, the SDR architecture interface definitions should fall at these stakeholder
boundaries.
5.3 Radio computer capabilities
The SDR platform is designed as multiradio computer platform, which may be composed of one or more general
purpose control processor(s) and of one or more specialized co-processors (e.g. digital signal processor clusters, vector
processors etc). This kind of heterogeneous multi-processor architecture operates under tight real-time constraints [in
µsec range] and is bound by a tight power budget. Dynamic reconfiguration of the hardware platform also needs to be
supported by the architecture. How to provide secure execution environment for all radio applications running on a
common radio computer platform is also an important design criteria.
Specifically, three types of multiradio SDR capability requirements have been identified in [i.1], each of which may
have impact on the multiradio interface definition:
Multiradio configuration capability: SDR equipment in mobile device is expected to install, load and activate a radio
application while running a set of radio systems already. Correspondingly it allows active radio systems to become
deactivated, unloaded and uninstalled.
Multiradio operation capability: SDR equipment in mobile device is expected to execute number of radio systems
simultaneously by taking into account temporal coexistence rules designed for their common operation to mitigate
inter-radio interference.
Multiradio resource sharing capability: SDR equipment in mobile device is expected to execute number of radio
systems simultaneously by sharing computation, memory, communications and RF circuitry resources available on the
radio computer platform by using appropriate resource allocation, binding and scheduling mechanisms.
5.4 Radio computer deployment scenarios
Being the interface towards SDR user entities, the multiradio interface definition should cover usage in various steps of
SDR platform advances. A phased approach is described, where each phase introduces new elements to the multiradio
computer. These elements are related to resource sharing capability between the concurrently active radio applications.
5.4.1 Scenario 1: Radio access technologies are legacy implementations
In this scenario at least some of the radios are implemented with non-SDR technology, e.g. with dedicated ASICs, and
are resource-wise independent of each other. The multiradio interface collects the control and user plane functionalities
of the diverse radios in a uniform manner, allowing easier development of architecturally coherent connectivity and
mobility management features. Simple cognitive radio functionality may be supported through radio parameter
management to the extent, which the radio implementations allow.
ETSI
15 ETSI TR 102 839 V1.1.1 (2011-04)
5.4.2 Scenario 2: Radio applications use pre-defined fixed resources
In this scenario, no dynamic resource management is available in the multiradio computer. The radio applications come
from a single source, typically the mobile device vendor or SDR chipset manufacturer. The application vendor also
provides a list of possible radio combinations that may run on the platform concurrently; such a list could for example
be "WiFi runs in parallel to GSM". The resources used by the applications running in parallel are fixed; the resource
allocation may be done during compile time, when the radio application package is created by the vendor. The
multiradio computer resource manager only does fixed resource assignment, when the application is placed into
execution. If dynamic resource management is applied within the fixed resource assignment, it is hard-coded in the
application itself.
If a new radio application is installed, a new list of possible parallel radio combinations is also provided.
5.4.3 Scenario 3: Radio applications have fixed resource requirements
Once the amount of radio applications become available, the list of possible parallel radio combinations may become
unwieldy. In this scenario, a resource budget is defined for each radio application. This budget contains a fixed resource
measure that represents the worst-case resource usage of the application, generated at compile time. If an application is
being started, the resource manager checks its resource budget and the sum of all resource budgets of already running
applications, and admits the new application only if the resources can still be guaranteed for all running applications.
Because of more flexible resource allocation, in general the same platform can run more concurrent radio applications
than what is possible in scenario 1. The penalty is that applications may not have enough resources to get into
execution, and this is not known until an admission check is done.
5.4.4 Scenario 4: Radio applications have dynamic resource requirements
This scenario assumes a similar resource manager as in scenario 2, but in addition the radio applications have now
varying resource demands based on their current type of activity. Applications have separate operational states for
different types of activity, and a resource budget is assigned to each operational state. The resource manager does
admission control and resource reservation when applications are being started, but also when they request to transition
into a new operational state with different resource demand.
5.4.5 Scenario 5: Radio applications come from third-party vendors
In this scenario, the methods of radio programming and the tools to support this have become sufficiently standard so
that third-party vendors may cre
...