Reconfigurable Radio Systems as Enabler for Exploiting the ... · 1. Introduction Vision of ETSI RRS: Radio Applications • The future revised Radio equipment and Telecommunications

Reconfigurable Radio Systems as Enabler for Exploiting the Future

Heterogeneous Wireless Communications Landscape

1/17

By Markus Mueck, Vladimir Ivanov, Seungwon Choi, Gianmarco Baldini,

Antti Piipponen, et al.

2012.12.12

http://dsplab.hanyang.ac.kr, Tel : 82-2-2299-6267 Fax : 82-2-2299-6263 All rights reserved by Prof. S. Choi

Communications Landscape

Contents

1. Introduction

2. Regulation Framework

3. Reconfigurable Platform Configuration

4. Security and Certification

2/17



5. Conclusion

1. Introduction

� Vision of ETSI RRS: Radio Applications

• The future revised Radio equipment and Telecommunications Terminal Equipment (R&TTE)

Directive is expected to allow for advanced reconfiguration, enabling users to acquire

and install so-called “Radio Applications (RA)” software components which may affect

the compliance of a Mobile Device (MD) to the essential requirements of the Directive.

3/17


<Examples of RAs and MD reconfiguration>

2. Regulation Framework

� Certification as a new challenge!

• A new “Dynamic Certification” paradigm is expected to be required.

• See work ongoing in ETSI RRS: Draft TR 102 967 Use Cases for Dynamic Declaration of

Conformity

�

�

4/17


�HW Manufacturer

Provides SW components

to Infrastructure

�Mass upgrade is performed

on all devices of a given

Device type

�Independent SW Component

developers create new SW

components (e.g., modified RATs) and

transfer them to various AppStores

�Some users acquire independly „Radio Apps“,

multiple „Radio Apps“ can be installed

and operated simultaneously, i.e.

each User Device possiby has a different

configuration

�Before operating new „Radio Apps“,

a certificate needs to be obtained from

a „Certification Provider“ which operates

as licensee of the regulation administration

�

�


� MD Reconfiguration Classes (MDRCs)

• According to the type of resource requirements and the form of the Radio Application

Package (RAP), eight different categories of MDRCs from MDRC-0 to MDRC-7 are

defined. ① MDRC-0: No MD reconfiguration is possible.

② MDRC-1: RAs use different fixed resources.

③ MDRC-2: RAs use pre-defined static resources.

④ MDRC-3: RAs have static resource requirements.

⑤ MDRC-4: RAs have dynamic resource

5/17


⑤ MDRC-4: RAs have dynamic resource

requirements.

⑥ MDRC-5: RAs use pre-defined static resources, on-

device compilation of software radio components.

⑦ MDRC-6: RAs have static resource requirements,

on-device compilation of software radio

components.

⑧ MDRC-7: RAs have dynamic resource

requirements, on-device compilation of software

radio components.

<Definition of MDRCs according to reconfiguration capabilities>


� MD Reconfiguration Classes (MDRCs)

Multi-radio

system

Resource Share

(among radio

applications)

Resource

Manager

Multi-

tasking

Resource

Measurement

Resource

Allocation

MDRC-0 No no no no Design-time Design-time

MDRC-1 Yes no no no Design-time Design-time

MDRC-2

MDRC-5Yes

No

(note1)

Yes

(note 2)

Yes

(note 3)

Design-time Design-time

Design-time Design-time

6/17


MDRC-5 (note1) (note 2) (note 3) Design-time

/Install-time

Design-time

/Install-time

MDRC-3

MDRC-6Yes yes yes yes

Design-time

Run-timeDesign-time

/Install-time

MDRC-4

MDRC-7Yes yes yes yes

Design-time

Run-timeDesign-time

/Install-time

NOTE1: Resource share can exist among Radio Access Technologies (RATs) in a given radio application.

NOTE2: This is for a fixed resource allocation only. Resource management and resource allocation among RATs

(in a single RA) are pre-determined in a static manner by radio application provider.

NOTE3: Multi-tasking in this case is for multiple RATs within a single radio application.


� SDR MD architecture

• SDR MD architecture is being developed in ETSI RRS in such a way that it is compatible to

the requirements of all MDRCs.

• Unified Radio Application Interface (URAI) is to harmonize the behavior of RAs toward the

Radio Control Framework (RCF).

• Multiradio Interface (MURI) is to provide a uniform way for user applications to access all

RAs in the reconfigurable MD.

7/17


<SDR MD architecture for multiradio applications>


� Application Processor (AP)

• 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. The OS includes

Administrator, Networking stack, Mobility Policy Manager (MPM), and Monitor. The OS

also includes RCF (AP part) as well as the four entities.

• Radio Controller (RC) in RA sends context information to the Monitor or sends/receives

data to/from Networking stack.

8/17




� Radio Processor (RP)

• Radio OS is a real-time OS that includes RCF (RP part).

• Radio platform driver is a hardware driver for the Radio OS to interact with the Radio

platform hardware.

• Radio platform hardware typically consists of core(s) and baseband accelerator(s).

Baseband accelerator implementing Standard Function Block (SFB) might be provided in a

form of an ASIC.

9/17




� Radio Control Framework (RCF)

• 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.

• 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.

10/17


• Flow Controller (FC) is responsible for sending and receiving of user data packets and

controlling the flow of signaling packets.

• 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.

• Resource Manager (RM) manages the computational resources to share them among

simultaneously active RAs, and to guarantee their real-time requirements.


� Radio computer framework for RA (ETSI TS 103 095)

• Radio Processor provides communication capabilities for mobile devices.

11/17


<Software architecture for RP>

① Radio OS includes RCF

② Implementation of Radio Virtual Machine

(RVM) if Shadow Radio Platform is equal to

RVM

③ Native implementation of Radio Lib if

Shadow RP is equal to RVM

④ Configuration codes (configcodes) of RAs


� Operational Structure of URA (executable codes case)

• RA configcodes are executable on the target radio platform.

• Radio Lib and User Defined Function Blocks (UDFBs) needed to perform a given RA(s) are

already bound in the executable configcodes of RA.

12/17


<Operational structure of URA when RA configcodes are executable on a target platform>


� Operational Structure of URA (IR case)

• RA configcodes should be back-end complied at a given MD.

• Native implementation of Radio Lib should be prepared in a given MD separately because

the Radio Lib cannot be contained in RA configcodes.

13/17


<Operational structure of URA when RA configcodes are IR to be back-end compiled>


� Baseband Interface (BBI)

• In order for an MD to be capable of realizing multiple radio reconfigurations, a standard set

of BBIs should be defined as a part of the Radio Programming Interface (RPI).

• The basic philosophy of generating the standard set of BBIs is to separate the modem

hardware from the RA such that an RA can be implemented independently of modem

hardware through the BBIs.

• RA providers and modem chip vendors can completely be separated if RA code is made up

14/17


with a collection of BBIs and the concerned modem chip is compliant with the BBIs.

Hardware and Software are decoupled!Hardware and Software are decoupled!

BBIBBI


� Security ThreatsThe capability of downloading new RadioApps (RA) and MD reconfigurability may introduce new security threats, which may impact the service availability of the MD.Potential threats are:

� Download and activation of a malicious RA� Activation of incorrect configuration in the MD.� Extraction of data from the MD.� Unauthorized use of MD resources or services.

Mitigation or Protection Solutions for Security Threats should include (at least):

15/17


Mitigation or Protection Solutions for Security Threats should include (at least):� Controlled access to the download and activation of the RA. CM and RCM are obviously involved.

� Protection of system and data integrity. Challenge to implement cost efficient but effective solutions.

� Compliance to the spectrum regulations. Last check based on configuration files which maps the local spectrum regulations.

The challenge is to implement a cost effective, scalable solution to address security threats.

5. Conclusion

� The proposed novel MDRCs and certificating procedures are expected to facilitate the gradual

introduction of reconfigurability features for commercial wireless MDs.

� The regulatory framework is currently evolving, at least in Europe, such that the market

introduction of novel “Radio Applications” features is indeed becoming possible.

� The ETSI RRS committee is developing standard BBIs because ETSI RRS considers it one of the

16/17


core requirements for resolving the problem of portability.

� The capability of downloading new RAP and MD reconfigurability may introduce new security

threats, which may impact the service availability of the MD.

� This overall picture thus represents a framework that will profoundly change the way wireless

MDs will function and operate in the future.

17/17


Documents

Reconfigurable Radio Systems as Enabler for Exploiting the ... · 1. Introduction Vision of ETSI RRS: Radio Applications • The future revised Radio equipment and Telecommunications