ETSI TR 103 527 V1.1.1 (2018-07)

TECHNICAL REPORT
SmartM2M;
Virtualized IoT Architectures with Cloud Back-ends

2 ETSI TR 103 527 V1.1.1 (2018-07)

Reference
DTR/SmartM2M-103527
Keywords
cloud, IoT, virtualisation
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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
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 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TR 103 527 V1.1.1 (2018-07)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
Introduction . 6
1 Scope . 8
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 8
3 Definitions and abbreviations . 9
3.1 Definitions . 9
3.2 Abbreviations . 9
4 Rationale for IoT Virtualization . 10
4.1 IoT: towards massive deployments . 10
4.2 Cloud Computing and Virtualization . 10
4.3 The new challenge: combining IoT and Cloud Computing . 11
4.4 Content of the report. 11
5 Some use cases for IoT Virtualization. 12
5.1 Introduction . 12
5.2 Horizontal up and down Auto-Scaling . 12
5.3 No single point of failure . 13
5.4 Data privacy . 13
5.5 The use case selected as a proof-of-concept . 14
6 Cloud Computing features for IoT Virtualization . 15
6.1 Introduction . 15
6.2 Functional requirements . 15
6.2.1 Introduction. 15
6.2.2 Multi-tenancy . 15
6.2.2.1 Definition . 15
6.2.2.2 Comparison with multi-instance architectures . 15
6.2.3 Massive Data processing . 16
6.3 Non-functional requirements . 16
6.3.1 High-throughput . 16
6.3.2 High-availability . 17
6.3.3 Low latency . 18
6.3.3.1 Requirements . 18
6.3.3.2 MapReduce . 18
6.3.3.3 In Memory Databases . 19
6.3.3.4 Edge Computing . 19
6.3.4 Security . 20
6.4 Features in support of virtualized IoT implementations . 20
6.4.1 Microservices . 20
6.4.1.1 Definition . 20
6.4.1.2 Comparison to monolithic architectures. 21
6.4.1.3 Impact on IoT solutions . 21
6.4.1.4 Scaling microservices. 21
6.4.1.5 Providing persistency for microservices . 22
6.4.1.6 Security for microservices . 23
6.4.2 Inter-Process Communication (IPC) in microservices architecture . 23
6.4.2.1 Communication Mechanisms . 23
6.4.2.2 Synchronous IPC communications: RESTful communication . 23
6.4.2.3 Asynchronous IPC communications: Messaging . 24
6.4.2.4 Hybrid IPC communications . 24
ETSI
4 ETSI TR 103 527 V1.1.1 (2018-07)
7 Implications of IoT virtualization . 25
7.1 Introduction . 25
7.2 Microservices for IoT Virtualization . 25
7.2.1 Microservices Architecture . 25
7.2.2 The Microservices Architecture in practice: an example . 26
7.2.3 Relationship of the microservice service HLA to oneM2M . 27
7.3 One High-Level Architecture for IoT Virtualization . 30
7.3.1 Functional Architecture for IoT Virtualization . 30
7.3.2 HLA for IoT Virtualization and oneM2M HLA . 30
8 Conclusions . 33
8.1 Implications . 33
8.2 Lessons Learned . 34
8.3 Recommendations to oneM2M . 34
Annex A: Relationship to big data . 35
Annex B: Relationship with NFV . 38
B.0 Introduction . 38
B.1 Virtualization in the NFV Architecture . 38
B.2 The NFV architecture and the Microservice-based HLA . 39
Annex C: Change History . 41
History . 42

ETSI
5 ETSI TR 103 527 V1.1.1 (2018-07)
List of figures
Figure 1: Options for adoption of Cloud Native solutions .11
Figure 2: Batch and Streaming data processing .16
Figure 3: Achieving high throughput processing of data sets .17
Figure 4: The MapReduce Concept .18
Figure 5: Device Edge .19
Figure 6: Cloud Edge .20
Figure 7: RESTful IPC .23
Figure 8: Asynchronous Messaging IPC .24
Figure 9: Hybrid IPC communications .24
Figure 10: Microservices Architecture for IoT Virtualization .25
Figure 11: Message Flow Example .27
Figure 12: Common Services Functions defined by oneM2M .28
Figure 13: Comparison between the microservices architecture and oneM2M CSF .29
Figure 14: A High-Level Architecture for IoT Virtualization .30
Figure 15: Mapping the Microservice Architecture and oneM2M Common Service Entities .31
Figure 16: An example of implementation options of the microservices HLA .32
Figure A.1: Passive IoT fault detection and isolation module .36
Figure A.2: Fault detection: Outlier data-point .36
Figure A.3: Fault detection: Spike behaviour .37
Figure B.1: High Level NFV Framework .39

ETSI
6 ETSI TR 103 527 V1.1.1 (2018-07)
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 Smart Machine-to-Machine
communications (SmartM2M).
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
In addition to interoperability and security that are two recognized key enablers to the development of large IoT
systems, a new one is emerging as another key condition of success: virtualization. The deployment of IoT systems will
occur not just within closed and secure administrative domains but also over architectures that support the dynamic
usage of resources that are provided by virtualization techniques over cloud back-ends.
This new challenge for IoT requires that the elements of an IoT system can work in a fully interoperable, secure and
dynamically configurable manner with other elements (devices, gateways, storage, etc.) that are deployed in different
operational and contractual conditions. To this extent, the current architectures of IoT will have to be aligned with those
that support the deployment of cloud-based systems (private, public, etc.).
Moreover, these architectures will have to support very diverse and often stringent non-functional requirements such as
scalability, reliability, fault tolerance, massive data, security. This will require very flexible architectures for the
elements (e.g. the application servers) that will support the virtualized IoT services, as well as very efficient and highly
modular implementations that will make a massive usage of Open Source components.
These architectures and these implementations form a new approach to IoT systems and the solutions that the present
document investigates also should be validated: to this extent, a Proof-of-Concept implementation involving a massive
number of virtualized elements has been made.
ETSI
7 ETSI TR 103 527 V1.1.1 (2018-07)
The present document is one of three Technical Reports addressing this issue:
• ETSI TR 103 527 (the present document): "Virtualized IoT Architectures with Cloud Back-ends" (the present
document);
• ETSI TR 103 528 [i.1]: "Landscape for open source and standards for cloud native software for a Virtualized
IoT service layer";
• ETSI TR 103 529 [i.2]: "Virtualized IoT over Cloud back-ends: A Proof of Concept".

ETSI
8 ETSI TR 103 527 V1.1.1 (2018-07)
1 Scope
The present document:
• makes a description of some use cases that benefit from virtualization and outlines which one will be used for
the Proof-of-Concept that is described in depth in ETSI TR 103 529 [i.2];
• addresses the rationale and requirements for the use of virtualization - and of the cloud in general - in support
of IoT systems. It also introduces some features that will be key for the definition and further implementation
of virtualized IoT systems such as microservices;
• provides the identification of new architectural elements (components, mappings, Application Programming
Interfaces (API), etc.) that are required to address IoT on a cloud back-end. In particular, one objective of the
present document is to describe how current IoT nodes e.g. the oneM2M CSE, can be modified and improved
by the introduction of micro-services.
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 TR 103 528: "SmartM2M; Landscape for open source and standards for cloud native
software applicable for a Virtualized IoT service layer", 2018.
[i.2] ETSI TR 103 529: "SmartM2M; IoT over Cloud back-ends: a Proof of Concept", 2018.
[i.3] ITU-T News: "What is 'cloud-native IoT' and why does it matter?", October 2017.
NOTE: Available at http://news.itu.int/what-is-cloud-native-iot-why-does-it-matter/.
[i.4] Amazon Web Services: "What is Auto-scaling".
NOTE: Available at http://docs.aws.amazon.com/autoscaling/latest/userguide/WhatIsAutoScaling.html.
[i.5] Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the
protection of natural persons with regard to the processing of personal data and on the free
movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation).
NOTE: Available at https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=celex%3A32016R0679.
[i.6] Deloitte: "Data Privacy in the cloud", 2016.
NOTE: Available at https://www2.deloitte.com/content/dam/Deloitte/ca/Documents/risk/ca-en-risk-privacy-in-
the-cloud-pov.PDF.
[i.7] ETSI TS 118 101 (V2.10.0): "oneM2M; Functional Architecture (oneM2M TS-0001
version 2.10.0 Release 2)".
ETSI
9 ETSI TR 103 527 V1.1.1 (2018-07)
[i.8] Recommendation ITU-T Y.3600: "Big data - Cloud computing-based requirements and
capabilities", 2015.
[i.9] ETSI GS NFV 002: "Network Functions Virtualisation (NFV); Architectural Framework".
[i.10] ETSI GS NFV-INF 001: "Network Functions Virtualisation (NFV); Infrastructure Overview".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Open Source Software (OSS): computer software that is available in source code form
NOTE: The source code and certain other rights normally reserved for copyright holders are provided under an
open-source license that permits users to study, change, improve and at times also to distribute the
software.
source code: any collection of computer instructions written using some human-readable computer language, usually as
text
standard: output from an SSO
Standards Setting Organization (SSO): any entity whose primary activities are developing, coordinating,
promulgating, revising, amending, reissuing, interpreting or otherwise maintaining standards that address the interests
of a wide base of users outside the standards development organization
NOTE: In the present document, SSO is used equally for both Standards Setting Organization or Standards
Developing Organization (SDO).
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AE Application Entity (in oneM2M)
AMQP Advanced Message Queuing Protocol
API Application Programming Interface
ARM Acorn RISC Machine architecture
BCP Best Common Practices
CAPEX Capital Expenditure
CEP Complex Event Processing
CoAP Constrained Application Protocol
CPU Central Processing Unit
CSC Cloud Service Customer
CSE Common Services Entity (in oneM2M)
CSF Common Service Function
CSP Cloud Service Provider
DDoS Distributed Denial of Service
EU European Union
GDPR Global Data Protection Regulation
HLA High Level Architecture
HTTP HyperText Transfer Protocol
IaaS Infrastructure as a Service
IAM Identity and Access Management
ICT Information and Communication Technology
IoT Internet of Things
IP Internet Protocol
IPC Inter-Process Communication
IPE Interworking Proxy Entity (in oneM2M)
ETSI
10 ETSI TR 103 527 V1.1.1 (2018-07)
ISG Industry Specification Group
IT Information Technology
MANO MANagement and Organization (in NFV)
MQTT Message Queuing Telemetry Transport
NFV Network Function Virtualisation
NFVI NFV Infrastructure
ONAP Open Network Automation Platform
OSM Open Source Mano (in ETSI)
OSS Open Source Software
PaaS Platform as a Service
PoC Proof-of-Concept
PoP Point of Presence
SaaS Software as a Service
SDO Standards Development Organization
SE Service Entity (in oneM2M)
SPOF Single Point Of Failure
SSO Standards Setting Organization
UC Use Case
URI Uniform Resource Identifier
VM Virtual Machine
VNF Virtualized Network Function
4 Rationale for IoT Virtualization
4.1 IoT: towards massive deployments
The focus of IoT in the recent years has been on connecting devices and applications. To this extent, a number of
standards, frameworks, solutions have been developed. Now that the maturation of the industry is progressing rapidly,
IoT is facing to major challenges.
On the one hand, connected devices as well as applications have to be integrated with existing, evolving or entirely new
business processes: this creates the need for very adaptive frameworks that offer the possibility to easily introduce new
applications and to ensure that they are properly connected to the existing enterprise systems, and to process enormous
quantity of data.
One the other hand, IoT systems are transitioning from proof-of-concept deployments or new projects with limited size
and scope towards full-fledge systems. These new systems may require extremely high numbers of connected devices
(thus generating needs for scalability or deployment automation) as well as stringent non-functional requirements (such
as low latency).
In both cases, new IoT systems will require a high degree of availability, adaptability and flexibility. In particular, the
resources used by those systems may have to be very dynamic, both in terms of configuration and run-time flexibility.
The models provided by Cloud Computing, which have been designed upfront with these two requirements in mind,
seem very attractive in this context.
4.2 Cloud Computing and Virtualization
Cloud computing is allowing the provision of very sophisticated capabilities; for computing, storage, analytics, etc.; to
very dynamic and potentially massive number of users. Those capabilities are provided as services
(Platform-as-a-Service, Infrastructure-as-a-Service; Software-as-a-Service; etc.) that provides functional and also non-
functional support (e.g. low latency fault-tolerance, horizontal scalability, cost-optimization, or geo-optimization
together with Service Level Agreements (SLAs), and security.
The technical capabilities of cloud computing technology made it possible to provide the most demanding information
and communication technology (ICT) infrastructures, such as communication networks, from specialized hardware and
software to new software paradigms, referred to as 'cloud-native'.
ETSI
11 ETSI TR 103 527 V1.1.1 (2018-07)

Figure 1: Options for adoption of Cloud Native solutions
The expectation of Cloud-Native applications is to benefit from offerings from Cloud Service Providers (CSP) that may
cover parts or all of the layers of Virtualized application, via Infrastructure as a Service (IaaS), Platform as a Service
(PaaS) or Software as a Service (SaaS). Figure 1 presents the possible usages of such offerings in delegating more and
more important parts of the underlying layers to a third-party in charge of hiding complexity, resource usage, etc.
4.3 The new challenge: combining IoT and Cloud Computing
The IoT industry starts to understand the potential benefits of combining the strengths of both IoT and Cloud industries
in a new value proposition (see [i.3] for example). IoT virtualization - i.e. IoT built on cloud-native principles - is to IoT
platforms as what Network Function Virtualisation (NFV) is to communication networks.
When applied to IoT, virtualization is expected to provide technical benefits such as more flexibility on assigning IoT
virtualized objects and functions to physical resources. Moreover, virtualization should bring as well financial benefits
(e.g. greater CAPEX efficiency) or operational benefits (e.g. improvement of automation and operating procedures)
altogether resulting in boosted service innovation.
The scope of IoT standards and protocols has so far focused on interface specifications and related data models.
Developing IoT platforms that use cloud-native principles will benefit from guidelines and Best Common Practices
(BCP) in building operational grade IT applications using cloud technologies.
The convergence of cloud and IoT is of major important to those (e.g. architects) aiming at building IoT solutions that
can dynamically reach massive scale in support of large IoT deployments, e.g. in Smart Cities. It is of great importance
for technical actors of IoT to benefit from guidelines for IoT virtualization, in particular regarding the 'containerisation'
of IoT applications.
4.4 Content of the report
Clause 5 provides a number of Use Cases (UC) that could benefit from virtualization of IoT. Each UC is described from
a functional standpoint, together with the expectations towards virtualization. Finally, one UC is highlighted since it is
the one that will be selected for implementation (as it is described in ETSI TR 103 529 [i.2]).
Clause 6 of the present document presents the Cloud Computing features that are relevant in the context of IoT
Virtualization. First, some functional requirements are introduced that correspond to specific functionalities that are
(better) supported by Virtualization. Similarly, some non-functional requirements are presented that are expected to be
specially supported through Virtualization. Finally, two key features that will play a key role in architectures and
implementations: microservices and inter-process communications.
Clause 7 investigates the main dimensions that will be addressed in order to define layered architectures supported by
microservices. A reference model for such an architecture is introduced that also serves as a basis for the description of
the "Landscape of Open Source and Standards" that is developed in ETSI TR 103 528 [i.1].
ETSI
12 ETSI TR 103 527 V1.1.1 (2018-07)
Clause 8 summarizes the main finding of the present document and provides a set of recommendations for architects
and developers in charge of potential IoT virtualization projects.
Annex A is addressing the relationship of IoT with Big Data and, in particular, regarding the question of Data Quality
and some potential solutions.
5 Some use cases for IoT Virtualization
5.1 Introduction
This clause introduces a (limited) number of generic Use Cases (UCs) that are illustrative of the expected benefits and
potential challenges of IoT virtualization. There is probably a large number of Use Cases for which a "traditional"
(i.e. non-virtualized) approach can and will apply. However, the introduction of IoT Virtualization is expected to make
some UCs more effective: it would generally improve the efficiency of their implementation or support interoperability
at a more fine-grained level (or both).
For the presentation of UCs, rather than present them based on the needs of a given business domain (aka a "vertical"),
the approach taken is to present the major features outlined by a class of applications in different "verticals". The name
of the UC will refer to the major underlying feature involved (e.g. fault-tolerance, data privacy, etc.).
5.2 Horizontal up and down Auto-Scaling
The amount and type of data transmitted by IoT devices may vary drastically in time depending on some events that can
be internal or external to the virtualized IoT system (e.g. road traffic increase during holiday departure).
A cloud-native IoT platform shall be able to continuously monitor its resources, scale-up its capabilities when needed,
then scale-down to an optimized state to avoid wasting resources. This capability is referred to as "Auto-Scaling" (see
[i.4] for example).
The main objective of Auto Scaling is to ensure that the number of Virtual Machine (VM) instances available for and
used by the virtualized application are optimal at a given time. Practically, a minimum number of VM instances is
defined (lower threshold for the auto-scaling down) as well as a maximum number (upper threshold for the auto-scaling
up). When needed, additional VMs are added (with an increment that can be predefined), used as long as needed and
released when the usage is no longer needed.
This UC can be illustrated by a number of examples taken from various verticals:
• Intelligent Transport Systems with a sudden increase in traffic (e.g. vacations).
• Electrical (Smart) Grids with burst reconnection of IoT devices after a power cut.
• Smart Metering with burst transmission of intelligent meters data at given time slots.
• And many more, etc.
The benefits of Auto Scaling are largely related to the non-functional support it provides to the virtualized applications:
• Improved availability: the virtualized application has, at any time, the best adjusted capacity to deal with the
most complex and hard to predict traffic patterns.
• Improved fault tolerance: when an instance (or a group of) VM(s) does not function properly, Auto-Scaling
allows to quickly terminate it and launch an adequate replacement.
• More effective cost management: thanks to the dynamic increase and decrease of the needed capacity, the
usage is constantly adjusted to reduce the consumption, hence the cost, of the computing resources.
ETSI
13 ETSI TR 103 527 V1.1.1 (2018-07)
5.3 No single point of failure
Like every other ICT systems, IoT systems can be built with one or more Single Point(s) Of Failure (SPOF). A SPOF is
the results of a flaw in the design, implementation or configuration of the system. It introduces a potentially very high
risk since one fault or malfunction may cause the entire system to stop operating. As an example, IoT servers and
gateways can be a SPOF in an IoT system: in a poorly designed architecture, when a server or a gateway goes down,
critical functions may stop.
Preventing that catastrophic outcome is possible, as long as the architects and designers can identify the SPOFs that
appear in the system's design and implement corrective measures - as long as this is both feasible and cost-effective.
The techniques that make this possible are largely based on clustering and replication. In principle, such techniques are
supported by a cloud-native IoT architecture and supported by the major cloud infrastructure providers.
Consequently, the possibility of providing this kind of support will be a major support for a large number of Use Cases
in a very large array of vertical domains. Some examples of such verticals and related UCs and related are shown
below:
• Health Care: remote patient examination, monitoring and surgery.
• Emergency Services: allowing Emergency Management Teams to access patient records while on the road.
• Railway systems: improved signalling with reliable communications and better integration with system.
• And many more, etc.
Cloud Computing is often seen as a way to avoid the single points of failure with built-in redundancy or clustering
services. It is important to note that Auto-Scaling is adding to the effectiveness of redundancy (by allowing to quickly
terminate malfunctioning VMs and launch an adequate replacement, as noted above) and is an important element in the
process of fixing the SPOFs in the cloud.
However, IoT Virtualization is not an absolute panacea, in the sense that there are still SPOFs that may be associated to
the use of Cloud Computing resources. An example of such SPOF is a centralized (and not replicated) monitoring
function that may be compromised in case of malicious attack (e.g. DDoS). Similarly, the possibility of the failure of
one cloud provider is another example of SPOF. So, architects and developers of Virtualized IoT systems will still have
to ensure that all SPOFs are identified and corrected, but it is expected that their number will be lower than in
"traditional" (non-virtualized) IoT systems.
5.4 Data privacy
Potentially, a wide range of IoT applications are impacted by data privacy and the need for Data Protection. The amount
of data that IoT devices can generate is enormous (with billions of data points created every day) and is leaving a lot of
this information vulnerable and susceptible to malicious usage (by hackers in the extreme case, but also by unauthorized
competitors).
IoT virtualization is also impacted by the question of data privacy. For instance, when a Cloud Service Provider (CSP)
is used, it is important to ensure that the data belonging to the Cloud Service Customer (CSC) is well protected by the
CSP that provides the Cloud service used by the CSC. In general, the inability to address these problems may create a
lack of trust that, in turn, may reduce the consumers' appetite for purchasing connected products, and prevent the IoT
from fulfilling its true potential.
The data privacy Use Case can be illustrated by a number of examples taken from various verticals:
• Electrical Smart Grids: collection of user data and anonymization.
• Agriculture: exchange of data between equipment, private storage of field information (crop, etc.).
• Connected cars: security coming together with guaranteed privacy policies.
• And many more, etc.
ETSI
14 ETSI TR 103 527 V1.1.1 (2018-07)
The reliance of IoT systems on the use of data and the potential issues associated to its management (and protection)
have increased the need for ensuring that information is well protected by guaranteed safeguards with a good level of
transparency. The question of privacy is going to be shaped by the General Data Protection Regulation (GDPR [i.5])
that is about to enter in force in Europe. GDPR is harmonising the current data protection regulations across EU
member states, with strict data compliance stipulations and potential huge financial penalties for those when the rules
are breached.
GDPR is not dealing specifically with Cloud Service Providers, but it has implications for organizations that use cloud
services to store data. As stated in [i.6], "[.], the adoption of cloud computing raises challenges in the face of new, and
often competing, privacy regulations across various jurisdictions, as well as evolving cybersecurity threats. For
example, organizations that rely on multiple cloud service providers may have little or no control over the movement of
their data through different data centres around the world. Similarly, it is not always clear whether the data custodian
or the third-party service provider is accountable to protect the data, or which sets of data protection laws apply".
GDPR will have a significant impact on the Cloud Computing industry, especially on Cloud Service Providers who will
have to provide a significantly higher level of transparency about the elements of their internal sub-structures that have
legal significance (e.g. vis-à-vis Third-Party subcontractors).
As such, the consequences of the introduction of GDPR [i.5] on the architectures of IoT systems are not yet fully
understood. At this stage, it is not clear yet whether or not virtualization (and the use of microservices in particular) will
improve the way privacy is currently handled. An example of such questions is multi-tenancy: on the one hand,
virtualization can help by providing different IP addresses to access the data of different tenants (thus better protecting
one tenant's data against - potentially malevolent - access to data from other tenants) whereas, on the other hand, multi-
tenancy can be provided without separating the databases of two different tenants. Overall, the answer to the question
will depend on the architecture choices and, even more importantly, on the implementation. Altogether, though the
impact of GDPR is expected to be significant on IoT virtualization, it is probably too early to assess it, specially via a
PoC.
5.5 The use case selected as a proof-of-concept
A Proof-of-concept (PoC) of IoT Virtualization is developed in ETSI TR 103 529 [i.2]. This PoC is an implementation
of the "Horizontal Up and Down Auto-Scaling" Use Case described above.
The main reason for the choice of this UC is that it demonstrates the feasibility of IoT Virtualization on a "real-life" Use
Case applicable to a large number of "verticals". Auto-Scaling has been seen, in the examples above, as a very critical
feature in virtualized IoT: the PoC is also a way to validate its applicability to IoT systems. In addition, it also makes
use of a great number of the Open Source Software components that are described in ETSI TR 103 528 [i.1].
It can be noted that the use of Auto-Scaling may not always be necessary in dealing with burst situations. However,
indications to developers on the concrete use of this technique in a real implementation is useful, and it is an additional
rational for its selection in the Proof-of-Concept (see ETSI TR 103 529 [i.2]).
Beyond the validation of the basic concepts that are implemented in the PoC (e.g. microservices based architecture,
layered architectural model), it is important to consider that - in a "real-life" implementation context - the auto-scaling
decision mechanism itself may be a differentiating factor, and therefore the possibility to implement Artificial
Intelligence-based "auto-scaling". To this extent, though the "auto-scaling" features in the PoC are implemented with a
"traditional" algorithmic approach where decisions are calculated on the basis of (more or less) hard-coded rules, the
description of the PoC architecture makes room for the possible usage of:
• Monitoring functions that may allow human to use additional rules; or
• Artificial Intelligence
...