SIST EN 303 641 V1.1.2:2020
(Main)Reconfigurable Radio Systems (RRS) - Radio Equipment (RE) reconfiguration requirements
Reconfigurable Radio Systems (RRS) - Radio Equipment (RE) reconfiguration requirements
The scope of the present document is to define the high level system requirements for reconfigurable Radio Equipment
enabling the provision of Radio Applications except for reconfigurable mobile devices which are covered in ETSI
EN 302 969 [i.4], ETSI EN 303 095 [i.5], ETSI EN 303 146 parts 1 [i.6] to 4 [i.9]. The work is based on the Use Cases
defined in ETSI TR 103 062 [i.1], ETSI TR 102 944 [i.2], ETSI TR 103 585 [i.3] and ETSI EN 302 969 [i.4].
Radijski sistemi z možnostjo preoblikovanja (RRS) - Zahteve za rekonfiguracijo radijske opreme (RE)
General Information
Buy Standard
Standards Content (Sample)
SLOVENSKI STANDARD
SIST EN 303 641 V1.1.2:2020
01-september-2020
Radijski sistemi z možnostjo preoblikovanja (RRS) - Zahteve za rekonfiguracijo
radijske opreme (RE)
Reconfigurable Radio Systems (RRS) - Radio Equipment (RE) reconfiguration
requirements
Ta slovenski standard je istoveten z: ETSI EN 303 641 V1.1.2 (2020-06)
ICS:
33.060.01 Radijske komunikacije na Radiocommunications in
splošno general
SIST EN 303 641 V1.1.2:2020 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST EN 303 641 V1.1.2:2020
---------------------- Page: 2 ----------------------
SIST EN 303 641 V1.1.2:2020
ETSI EN 303 641 V1.1.2 (2020-06)
EUROPEAN STANDARD
Reconfigurable Radio Systems (RRS);
Radio Equipment (RE) reconfiguration requirements
---------------------- Page: 3 ----------------------
SIST EN 303 641 V1.1.2:2020
2 ETSI EN 303 641 V1.1.2 (2020-06)
Reference
REN/RRS-0226
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/standards-search
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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
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.
© ETSI 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 4 ----------------------
SIST EN 303 641 V1.1.2:2020
3 ETSI EN 303 641 V1.1.2 (2020-06)
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 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Requirement Organization and Methodology . 9
4.0 General . 9
4.1 Requirement Organization. 9
4.2 Requirement Format . 10
4.3 Requirement Formulation . 10
5 Working assumptions . 10
5.1 Assumptions . 10
5.1.1 Radio Equipment 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 RERC-1 to RERC-7 . 13
6.1.2 R-FUNC-RAT–02 Function for RERC-1 to RERC-7 . 13
6.1.3 R-FUNC-RAT–03 Function for RERC-1 to RERC-7 . 13
6.1.4 R-FUNC-RAT–04 Function for RERC-1 to RERC-7 . 14
6.1.5 R-FUNC-RAT–05 Function for RERC-1 to RERC-7 . 14
6.1.6 R-FUNC-RAT–06 Function for RERC-1 to RERC-7 . 14
6.2 Radio Application Requirements . 14
6.2.0 General . 14
6.2.1 R-FUNC-RA-01 Radio Applications Support for RERC-1 to RERC-7 . 14
6.2.2 R-FUNC-RA-02 Composition for RERC-1 to RERC-7 . 14
6.2.3 R-FUNC-RA-03 Concurrency for RERC-1 to RERC-7 . 14
6.2.4 R-FUNC-RA-04 Data for RERC-1 to RERC-7 . 14
6.2.5 R-FUNC-RA-05 Context Information for RERC-1 to RERC-7 . 14
6.2.6 R-FUNC-RA-06 Pipelining for RERC-2 to RERC-7 . 15
6.3 Radio Application Functional Block Requirements . 15
6.3.1 R-FUNC-FB-01 Implementation for RERC-2 to RERC-7 . 15
6.3.2 R-FUNC-FB-02 Execution for RERC-2 to RERC-7 . 15
6.3.3 R-FUNC-FB-03 Side Effects for RERC-2 to RERC-7 . 16
6.3.4 R-FUNC-FB-04 Shared Data for RERC-2 to RERC-7 . 16
6.3.5 R-FUNC-FB-05 Concurrency for RERC-2 to RERC-7 . 16
6.3.6 R-FUNC-FB-06 Extendibility for RERC-2 to RERC-7 . 16
6.4 Radio Equipment Reconfiguration Requirements . 16
6.4.1 R-FUNC-RER-01 Platform-specific Executable Code for RERC-2, RERC-3 or RERC-4 . 16
6.4.2 R-FUNC-RER-02 Platform-independent Source Code or IR for RERC-5, RERC-6 or RERC-7 . 16
6.4.3 R-FUNC-RER-03 Radio Configuration of Platform RERC-1 to RERC-7 . 17
6.4.4 R-FUNC-RER-04 Radio Programming for RERC-1 to RERC-7 . 17
6.4.5 R-FUNC-RER-05 Dynamic Execution for RERC-4, and RERC-7 . 17
6.4.6 R-FUNC-RER-06 Independency on Memory Model for RERC-1 to RERC-7 . 17
6.4.7 R-FUNC-RER-07 Code for RERC-2 to RERC-7 . 17
6.4.8 R-FUNC-RER-08 IR Format for RERC-5 to RERC-7 . 17
6.4.9 R-FUNC-RER-09 Timing Constraints for RERC-1 to RERC-7 . 17
6.4.10 R-FUNC-RER-10 Platform Independency for RERC-5 to RERC-7 . 18
ETSI
---------------------- Page: 5 ----------------------
SIST EN 303 641 V1.1.2:2020
4 ETSI EN 303 641 V1.1.2 (2020-06)
6.4.11 R-FUNC-RER-11 Radio Application for RERC-5 to RERC-7 . 18
6.4.12 R-FUNC-RER-12 Function Granularity for RERC-1 to RERC-7 . 18
6.4.13 R-FUNC-RER-13 Radio Virtual Machine for RERC-2 to RERC-7 . 18
6.4.14 R-FUNC-RER-14 Radio Virtual Machine Structure for RERC-2 to RERC-7 . 18
6.4.15 R-FUNC-RER-15 Selection of Radio Virtual Machine Protection Class for RERC-2 to RERC-7 . 18
6.4.16 R-FUNC-RER-16 Distributed Computations for RERC-5, RERC-6, RERC-7 . 19
6.5 Radio Frequency (RF) Transceiver Requirements . 20
6.5.0 General . 20
6.5.1 R-FUNC-RFT-01 RF Configuration for RERC-1 to RERC-7 . 20
6.5.2 R-FUNC-RFT-02 Extendibility for multiple-antenna system for RERC-1 to RERC-7 . 20
6.5.3 R-FUNC-RFT-03 Capability of multiple frequency bands for RERC-1 to RERC-7. 20
6.5.4 R-FUNC-RFT-04 Reconfigurability of RF Transceiver for RERC-1 to RERC-7 . 20
6.5.5 R-FUNC-RFT-05 Interoperability of radio resources for RERC-2 to RERC-7 . 20
6.5.6 R-FUNC-RFT-06 Testability of radio equipment for RERC-1 to RERC-7 . 20
6.5.7 R-FUNC-RFT-07 Unified representation of control information for RERC-1 to RERC-7 . 20
6.5.8 R-FUNC-RFT-08 Unified representation of data payload for RERC-1 to RERC-7 . 21
6.5.9 R-FUNC-RFT-09 Selection of RF Protection Class for RERC-1 to RERC-7 . 21
6.6 Security Requirements . 21
6.6.0 General . 21
6.6.1 R-FUNC-SEC-01 REConfPol-RAP-Security . 21
6.6.2 R-FUNC-SEC-02 Administration-Security . 21
6.6.3 R-FUNC-SEC-03 Secure Management . 21
6.6.4 R-FUNC-SEC-04 Root of Trust . 22
History . 23
ETSI
---------------------- Page: 6 ----------------------
SIST EN 303 641 V1.1.2:2020
5 ETSI EN 303 641 V1.1.2 (2020-06)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 (https://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.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
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: 9 June 2020
Date of latest announcement of this EN (doa): 30 September 2020
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 March 2021
Date of withdrawal of any conflicting National Standard (dow): 31 March 2021
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "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: 7 ----------------------
SIST EN 303 641 V1.1.2:2020
6 ETSI EN 303 641 V1.1.2 (2020-06)
1 Scope
The scope of the present document is to define the high level system requirements for reconfigurable Radio Equipment
enabling the provision of Radio Applications except for reconfigurable mobile devices which are covered in ETSI
EN 302 969 [i.4], ETSI EN 303 095 [i.5], ETSI EN 303 146 parts 1 [i.6] to 4 [i.9]. The work is based on the Use Cases
defined in ETSI TR 103 062 [i.1], ETSI TR 102 944 [i.2], ETSI TR 103 585 [i.3] and ETSI EN 302 969 [i.4].
2 References
2.1 Normative 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
https://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.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative 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.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
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".
[i.3] ETSI TR 103 585: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration
use cases".
[i.4] ETSI EN 302 969: "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
Requirements for Mobile Devices".
[i.5] ETSI EN 303 095: "Reconfigurable Radio Systems (RRS); Radio reconfiguration related
architecture for Mobile Devices (MD)".
[i.6] ETSI EN 303 146-1: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 1: Multiradio Interface (MURI)".
[i.7] ETSI EN 303 146-2: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 2: Reconfigurable Radio Frequency Interface (RRFI)".
[i.8] ETSI EN 303 146-3: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 3: Unified Radio Application Interface (URAI)".
ETSI
---------------------- Page: 8 ----------------------
SIST EN 303 641 V1.1.2:2020
7 ETSI EN 303 641 V1.1.2 (2020-06)
[i.9] ETSI EN 303 146-4: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 4: Radio Programming Interface (RPI)".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
distributed computations: model in which components located on networked computers communicate and coordinate
their actions by passing messages interacting with each other in order to achieve a common goal
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.
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.
ETSI
---------------------- Page: 9 ----------------------
SIST EN 303 641 V1.1.2:2020
8 ETSI EN 303 641 V1.1.2 (2020-06)
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, and
laptops.
reconfigurable radio equipment: radio equipment with radio communication capabilities providing support for radio
reconfiguration
NOTE: Reconfigurable radio equipment includes smartphones, feature phones, tablets, laptops, connected vehicle
communication platform, network platform, IoT device, etc.
resources: hardware resources that a radio application needs in active state
NOTE 1: Resources are provided by the reconfigurable Radio Equipment (RE), 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 RE.
NOTE 2: Resources may include processors, accelerators, memory, Radio Frequency circuitry, etc.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
BER Bit Error Rate
CAT CATegory
CR Cognitive Radio
FB Functional Block
FEC Forward Error Correction
FFT Fast Fourier Transform
HAL Hardware Abstraction Layer
IoT Internet of Things
IR Intermediate Representation
LTE Long Term Evolution
MAC Media Access Control
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
RE Radio Equipment
RERC Radio Equipment Reconfiguration Class
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
ETSI
---------------------- Page: 10 ----------------------
SIST EN 303 641 V1.1.2:2020
9 ETSI EN 303 641 V1.1.2 (2020-06)
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
4 Requirement Organization and Methodology
4.0 General
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.
Figure 1: Overall requirements structure
ETSI
---------------------- Page: 11 ----------------------
SIST EN 303 641 V1.1.2:2020
10 ETSI EN 303 641 V1.1.2 (2020-06)
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.
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 the terms as described in the clause</br>
"Modal verbs terminology" above.</br>
5 Working assumptions</br>
5.1 Assumptions</br>
5.1.1 Radio Equipment Reconfiguration Classes</br>
As it is expected that the reconfiguration capabilities of a Radio Equipment will evolve over time, Radio Equipment</br>
Reconfiguration Classes (RERC) are introduced. As shown in Figure 2, 7 different classes of reconfigurable RE are</br>
introduced (RERC-0 corresponds to a non-reconfigurable device).</br>
ETSI</br>
</br>
---------------------- Page: 12 ----------------------</br>
SIST EN 303 641 V1.1.2:2020</br>
</br>
11 ETSI EN 303 641 V1.1.2 (2020-06)</br>
</br>
Figure 2: Definition of RERCs according to reconfiguration capabilities</br>
A reconfigurable RE 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 RE classes are</br>
defined as follows (see also Figure 2):</br>
1) RERC-0: No RE reconfiguration is possible.</br>
RERC-0 represents legacy radio implementations and do not allow for RE reconfiguration (except for bug fixing and</br>
release-updates through firmware updates) or exploitation of Cognitive Radio (CR) features. RERC-0 represents legacy</br>
radio implementations and does not allow for RE reconfiguration.</br>
2) RERC-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) technology,</br>
e.g. with dedicated Application Specific Integrated Circuits (ASICs), and are Resource-wise independent of each other.</br>
Simple CR functionality may be supported through radio parameter management to the extent which the radio</br>
implementations allow. RERC-1 implements multiple Radio Applications with fixed Resources allocation and no</br>
Resource sharing.</br>
The rule for Resource allocation for multiple applications {A , A , …, A } can be formulated as follows: A → R ,</br>
1 2 N i i</br>
∀i∈{1, ., N}, where R denotes Resources allocated for application A and R ∩ R = ∅ for ∀i ≠ j. Note that</br>
i i i j</br>
applications can be run concurrently in any combination; a Resource allocation mechanism within separate applications</br>
is not specified.</br>
3) RERC-2: Radio Applications use pre-defined static Resources.</br>
RERC-2 implements multiple Radio Applications but no dynamic Resource management is available. The Radio</br>
Applications for RERC-2 come from a single Radio Application Package which is normally provided by a</br>
reconfigurable RE vendor or SDR chipset manufacturer. In this scenario, it is assumed that software radio components</br>
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 follows:</br>
1 2 N</br>
A →R , ∀i∈{1, ., N}, where R denotes Resources allocated for application A , if ∃ i ≠ j so that R ∩ R ≠ ∅ then su</br>
<b>...</b>
ETSI EN 303 641 V1.1.2 (2020-06)
EUROPEAN STANDARD
Reconfigurable Radio Systems (RRS);
Radio Equipment (RE) reconfiguration requirements
---------------------- Page: 1 ----------------------
2 ETSI EN 303 641 V1.1.2 (2020-06)
Reference
REN/RRS-0226
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/standards-search
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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
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.
© ETSI 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 2 ----------------------
3 ETSI EN 303 641 V1.1.2 (2020-06)
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 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Requirement Organization and Methodology . 9
4.0 General . 9
4.1 Requirement Organization. 9
4.2 Requirement Format . 10
4.3 Requirement Formulation . 10
5 Working assumptions . 10
5.1 Assumptions . 10
5.1.1 Radio Equipment 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 RERC-1 to RERC-7 . 13
6.1.2 R-FUNC-RAT–02 Function for RERC-1 to RERC-7 . 13
6.1.3 R-FUNC-RAT–03 Function for RERC-1 to RERC-7 . 13
6.1.4 R-FUNC-RAT–04 Function for RERC-1 to RERC-7 . 14
6.1.5 R-FUNC-RAT–05 Function for RERC-1 to RERC-7 . 14
6.1.6 R-FUNC-RAT–06 Function for RERC-1 to RERC-7 . 14
6.2 Radio Application Requirements . 14
6.2.0 General . 14
6.2.1 R-FUNC-RA-01 Radio Applications Support for RERC-1 to RERC-7 . 14
6.2.2 R-FUNC-RA-02 Composition for RERC-1 to RERC-7 . 14
6.2.3 R-FUNC-RA-03 Concurrency for RERC-1 to RERC-7 . 14
6.2.4 R-FUNC-RA-04 Data for RERC-1 to RERC-7 . 14
6.2.5 R-FUNC-RA-05 Context Information for RERC-1 to RERC-7 . 14
6.2.6 R-FUNC-RA-06 Pipelining for RERC-2 to RERC-7 . 15
6.3 Radio Application Functional Block Requirements . 15
6.3.1 R-FUNC-FB-01 Implementation for RERC-2 to RERC-7 . 15
6.3.2 R-FUNC-FB-02 Execution for RERC-2 to RERC-7 . 15
6.3.3 R-FUNC-FB-03 Side Effects for RERC-2 to RERC-7 . 16
6.3.4 R-FUNC-FB-04 Shared Data for RERC-2 to RERC-7 . 16
6.3.5 R-FUNC-FB-05 Concurrency for RERC-2 to RERC-7 . 16
6.3.6 R-FUNC-FB-06 Extendibility for RERC-2 to RERC-7 . 16
6.4 Radio Equipment Reconfiguration Requirements . 16
6.4.1 R-FUNC-RER-01 Platform-specific Executable Code for RERC-2, RERC-3 or RERC-4 . 16
6.4.2 R-FUNC-RER-02 Platform-independent Source Code or IR for RERC-5, RERC-6 or RERC-7 . 16
6.4.3 R-FUNC-RER-03 Radio Configuration of Platform RERC-1 to RERC-7 . 17
6.4.4 R-FUNC-RER-04 Radio Programming for RERC-1 to RERC-7 . 17
6.4.5 R-FUNC-RER-05 Dynamic Execution for RERC-4, and RERC-7 . 17
6.4.6 R-FUNC-RER-06 Independency on Memory Model for RERC-1 to RERC-7 . 17
6.4.7 R-FUNC-RER-07 Code for RERC-2 to RERC-7 . 17
6.4.8 R-FUNC-RER-08 IR Format for RERC-5 to RERC-7 . 17
6.4.9 R-FUNC-RER-09 Timing Constraints for RERC-1 to RERC-7 . 17
6.4.10 R-FUNC-RER-10 Platform Independency for RERC-5 to RERC-7 . 18
ETSI
---------------------- Page: 3 ----------------------
4 ETSI EN 303 641 V1.1.2 (2020-06)
6.4.11 R-FUNC-RER-11 Radio Application for RERC-5 to RERC-7 . 18
6.4.12 R-FUNC-RER-12 Function Granularity for RERC-1 to RERC-7 . 18
6.4.13 R-FUNC-RER-13 Radio Virtual Machine for RERC-2 to RERC-7 . 18
6.4.14 R-FUNC-RER-14 Radio Virtual Machine Structure for RERC-2 to RERC-7 . 18
6.4.15 R-FUNC-RER-15 Selection of Radio Virtual Machine Protection Class for RERC-2 to RERC-7 . 18
6.4.16 R-FUNC-RER-16 Distributed Computations for RERC-5, RERC-6, RERC-7 . 19
6.5 Radio Frequency (RF) Transceiver Requirements . 20
6.5.0 General . 20
6.5.1 R-FUNC-RFT-01 RF Configuration for RERC-1 to RERC-7 . 20
6.5.2 R-FUNC-RFT-02 Extendibility for multiple-antenna system for RERC-1 to RERC-7 . 20
6.5.3 R-FUNC-RFT-03 Capability of multiple frequency bands for RERC-1 to RERC-7. 20
6.5.4 R-FUNC-RFT-04 Reconfigurability of RF Transceiver for RERC-1 to RERC-7 . 20
6.5.5 R-FUNC-RFT-05 Interoperability of radio resources for RERC-2 to RERC-7 . 20
6.5.6 R-FUNC-RFT-06 Testability of radio equipment for RERC-1 to RERC-7 . 20
6.5.7 R-FUNC-RFT-07 Unified representation of control information for RERC-1 to RERC-7 . 20
6.5.8 R-FUNC-RFT-08 Unified representation of data payload for RERC-1 to RERC-7 . 21
6.5.9 R-FUNC-RFT-09 Selection of RF Protection Class for RERC-1 to RERC-7 . 21
6.6 Security Requirements . 21
6.6.0 General . 21
6.6.1 R-FUNC-SEC-01 REConfPol-RAP-Security . 21
6.6.2 R-FUNC-SEC-02 Administration-Security . 21
6.6.3 R-FUNC-SEC-03 Secure Management . 21
6.6.4 R-FUNC-SEC-04 Root of Trust . 22
History . 23
ETSI
---------------------- Page: 4 ----------------------
5 ETSI EN 303 641 V1.1.2 (2020-06)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 (https://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.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
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: 9 June 2020
Date of latest announcement of this EN (doa): 30 September 2020
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 March 2021
Date of withdrawal of any conflicting National Standard (dow): 31 March 2021
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "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 303 641 V1.1.2 (2020-06)
1 Scope
The scope of the present document is to define the high level system requirements for reconfigurable Radio Equipment
enabling the provision of Radio Applications except for reconfigurable mobile devices which are covered in ETSI
EN 302 969 [i.4], ETSI EN 303 095 [i.5], ETSI EN 303 146 parts 1 [i.6] to 4 [i.9]. The work is based on the Use Cases
defined in ETSI TR 103 062 [i.1], ETSI TR 102 944 [i.2], ETSI TR 103 585 [i.3] and ETSI EN 302 969 [i.4].
2 References
2.1 Normative 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
https://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.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative 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.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
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".
[i.3] ETSI TR 103 585: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration
use cases".
[i.4] ETSI EN 302 969: "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
Requirements for Mobile Devices".
[i.5] ETSI EN 303 095: "Reconfigurable Radio Systems (RRS); Radio reconfiguration related
architecture for Mobile Devices (MD)".
[i.6] ETSI EN 303 146-1: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 1: Multiradio Interface (MURI)".
[i.7] ETSI EN 303 146-2: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 2: Reconfigurable Radio Frequency Interface (RRFI)".
[i.8] ETSI EN 303 146-3: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 3: Unified Radio Application Interface (URAI)".
ETSI
---------------------- Page: 6 ----------------------
7 ETSI EN 303 641 V1.1.2 (2020-06)
[i.9] ETSI EN 303 146-4: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 4: Radio Programming Interface (RPI)".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
distributed computations: model in which components located on networked computers communicate and coordinate
their actions by passing messages interacting with each other in order to achieve a common goal
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.
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.
ETSI
---------------------- Page: 7 ----------------------
8 ETSI EN 303 641 V1.1.2 (2020-06)
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, and
laptops.
reconfigurable radio equipment: radio equipment with radio communication capabilities providing support for radio
reconfiguration
NOTE: Reconfigurable radio equipment includes smartphones, feature phones, tablets, laptops, connected vehicle
communication platform, network platform, IoT device, etc.
resources: hardware resources that a radio application needs in active state
NOTE 1: Resources are provided by the reconfigurable Radio Equipment (RE), 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 RE.
NOTE 2: Resources may include processors, accelerators, memory, Radio Frequency circuitry, etc.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
BER Bit Error Rate
CAT CATegory
CR Cognitive Radio
FB Functional Block
FEC Forward Error Correction
FFT Fast Fourier Transform
HAL Hardware Abstraction Layer
IoT Internet of Things
IR Intermediate Representation
LTE Long Term Evolution
MAC Media Access Control
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
RE Radio Equipment
RERC Radio Equipment Reconfiguration Class
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
ETSI
---------------------- Page: 8 ----------------------
9 ETSI EN 303 641 V1.1.2 (2020-06)
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
4 Requirement Organization and Methodology
4.0 General
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.
Figure 1: Overall requirements structure
ETSI
---------------------- Page: 9 ----------------------
10 ETSI EN 303 641 V1.1.2 (2020-06)
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.
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 the terms as described in the clause</br>
"Modal verbs terminology" above.</br>
5 Working assumptions</br>
5.1 Assumptions</br>
5.1.1 Radio Equipment Reconfiguration Classes</br>
As it is expected that the reconfiguration capabilities of a Radio Equipment will evolve over time, Radio Equipment</br>
Reconfiguration Classes (RERC) are introduced. As shown in Figure 2, 7 different classes of reconfigurable RE are</br>
introduced (RERC-0 corresponds to a non-reconfigurable device).</br>
ETSI</br>
</br>
---------------------- Page: 10 ----------------------</br>
11 ETSI EN 303 641 V1.1.2 (2020-06)</br>
</br>
Figure 2: Definition of RERCs according to reconfiguration capabilities</br>
A reconfigurable RE 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 RE classes are</br>
defined as follows (see also Figure 2):</br>
1) RERC-0: No RE reconfiguration is possible.</br>
RERC-0 represents legacy radio implementations and do not allow for RE reconfiguration (except for bug fixing and</br>
release-updates through firmware updates) or exploitation of Cognitive Radio (CR) features. RERC-0 represents legacy</br>
radio implementations and does not allow for RE reconfiguration.</br>
2) RERC-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) technology,</br>
e.g. with dedicated Application Specific Integrated Circuits (ASICs), and are Resource-wise independent of each other.</br>
Simple CR functionality may be supported through radio parameter management to the extent which the radio</br>
implementations allow. RERC-1 implements multiple Radio Applications with fixed Resources allocation and no</br>
Resource sharing.</br>
The rule for Resource allocation for multiple applications {A , A , …, A } can be formulated as follows: A → R ,</br>
1 2 N i i</br>
∀i∈{1, ., N}, where R denotes Resources allocated for application A and R ∩ R = ∅ for ∀i ≠ j. Note that</br>
i i i j</br>
applications can be run concurrently in any combination; a Resource allocation mechanism within separate applications</br>
is not specified.</br>
3) RERC-2: Radio Applications use pre-defined static Resources.</br>
RERC-2 implements multiple Radio Applications but no dynamic Resource management is available. The Radio</br>
Applications for RERC-2 come from a single Radio Application Package which is normally provided by a</br>
reconfigurable RE vendor or SDR chipset manufacturer. In this scenario, it is assumed that software radio components</br>
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 follows:</br>
1 2 N</br>
A →R , ∀i∈{1, ., N}, where R denotes Resources allocated for application A , if ∃ i ≠ j so that R ∩ R ≠ ∅ then such</br>
i i i i i j</br>
applications cannot be run concurrently, all other combinations are allowed; a Resource allocation mechanism within</br>
separate applications is not specified.</br>
4) RERC-3: Radio Applications have static Resource requirements.</br>
ETSI</br>
</br>
---------------------- Page: 11 ----------------------</br>
12 ETSI EN 303 641 V1.1.2 (2020-06)</br>
For RERC-3, a Resource budget is defined for each Radio Application. This budget contains a static Resource measure</br>
that represents the worst-case Resource usage of the application, generated at Radio Application compile-time. If an</br>
application is being started, the Resource manager installed in a reconfigurable RE of RERC-3 checks its Resource</br>
budget and the sum of all Resource budgets of already running applications, and admits the new application only if the</br>
Resources can still be guaranteed for all running applications. In this scenario, it is assumed that software radio</br>
components in the Radio Application Package are provided in platform-specific executable code.</br>
The r</br>
<b>...</b>
Draft ETSI EN 303 641 V1.1.2 (2020-03)
EUROPEAN STANDARD
Reconfigurable Radio Systems (RRS);
Radio Equipment (RE) reconfiguration requirements
---------------------- Page: 1 ----------------------
2 Draft ETSI EN 303 641 V1.1.2 (2020-03)
Reference
REN/RRS-0226
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/standards-search
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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
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.
© ETSI 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 2 ----------------------
3 Draft ETSI EN 303 641 V1.1.2 (2020-03)
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 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Requirement Organization and Methodology . 9
4.0 General . 9
4.1 Requirement Organization. 9
4.2 Requirement Format . 10
4.3 Requirement Formulation . 10
5 Working assumptions . 10
5.1 Assumptions . 10
5.1.1 Radio Equipment 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 RERC-1 to RERC-7 . 13
6.1.2 R-FUNC-RAT–02 Function for RERC-1 to RERC-7 . 13
6.1.3 R-FUNC-RAT–03 Function for RERC-1 to RERC-7 . 13
6.1.4 R-FUNC-RAT–04 Function for RERC-1 to RERC-7 . 14
6.1.5 R-FUNC-RAT–05 Function for RERC-1 to RERC-7 . 14
6.1.6 R-FUNC-RAT–06 Function for RERC-1 to RERC-7 . 14
6.2 Radio Application Requirements . 14
6.2.0 General . 14
6.2.1 R-FUNC-RA-01 Radio Applications Support for RERC-1 to RERC-7 . 14
6.2.2 R-FUNC-RA-02 Composition for RERC-1 to RERC-7 . 14
6.2.3 R-FUNC-RA-03 Concurrency for RERC-1 to RERC-7 . 14
6.2.4 R-FUNC-RA-04 Data for RERC-1 to RERC-7 . 14
6.2.5 R-FUNC-RA-05 Context Information for RERC-1 to RERC-7 . 14
6.2.6 R-FUNC-RA-06 Pipelining for RERC-2 to RERC-7 . 15
6.3 Radio Application Functional Block Requirements . 15
6.3.1 R-FUNC-FB-01 Implementation for RERC-2 to RERC-7 . 15
6.3.2 R-FUNC-FB-02 Execution for RERC-2 to RERC-7 . 15
6.3.3 R-FUNC-FB-03 Side Effects for RERC-2 to RERC-7 . 16
6.3.4 R-FUNC-FB-04 Shared Data for RERC-2 to RERC-7 . 16
6.3.5 R-FUNC-FB-05 Concurrency for RERC-2 to RERC-7 . 16
6.3.6 R-FUNC-FB-06 Extendibility for RERC-2 to RERC-7 . 16
6.4 Radio Equipment Reconfiguration Requirements . 16
6.4.1 R-FUNC-RER-01 Platform-specific Executable Code for RERC-2, RERC-3 or RERC-4 . 16
6.4.2 R-FUNC-RER-02 Platform-independent Source Code or IR for RERC-5, RERC-6 or RERC-7 . 17
6.4.3 R-FUNC-RER-03 Radio Configuration of Platform RERC-1 to RERC-7 . 17
6.4.4 R-FUNC-RER-04 Radio Programming for RERC-1 to RERC-7 . 17
6.4.5 R-FUNC-RER-05 Dynamic Execution for RERC-4, and RERC-7 . 17
6.4.6 R-FUNC-RER-06 Independency on Memory Model for RERC-1 to RERC-7 . 17
6.4.7 R-FUNC-RER-07 Code for RERC-2 to RERC-7 . 17
6.4.8 R-FUNC-RER-08 IR Format for RERC-5 to RERC-7 . 18
6.4.9 R-FUNC-RER-09 Timing Constraints for RERC-1 to RERC-7 . 18
6.4.10 R-FUNC-RER-10 Platform Independency for RERC-5 to RERC-7 . 18
ETSI
---------------------- Page: 3 ----------------------
4 Draft ETSI EN 303 641 V1.1.2 (2020-03)
6.4.11 R-FUNC-RER-11 Radio Application for RERC-5 to RERC-7 . 18
6.4.12 R-FUNC-RER-12 Function Granularity for RERC-1 to RERC-7 . 18
6.4.13 R-FUNC-RER-13 Radio Virtual Machine for RERC-2 to RERC-7 . 18
6.4.14 R-FUNC-RER-14 Radio Virtual Machine Structure for RERC-2 to RERC-7 . 18
6.4.15 R-FUNC-RER-15 Selection of Radio Virtual Machine Protection Class for RERC-2 to RERC-7 . 18
6.4.16 R-FUNC-RER-16 Distributed Computations for RERC-5, RERC-6, RERC-7 . 20
6.5 Radio Frequency (RF) Transceiver Requirements . 20
6.5.0 General . 20
6.5.1 R-FUNC-RFT-01 RF Configuration for RERC-1 to RERC-7 . 20
6.5.2 R-FUNC-RFT-02 Extendibility for multiple-antenna system for RERC-1 to RERC-7 . 20
6.5.3 R-FUNC-RFT-03 Capability of multiple frequency bands for RERC-1 to RERC-7. 20
6.5.4 R-FUNC-RFT-04 Reconfigurability of RF Transceiver for RERC-1 to RERC-7 . 20
6.5.5 R-FUNC-RFT-05 Interoperability of radio resources for RERC-2 to RERC-7 . 20
6.5.6 R-FUNC-RFT-06 Testability of radio equipment for RERC-1 to RERC-7 . 20
6.5.7 R-FUNC-RFT-07 Unified representation of control information for RERC-1 to RERC-7 . 21
6.5.8 R-FUNC-RFT-08 Unified representation of data payload for RERC-1 to RERC-7 . 21
6.5.9 R-FUNC-RFT-09 Selection of RF Protection Class for RERC-1 to RERC-7 . 21
6.6 Security Requirements . 21
6.6.0 General . 21
6.6.1 R-FUNC-SEC-01 REConfPol-RAP-Security . 21
6.6.2 R-FUNC-SEC-02 Administration-Security . 21
6.6.3 R-FUNC-SEC-03 Secure Management . 22
6.6.4 R-FUNC-SEC-04 Root of Trust . 22
History . 23
ETSI
---------------------- Page: 4 ----------------------
5 Draft ETSI EN 303 641 V1.1.2 (2020-03)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 (https://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.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
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", "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 303 641 V1.1.2 (2020-03)
1 Scope
The scope of the present document is to define the high level system requirements for reconfigurable Radio Equipment
enabling the provision of Radio Applications except for reconfigurable mobile devices which are covered in ETSI
EN 302 969 [i.4], ETSI EN 303 095 [i.5], ETSI EN 303 146 parts 1 [i.6] to 4 [i.9]. The work is based on the Use Cases
defined in ETSI TR 103 062 [i.1], ETSI TR 102 944 [i.2], ETSI TR 103 585 [i.3] and ETSI EN 302 969 [i.4].
2 References
2.1 Normative 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
https://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.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative 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.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
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".
[i.3] ETSI TR 103 585: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration
use cases".
[i.4] ETSI EN 302 969: "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
Requirements for Mobile Devices".
[i.5] ETSI EN 303 095: "Reconfigurable Radio Systems (RRS); Radio reconfiguration related
architecture for Mobile Devices (MD)".
[i.6] ETSI EN 303 146-1: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 1: Multiradio Interface (MURI)".
[i.7] ETSI EN 303 146-2: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 2: Reconfigurable Radio Frequency Interface (RRFI)".
[i.8] ETSI EN 303 146-3: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 3: Unified Radio Application Interface (URAI)".
ETSI
---------------------- Page: 6 ----------------------
7 Draft ETSI EN 303 641 V1.1.2 (2020-03)
[i.9] ETSI EN 303 146-4: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 4: Radio Programming Interface (RPI)".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
distributed computations: model in which components located on networked computers communicate and coordinate
their actions by passing messages interacting with each other in order to achieve a common goal
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.
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.
ETSI
---------------------- Page: 7 ----------------------
8 Draft ETSI EN 303 641 V1.1.2 (2020-03)
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, and
laptops.
reconfigurable radio equipment: radio equipment with radio communication capabilities providing support for radio
reconfiguration
NOTE: Reconfigurable radio equipment includes smartphones, feature phones, tablets, laptops, connected vehicle
communication platform, network platform, IoT device, etc.
resources: hardware resources that a radio application needs in active state
NOTE 1: Resources are provided by the reconfigurable Radio Equipment (RE), 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 RE.
NOTE 2: Resources may include processors, accelerators, memory, Radio Frequency circuitry, etc.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
BER Bit Error Rate
CAT CATegory
CR Cognitive Radio
FB Functional Block
FEC Forward Error Correction
FFT Fast Fourier Transform
HAL Hardware Abstraction Layer
IoT Internet of Things
IR Intermediate Representation
LTE Long Term Evolution
MAC Media Access Control
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
RE Radio Equipment
RERC Radio Equipment Reconfiguration Class
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
ETSI
---------------------- Page: 8 ----------------------
9 Draft ETSI EN 303 641 V1.1.2 (2020-03)
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
4 Requirement Organization and Methodology
4.0 General
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.
Figure 1: Overall requirements structure
ETSI
---------------------- Page: 9 ----------------------
10 Draft ETSI EN 303 641 V1.1.2 (2020-03)
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.
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 the terms as described in the clause</br>
"Modal verbs terminology" above.</br>
5 Working assumptions</br>
5.1 Assumptions</br>
5.1.1 Radio Equipment Reconfiguration Classes</br>
As it is expected that the reconfiguration capabilities of a Radio Equipment will evolve over time, Radio Equipment</br>
Reconfiguration Classes (RERC) are introduced. As shown in Figure 2, 7 different classes of reconfigurable RE are</br>
introduced (RERC-0 corresponds to a non-reconfigurable device).</br>
ETSI</br>
</br>
---------------------- Page: 10 ----------------------</br>
11 Draft ETSI EN 303 641 V1.1.2 (2020-03)</br>
</br>
Figure 2: Definition of RERCs according to reconfiguration capabilities</br>
A reconfigurable RE 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 RE classes are</br>
defined as follows (see also Figure 2):</br>
1) RERC-0: No RE reconfiguration is possible.</br>
RERC-0 represents legacy radio implementations and do not allow for RE reconfiguration (except for bug fixing and</br>
release-updates through firmware updates) or exploitation of Cognitive Radio (CR) features. RERC-0 represents legacy</br>
radio implementations and does not allow for RE reconfiguration.</br>
2) RERC-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) technology,</br>
e.g. with dedicated Application Specific Integrated Circuits (ASICs), and are Resource-wise independent of each other.</br>
Simple CR functionality may be supported through radio parameter management to the extent which the radio</br>
implementations allow. RERC-1 implements multiple Radio Applications with fixed Resources allocation and no</br>
Resource sharing.</br>
The rule for Resource allocation for multiple applications {A , A , …, A } can be formulated as follows: A → R ,</br>
1 2 N i i</br>
∀i∈{1, ., N}, where R denotes Resources allocated for application A and R ∩ R = ∅ for ∀i ≠ j. Note that</br>
i i i j</br>
applications can be run concurrently in any combination; a Resource allocation mechanism within separate applications</br>
is not specified.</br>
3) RERC-2: Radio Applications use pre-defined static Resources.</br>
RERC-2 implements multiple Radio Applications but no dynamic Resource management is available. The Radio</br>
Applications for RERC-2 come from a single Radio Application Package which is normally provided by a</br>
reconfigurable RE vendor or SDR chipset manufacturer. In this scenario, it is assumed that software radio components</br>
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 follows:</br>
1 2 N</br>
A →R , ∀i∈{1, ., N}, where R denotes Resources allocated for application A , if ∃ i ≠ j so that R ∩ R ≠ ∅ then such</br>
i i i i i j</br>
applications cannot be run concurrently, all other combinations are allowed; a Resource allocation mechanism within</br>
separate applications is not specified.</br>
4) RERC-3: Radio Applications have static Resource requirements.</br>
ETSI</br>
</br>
---------------------- Page: 11 ----------------------</br>
12 Draft ETSI EN 303 641 V1.1.2 (2020-03)</br>
For RERC-3, a Resource budget is defined for each Radio Application. This budget contains a static Resource measure</br>
that represents the worst-case Resource usage of the application, generated at Radio Application compile-time. If an</br>
application is being started, the Resource manager installed in a reconfigurable RE of RERC-3 checks its Resource</br>
budget and the sum of all Resource budgets of already running applications, and admits the new application only if the</br>
Resources can still be guarante</br>
<b>...</b>
SLOVENSKI STANDARD
oSIST prEN 303 641 V1.1.2:2020
01-junij-2020
Radijski sistemi z možnostjo preoblikovanja (RRS) - Zahteve za rekonfiguracijo
radijske opreme (RE)
Reconfigurable Radio Systems (RRS) - Radio Equipment (RE) reconfiguration
requirements
Ta slovenski standard je istoveten z: ETSI EN 303 641 V1.1.2 (2020-03)
ICS:
33.060.01 Radijske komunikacije na Radiocommunications in
splošno general
oSIST prEN 303 641 V1.1.2:2020 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
oSIST prEN 303 641 V1.1.2:2020
---------------------- Page: 2 ----------------------
oSIST prEN 303 641 V1.1.2:2020
Draft ETSI EN 303 641 V1.1.2 (2020-03)
EUROPEAN STANDARD
Reconfigurable Radio Systems (RRS);
Radio Equipment (RE) reconfiguration requirements
---------------------- Page: 3 ----------------------
oSIST prEN 303 641 V1.1.2:2020
2 Draft ETSI EN 303 641 V1.1.2 (2020-03)
Reference
REN/RRS-0226
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/standards-search
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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
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.
© ETSI 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 4 ----------------------
oSIST prEN 303 641 V1.1.2:2020
3 Draft ETSI EN 303 641 V1.1.2 (2020-03)
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 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Requirement Organization and Methodology . 9
4.0 General . 9
4.1 Requirement Organization. 9
4.2 Requirement Format . 10
4.3 Requirement Formulation . 10
5 Working assumptions . 10
5.1 Assumptions . 10
5.1.1 Radio Equipment 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 RERC-1 to RERC-7 . 13
6.1.2 R-FUNC-RAT–02 Function for RERC-1 to RERC-7 . 13
6.1.3 R-FUNC-RAT–03 Function for RERC-1 to RERC-7 . 13
6.1.4 R-FUNC-RAT–04 Function for RERC-1 to RERC-7 . 14
6.1.5 R-FUNC-RAT–05 Function for RERC-1 to RERC-7 . 14
6.1.6 R-FUNC-RAT–06 Function for RERC-1 to RERC-7 . 14
6.2 Radio Application Requirements . 14
6.2.0 General . 14
6.2.1 R-FUNC-RA-01 Radio Applications Support for RERC-1 to RERC-7 . 14
6.2.2 R-FUNC-RA-02 Composition for RERC-1 to RERC-7 . 14
6.2.3 R-FUNC-RA-03 Concurrency for RERC-1 to RERC-7 . 14
6.2.4 R-FUNC-RA-04 Data for RERC-1 to RERC-7 . 14
6.2.5 R-FUNC-RA-05 Context Information for RERC-1 to RERC-7 . 14
6.2.6 R-FUNC-RA-06 Pipelining for RERC-2 to RERC-7 . 15
6.3 Radio Application Functional Block Requirements . 15
6.3.1 R-FUNC-FB-01 Implementation for RERC-2 to RERC-7 . 15
6.3.2 R-FUNC-FB-02 Execution for RERC-2 to RERC-7 . 15
6.3.3 R-FUNC-FB-03 Side Effects for RERC-2 to RERC-7 . 16
6.3.4 R-FUNC-FB-04 Shared Data for RERC-2 to RERC-7 . 16
6.3.5 R-FUNC-FB-05 Concurrency for RERC-2 to RERC-7 . 16
6.3.6 R-FUNC-FB-06 Extendibility for RERC-2 to RERC-7 . 16
6.4 Radio Equipment Reconfiguration Requirements . 16
6.4.1 R-FUNC-RER-01 Platform-specific Executable Code for RERC-2, RERC-3 or RERC-4 . 16
6.4.2 R-FUNC-RER-02 Platform-independent Source Code or IR for RERC-5, RERC-6 or RERC-7 . 17
6.4.3 R-FUNC-RER-03 Radio Configuration of Platform RERC-1 to RERC-7 . 17
6.4.4 R-FUNC-RER-04 Radio Programming for RERC-1 to RERC-7 . 17
6.4.5 R-FUNC-RER-05 Dynamic Execution for RERC-4, and RERC-7 . 17
6.4.6 R-FUNC-RER-06 Independency on Memory Model for RERC-1 to RERC-7 . 17
6.4.7 R-FUNC-RER-07 Code for RERC-2 to RERC-7 . 17
6.4.8 R-FUNC-RER-08 IR Format for RERC-5 to RERC-7 . 18
6.4.9 R-FUNC-RER-09 Timing Constraints for RERC-1 to RERC-7 . 18
6.4.10 R-FUNC-RER-10 Platform Independency for RERC-5 to RERC-7 . 18
ETSI
---------------------- Page: 5 ----------------------
oSIST prEN 303 641 V1.1.2:2020
4 Draft ETSI EN 303 641 V1.1.2 (2020-03)
6.4.11 R-FUNC-RER-11 Radio Application for RERC-5 to RERC-7 . 18
6.4.12 R-FUNC-RER-12 Function Granularity for RERC-1 to RERC-7 . 18
6.4.13 R-FUNC-RER-13 Radio Virtual Machine for RERC-2 to RERC-7 . 18
6.4.14 R-FUNC-RER-14 Radio Virtual Machine Structure for RERC-2 to RERC-7 . 18
6.4.15 R-FUNC-RER-15 Selection of Radio Virtual Machine Protection Class for RERC-2 to RERC-7 . 18
6.4.16 R-FUNC-RER-16 Distributed Computations for RERC-5, RERC-6, RERC-7 . 20
6.5 Radio Frequency (RF) Transceiver Requirements . 20
6.5.0 General . 20
6.5.1 R-FUNC-RFT-01 RF Configuration for RERC-1 to RERC-7 . 20
6.5.2 R-FUNC-RFT-02 Extendibility for multiple-antenna system for RERC-1 to RERC-7 . 20
6.5.3 R-FUNC-RFT-03 Capability of multiple frequency bands for RERC-1 to RERC-7. 20
6.5.4 R-FUNC-RFT-04 Reconfigurability of RF Transceiver for RERC-1 to RERC-7 . 20
6.5.5 R-FUNC-RFT-05 Interoperability of radio resources for RERC-2 to RERC-7 . 20
6.5.6 R-FUNC-RFT-06 Testability of radio equipment for RERC-1 to RERC-7 . 20
6.5.7 R-FUNC-RFT-07 Unified representation of control information for RERC-1 to RERC-7 . 21
6.5.8 R-FUNC-RFT-08 Unified representation of data payload for RERC-1 to RERC-7 . 21
6.5.9 R-FUNC-RFT-09 Selection of RF Protection Class for RERC-1 to RERC-7 . 21
6.6 Security Requirements . 21
6.6.0 General . 21
6.6.1 R-FUNC-SEC-01 REConfPol-RAP-Security . 21
6.6.2 R-FUNC-SEC-02 Administration-Security . 21
6.6.3 R-FUNC-SEC-03 Secure Management . 22
6.6.4 R-FUNC-SEC-04 Root of Trust . 22
History . 23
ETSI
---------------------- Page: 6 ----------------------
oSIST prEN 303 641 V1.1.2:2020
5 Draft ETSI EN 303 641 V1.1.2 (2020-03)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 (https://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.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
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", "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: 7 ----------------------
oSIST prEN 303 641 V1.1.2:2020
6 Draft ETSI EN 303 641 V1.1.2 (2020-03)
1 Scope
The scope of the present document is to define the high level system requirements for reconfigurable Radio Equipment
enabling the provision of Radio Applications except for reconfigurable mobile devices which are covered in ETSI
EN 302 969 [i.4], ETSI EN 303 095 [i.5], ETSI EN 303 146 parts 1 [i.6] to 4 [i.9]. The work is based on the Use Cases
defined in ETSI TR 103 062 [i.1], ETSI TR 102 944 [i.2], ETSI TR 103 585 [i.3] and ETSI EN 302 969 [i.4].
2 References
2.1 Normative 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
https://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.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative 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.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
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".
[i.3] ETSI TR 103 585: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration
use cases".
[i.4] ETSI EN 302 969: "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
Requirements for Mobile Devices".
[i.5] ETSI EN 303 095: "Reconfigurable Radio Systems (RRS); Radio reconfiguration related
architecture for Mobile Devices (MD)".
[i.6] ETSI EN 303 146-1: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 1: Multiradio Interface (MURI)".
[i.7] ETSI EN 303 146-2: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 2: Reconfigurable Radio Frequency Interface (RRFI)".
[i.8] ETSI EN 303 146-3: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 3: Unified Radio Application Interface (URAI)".
ETSI
---------------------- Page: 8 ----------------------
oSIST prEN 303 641 V1.1.2:2020
7 Draft ETSI EN 303 641 V1.1.2 (2020-03)
[i.9] ETSI EN 303 146-4: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 4: Radio Programming Interface (RPI)".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
distributed computations: model in which components located on networked computers communicate and coordinate
their actions by passing messages interacting with each other in order to achieve a common goal
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.
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.
ETSI
---------------------- Page: 9 ----------------------
oSIST prEN 303 641 V1.1.2:2020
8 Draft ETSI EN 303 641 V1.1.2 (2020-03)
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, and
laptops.
reconfigurable radio equipment: radio equipment with radio communication capabilities providing support for radio
reconfiguration
NOTE: Reconfigurable radio equipment includes smartphones, feature phones, tablets, laptops, connected vehicle
communication platform, network platform, IoT device, etc.
resources: hardware resources that a radio application needs in active state
NOTE 1: Resources are provided by the reconfigurable Radio Equipment (RE), 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 RE.
NOTE 2: Resources may include processors, accelerators, memory, Radio Frequency circuitry, etc.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
BER Bit Error Rate
CAT CATegory
CR Cognitive Radio
FB Functional Block
FEC Forward Error Correction
FFT Fast Fourier Transform
HAL Hardware Abstraction Layer
IoT Internet of Things
IR Intermediate Representation
LTE Long Term Evolution
MAC Media Access Control
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
RE Radio Equipment
RERC Radio Equipment Reconfiguration Class
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
ETSI
---------------------- Page: 10 ----------------------
oSIST prEN 303 641 V1.1.2:2020
9 Draft ETSI EN 303 641 V1.1.2 (2020-03)
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
4 Requirement Organization and Methodology
4.0 General
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.
Figure 1: Overall requirements structure
ETSI
---------------------- Page: 11 ----------------------
oSIST prEN 303 641 V1.1.2:2020
10 Draft ETSI EN 303 641 V1.1.2 (2020-03)
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.
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 the terms as described in the clause</br>
"Modal verbs terminology" above.</br>
5 Working assumptions</br>
5.1 Assumptions</br>
5.1.1 Radio Equipment Reconfiguration Classes</br>
As it is expected that the reconfiguration capabilities of a Radio Equipment will evolve over time, Radio Equipment</br>
Reconfiguration Classes (RERC) are introduced. As shown in Figure 2, 7 different classes of reconfigurable RE are</br>
introduced (RERC-0 corresponds to a non-reconfigurable device).</br>
ETSI</br>
</br>
---------------------- Page: 12 ----------------------</br>
oSIST prEN 303 641 V1.1.2:2020</br>
11 Draft ETSI EN 303 641 V1.1.2 (2020-03)</br>
</br>
Figure 2: Definition of RERCs according to reconfiguration capabilities</br>
A reconfigurable RE 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 RE classes are</br>
defined as follows (see also Figure 2):</br>
1) RERC-0: No RE reconfiguration is possible.</br>
RERC-0 represents legacy radio implementations and do not allow for RE reconfiguration (except for bug fixing and</br>
release-updates through firmware updates) or exploitation of Cognitive Radio (CR) features. RERC-0 represents legacy</br>
radio implementations and does not allow for RE reconfiguration.</br>
2) RERC-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) technology,</br>
e.g. with dedicated Application Specific Integrated Circuits (ASICs), and are Resource-wise independent of each other.</br>
Simple CR functionality may be supported through radio parameter management to the extent which the radio</br>
implementations allow. RERC-1 implements multiple Radio Applications with fixed Resources allocation and no</br>
Resource sharing.</br>
The rule for Resource allocation for multiple applications {A , A , …, A } can be formulated as follows: A → R ,</br>
1 2 N i i</br>
∀i∈{1, ., N}, where R denotes Resources allocated for application A and R ∩ R = ∅ for ∀i ≠ j. Note that</br>
i i i j</br>
applications can be run concurrently in any combination; a Resource allocation mechanism within separate applications</br>
is not specified.</br>
3) RERC-2: Radio Applications use pre-defined static Resources.</br>
RERC-2 implements multiple Radio Applications but no dynamic Resource management is available. The Radio</br>
Applications for RERC-2 come from a single Radio Application Package which is normally provided by a</br>
reconfigurable RE vendor or SDR chipset manufacturer. In this scenario, it is assumed that software radio components</br>
in the Radio Application Package are provided in platform-specific executable code.</br>
The rule for the Resource all</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.