ETSI TR 103 585 V1.2.1 (2019-11)

Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration use cases

RTR/RRS-0220

General Information

• Status: Published
• Publication Date: 28-Nov-2019
• Technical Committee: RRS 2 - REA - Reconfigurable Radio Equipment Architecture
• Current Stage: 12 - Completion
• Due Date: 02-Dec-2019
• Completion Date: 29-Nov-2019

Standards Content (Sample)

ETSI TR 103 585 V1.2.1 (2019-11)






TECHNICAL REPORT
Reconfigurable Radio Systems (RRS);
Radio Equipment (RE) reconfiguration use cases

---------------------- Page: 1 ----------------------
2 ETSI TR 103 585 V1.2.1 (2019-11)



Reference
RTR/RRS-0220
Keywords
software, use case

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
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 2019.
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 TR 103 585 V1.2.1 (2019-11)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 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 . 7
3.3 Abbreviations . 7
4 Radio Equipment Reconfiguration Use Cases . 7
4.1 Overview . 7
4.2 Use Case "Smartphone Radio Reconfiguration" . 8
4.2.0 General . 8
4.2.1 Scenario "Optimize the operation of Smartphone" . 8
4.2.2 Stakeholders . 8
4.2.3 Information Flow . 9
4.2.3.1 Information Flows for Scenario "Optimize the operation of Smartphone" . 9
4.3 Use Case "Connected Vehicle Radio Reconfiguration" . 10
4.3.0 General . 10
4.3.1 Scenario "Upgrade of Feature-Set" . 10
4.3.2 Scenario "Addressing Vulnerabilities" . 10
4.3.3 Stakeholders . 10
4.3.4 Information Flow . 11
4.3.4.1 Information Flows for Scenario "Upgrade of feature-Set" and "Addressing Vulnerabilities" . 11
4.4 Use Case "Network Radio Reconfiguration" . 12
4.4.0 General . 12
4.4.1 Scenario "Single-Entity Network Radio Reconfiguration" . 12
4.4.2 Scenario "Multiple-Entities Network Radio Reconfiguration" . 12
4.4.3 Stakeholders . 12
4.4.4 Information Flow . 13
4.4.4.1 Information Flows for Scenario "Single-Entity Network Radio Reconfiguration" . 13
4.4.4.2 Information Flows for Scenario "Multiple-Entities Network Radio Reconfiguration" . 14
4.5 Use Case "IoT Device Reconfiguration" . 15
4.5.0 General . 15
4.5.1 Scenario "Optimization by pre-provisioning of a RA at manufacture time" . 15
4.5.2 Scenario "Optimization by downloading of a RA from Radio Apps Store" . 15
4.5.3 Stakeholders . 15
4.5.4 Information Flow . 16
4.5.4.1 Information Flows for Scenario "Optimization by pre-provisioning of a RA at manufacture time" . 16
4.5.4.2 Information Flows for Scenario "Optimization by downloading of a RA from Radio Apps Store" . 17
4.6 Use Case "Radio Reconfiguration through an external Component" . 17
4.6.0 General . 17
4.6.1 Scenario "Standalone external components" . 18
4.6.2 Scenario "Host dependent external component" . 18
4.6.3 Stakeholders . 18
4.6.4 Information Flows . 19
4.6.4.1 Information Flows for Scenario "Standalone external components". 19
4.6.4.2 Information Flows for Scenario "Host dependent external component" . 23
4.7 Use Case "Reconfigurable Satellite Telecom Payload". 24
4.7.1 Introduction. 24
4.7.2 Scenario "Access Links Provisioning" . 25
ETSI

---------------------- Page: 3 ----------------------
4 ETSI TR 103 585 V1.2.1 (2019-11)
4.7.3 Scenario "Regenerator Reconfiguration" . 25
4.7.4 Stakeholders . 26
4.7.5 Information Flows . 26
4.7.5.1 Information Flows for Scenario "Access Links Provisioning" . 26
4.7.5.2 Information Flows for Scenario "Regenerator Reconfiguration" . 26
4.8 Use Case "Bug-fix and security updates" . 27
4.8.1 Introduction. 27
4.8.2 Scenario "Automated Updates" . 27
4.8.3 Scenario "Manual Updates" . 27
4.8.4 Stakeholders . 27
4.8.5 Information Flows . 28
4.8.5.1 Information Flows for Scenario "Automated Updates" . 28
4.8.5.2 Information Flows for Scenario "Manual Updates" . 29
4.9 Use Case "Medical Applications" . 30
4.9.1 Introduction. 30
4.9.2 Scenario "Automated Updates" . 30
4.9.3 Stakeholders . 30
4.9.4 Information Flows . 31
4.9.4.1 Information Flows for Scenario "Automated Updates" . 31
History . 32


ETSI

---------------------- Page: 4 ----------------------
5 ETSI TR 103 585 V1.2.1 (2019-11)
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 Technical Report (TR) has been produced by ETSI Technical Committee Reconfigurable Radio Systems (RRS).
Modal verbs terminology
In the present document "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.
Introduction
The present document provides use cases for radio equipment reconfiguration through software. It extends the use cases
defined in ETSI TR 103 062 [i.7] for mobile device reconfiguration to the more generic framework of radio equipment
reconfiguration.

ETSI

---------------------- Page: 5 ----------------------
6 ETSI TR 103 585 V1.2.1 (2019-11)
1 Scope
The scope of the present document is to define use cases for radio equipment reconfiguration through software.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
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 EN 302 969 (V1.2.1): "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
Requirements for Mobile Devices".
[i.2] ETSI EN 303 095 (V1.2.1): "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
Architecture for Mobile Devices".
[i.3] ETSI EN 303 146-1 (V1.2.1): "Reconfigurable Radio Systems (RRS); Mobile Device Information
Models and Protocols; Part 1: Multiradio Interface (MURI)".
[i.4] ETSI EN 303 146-2 (V1.2.1): "Reconfigurable Radio Systems (RRS); Mobile Device (MD)
information models and protocols; Part 2: Reconfigurable Radio Frequency Interface (RRFI)".
[i.5] ETSI EN 303 146-3 (V1.2.1): "Reconfigurable Radio Systems (RRS); Mobile Device (MD)
information models and protocols; Part 3: Unified Radio Application Interface (URAI)".
[i.6] ETSI EN 303 146-4 (V1.1.2): "Reconfigurable Radio Systems (RRS); Mobile Device (MD)
information models and protocols; Part 4: Radio Programming Interface (RPI)".
[i.7] ETSI TR 103 062 (V1.1.1): "Reconfigurable Radio Systems (RRS); Use Cases and Scenarios for
Software Defined Radio (SDR) Reference Architecture for Mobile Device".
[i.8] Recommendation ITU-R S.1709-1: "Technical characteristics of air interfaces for global
broadband satellite systems".
[i.9] From "Bent Pipes" to "Software Defined Payloads": Evolution and Trends of Satellite
Communications Systems, Piero Angeletti, Riccardo De Gaudenzi and Marco Lisi, June, 2008.
[i.10] IETF RFC 7426: "Software-Defined Networking (SDN): Layers and Architecture Terminology".
[i.11] ETSI GS NFV 002 (V1.1.1): "Network Functions Virtualisation (NFV); Architectural
Framework".
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TR 103 585 V1.2.1 (2019-11)
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
FFT Fast Fourier Transform
FPGA Field Programmable Gate Array
GEO Geostationary Earth Orbit
IoT Internet of Things
LEO Low Earth Orbit
LLC Logic Link Control
MURI Multi Radio Interface
NR New Radio
RA Radio Application
RadioApps Radio Application Store
RAP Radio Application Package
RAT Radio Access Technology
RLC Radio Link Control
RRS Reconfigurable Radio Systems
SCC Satellite Control Center
SDR Software Defined Radio
SW SoftWare
USB Universal Serial Bus
V2X Vehicle to Everything
RF Radio Frequency
RX Receive
TX Transmit
4 Radio Equipment Reconfiguration Use Cases
4.1 Overview
This clause provides some use cases of the SW reconfiguration and related equipment-specific application scenarios.
Use cases considered in this clause are as follows:
• Use Case "Smartphone Radio Reconfiguration" in clause 4.2.
• Use Case "Connected Vehicle Radio Reconfiguration" in clause 4.3.
• Use Case "Network Radio Reconfiguration" in clause 4.4.
• Use Case "IoT Device Reconfiguration" in clause 4.5.
• Use Case "Radio Reconfiguration through an external Component" in clause 4.6.
• Use Case "Reconfigurable Satellite Telecom Payload" in clause 4.7.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TR 103 585 V1.2.1 (2019-11)
• Use Case "Bug-fix and security updates" in clause 4.8.
NOTE: Use Cases given in clauses 4.2, 4.3, 4.4, 4.5, 4.6 and 4.7 are design Use Cases; the Use Case given in
clause 4.8 is a Use Case for achieving a defined purpose.
4.2 Use Case "Smartphone Radio Reconfiguration"
4.2.0 General
The average lifetime of smartphones is substantially shorter (~2 years) compared to other radio equipment (> 2 years)
such as vehicles, base stations, etc. Since smartphones are also generic computing platforms, they are subject to gradual
obsolescence - in terms of computing power - when new use cases and software-based solutions become available.
Therefore, radio reconfiguration use cases corresponding to the evolution of communication standards do not seem to
be a major factor in the case of smartphones. Rather, the scenario of optimizing the operation of smartphones in
accordance to the functional blocks in a given Radio Application code that might be downloaded from RadioApp Stores
will be the main factor determining the use case of the smartphone radio reconfiguration. In this context however, minor
updates to Radio Applications remain critical in order to provide technical corrections and address security
vulnerabilities. RadioApps, provided as the ETSI SW Reconfiguration solutions, extend or modify existing radio
features and define solutions for technical, certification and security needs.
4.2.1 Scenario "Optimize the operation of Smartphone"
In this scenario, the operation of smartphone is optimized using an RA code corresponding to the required functional
block(s) of desired communication protocol(s) downloaded from RadioApp Store upon user’s request. For example, a
LTE smartphone user could update his/her RA code of LTE protocol with a new FFT functional block which, for
instance, utilizes less computational resources compared to the FFT functional block in the given RA code in order to
save the computational complexity. The optimization of smartphone operation is achieved in general by replacing some
functional blocks with new ones or the entire RA code with a new one.
4.2.2 Stakeholders
• End users: the users of the smartphones accessing internet and other similar mobile data services.
• Network operators:
- operate and maintain the required infrastructure;
- might provide information on the availability of new RAP(s) to the end users; might provide the new
RAP(s) to the end users.
• Software Manufacturer: may provide new RAP(s) for optimizing the operation of smartphone.
• National Regulatory Authority: provides framework for certification of new RAP(s) provided by software
manufacturers.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TR 103 585 V1.2.1 (2019-11)
4.2.3 Information Flow
4.2.3.1 Information Flows for Scenario "Optimize the operation of Smartphone"
Access Software Regulation
Smartphone
Network Manufacturer
Administration
Generate new RAP(s)
Required information is
received, which is
necessary for the
regulatory framework
Provide new RAP(s)
ACK/NACK for new
RAP(s)
Upload new RAP(s)
on Radio Apps Store
Request download
of new RAP(s)
Provide new RAP(s)
Reconfigure with
new RAP(s)
Request network access
with new RAP(s)
Grant network access
Completion of
network access with
new RAP(s)

NOTE: The RAP(s) shown in Figure 4.2.3.1-1 is for functional block(s) of desired communication protocol(s) or
entire RAT.

Figure 4.2.3.1-1: Information Flow for Scenario "Optimize the operation of Smartphone"
NOTE: The "required information" for the Regulation Administration is issued by a suitable source. In this
Use Case, no assumption on the responsible party for regulatory compliance is made.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TR 103 585 V1.2.1 (2019-11)
4.3 Use Case "Connected Vehicle Radio Reconfiguration"
4.3.0 General
Since the lifetime of automotive communication components is substantially longer (> 10 years) compared to
smartphones (~2 years), it seems to be necessary for the communication platform in a vehicle to cope with the new
communication standard through the SW reconfiguration. The challenge is to ensure that a radio communications
component remains relevant over the entire life-time of a vehicle, i.e. 10 years and beyond. It is almost certain that a
V2X framework feature-set will evolve within this period. SW Reconfiguration will enable Manufacturers to replace
specific SW and thus maintain related feature-sets up-to-date without requiring changes to the hardware. Accordingly,
the use case for the connected vehicle should be based on the SW reconfiguration of the communication platform in
accordance to the changes in the communication standard being used in vehicular communications.
4.3.1 Scenario "Upgrade of Feature-Set"
It is expected that LTE C-V2X will further evolve towards 5G New Radio based V2X services and beyond.
Consequently, new features will be added by a continued standardization activity. In this scenario, it is assumed that an
initial radio component design will comprise supplementary computational and memory resources which may remain
unused during a first phase; with upcoming new features, however, corresponding software components will be made
available to provide required feature-sets by exploiting those resources. Typically, the resources include FPGA (Field
Programmable Gate Array), DSPs (Digital Signal Processors), memory and other resources.
4.3.2 Scenario "Addressing Vulnerabilities"
Automotive communication components are a likely target for malicious attacks due to the large scale deployment, the
high potential for causing damage through attacks and the long life-time of radio components. Indeed, the life-time
corresponds to the life-time of a vehicle which is typically 10 years or more. It is therefore likely that vulnerabilities
will be identified during this substantial time period. Those vulnerabilities may relate to design choices, protocol
weaknesses, etc. When such a vulnerability is identified, it is essential to modify affected functionalities such that no
damage can be caused to concerned vehicles and persons. Preferably, this modification is implemented on all relevant
vehicles within the shortest time possible. Over-the-Air Software updates are a suitable means to achieve this objective.
4.3.3 Stakeholders
• End users: the users of the connected vehicles accessing internet and other similar mobile data services.
• Network operators:
- operate and maintain the required infrastructure;
- might provide information on the availability of new RAP(s) to the end users; might provide the new
RAP(s) to the end users.
• Vehicle manufacturers: provide information on the availability of new RAP(s) to the network operators; might
provide new RAP(s) to network operators.
• National Regulatory Authority: provides framework for certification of new RAP(s) provided by vehicle
manufacturers.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TR 103 585 V1.2.1 (2019-11)
4.3.4 Information Flow
4.3.4.1 Information Flows for Scenario "Upgrade of feature-Set" and "Addressing
Vulnerabilities"
Connected Access Vehicle Regulation
Vehicle Network Manufacturer Administration
Generate new RAP(s)
Required information is
received, which is
necessary for the
regulatory framework
Provide new RAP(s)
ACK/NACK for new
RAP(s)
Upload new RAP(s)
on Radio Apps Store
Inform availability
of new RAP(s)
Power On
Request download
of new RAP(s)
Provide new RAP(s)
Reconfigure with
new RAP(s)
Request network access
with new RAP(s)
Grant network access
Completion of
network access with
new RAP(s)

Figure 4.3.4.1-1: Information Flow for Scenarios "Upgrade of feature-Set" and
"Addressing Vulnerabilities"
Note that the RAP(s) shown in Figure 4.3.4.1-1 is for upgrade of feature-set or addressing vulnerabilities. A typical
example RAP for the upgrade of feature-set might be a 5G New Radio (NR) protocol that will be available as the
standard of mobile communications evolves from 4G to 5G. A typical example for the addressing vulnerabilities might
be a security-related RAP as a countermeasure against malicious attack(s). It is noteworthy that vehicle manufacturers
rd
not the 3 party software manufacturer provide the RAP in the vehicle use case. The reason being so is that only the
RAP of which the operation is fully verified is provided by vehicle manufacturers in the use case of connected vehicle.
NOTE: The "required information" for the Regulation Administration is issued by a suitable source. In this
Use Case, no assumption on the responsible party for regulatory compliance is made.
ETSI

---------------------- Page: 11 ----------------------
12 ETSI TR 103 585 V1.2.1 (2019-11)
4.4 Use Case "Network Radio Reconfiguration"
4.4.0 General
With the evolution of wireless standards, network functions need to be updated. In this Use Case, the installation of
RadioApps is addressed in order to provide updated or new features which address the radio characteristics of the
network. For example, a new Radio Access Technology may be made available through the installation of a software
component. The installation of a single RAP may be sufficient if the target network functions are provided in a
dedicated, single equipment such as a Small Cell owned by a User. In other cases, network functions are distributed
across a variety of physical entities which all require dedicated software updates for the provisioning of a specific new
service.
Typically, such equipment is then further connected to a larger network, for example through wireless or cabled
backb
...