ETSI TS 102 969 V1.1.1 (2012-03)

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

DTS/RRS-02006

General Information

• Status: Published
• Publication Date: 29-Mar-2012
• Technical Committee: RRS 2 - REA - Reconfigurable Radio Equipment Architecture
• Current Stage: 12 - Completion
• Due Date: 05-Apr-2012
• Completion Date: 30-Mar-2012

Standards Content (Sample)

Technical Specification
Reconfigurable Radio Systems (RRS);
Radio Reconfiguration related Requirements
for Mobile Devices
2 ETSI TS 102 969 V1.1.1 (2012-03)

Reference
DTS/RRS-02006
Keywords
CRS, 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 2012.
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 102 969 V1.1.1 (2012-03)
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 . 6
3.1 Definitions . 6
3.2 Abbreviations . 7
4 Requirement Organization and Methodology . 7
4.1 Requirement Organization. 7
4.2 Requirement Format . 8
4.3 Requirement Formulation . 8
5 Working assumptions . 9
5.1 Assumptions . 9
5.1.1 Mobile Device Reconfiguration Classes . 9
6 Functional Requirements . 12
6.1 Requirements on RAT Link Support and Management . 12
6.1.1 R-FUNC-RAT–01 Function for MDRC-1 to MDRC-7 . 12
6.1.2 R-FUNC-RAT–02 Function for MDRC-1 to MDRC-7 . 12
6.1.3 R-FUNC-RAT–03 Function for MDRC-1 to MDRC-7 . 12
6.1.4 R-FUNC-RAT–04 Function for MDRC-1 to MDRC-7 . 12
6.1.5 R-FUNC-RAT–05 Function for MDRC-1 to MDRC-7 . 12
6.1.6 R-FUNC-RAT–06 Function for MDRC-1 to MDRC-7 . 12
6.1.7 R-FUNC-RAT–07 Function for MDRC-1 to MDRC-7 . 12
6.2 Base Band Interface Requirements. 12
6.2.1 R-FUNC-BBI-01 Composition for MDRC-1 to MDRC-7 . 12
6.2.2 R-FUNC-BBI-02 Data for MDRC-1 to MDRC-7 . 13
6.2.3 R-FUNC-BBI-03 Context Information for MDRC-1 to MDRC-7 . 13
6.2.4 R-FUNC-BBI-04 Interface Type for MDRC-2 to MDRC-7 . 13
6.2.5 R-FUNC-BBI-05 Pipelining for MDRC-2 to MDRC-7 . 13
6.2.6 R-FUNC-BBI-06 Transferring of Context Information for MDRC-1 to MDRC-7 . 13
6.2.7 R-FUNC-BBI-07 Support for Multi-antenna Technologies for MDRC-1 to MDRC-7 . 13
6.2.8 R-FUNC-BBI-08 Access to Device-internal Radio Context Information for MDRC-1 to MDRC-7 . 13
6.3 Base Band Function Block requirements . 14
6.3.1 R-FUNC-FB-01 Implementation for MDRC-2 to MDRC-7 . 14
6.3.2 R-FUNC-FB-02 Function Block for MDRC-2 to MDRC-7 . 14
6.3.3 R-FUNC-FB-03 Normative Library for MDRC-2 to MDRC-7 . 14
6.3.4 R-FUNC-FB-04 Execution for MDRC-2 to MDRC-7 . 15
6.3.5 R-FUNC-FB-05 Side Effects for MDRC-2 to MDRC-7 . 15
6.3.6 R-FUNC-FB-06 Shared Data for MDRC-2 to MDRC-7 . 15
6.3.7 R-FUNC-FB-07 Concurrency for MDRC-2 to MDRC-7 . 15
6.3.8 R-FUNC-FB-08 User Defined Function Block for MDRC-2 to MDRC-7 . 15
6.3.9 R-FUNC-FB-09 Extendability for MDRC-2 to MDRC-7 . 15
6.4 Mobile Device Reconfiguration Requirements . 15
6.4.1 R-FUNC-MDR-01 Platform-specific Executable Code for MDRC-2, MDRC-3 or MDRC-4 . 15
6.4.2 R-FUNC-MDR-02 Platform-independent Source Code or IR for MDRC-5, MDRC-6 or MDRC-7 . 16
6.4.3 R-FUNC-MDR-03 Radio Configuration of Platform MDRC-1 to MDRC-7 . 18
6.4.4 R-FUNC-MDR-04 Radio Programming Interface for MDRC-1 to MDRC-7 . 18
6.4.5 R-FUNC-MDR-05 Concurrent Execution for MDRC-1 to MDRC-7 . 18
6.4.6 R-FUNC-MDR-06 Dynamic Execution for MDRC-3, MDRC-4, MDRC-6 and MDRC-7 . 18
6.4.7 R-FUNC-MDR-07 Formal Verification for MDRC-1 to MDRC-7 . 19
6.4.8 R-FUNC-MDR-08 Independency on Memory Model for MDRC-1 to MDRC-7 . 19
ETSI
4 ETSI TS 102 969 V1.1.1 (2012-03)
6.4.9 R-FUNC-MDR-09 IR Format for MDRC-5 to MDRC-7 . 19
6.4.10 R-FUNC-MDR-10 Timing Constraints for MDRC-1 to MDRC-7 . 19
6.4.11 R-FUNC-MDR-11 Intermediate Representation for MDRC-5 to MDRC-7 . 19
6.4.12 R-FUNC-MDR-12 Unified Radio Application for MDRC-1 to MDRC-7 . 19
6.4.13 R-FUNC-MDR-13 Function Granularity for MDRC-1 to MDRC-7 . 19
7 Conclusions . 19
History . 20

ETSI
5 ETSI TS 102 969 V1.1.1 (2012-03)
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
6 ETSI TS 102 969 V1.1.1 (2012-03)
1 Scope
The scope of the present document is to define the system requirements for reconfiguring the radios in 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].
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
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 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".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
resource: resource that radio application needs in active state, which includes processor and accelerator loads, memory
usage, interconnect bandwidth occupation, Radio Frequency (RF) circuitry, etc.
NOTE: Resources are provided by the reconfigurable Mobile Device (MD), to be used by the radio applications
when they are active. Radio applications provide their resource needs (e.g. using operational states) so
that the multiradio computer may judge whether these resources are available, in order to ensure
non-conflicting operation with other radio applications. Resources may or may not be shared in the MD.
ETSI
7 ETSI TS 102 969 V1.1.1 (2012-03)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASIC Application Specific Integrated Circuit
BBI BaseBand Interface
BER Bit Error Rate
BPA Baseband Parameter Aggregation
CAT Category
CII Context Information Interface
CR Cognitive Radio
DoA Direction of Arrival
FEC Forward Error Correction
FFT Fast Fourier Transform
IP Internet Protocol
IR Intermediate Representation
MAC Media Access Control
MD Mobile Device
MDRC Mobile Device Reconfiguration Classes
MIMO Multi-Input Multi-Output
MU-MIMO Multi User-MIMO
PER Packet Error Rate
PMI Precoding Matrix Indicator
RAI Radio Application Interface
RAT Radio Access Technology
RF Radio Frequency
RI Rank Indicator
RPI Radio Programming Interface
RRS Reconfigurable Radio Systems
RSSI Received Signal Strength Indication
Rx Recieve
SDR Software Defined Radio
SINR Signal to Interference-plus-Noise Ratio
SU-MIMO Single User-MIMO
Tx Transmit
URA Unified Radio Application
4 Requirement Organization and Methodology
This clause is containing the description of how the requirements are organised and the format of the requirement.
4.1 Requirement Organization
The present document is structured such that a level 1 section is dedicated to the requirements associated with a single
category. The requirements should be partitioned into groups of related category to assist understanding. The overall
structure is shown in figure 4.1.1.
ETSI
8 ETSI TS 102 969 V1.1.1 (2012-03)

Figure 4.1.1: Overall requirememts structure
4.2 Requirement Format
A letter code system is defined which makes a unique identification of each requirement R---. It
should be constructed as follows:
• R-: Standard requirement prefix
•
Code Category
FUNC Functional aspects
• : Requirement group identifier. A letter code will be used for this identifier. The three first letters
will give the identifier of the group.
• : Requirement identifier within requirement group; range 01 => 99.
EXAMPLE: R-FUNC-QOS-01
4.3 Requirement Formulation
A requirement formulation is defined which makes a unique way to formulate it. It will be built as follows:
Title: </br> • Description: <The description of the requirement shall be formulated using one of the following terms. As</br> described into the ETSI Terms & Definitions database (TEDDI), the terms are explained here for information:</br> - "shall" term means that the definition is an absolute requirement of a profile (shall equals is required to).</br> - "should" term means that among several possibilities one is recommended, in a profile, as particularly</br> suitable, without mentioning or excluding others, or that a certain course of action is preferred but not</br> necessarily required (should equals is recommended that).</br> ETSI</br> 9 ETSI TS 102 969 V1.1.1 (2012-03)</br> - "may" term means that a course of action is permissible within a profile (may equals is permitted to).</br> 5 Working assumptions</br> 5.1 Assumptions</br> 5.1.1 Mobile Device Reconfiguration Classes</br> As introduced in [i.2], clause 5.4: Radio computer deployment scenarios, it is expected that the reconfiguration</br> capabilities of MD will evolve over time. The requirements defined in the present document will thus be introduced for</br> the concerned Mobile Device Reconfiguration Classes (MDRC) as shown in figure 5.1.1.1. Figure 5.1.1.1 illustrates</br> MDRC classified according to type of resource requirements and form of radio application package.</br> </br> Figure 5.1.1.1: Definition of MDRCs according to reconfiguration capabilities</br> Reconfiguration capability, which is determined by the type of resource requirements and the form of radio application</br> package, is explained for each class as follows:</br> 1) MDRC-0: No MD reconfiguration is possible</br> MDRC-0 represents legacy radio implementations and do not allow for MD reconfiguration (except for bug</br> fixing and release-updates through firmware updates) or exploitation of Cognitive Radio (CR) features.</br> MDRC-0 represents legacy radio implementations and do not allow for MD reconfiguration.</br> 2) MDRC-1: Radio applications use different fixed resources</br> In this scenario, at least some of the radios are implemented with non-software defined radio (SDR)</br> technology, e.g. with dedicated Application Specific Integrated Circuits (ASICs), and are resource-wise</br> independent of each other. Simple CR functionality may be supported through radio parameter management to</br> the extent which the radio implementations allow.</br> MDRC-1 implements multiple radio applications with fixed resources allocation and no resource sharing.</br> The rule for resource allocation for multiple applications {A , A , …, A } can be formulated as follows: A →</br> 1 2 N i</br> R , ∀i∈{1, ., N}, where R denotes resource allocated for application A and R ∩ R = ∅ for ∀i ≠ j. Note that</br> i i i i j</br> applications can be run concurrently in any combination; resource allocation mechanism within separate</br> application is not specified.</br> ETSI</br> 10 ETSI TS 102 969 V1.1.1 (2012-03)</br> 3) MDRC-2: Radio applications use pre-defined static resources</br> MDRC-2 implements multiple radio applications but no dynamic resource management is available. The radio</br> applications for MDRC-2 come from a single radio application package which is normally provided by a MD</br> vendor or SDR chipset manufacturer. In this scenario, we assume that software radio components in the radio</br> application package are provided in platform-specific executable code.</br> The rule for resource allocation for multiple applications {A , A , …, A } can be formulated as follows: A →</br> 1 2 N i</br> R , ∀i∈{1, ., N}, where R denotes resource allocated for application A , if ∃ i ≠ j so that R ∩ R ≠ ∅ then</br> i i i i j</br> such applications cannot be run concurrently, all other combinations are allowed; resource allocation</br> mechanism within separate application is not specified.</br> 4) MDRC-3: Radio applications have static resource requirements</br> For MDRC-3, a resource budget is defined for each radio application. This budget contains a static resource</br> measure that represents the worst-case resource usage of the application, generated at radio application</br> compile-time. If an application is being started, the resource manager installed in MD of MDRC-3 checks its</br> resource budget and the sum of all resource budgets of already running applications, and admits the new</br> application only if the resources can still be guaranteed for all running applications. In this scenario, we</br> assume that software radio components in the radio application package are provided in platform-specific</br> executable code.</br> The rule for resource allocation for multiple applications {A , A , …, A } can be formulated as follows:</br> 1 2 N</br> A → R(A ), where R denotes total resources to be shared and R(A ) denotes a part of R allocated for A ; if for</br> i i i i</br> i1, i2, ., iM ∈{1, ., N}, M ≤ N, R(A ) ∪ R(A ) ∪ . ∪ R(A ) ⊂ R then applications A , A , …, A can be</br> i1 i2 iM i1 i2 iM</br> run concurrently; resour</br> <b>...</b>