1. ETSI Contribution to 3rd Meeting of EC Expert Group on RRS
Dr. Markus Mueck, Chairman ETSI TC RRS
8 February 2018

2. Overview ETSI effort to collect Use Cases, Classes and Categories
Following the provision of a first set of proposed Use Cases to the 2nd meeting of EG RRS, an updated set of proposed Use Cases is propoved in the present document

3. ETSI effort to collect Use Cases, Classes and Categories
Related to the activity of the EC Expert Group on RRS, ETSI has invited all of its Technical Bodies to provide
Use Cases
Categories or Classes
ETSI is currently collecting further inputs. Additional contributions are expected.
Following the provision of an initial set of Use Cases for the 2nd EG RRS meeting, an updated set is provided in this document.

4. Commercial Equipment
The following initial set of commercial Use Cases is proposed:
Use Case C1 – Smartphone Reconfiguration
… Beyond the provisioning of additional modules, it is also possible to replace entire RATs in case those sufficient computational resources are available.
ETSI builds test specifications on 3GPP specifications, and therefore 3GPP use cases and equipment classes and categories should be considered.
Reconfiguration can also be a remote software update of a device after it is already deployed e.g. to perform an update to a new 3GPP feature
Example: Secure environment such as the UICC or the new Smart Secure Platform (SSP)
This requires: i) Verifying the Integrity and Authenticity of the new software; ii) Mutual Authentication between the device and the software provider or the service provider who performs the software update.
The next generation technology SSP (Smart Secure Platform), successor of SIM/UICC currently developed in ETSI, will allow to implement security services not only on a removable or embedded Secure Element, but also on an integrated Secure Environment of a System on Chip (SoC) and could be extended to any kind of device/equipment where updates of e.g. the firmware, need to be protected.

5. Commercial Equipment Use Case C2 – Internet-of-Things product design
… a limited number of generic and reconfigurable components will be made available which are suitably tailored to the target market through software components.
Use Case C3 – Automotive Applications
… Software Reconfiguration will enable Manufacturers to replace specific Software and thus maintain related feature-sets up-to-date without requiring changes to the hardware.
NOTE: The upper Use Cases are in accordance with the ETSI White Paper on SW Reconfiguration and Annex 2 of the TCAM SDR Final Report (EG RRS (01)05; TCAM WG (11)25).

6. Commercial Equipment Additional Details on Automotive Applications
Context: In order to understand the need for SW Reconfiguration affecting the compliance of equipment to the RED, it is proposed to consider the requirement of vehicular communication modules to remain relevant over the life-time of a vehicle, which can be 10 years or more for a mass-market car , 25 years or more for commercial vehicles or even more than 25 years for traffic infrastructure.
Update of Feature Sets: Mobile communication specifications are expected to evolve substantially over time. To give an example, 3GPP provides new Releases every 2-3 years including a substantial extension of feature sets. In this Use Case, a wireless communication platform which is already deployed in the market is able to receive feature updates through SW Updates affecting the compliance of the wireless equipment to the essential requirements of the RED. In a typical example, critical new safety related features are provided to vehicles which are already in the field.
Mitigation of Vulnerabilities and Implementation Issues: Vehicular communication equipment may be the object of malicious attacks. Typically, vulnerabilities or implementation issues may be exploited for this purpose. Once such vulnerabilities or implementation issues are detected, concerned components are replaced through SW Updates affecting the compliance of the wireless equipment to the essential requirements of the RED. Note that the original concerned components may be provided as hardwired and/or SW based solutions.

7. Commercial Equipment Use Case C4 – Cable Systems
A variant that is widely relevant to integrated broadband cable and television networks employs a device with non-radio and radio interfaces, where only the cable network interface is used for loading new software onto the device. The software is monolithic in a sense that all device functions are included in a single software load, such that in order to alter an individual function of the device a complete software load has to be delivered to the device. The mechanism to provide such a software load involves a secured delivery protocol as well as an authorization of the software load from a trusted entity.
In this case, is the secured software delivery mechanism sufficient to protect the radio device?

8. Commercial Equipment Use Case C4 – Cable Systems, Cont’d
 The unique attributes of the device class that we are suggesting above are:
Radio and non-radio interfaces
Software loading over the cable network interface only
Secured delivery protocol and signed software
For illustration purposes, the following example may be considered. The device is a DOCSIS-compliant cable modem with integrated Wi-Fi. The software can only be delivered via the HFC network using the DOCSIS-specified secure software download mechanism.

9. Professional Users applying direct link
Use Case P1 – link-by-link licensed system
Assume a "link-by-link licensed" case, where all parameters subject of the individual license (also other that mere frequency and eirp, such as channel size and reference modulation in "adaptive modulation case") need to be open to the operator/administration according the individual license condition. (HS EN is EN V3.1.1 (OJ published 6/2017), which comprises all Point-to-point FS equipment operating in FS allocated bands from 1.4 to 86 GHz bands)
Equipment needs to remain sufficiently “open” to allow for this usage.

10. General recommendation
General Impact of Device Protection
Implementation of device protection should not adversely affect secure devices, having a minimum of capabilities for cryptographic protection and secret storage. Available resources may not be sufficient any more in case that additional capabilities are needed. Right balance for protection is needed. This may have an impact on sensor networks, smart cities, etc.
(Firmware) Updates (e.g., for bugfixing) of existing equipment should remain possible.

11. General comment
ETSI is in the process of collecting relevant Use Cases, Categories and Classes from its Technical Bodies
NOTE: The final list will rely on input by ETSI members and cannot be guaranteed to be exhaustive.