ETSI EN 302 969 V1.2.1 (2014-11)
Reconfigurable Radio Systems (RRS); Radio Reconfiguration related Requirements for Mobile Devices
Reconfigurable Radio Systems (RRS); Radio Reconfiguration related Requirements for Mobile Devices
REN/RRS-0210
Radijski sistemi z možnostjo preoblikovanja (RRS) - Preoblikovanje radia glede na zahteve za mobilne naprave
General Information
Buy Standard
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Radijski sistemi z možnostjo preoblikovanja (RRS) - Preoblikovanje radia glede na zahteve za mobilne napraveReconfigurable Radio Systems (RRS) - Radio Reconfiguration related Requirements for Mobile Devices33.060.01Radijske komunikacije na splošnoRadiocommunications in generalICS:Ta slovenski standard je istoveten z:EN 302 969 V1.2.1:2014SIST EN 302 969 V1.2.1:2015en01-julij-2015SIST EN 302 969 V1.2.1:2015SLOVENSKI
STANDARD
SIST EN 302 969 V1.2.1:2015
ETSI EN 302 969 V1.2.1 (2014-11) Reconfigurable Radio Systems (RRS); Radio Reconfiguration related Requirements for Mobile Devices
EUROPEAN STANDARD SIST EN 302 969 V1.2.1:2015
ETSI ETSI EN 302 969 V1.2.1 (2014-11) 2
Reference REN/RRS-0210 Keywords CRS, mobile, SDR ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00
Fax: +33 4 93 65 47 16
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 The present document can be downloaded from: http://www.etsi.org The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (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 or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2014. All rights reserved.
DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM 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. SIST EN 302 969 V1.2.1:2015
ETSI ETSI EN 302 969 V1.2.1 (2014-11) 3 Contents Intellectual Property Rights . 5 Foreword . 5 Modal verbs terminology . 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 . 8 4 Requirement Organization and Methodology . 8 4.1 Requirement Organization. 8 4.2 Requirement Format . 9 4.3 Requirement Formulation . 10 5 Working assumptions . 10 5.1 Assumptions . 10 5.1.1 Mobile Device Reconfiguration Classes . 10 6 Functional Requirements . 13 6.1 Requirements on RAT Link Support and Management . 13 6.1.1 R-FUNC-RAT–01 Function for MDRC-1 to MDRC-7 . 13 6.1.2 R-FUNC-RAT–02 Function for MDRC-1 to MDRC-7 . 13 6.1.3 R-FUNC-RAT–03 Function for MDRC-1 to MDRC-7 . 13 6.1.4 R-FUNC-RAT–04 Function for MDRC-1 to MDRC-7 . 14 6.1.5 R-FUNC-RAT–05 Function for MDRC-1 to MDRC-7 . 14 6.1.6 R-FUNC-RAT–06 Function for MDRC-1 to MDRC-7 . 14 6.2 Radio Application Requirements . 14 6.2.1 R-FUNC-RA-01 Radio Applications Support for MDRC-1 to MDRC-7 . 14 6.2.2 R-FUNC-RA-02 Composition for MDRC-1 to MDRC-7 . 14 6.2.3 R-FUNC-RA-03 Concurency for MDRC-1 to MDRC-7 . 14 6.2.4 R-FUNC-RA-04 Data for MDRC-1 to MDRC-7 . 14 6.2.5 R-FUNC-RA-05 Context Information for MDRC-1 to MDRC-7 . 14 6.2.6 R-FUNC-RA-06 Pipelining for MDRC-2 to MDRC-7 . 15 6.3 Radio Application Functional Block Requirements . 15 6.3.1 R-FUNC-FB-01 Implementation for MDRC-2 to MDRC-7 . 15 6.3.2 R-FUNC-FB-02 Execution for MDRC-2 to MDRC-7 . 15 6.3.3 R-FUNC-FB-03 Side Effects for MDRC-2 to MDRC-7 . 16 6.3.4 R-FUNC-FB-04 Shared Data for MDRC-2 to MDRC-7 . 16 6.3.5 R-FUNC-FB-05 Concurrency for MDRC-2 to MDRC-7 . 16 6.3.6 R-FUNC-FB-06 Extendability for MDRC-2 to MDRC-7 . 16 6.4 Mobile Device Reconfiguration Requirements . 16 6.4.1 R-FUNC-MDR-01 Platform-specific Executable Code for MDRC-2, MDRC-3 or MDRC-4 . 16 6.4.2 R-FUNC-MDR-02 Platform-independent Source Code or IR for MDRC-5, MDRC-6 or MDRC-7 . 17 6.4.3 R-FUNC-MDR-03 Radio Configuration of Platform MDRC-1 to MDRC-7 . 17 6.4.4 R-FUNC-MDR-04 Radio Programming for MDRC-1 to MDRC-7 . 17 6.4.5 R-FUNC-MDR-05 Dynamic Execution for MDRC-4, and MDRC-7 . 17 6.4.6 R-FUNC-MDR-06 Independency on Memory Model for MDRC-1 to MDRC-7 . 17 6.4.7 R-FUNC-MDR-07 Code for MDRC-2 to MDRC-7 . 17 6.4.8 R-FUNC-MDR-08 IR Format for MDRC-5 to MDRC-7 . 18 6.4.9 R-FUNC-MDR-09 Timing Constraints for MDRC-1 to MDRC-7 . 18 6.4.10 R-FUNC-MDR-10 Platform Independency for MDRC-5 to MDRC-7 . 18 6.4.11 R-FUNC-MDR-11 Radio Application for MDRC-5 to MDRC-7 . 18 6.4.12 R-FUNC-MDR-12 Function Granularity for MDRC-1 to MDRC-7 . 18 SIST EN 302 969 V1.2.1:2015
ETSI ETSI EN 302 969 V1.2.1 (2014-11) 4 6.4.13 R-FUNC-MDR-13 Radio Virtual Machine for MDRC-2 to MDRC-7 . 18 6.4.14 R-FUNC-MDR-14 RadioVirtual Machine Structure for MDRC-2 to MDRC-7 . 18 6.4.15 R-FUNC-MDR-15 Selection of Radio Virtual Machine Protection Class for MDRC-2 to MDRC-7 . 18 6.5 Radio Frequency(RF) Transceiver Requirements . 20 6.5.1 R-FUNC-RFT-01 RF Configuration for MDRC-1 to MDRC-7 . 20 6.5.2 R-FUNC-RFT-02 Extendibility for multiple-antenna system for MDRC-1 to MDRC-7 . 20 6.5.3 R-FUNC-RFT-03 Capability of multiple frequency bands for MDRC-1 to MDRC-7 . 20 6.5.4 R-FUNC-RFT-04 Reconfigurability of RF Transceiver for MDRC-1 to MDRC-7 . 20 6.5.5 R-FUNC-RFT-05 Interoperability of radio resources for MDRC-2 to MDRC-7 . 20 6.5.6 R-FUNC-RFT-06 Testability of radio equipment for MDRC-1 to MDRC-7 . 20 6.5.7 R-FUNC-RFT-07 Unified representation of control information for MDRC-1 to MDRC-7 . 20 6.5.8 R-FUNC-RFT-08 Unified representation of data payload for MDRC-1 to MDRC-7 . 21 6.5.9 R-FUNC-RFT-09 Selection of RF Protection Class for MDRC-1 to MDRC-7 . 21 History . 22
SIST EN 302 969 V1.2.1:2015
ETSI ETSI EN 302 969 V1.2.1 (2014-11) 5 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 European Standard (EN) has been produced by ETSI Technical Committee Reconfigurable Radio Systems (RRS).
National transposition dates Date of adoption of this EN: 10 November 2014 Date of latest announcement of this EN (doa): 28 February 2015 Date of latest publication of new National Standard or endorsement of this EN (dop/e):
31 August 2015 Date of withdrawal of any conflicting National Standard (dow): 31 August 2015
Modal verbs terminology In the present document "shall", "shall not", "should", "should not", "may", "may not", "need", "need not", "will", "will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). "must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation. SIST EN 302 969 V1.2.1:2015
ETSI ETSI EN 302 969 V1.2.1 (2014-11) 6 1 Scope The scope of the present document is to define the high level system requirements for reconfigurable Mobile Devices enabling the provision of Radio Applications. The work will be based on the Use Cases defined in TR 103 062 [i.1] and TR 102 944 [i.2]. 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 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 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: Functional Block (FB): function needed for real-time implementation of Radio Application(s) NOTE 1: A functional block includes not only the modem functions in Layer1 (L1), Layer2 (L2), and Layer 3 (L3) but also all the control functions that should be processed in real-time for implementing given Radio Application(s). NOTE 2: Functional blocks are categorized into standard functional blocks and user defined functional blocks. In more details: 1) Standard functional blocks can be shared by many Radio Applications. For example, Forward Error Correction (FEC), Fast Fourier Transform (FFT)/Inverse Fast Fourier Transform (IFFT), (de)interleaver, Turbo coding, Viterbi coding, Multiple Input Multiple Output (MIMO), Beamforming, etc are the typical category of standard functional block. SIST EN 302 969 V1.2.1:2015
ETSI ETSI EN 302 969 V1.2.1 (2014-11) 7 2) User defined functional blocks include those functional blocks that are dependent upon a specific Radio Application. They are used to support special function(s) required in a specific Radio Application or to support a special algorithm used for performance improvement. In addition, a user defined functional block can be used as a baseband controller functional block which controls the functional blocks operating in baseband processor in real-time and to control some context information processed in real-time. NOTE 3: Each functional block has its unique name, Input, Output and properties. network coding: technique in which transmitted data is encoded and decoded to improve network performance Radio Application (RA): software which enforces the generation of the transmit RF signals or the decoding of the receive RF signals NOTE 1: The Software is executed on a particular radio platform or an RVM as part of the radio platform. NOTE 2: 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;
Intermediate Representations (IRs) including Radio Library calls of Radio Library native implementation and radio HAL calls;
Executable codes for a particular radio platform. radio library: library of Standard Functional Blocks (SFB) that is provided by a platform vendor in a form of platform-specific executable code 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: An SFB is implemented through a Radio Hardware Abstraction Layer (HAL) when the SFB is implemented on dedicated HW accelerators. Radio HAL is part of ROS. Radio Virtual Machine (RVM): abstract machine supporting reactive and concurrent executions NOTE: A Radio Virtual Machine may be implemented as a controlled execution environment which allows the selection of a trade-off between flexibility of base band code development and required (re-)certification efforts. reconfigurable mobile device: Mobile Device with radio communication capabilities providing support for radio reconfiguration NOTE: Reconfigurable Mobile Devices include but are not limited to: Smartphones, Feature Phones, Tablets, Laptops. resources: Hardware Resources that a Radio Application needs in active state NOTE 1: 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 reconfigurable MD. NOTE 2: Resources may include processors, accelerators, memory, Radio Frequency circuitry, etc. SIST EN 302 969 V1.2.1:2015
ETSI ETSI EN 302 969 V1.2.1 (2014-11) 8 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ASIC Application Specific Integrated Circuit BER Bit Error Rate CAT Category CR Cognitive Radio DoA Direction of Arrival FB Functional Block FEC Forward Error Correction FFT Fast Fourier Transform HAL Hardware Abstraction Layer IR Intermediate Representation LTE Long Term Evolution MAC Media Access Control MD Mobile Device MDRC Mobile Device Reconfiguration Class MIMO Multi-Input Multi-Output MU-MIMO Multi User- Multi-Input Multi-Output PER Packet Error Rate PMI Precoding Matrix Indicator RA Radio Application RAT Radio Access Technology RF Radio Frequency RI Rank Indicator ROS Radio Operating System RRS Reconfigurable Radio Systems RSSI Received Signal Strength Indication RVM Radio Virtual Machine Rx Receive SDR Software Defined Radio SFB Standard Functional Block SINR Signal to Interference-plus-Noise Ratio SU-MIMO Single User- Multi-Input Multi-Output Tx Transmit UDFB User Defined Functional Block WiFi Wireless Fidelity 4 Requirement Organization and Methodology This clause is containing the description of how the requirements are organized and the related format. 4.1 Requirement Organization As shown in Figure 1, all requirements described in the present document belong to one single category (the functional requirements category). Requirements are, in turn, organized into groups. SIST EN 302 969 V1.2.1:2015
ETSI ETSI EN 302 969 V1.2.1 (2014-11) 9
Figure 1: Overall requirements structure 4.2 Requirement Format A letter code system is defined which makes a unique identification of each requirement R---. Each requirement is 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. SIST EN 302 969 V1.2.1:2015
ETSI ETSI EN 302 969 V1.2.1 (2014-11) 10 4.3 Requirement Formulation A requirement is formulated in such a way that it is uniquely defined. It is built as follows: Title: • Description: the description of a requirement will be formulated using one of the following terms: - "shall" is used to express mandatory requirements (i.e. provisions that have to be followed) - "should" is used to express recommendations (provisions that an implementation is expected to follow unless there is a strong reason for not doing so) - "May" is used to express permissible actions (provisions that an implementation is able to follow or not follow) 5 Working assumptions 5.1 Assumptions 5.1.1 Mobile Device Reconfiguration Classes As it is expected that the reconfiguration capabilities of a Mobile Device will evolve over time, Mobile Device Reconfiguration Classes (MDRC) are introduced. As shown in Figure 2, 7 different classes of reconfigurable MD are introduced (MDRC-0 corresponds to a non-reconfigurable device).</br>
Figure 2: Definition of MDRCs according to reconfiguration capabilities A reconfigurable MD belongs to a defined class according to the reconfiguration capabilities, which are determined by the type of Resource requirements and the form of the Radio Application Package. Reconfigurable MD classes are defined as follows (see also Figure 2): 1) MDRC-0: No MD reconfiguration is possible MDRC-0 represents legacy radio implementations and do not allow for MD reconfiguration (except for bug fixing and release-updates through firmware updates) or exploitation of Cognitive Radio (CR) features. MDRC-0 represents legacy radio implementations and does not allow for MD reconfiguration. SIST EN 302 969 V1.2.1:2015</br>
</br>
</br>
</br>
ETSI ETSI EN 302 969 V1.2.1 (2014-11) 11 2) MDRC-1: Radio Applications use different fixed Resources In this scenario, at least some of the radios are implemented with non-software defined radio (SDR) technology, e.g. with dedicated Application Specific Integrated Circuits (ASICs), and are Resource-wise independent of each other. Simple CR functionality may be supported through radio parameter management to the extent which the radio implementations allow. MDRC-1 implements multiple Radio Applications with fixed Resources allocation and no Resource sharing.</br>
The rule for Resource allocation for multiple applications {A1, A2, …, AN} can be formulated as follows: Ai → Ri, ∀i∈{1, ., N}, where Ri denotes Resources allocated for application Ai and Ri ∩ Rj = ∅ for ∀i ≠ j. Note that applications can be run concurrently in any combination; a Resource allocation mechanism within separate applications is not specified. 3) MDRC-2: Radio Applications use pre-defined static Resources MDRC-2 implements multiple Radio Applications but no dynamic Resource management is available. The Radio Applications for MDRC-2 come from a single Radio Application Package which is normally provided by a reconfigurable MD vendor or SDR chipset manufacturer. In this scenario, we assume that software radio components in the Radio Application Package are provided in platform-specific executable code. The rule for the Resource allocation related to multiple applications {A1, A2, …, AN} can be formulated as follows: Ai →Ri, ∀i∈{1, ., N}, where Ri denotes Resources allocated for application Ai, if ∃ i ≠ j so that Ri ∩ Rj ≠ ∅ then such applications cannot be run concurrently, all other combinations are allowed; a Resource allocation mechanism within separate applications is not specified. 4) MDRC-3: Radio Applications have static Resource requirements For MDRC-3, a Resource budget is defined for each Radio Application. This budget contains a static Resource measure that represents the worst-case Resource usage of the application, generated at Radio Application compile-time. If an application is being started, the Resource manager installed in a reconfigurable MD of MDRC-3 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. In this scenario, we assume that software radio components in the Radio Application Package are provided in platform-specific executable code. The rule for Resource allocation for multiple applications {A1, A2, …, AN} can be formulated as follows:</br>
Ai → R(Ai), where R denotes total Resources to be shared and R(Ai) denotes a part of R allocated for Ai; if for i1, i2, ., iM ∈{1, ., N}, M ≤ N, R(Ai1) ∪ R(Ai2) ∪ . ∪ R(AiM) ⊂ R then applications Ai1, Ai2, …, AiM can be run concurrently; a Resource allocation mechanism within separate applications is not specified. 5) MDRC-4: Radio Applications have dynamic Resource requirements This scenario assumes a similar Resource manager in a reconfigurable MD as for MDRC-3, 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. In this scenario, we assume that software radio components in the Radio Application Package are provided in platform-specific executable code. Resource management for MDRC-4 can be formulated as follows. Multiple applications {A1, A2, …, AN} can be run and each application Ai is divided into tasks {t1(Ai), t2(Ai), ., tk(Ai)}. Resource allocation is provided by the Resource manager in a reconfigurable MD for each task tj(Ai) → R(tj(Ai)). The rule for task running is exactly the same as for MDRC-3 except that each application should be replaced by a corresponding task. Therefore, if for i1, i2, ., iM ∈{1, ., N}, M ≤ N, R(tj1(Ai1)) ∪ R(tj2(Ai2)) ∪ . ∪ R(tjL(AiM)) ⊂ R then tasks tj1(Ai1), tj2(Ai2), ., tjL(AiM) can be run concurrently; a Resource allocation mechanism within separate tasks is not specified. SIST EN 302 969 V1.2.1:2015</br>
</br>
</br>
</br>
ETSI ETSI EN 302 969 V1.2.1 (2014-11) 12 6) MDRC-5: Radio Applications use pre-defined static Resources, on-device compilation of Software Radio Components This class corresponds to MDRC-2 with the difference that all or part of the software radio components are provided in the Radio Application Package as platform-independent source code or platform-independent Intermediate Representation (IR), which is compiled on the reconfigurable MD itself. It particularly means that the reconfigurable MD should include a proper compiler in order to convert the source code or IR of the software radio components into an executable code that runs on a given modem chip of a reconfigurable MD. It is assumed that the methods of radio programming and the tools to support this category have become sufficiently standardized so that third-party vendors may create Radio Applications and activate them to different platforms with relative ease. The formal description of the Resource management is the same as for MDRC-2. 7) MDRC-6: Radio Applications have static Resource requirements, on-device compilation of Software Radio Components This class corresponds to MDRC-3 with the difference that all or part of the software radio components are provided in the Radio Application Package as platform-independent source code or platform-independent IR, which is compiled on the reconfigurable MD itself. As in the case of MDRC-5, it particularly means that the reconfigurable MD should include a proper compiler in order to convert the source code or IR of the software radio components into an executable code that runs on a given modem chip of a reconfigurable MD. As in the case of MDRC-5, it is assumed that the methods of radio programming and the tools to support this category have become sufficiently standardized so that third-party vendors may create Radio Applications and activate them to different platforms with relative ease. The formal description of the Resource management is the same as for MDRC-3. 8) MDRC-7: Radio Applications have dynamic Resource requirements, on-device compilation of Software Radio Components This class corresponds to MDRC-4 with the difference that all or part of the software radio components are provided in the Radio Application Package as platform-independent source code or platform-independent IR, which is compiled on the reconfigurable MD itself. As in the case of MDRC-5 or MDRC-6, it particularly means that the reconfigurable MD should include a proper compiler in order to convert the source code or IR of the software radio components into an executable code that runs on a given modem chip of a reconfigurable MD. As in the case of MDRC-5 or MDRC-6, it is assumed that the methods o</br>
<b>...</b>
ETSI EN 302 969 V1.2.1 (2014-11)
EUROPEAN STANDARD
Reconfigurable Radio Systems (RRS);
Radio Reconfiguration related Requirements
for Mobile Devices
---------------------- Page: 1 ----------------------
2 ETSI EN 302 969 V1.2.1 (2014-11)
Reference
REN/RRS-0210
Keywords
CRS, mobile, SDR
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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
The present document can be downloaded from:
http://www.etsi.org
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (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 or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2014.
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
---------------------- Page: 2 ----------------------
3 ETSI EN 302 969 V1.2.1 (2014-11)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 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 . 8
4 Requirement Organization and Methodology . 8
4.1 Requirement Organization. 8
4.2 Requirement Format . 9
4.3 Requirement Formulation . 10
5 Working assumptions . 10
5.1 Assumptions . 10
5.1.1 Mobile Device Reconfiguration Classes . 10
6 Functional Requirements . 13
6.1 Requirements on RAT Link Support and Management . 13
6.1.1 R-FUNC-RAT–01 Function for MDRC-1 to MDRC-7 . 13
6.1.2 R-FUNC-RAT–02 Function for MDRC-1 to MDRC-7 . 13
6.1.3 R-FUNC-RAT–03 Function for MDRC-1 to MDRC-7 . 13
6.1.4 R-FUNC-RAT–04 Function for MDRC-1 to MDRC-7 . 14
6.1.5 R-FUNC-RAT–05 Function for MDRC-1 to MDRC-7 . 14
6.1.6 R-FUNC-RAT–06 Function for MDRC-1 to MDRC-7 . 14
6.2 Radio Application Requirements . 14
6.2.1 R-FUNC-RA-01 Radio Applications Support for MDRC-1 to MDRC-7 . 14
6.2.2 R-FUNC-RA-02 Composition for MDRC-1 to MDRC-7 . 14
6.2.3 R-FUNC-RA-03 Concurency for MDRC-1 to MDRC-7 . 14
6.2.4 R-FUNC-RA-04 Data for MDRC-1 to MDRC-7 . 14
6.2.5 R-FUNC-RA-05 Context Information for MDRC-1 to MDRC-7 . 14
6.2.6 R-FUNC-RA-06 Pipelining for MDRC-2 to MDRC-7 . 15
6.3 Radio Application Functional Block Requirements . 15
6.3.1 R-FUNC-FB-01 Implementation for MDRC-2 to MDRC-7 . 15
6.3.2 R-FUNC-FB-02 Execution for MDRC-2 to MDRC-7 . 15
6.3.3 R-FUNC-FB-03 Side Effects for MDRC-2 to MDRC-7 . 16
6.3.4 R-FUNC-FB-04 Shared Data for MDRC-2 to MDRC-7 . 16
6.3.5 R-FUNC-FB-05 Concurrency for MDRC-2 to MDRC-7 . 16
6.3.6 R-FUNC-FB-06 Extendability for MDRC-2 to MDRC-7 . 16
6.4 Mobile Device Reconfiguration Requirements . 16
6.4.1 R-FUNC-MDR-01 Platform-specific Executable Code for MDRC-2, MDRC-3 or MDRC-4 . 16
6.4.2 R-FUNC-MDR-02 Platform-independent Source Code or IR for MDRC-5, MDRC-6 or MDRC-7 . 17
6.4.3 R-FUNC-MDR-03 Radio Configuration of Platform MDRC-1 to MDRC-7 . 17
6.4.4 R-FUNC-MDR-04 Radio Programming for MDRC-1 to MDRC-7 . 17
6.4.5 R-FUNC-MDR-05 Dynamic Execution for MDRC-4, and MDRC-7 . 17
6.4.6 R-FUNC-MDR-06 Independency on Memory Model for MDRC-1 to MDRC-7 . 17
6.4.7 R-FUNC-MDR-07 Code for MDRC-2 to MDRC-7 . 17
6.4.8 R-FUNC-MDR-08 IR Format for MDRC-5 to MDRC-7 . 18
6.4.9 R-FUNC-MDR-09 Timing Constraints for MDRC-1 to MDRC-7 . 18
6.4.10 R-FUNC-MDR-10 Platform Independency for MDRC-5 to MDRC-7 . 18
6.4.11 R-FUNC-MDR-11 Radio Application for MDRC-5 to MDRC-7 . 18
6.4.12 R-FUNC-MDR-12 Function Granularity for MDRC-1 to MDRC-7 . 18
ETSI
---------------------- Page: 3 ----------------------
4 ETSI EN 302 969 V1.2.1 (2014-11)
6.4.13 R-FUNC-MDR-13 Radio Virtual Machine for MDRC-2 to MDRC-7 . 18
6.4.14 R-FUNC-MDR-14 RadioVirtual Machine Structure for MDRC-2 to MDRC-7 . 18
6.4.15 R-FUNC-MDR-15 Selection of Radio Virtual Machine Protection Class for MDRC-2 to MDRC-7 . 18
6.5 Radio Frequency(RF) Transceiver Requirements . 20
6.5.1 R-FUNC-RFT-01 RF Configuration for MDRC-1 to MDRC-7 . 20
6.5.2 R-FUNC-RFT-02 Extendibility for multiple-antenna system for MDRC-1 to MDRC-7 . 20
6.5.3 R-FUNC-RFT-03 Capability of multiple frequency bands for MDRC-1 to MDRC-7 . 20
6.5.4 R-FUNC-RFT-04 Reconfigurability of RF Transceiver for MDRC-1 to MDRC-7 . 20
6.5.5 R-FUNC-RFT-05 Interoperability of radio resources for MDRC-2 to MDRC-7 . 20
6.5.6 R-FUNC-RFT-06 Testability of radio equipment for MDRC-1 to MDRC-7 . 20
6.5.7 R-FUNC-RFT-07 Unified representation of control information for MDRC-1 to MDRC-7 . 20
6.5.8 R-FUNC-RFT-08 Unified representation of data payload for MDRC-1 to MDRC-7 . 21
6.5.9 R-FUNC-RFT-09 Selection of RF Protection Class for MDRC-1 to MDRC-7 . 21
History . 22
ETSI
---------------------- Page: 4 ----------------------
5 ETSI EN 302 969 V1.2.1 (2014-11)
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 European Standard (EN) has been produced by ETSI Technical Committee Reconfigurable Radio Systems (RRS).
National transposition dates
Date of adoption of this EN: 10 November 2014
Date of latest announcement of this EN (doa): 28 February 2015
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 August 2015
Date of withdrawal of any conflicting National Standard (dow): 31 August 2015
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "may not", "need", "need not", "will",
"will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms
for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
---------------------- Page: 5 ----------------------
6 ETSI EN 302 969 V1.2.1 (2014-11)
1 Scope
The scope of the present document is to define the high level system requirements for reconfigurable Mobile Devices
enabling the provision of Radio Applications. The work will be based on the Use Cases defined in TR 103 062 [i.1] and
TR 102 944 [i.2].
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 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 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:
Functional Block (FB): function needed for real-time implementation of Radio Application(s)
NOTE 1: A functional block includes not only the modem functions in Layer1 (L1), Layer2 (L2), and Layer 3 (L3)
but also all the control functions that should be processed in real-time for implementing given Radio
Application(s).
NOTE 2: Functional blocks are categorized into standard functional blocks and user defined functional blocks. In
more details:
1) Standard functional blocks can be shared by many Radio Applications. For example, Forward Error
Correction (FEC), Fast Fourier Transform (FFT)/Inverse Fast Fourier Transform (IFFT),
(de)interleaver, Turbo coding, Viterbi coding, Multiple Input Multiple Output (MIMO),
Beamforming, etc are the typical category of standard functional block.
ETSI
---------------------- Page: 6 ----------------------
7 ETSI EN 302 969 V1.2.1 (2014-11)
2) User defined functional blocks include those functional blocks that are dependent upon a specific
Radio Application. They are used to support special function(s) required in a specific Radio
Application or to support a special algorithm used for performance improvement. In addition, a
user defined functional block can be used as a baseband controller functional block which controls
the functional blocks operating in baseband processor in real-time and to control some context
information processed in real-time.
NOTE 3: Each functional block has its unique name, Input, Output and properties.
network coding: technique in which transmitted data is encoded and decoded to improve network performance
Radio Application (RA): software which enforces the generation of the transmit RF signals or the decoding of the
receive RF signals
NOTE 1: The Software is executed on a particular radio platform or an RVM as part of the radio platform.
NOTE 2: 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;
Intermediate Representations (IRs) including Radio Library calls of Radio Library native
implementation and radio HAL calls;
Executable codes for a particular radio platform.
radio library: library of Standard Functional Blocks (SFB) that is provided by a platform vendor in a form of platform-
specific executable code
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: An SFB is implemented through a Radio Hardware Abstraction Layer (HAL) when the SFB is
implemented on dedicated HW accelerators. Radio HAL is part of ROS.
Radio Virtual Machine (RVM): abstract machine supporting reactive and concurrent executions
NOTE: A Radio Virtual Machine may be implemented as a controlled execution environment which allows the
selection of a trade-off between flexibility of base band code development and required (re-)certification
efforts.
reconfigurable mobile device: Mobile Device with radio communication capabilities providing support for radio
reconfiguration
NOTE: Reconfigurable Mobile Devices include but are not limited to: Smartphones, Feature Phones, Tablets,
Laptops.
resources: Hardware Resources that a Radio Application needs in active state
NOTE 1: 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
reconfigurable MD.
NOTE 2: Resources may include processors, accelerators, memory, Radio Frequency circuitry, etc.
ETSI
---------------------- Page: 7 ----------------------
8 ETSI EN 302 969 V1.2.1 (2014-11)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASIC Application Specific Integrated Circuit
BER Bit Error Rate
CAT Category
CR Cognitive Radio
DoA Direction of Arrival
FB Functional Block
FEC Forward Error Correction
FFT Fast Fourier Transform
HAL Hardware Abstraction Layer
IR Intermediate Representation
LTE Long Term Evolution
MAC Media Access Control
MD Mobile Device
MDRC Mobile Device Reconfiguration Class
MIMO Multi-Input Multi-Output
MU-MIMO Multi User- Multi-Input Multi-Output
PER Packet Error Rate
PMI Precoding Matrix Indicator
RA Radio Application
RAT Radio Access Technology
RF Radio Frequency
RI Rank Indicator
ROS Radio Operating System
RRS Reconfigurable Radio Systems
RSSI Received Signal Strength Indication
RVM Radio Virtual Machine
Rx Receive
SDR Software Defined Radio
SFB Standard Functional Block
SINR Signal to Interference-plus-Noise Ratio
SU-MIMO Single User- Multi-Input Multi-Output
Tx Transmit
UDFB User Defined Functional Block
WiFi Wireless Fidelity
4 Requirement Organization and Methodology
This clause is containing the description of how the requirements are organized and the related format.
4.1 Requirement Organization
As shown in Figure 1, all requirements described in the present document belong to one single category (the functional
requirements category). Requirements are, in turn, organized into groups.
ETSI
---------------------- Page: 8 ----------------------
9 ETSI EN 302 969 V1.2.1 (2014-11)
Figure 1: Overall requirements structure
4.2 Requirement Format
A letter code system is defined which makes a unique identification of each requirement R---.
Each requirement is 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.
ETSI
---------------------- Page: 9 ----------------------
10 ETSI EN 302 969 V1.2.1 (2014-11)
4.3 Requirement Formulation
A requirement is formulated in such a way that it is uniquely defined. It is built as follows:
Title: </br>
• Description: the description of a requirement will be formulated using one of the following terms:</br>
- "shall" is used to express mandatory requirements (i.e. provisions that have to be followed)</br>
- "should" is used to express recommendations (provisions that an implementation is expected to follow</br>
unless there is a strong reason for not doing so)</br>
- "May" is used to express permissible actions (provisions that an implementation is able to follow or not</br>
follow)</br>
5 Working assumptions</br>
5.1 Assumptions</br>
5.1.1 Mobile Device Reconfiguration Classes</br>
As it is expected that the reconfiguration capabilities of a Mobile Device will evolve over time, Mobile Device</br>
Reconfiguration Classes (MDRC) are introduced. As shown in Figure 2, 7 different classes of reconfigurable MD are</br>
introduced (MDRC-0 corresponds to a non-reconfigurable device).</br>
</br>
Figure 2: Definition of MDRCs according to reconfiguration capabilities</br>
A reconfigurable MD belongs to a defined class according to the reconfiguration capabilities, which are determined by</br>
the type of Resource requirements and the form of the Radio Application Package. Reconfigurable MD classes are</br>
defined as follows (see also Figure 2):</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 does not allow for MD reconfiguration.</br>
ETSI</br>
</br>
---------------------- Page: 10 ----------------------</br>
11 ETSI EN 302 969 V1.2.1 (2014-11)</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 Resources 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; a Resource allocation mechanism within separate</br>
applications is not specified.</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</br>
Radio Applications for MDRC-2 come from a single Radio Application Package which is normally provided</br>
by a reconfigurable MD vendor or SDR chipset manufacturer. In this scenario, we assume that software radio</br>
components in the Radio Application Package are provided in platform-specific executable code.</br>
The rule for the Resource allocation related to multiple applications {A , A , …, A } can be formulated as</br>
1 2 N</br>
follows: A →R , ∀i∈{1, ., N}, where R denotes Resources allocated for application A , if ∃ i ≠ j so that R ∩</br>
i i i i i</br>
R ≠ ∅ then such applications cannot be run concurrently, all other combinations are allowed; a Resource</br>
j</br>
allocation mechanism within separate applications 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 a reconfigurable MD of</br>
MDRC-3 checks its Resource budget and the sum of all Resource budgets of already running applications, and</br>
admits the new application only if the Resources can still be guaranteed for all running applications. In this</br>
scenario, we assume that software radio components in the Radio Application Package are provided in</br>
platform-specific 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; a Resource allocation mechanism within separate applications is not specified.</br>
5) MDRC-4: Radio Applications have dynamic Resource requirements</br>
This scenario assumes a similar Resource manager in a reconfigurable MD as for MDRC-3, but in addition the</br>
Radio Applications have now varying Resource demands based on their current type of activity. Applications</br>
have separate operational states for different types of activity, and a Resource budget is assigned to each</br>
operational state. In this scenario, we assume that software radio components in the Radio Application</br>
Package are provided in platform-specific executable code.</br>
Resource management for MDRC-4 can be formulated as follows. Multiple applications {A , A , …, A } can</br>
1 2 N</br>
be run and each application A is divided into tasks {t (A ), t (A ), ., t (A )}. Resource allocation is provided</br>
i 1 i 2 i k i</br>
by the Resource manager in a reconfigurable MD for each task t (A ) → R(t (A )).</br>
j i j i</br>
The rule for task running is exactly the same as for MDRC-3 except that each application should be replaced</br>
by a corresponding task. Therefore, if for i1, i2, ., iM ∈{1, ., N}, M ≤ N, R(t (A )) ∪ R(t (A )) ∪ . ∪</br>
j1 i1 j2 i2</br>
R(t (A )) ⊂ R then tasks t (A ), t (A ), ., t (A ) can be run concurrently; a Resource allocation</br>
jL iM j1 i1 j2 i2 jL iM</br>
mechanism within separate tasks is not specified.</br>
ETSI</br>
</br>
---------------------- Page: 11 ----------------------</br>
12 ETSI EN 302 969 V1.2.1 (2014-11)</br>
6) MDRC-5: Radio Applications use pre-defined static Resources, on-device compilation of Software Radio</br>
Components</br>
This class corresponds to MDRC-2 with the difference that all or part of the software radio components are</br>
provided in the Radio Application Package as platform-independent source code or platform-independent</br>
Intermediate Representation (IR), which is compiled on the reconfigurable MD itself. It particularly means that</br>
the reconfigurable MD should include a proper compiler in order to convert the source code or IR of the</br>
software radio components into an executable code that runs on a given modem chip of a reconfigurable MD.</br>
It is assumed that the methods of radio programming and the tools to support this category have become</br>
sufficiently standardized so that third-party vendors may create Radio Applications and activate them to</br>
different platforms with relative ease. The formal description of the Resource management is the same as for</br>
MDRC-2.</br>
7) MDRC-6: Radio Applications have static Resource requirements, on-device compilation of Software Radio</br>
Components</br>
This class corresponds to MDRC-3 with the difference that all or part of the software radio components are</br>
provided in the Radio Application Package as platform-independent source code or platform-independent IR,</br>
which is compiled on the reconfigurable MD itself. As in the case of MDRC-5, it particularly means that the</br>
reconfigurable MD should include a proper compiler in order to convert the source code or IR of the software</br>
radio components into an executable code that runs on a given modem chip of a reconfigurable MD. As in the</br>
case of MDRC-5, it is assumed that the methods of radio programming and the tools to support this category</br>
have become sufficiently standardized so that third-party vendors may create Radio Applications and activate</br>
them to different platforms with relative ease. The formal description of the Resource management is the same</br>
as for MDRC-3.</br>
8) MDRC-7: Radio Applications have dynamic Resource requirements, on-device compilation of Software Radio</br>
Components</br>
This class corresponds to MDRC-4 with the difference that all or part of the software radio components are</br>
provided in the Radio Application Package as platform-independent source code or platform-independent IR,</br>
which is compiled on the reconfigurable MD itself. As in the case of MDRC-5 or MDRC-6, it particularly</br>
means that the reconfigurable MD should include</br>
<b>...</b>
Draft ETSI EN 302 969 V1.2.1 (2014-07)
EUROPEAN STANDARD
Reconfigurable Radio Systems (RRS);
Radio Reconfiguration related Requirements
for Mobile Devices
---------------------- Page: 1 ----------------------
2 Draft ETSI EN 302 969 V1.2.1 (2014-07)
Reference
REN/RRS-0210
Keywords
CRS, mobile, SDR
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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
The present document can be downloaded from:
http://www.etsi.org
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (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 or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2014.
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
---------------------- Page: 2 ----------------------
3 Draft ETSI EN 302 969 V1.2.1 (2014-07)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 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 . 8
4 Requirement Organization and Methodology . 8
4.1 Requirement Organization. 8
4.2 Requirement Format . 9
4.3 Requirement Formulation . 10
5 Working assumptions . 10
5.1 Assumptions . 10
5.1.1 Mobile Device Reconfiguration Classes . 10
6 Functional Requirements . 13
6.1 Requirements on RAT Link Support and Management . 13
6.1.1 R-FUNC-RAT–01 Function for MDRC-1 to MDRC-7 . 13
6.1.2 R-FUNC-RAT–02 Function for MDRC-1 to MDRC-7 . 13
6.1.3 R-FUNC-RAT–03 Function for MDRC-1 to MDRC-7 . 13
6.1.4 R-FUNC-RAT–04 Function for MDRC-1 to MDRC-7 . 14
6.1.5 R-FUNC-RAT–05 Function for MDRC-1 to MDRC-7 . 14
6.1.6 R-FUNC-RAT–06 Function for MDRC-1 to MDRC-7 . 14
6.2 Radio Application Requirements . 14
6.2.1 R-FUNC-RA-01 Radio Applications Support for MDRC-1 to MDRC-7 . 14
6.2.2 R-FUNC-RA-02 Composition for MDRC-1 to MDRC-7 . 14
6.2.3 R-FUNC-RA-03 Concurency for MDRC-1 to MDRC-7 . 14
6.2.4 R-FUNC-RA-04 Data for MDRC-1 to MDRC-7 . 14
6.2.5 R-FUNC-RA-05 Context Information for MDRC-1 to MDRC-7 . 14
6.2.6 R-FUNC-RA-06 Pipelining for MDRC-2 to MDRC-7 . 15
6.3 Radio Application Functional Block Requirements . 15
6.3.1 R-FUNC-FB-01 Implementation for MDRC-2 to MDRC-7 . 15
6.3.2 R-FUNC-FB-02 Execution for MDRC-2 to MDRC-7 . 15
6.3.3 R-FUNC-FB-03 Side Effects for MDRC-2 to MDRC-7 . 16
6.3.4 R-FUNC-FB-04 Shared Data for MDRC-2 to MDRC-7 . 16
6.3.5 R-FUNC-FB-05 Concurrency for MDRC-2 to MDRC-7 . 16
6.3.6 R-FUNC-FB-06 Extendability for MDRC-2 to MDRC-7 . 16
6.4 Mobile Device Reconfiguration Requirements . 16
6.4.1 R-FUNC-MDR-01 Platform-specific Executable Code for MDRC-2, MDRC-3 or MDRC-4 . 16
6.4.2 R-FUNC-MDR-02 Platform-independent Source Code or IR for MDRC-5, MDRC-6 or MDRC-7 . 17
6.4.3 R-FUNC-MDR-03 Radio Configuration of Platform MDRC-1 to MDRC-7 . 17
6.4.4 R-FUNC-MDR-04 Radio Programming for MDRC-1 to MDRC-7 . 17
6.4.5 R-FUNC-MDR-05 Dynamic Execution for MDRC-4, and MDRC-7 . 17
6.4.6 R-FUNC-MDR-06 Independency on Memory Model for MDRC-1 to MDRC-7 . 17
6.4.7 R-FUNC-MDR-07 Code for MDRC-2 to MDRC-7 . 17
6.4.8 R-FUNC-MDR-08 IR Format for MDRC-5 to MDRC-7 . 18
6.4.9 R-FUNC-MDR-09 Timing Constraints for MDRC-1 to MDRC-7 . 18
6.4.10 R-FUNC-MDR-10 Platform Independency for MDRC-5 to MDRC-7 . 18
6.4.11 R-FUNC-MDR-11 Radio Application for MDRC-5 to MDRC-7 . 18
6.4.12 R-FUNC-MDR-12 Function Granularity for MDRC-1 to MDRC-7 . 18
ETSI
---------------------- Page: 3 ----------------------
4 Draft ETSI EN 302 969 V1.2.1 (2014-07)
6.4.13 R-FUNC-MDR-13 Radio Virtual Machine for MDRC-2 to MDRC-7 . 18
6.4.14 R-FUNC-MDR-14 RadioVirtual Machine Structure for MDRC-2 to MDRC-7 . 18
6.4.15 R-FUNC-MDR-15 Selection of Radio Virtual Machine Protection Class for MDRC-2 to MDRC-7 . 18
6.5 Radio Frequency(RF) Transceiver Requirements . 20
6.5.1 R-FUNC-RFT-01 RF Configuration for MDRC-1 to MDRC-7 . 20
6.5.2 R-FUNC-RFT-02 Extendibility for multiple-antenna system for MDRC-1 to MDRC-7 . 20
6.5.3 R-FUNC-RFT-03 Capability of multiple frequency bands for MDRC-1 to MDRC-7 . 20
6.5.4 R-FUNC-RFT-04 Reconfigurability of RF Transceiver for MDRC-1 to MDRC-7 . 20
6.5.5 R-FUNC-RFT-05 Interoperability of radio resources for MDRC-2 to MDRC-7 . 20
6.5.6 R-FUNC-RFT-06 Testability of radio equipment for MDRC-1 to MDRC-7 . 20
6.5.7 R-FUNC-RFT-07 Unified representation of control information for MDRC-1 to MDRC-7 . 20
6.5.8 R-FUNC-RFT-08 Unified representation of data payload for MDRC-1 to MDRC-7 . 21
6.5.9 R-FUNC-RFT-09 Selection of RF Protection Class for MDRC-1 to MDRC-7 . 21
History . 22
ETSI
---------------------- Page: 4 ----------------------
5 Draft ETSI EN 302 969 V1.2.1 (2014-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 draft European Standard (EN) has been produced by ETSI Technical Committee Reconfigurable Radio Systems
(RRS), and is now submitted for the combined Public Enquiry and Vote phase of the ETSI standards EN Approval
Procedure.
Proposed national transposition dates
Date of latest announcement of this EN (doa): 3 months after ETSI publication
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 6 months after doa
Date of withdrawal of any conflicting National Standard (dow): 6 months after doa
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "may not", "need", "need not", "will",
"will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms
for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
---------------------- Page: 5 ----------------------
6 Draft ETSI EN 302 969 V1.2.1 (2014-07)
1 Scope
The scope of the present document is to define the high level system requirements for reconfigurable Mobile Devices
enabling the provision of Radio Applications. The work will be based on the Use Cases defined in TR 103 062 [i.1] and
TR 102 944 [i.2].
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 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 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:
Functional Block (FB): function needed for real-time implementation of Radio Application(s)
NOTE 1: A functional block includes not only the modem functions in Layer1 (L1), Layer2 (L2), and Layer 3 (L3)
but also all the control functions that should be processed in real-time for implementing given Radio
Application(s).
NOTE 2: Functional blocks are categorized into standard functional blocks and user defined functional blocks. In
more details:
1) Standard functional blocks can be shared by many Radio Applications. For example, Forward Error
Correction (FEC), Fast Fourier Transform (FFT)/Inverse Fast Fourier Transform (IFFT),
(de)interleaver, Turbo coding, Viterbi coding, Multiple Input Multiple Output (MIMO),
Beamforming, etc are the typical category of standard functional block.
ETSI
---------------------- Page: 6 ----------------------
7 Draft ETSI EN 302 969 V1.2.1 (2014-07)
2) User defined functional blocks include those functional blocks that are dependent upon a specific
Radio Application. They are used to support special function(s) required in a specific Radio
Application or to support a special algorithm used for performance improvement. In addition, a
user defined functional block can be used as a baseband controller functional block which controls
the functional blocks operating in baseband processor in real-time and to control some context
information processed in real-time.
NOTE 3: Each functional block has its unique name, Input, Output and properties.
network coding: technique in which transmitted data is encoded and decoded to improve network performance
Radio Application (RA): software which enforces the generation of the transmit RF signals or the decoding of the
receive RF signals
NOTE 1: The Software is executed on a particular radio platform or an RVM as part of the radio platform.
NOTE 2: 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;
Intermediate Representations (IRs) including Radio Library calls of Radio Library native
implementation and radio HAL calls;
Executable codes for a particular radio platform.
radio library: library of Standard Functional Blocks (SFB) that is provided by a platform vendor in a form of platform-
specific executable code
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: An SFB is implemented through a Radio Hardware Abstraction Layer (HAL) when the SFB is
implemented on dedicated HW accelerators. Radio HAL is part of ROS.
Radio Virtual Machine (RVM): abstract machine supporting reactive and concurrent executions
NOTE: A Radio Virtual Machine may be implemented as a controlled execution environment which allows the
selection of a trade-off between flexibility of base band code development and required (re-)certification
efforts.
reconfigurable mobile device: Mobile Device with radio communication capabilities providing support for radio
reconfiguration.
NOTE: Reconfigurable Mobile Devices include but are not limited to: Smartphones, Feature Phones, Tablets,
Laptops.
resources: Hardware Resources that a Radio Application needs in active state
NOTE 1: 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
reconfigurable MD.
NOTE 2: Resources may include processors, accelerators, memory, Radio Frequency circuitry, etc.
ETSI
---------------------- Page: 7 ----------------------
8 Draft ETSI EN 302 969 V1.2.1 (2014-07)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASIC Application Specific Integrated Circuit
BER Bit Error Rate
CAT Category
CR Cognitive Radio
DoA Direction of Arrival
FB Functional Block
FEC Forward Error Correction
FFT Fast Fourier Transform
HAL Hardware Abstraction Layer
IR Intermediate Representation
LTE Long Term Evolution
MAC Media Access Control
MD Mobile Device
MDRC Mobile Device Reconfiguration Class
MIMO Multi-Input Multi-Output
MU-MIMO Multi User- Multi-Input Multi-Output
PER Packet Error Rate
PMI Precoding Matrix Indicator
RA Radio Application
RAT Radio Access Technology
RF Radio Frequency
RI Rank Indicator
ROS Radio Operating System
RRS Reconfigurable Radio Systems
RSSI Received Signal Strength Indication
RVM Radio Virtual Machine
Rx Receive
SDR Software Defined Radio
SFB Standard Functional Block
SINR Signal to Interference-plus-Noise Ratio
SU-MIMO Single User- Multi-Input Multi-Output
Tx Transmit
UDFB User Defined Functional Block
WiFi Wireless Fidelity
4 Requirement Organization and Methodology
This clause is containing the description of how the requirements are organized and the related format.
4.1 Requirement Organization
As shown in Figure 1, all requirements described in the present document belong to one single category (the functional
requirements category). Requirements are, in turn, organized into groups.
ETSI
---------------------- Page: 8 ----------------------
9 Draft ETSI EN 302 969 V1.2.1 (2014-07)
Figure 1: Overall requirements structure
4.2 Requirement Format
A letter code system is defined which makes a unique identification of each requirement R---.
Each requirement is 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.
ETSI
---------------------- Page: 9 ----------------------
10 Draft ETSI EN 302 969 V1.2.1 (2014-07)
4.3 Requirement Formulation
A requirement is formulated in such a way that it is uniquely defined. It is built as follows:
Title: </br>
• Description: the description of a requirement will be formulated using one of the following terms:</br>
- "shall" is used to express mandatory requirements (i.e. provisions that have to be followed)</br>
- "should" is used to express recommendations (provisions that an implementation is expected to follow</br>
unless there is a strong reason for not doing so)</br>
- "May" is used to express permissible actions (provisions that an implementation is able to follow or not</br>
follow)</br>
5 Working assumptions</br>
5.1 Assumptions</br>
5.1.1 Mobile Device Reconfiguration Classes</br>
As it is expected that the reconfiguration capabilities of a Mobile Device will evolve over time, Mobile Device</br>
Reconfiguration Classes (MDRC) are introduced. As shown in Figure 2, 7 different classes of reconfigurable MD are</br>
introduced (MDRC-0 corresponds to a non-reconfigurable device).</br>
</br>
Figure 2: Definition of MDRCs according to reconfiguration capabilities</br>
A reconfigurable MD belongs to a defined class according to the reconfiguration capabilities, which are determined by</br>
the type of Resource requirements and the form of the Radio Application Package. Reconfigurable MD classes are</br>
defined as follows (see also Figure 2):</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 does not allow for MD reconfiguration.</br>
ETSI</br>
</br>
---------------------- Page: 10 ----------------------</br>
11 Draft ETSI EN 302 969 V1.2.1 (2014-07)</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 Resources 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; a Resource allocation mechanism within separate</br>
applications is not specified.</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</br>
Radio Applications for MDRC-2 come from a single Radio Application Package which is normally provided</br>
by a reconfigurable MD vendor or SDR chipset manufacturer. In this scenario, we assume that software radio</br>
components in the Radio Application Package are provided in platform-specific executable code.</br>
The rule for the Resource allocation related to multiple applications {A , A , …, A } can be formulated as</br>
1 2 N</br>
follows: A →R , ∀i∈{1, ., N}, where R denotes Resources allocated for application A , if ∃ i ≠ j so that R ∩</br>
i i i i i</br>
R ≠ ∅ then such applications cannot be run concurrently, all other combinations are allowed; a Resource</br>
j</br>
allocation mechanism within separate applications 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 a reconfigurable MD of</br>
MDRC-3 checks its Resource budget and the sum of all Resource budgets of already running applications, and</br>
admits the new application only if the Resources can still be guaranteed for all running applications. In this</br>
scenario, we assume that software radio components in the Radio Application Package are provided in</br>
platform-specific 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; a Resource allocation mechanism within separate applications is not specified.</br>
5) MDRC-4: Radio Applications have dynamic Resource requirements</br>
This scenario assumes a similar Resource manager in a reconfigurable MD as for MDRC-3, but in addition the</br>
Radio Applications have now varying Resource demands based on their current type of activity. Applications</br>
have separate operational states for different types of activity, and a Resource budget is assigned to each</br>
operational state. In this scenario, we assume that software radio components in the Radio Application</br>
Package are provided in platform-specific executable code.</br>
Resource management for MDRC-4 can be formulated as follows. Multiple applications {A , A , …, A } can</br>
1 2 N</br>
be run and each application A is divided into tasks {t (A ), t (A ), ., t (A )}. Resource allocation is provided</br>
i 1 i 2 i k i</br>
by the Resource manager in a reconfigurable MD for each task t (A ) → R(t (A )).</br>
j i j i</br>
The rule for task running is exactly the same as for MDRC-3 except that each application should be replaced</br>
by a corresponding task. Therefore, if for i1, i2, ., iM ∈{1, ., N}, M ≤ N, R(t (A )) ∪ R(t (A )) ∪ . ∪</br>
j1 i1 j2 i2</br>
R(t (A )) ⊂ R then tasks t (A ), t (A ), ., t (A ) can be run concurrently; a Resource allocation</br>
jL iM j1 i1 j2 i2 jL iM</br>
mechanism within separate tasks is not specified.</br>
ETSI</br>
</br>
---------------------- Page: 11 ----------------------</br>
12 Draft ETSI EN 302 969 V1.2.1 (2014-07)</br>
6) MDRC-5: Radio Applications use pre-defined static Resources, on-device compilation of Software Radio</br>
Components</br>
This class corresponds to MDRC-2 with the difference that all or part of the software radio components are</br>
provided in the Radio Application Package as platform-independent source code or platform-independent</br>
Intermediate Representation (IR), which is compiled on the reconfigurable MD itself. It particularly means that</br>
the reconfigurable MD should include a proper compiler in order to convert the source code or IR of the</br>
software radio components into an executable code that runs on a given modem chip of a reconfigurable MD.</br>
It is assumed that the methods of radio programming and the tools to support this category have become</br>
sufficiently standardized so that third-party vendors may create Radio Applications and activate them to</br>
different platforms with relative ease. The formal description of the Resource management is the same as for</br>
MDRC-2.</br>
7) MDRC-6: Radio Applications have static Resource requirements, on-device compilation of Software Radio</br>
Components</br>
This class corresponds to MDRC-3 with the difference that all or part of the software radio components are</br>
provided in the Radio Application Package as platform-independent source code or platform-independent IR,</br>
which is compiled on the reconfigurable MD itself. As in the case of MDRC-5, it particularly means that the</br>
reconfigurable MD should include a proper compiler in order to convert the source code or IR of the software</br>
radio components into an executable code that runs on a given modem chip of a reconfigurable MD. As in the</br>
case of MDRC-5, it is assumed that the methods of radio programming and the tools to support this category</br>
have become sufficiently standardized so that third-party vendors may create Radio Applications and activate</br>
them to different platforms with relative ease. The formal description of the Resource management is the same</br>
as for MDRC-3.</br>
8) MDRC-7: Radio Applications have dynamic Resource requirements, on-device compilation of Software Radio</br>
Components</br>
This class corresponds to MDRC-4 with the difference that all or part of the software radio components are</br>
provided in the Radio Application Package as platform-independent source code</br>
<b>...</b>
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.