ETSI TR 103 529 V1.1.1 (2018-08)

ETSI TR 103 529 V1.1.1 (2018-08)






TECHNICAL REPORT
SmartM2M;
IoT over Cloud back-ends:
A Proof of Concept

---------------------- Page: 1 ----------------------
2 ETSI TR 103 529 V1.1.1 (2018-08)



Reference
DTR/SmartM2M-103529
Keywords
cloud, IoT, open source, proof of concept,
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

---------------------- Page: 2 ----------------------
3 ETSI TR 103 529 V1.1.1 (2018-08)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
4 Virtualization of IoT: A Proof-of-Concept. 8
4.1 Virtualized IoT and Cloud-Native Computing . 8
4.2 The rationale for a Proof-of-Concept . 8
4.3 Content of the report. 9
5 Main elements of the Proof-of-Concept . 9
5.1 The Use Case . 9
5.2 High-Level Architecture . 10
5.3 Technical choices . 10
5.4 Message flow . 11
5.5 Auto scaling up and down . 12
6 Implementation . 12
6.1 Initial Deployment architecture . 12
6.2 Set-up of the PoC Deployment Infrastructure . 13
6.2.1 Installation of the Kubernetes cluster. 13
6.2.1.1 Introduction . 13
TM
6.2.1.2 Utilization of Google Cloud Kubernetes Engine . 13
6.2.1.3 Installation from scratch . 14
6.2.2 Installation of the IoT Components . 17
6.2.3 Horizontal autoscaling . 18
7 Conclusions . 19
7.1 Introduction . 19
7.2 Lessons Learned and Recommendations . 19
Annex A: Change History . 20
History . 21

ETSI

---------------------- Page: 3 ----------------------
4 ETSI TR 103 529 V1.1.1 (2018-08)
List of figures
Figure 1: PoC High level architecture .10
Figure 2: Open source components in the Proof-of-Concept .11
Figure 3: Message Flow in the Proof-of-Concept .11
Figure 4: Kubernetes Horizontal Pod Autoscaler (HPA) architecture .12
Figure 5: PoC initial deployment architecture .13

ETSI

---------------------- Page: 4 ----------------------
5 ETSI TR 103 529 V1.1.1 (2018-08)
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 this STF will
investigate will also have to be validated: to this extent, a Proof-of-Concept implementation involving a massive
number of virtualized elements will be made.
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TR 103 529 V1.1.1 (2018-08)
The present document is one of three Technical Reports addressing this issue:
• ETSI TR 103 527 [i.1]: "SmartM2M; Virtualized IoT Architectures with Cloud Back-ends".
• ETSI TR 103 528 [i.2]: "Landscape for open source and standards for cloud native software for a Virtualized
IoT service layer".
• ETSI TR 103 529 (the present document): "IoT over Cloud back-ends: A Proof of Concept".

ETSI

---------------------- Page: 6 ----------------------
7 ETSI TR 103 529 V1.1.1 (2018-08)
1 Scope
The present document:
• Recalls the main elements of the Proof-of-Concept (PoC) in support of IoT Virtualization: use case
description, high-level architecture of the application developed, main technical choices.
• Presents the main implementation choices.
• Outlines the lessons learned and the possible impact of future IoT Virtualization implementations.
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 527: "SmartM2M; Virtualized IoT Architectures with Cloud Back-ends".
[i.2] ETSI TR 103 528: "SmartM2M; Landscape for open source and standards for cloud native
software applicable for a Virtualized IoT service layer".
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
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TR 103 529 V1.1.1 (2018-08)
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 Organizations (SDO).
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programming Interface
CPU Central Processing Unit
CSE Common Service Entity (in oneM2M)
CSP Cloud Service Provider
EOF End Of File
HLA High-Level Architecture
HPA Horizontal Pod Autoscaler
IaaS Infrastructure as a Service
NFS Network File System
OSS Open Source Software
PaaS Platform as a Service
PoC Proof of Concept
RAM Random Access Memory
RC Replication Controller
REST REpresentational State Transfer
SaaS Software as a Service
SDO Standards Development Organization
SSH Secure SHell
SSO Standards Setting Organization
STF Specialist Task Force
VM Virtual Machine
YAML YAML Ain't Markup Language
4 Virtualization of IoT: A Proof-of-Concept
4.1 Virtualized IoT and Cloud-Native Computing
The IoT industry has started to understand and evaluate the potential benefits of Cloud-Native Computing for the fast,
effective and future-safe development of IoT systems combining the strengths of both IoT and Cloud industries in a
new value proposition. The expectation of Cloud-Native applications is to benefit from offerings from Cloud Service
Providers (CSP) that may cover all or part of the layers of Virtualized application, via Infrastructure as a Service (IaaS),
Platform as a Service (PaaS) or Software as a Service (SaaS).
In the case of IoT applications, the trade-off between what is delegated to the Cloud Service Provider and what is kept
in the hands of the application developers may vary depending a large number of potential factors and will finally
materialize into different architecture, design and implementation choices.
The approach of Cloud-Native Computing is now widely supported by a large set of technologies embedded in Cloud-
Native Infrastructures in support of Cloud-Native Applications. These technologies are now very diverse, technology-
ready (as shown in the landscape of Open Source components described in ETSI TR 103 528 [i.2]) and support all the
layers of a Micro-Service Architecture (such as the one described in ETSI TR 103 527 [i.1]).
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TR 103 529 V1.1.1 (2018-08)
4.2 The rationale for a Proof-of-Concept
As pointed out in ETSI TR 103 527 [i.1], "there is probably a large number of [IoT] 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 Use Cases more effective: it would generally improve the efficiency of their implementation or support
interoperability at a more fine-grained level (or both)".
The Cloud-Native Computing technologies have been made much easier to apprehend, to master and to package into
more and more complex systems. However, the effective usage of the vast catalogue of components potentially
applicable for IoT Virtualization is still under evaluation in the IoT community.
The Proof-of-concept (PoC) of IoT Virtualization exposed in the present report is an implementation of the "Horizontal
Up and Down Auto-Scaling" Use Case which has been selected in ETSI TR 103 527 [i.1] as a well-adapted example for
the following reasons:
• It demonstrates the feasibility of IoT Virtualization on a "real-life" Use Case applicable to a large number of
sectors (aka "verticals").
• It addresses a feature (auto-scaling) that is being deemed as very critical in virtualized IoT and for which an
implementation via the use of "off-the-shelf" Open Source Software components requires some validation.
• It makes use of a great number of the Open Source Software components described in ETSI TR 103 528 [i.2].
4.3 Content of the report
Clause 5 outlines the main elements for the definition, design and implementation of the selected Use Case, mostly the
High-Level Architecture, the main Open Source components selected and the message flow.
Clause 6 describes the initial deployment architecture and explains the steps to be followed for the set-up of the
deployment infrastructure.
Clause 7 outlines the main lessons learned from the implementation and provides a few basic recommendations.
5 Main elements of the Proof-of-Concept
5.1 The Use Case
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 will 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.
The main objective of Auto Scaling is to ensure that the number of Virtual Machine (VM) instances
...