USER; Quality of ICT services; New QoS approach in a digital ecosystem

DTR/USER-0045

General Information

Status
Not Published
Technical Committee
Current Stage
12 - Completion
Due Date
02-Nov-2020
Completion Date
06-Nov-2020
Ref Project

Buy Standard

Standard
ETSI TR 103 437 V1.1.1 (2020-11) - USER; Quality of ICT services; New QoS approach in a digital ecosystem
English language
30 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

ETSI TR 103 437 V1.1.1 (2020-11)






TECHNICAL REPORT
USER;
Quality of ICT services;
New QoS approach in a digital ecosystem

---------------------- Page: 1 ----------------------
2 ETSI TR 103 437 V1.1.1 (2020-11)



Reference
DTR/USER-0045
Keywords
ICT, QoS, quality, service, SLA, user

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 TR 103 437 V1.1.1 (2020-11)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 6
3.3 Abbreviations . 6
4 User in a digital ecosystem . 7
4.0 New user provisioning approach . 7
4.1 User profile . 7
4.2 Requirements: Service Level Agreement (SLA) . 8
5 Service offered . 9
5.0 As-a-Service environment . 9
5.1 Service definition . 9
5.2 "As-a-Service" properties . 10
5.2.0 "As-a-Service" in the new architecture . 10
5.2.1 Properties related to service structure . 11
5.2.2 Properties related to service interactions . 12
5.2.3 Properties related to service management . 12
5.3 Interfaces . 13
5.4 Functional aspects . 14
5.5 Non-functional aspects: QoS . 15
6 QoS evaluation: New approach . 16
6.0 QoS evaluation model . 16
6.1 Measurable requirements: QoS criteria . 16
6.2 The measure . 18
6.2.0 The measure model . 18
6.2.1 What to measure . 18
6.2.2 When to measure? . 19
6.2.3 Where to measure?. 19
6.2.4 How to measure? . 19
6.3 Calibration . 20
6.3.1 Calibration method . 20
6.3.2 Calibration result: QoS design and threshold values. . 20
7 Requested service . 22
7.1 Service composition . 22
7.2 User end-to-end service . 23
8 Catalogue . 24
8.1 The role of the catalogue . 24
8.2 Example: Automatic Number Plate Recognition System . 25
9 Use cases: service composition in medical warning system . 27
Annex A: Change History . 29
History . 30

ETSI

---------------------- Page: 3 ----------------------
4 ETSI TR 103 437 V1.1.1 (2020-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 User Group (USER).
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
Nowadays, the user is at the centre of the architecture. He has access to any service, from any network and by any
means, from anywhere, all the time.

ETSI

---------------------- Page: 4 ----------------------
5 ETSI TR 103 437 V1.1.1 (2020-11)
1 Scope
The experience of the "Covid-19" recently faced has played a role of accelerating and making users enter definitively
into "the digital era".
On the user side, this meant that in their daily life teleworking, online shopping and a lot of vital and key information
was shared through online social networks. Considering the needed digital services, often used for the first time, the
user became aware of the importance of quality of service and the many factors which contribute to it.
On the supplier side, the role of digital transformation manager was created, directly linked to general management.
Among the new paradigms, the "As-a-Service" is the main driver to support digital transformation. The user wishes to
obtain a personalized service whatever the place they are and whatever their means of access with the corresponding
QoS. The user expects this is also provided "As-a-Service", meeting their needs and not a "best effort" delivery.
The present document proposes a new approach to implement a QoS adapted to the digital ecosystem, with both views
from the user side and from the supplier side.
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 TS 102 827 (V1.1.1) (2008-08): "GRID; Grid Component Model (GCM); GCM
Interoperability Deployment".
[i.2] ETSI TS 102 828 (V2.1.1) (2010-03): "GRID; Grid Component Model (GCM); GCM Application
Description".
[i.3] ETSI TS 102 829 (V1.1.1) (2009-03): "GRID; Grid Component Model (GCM); GCM Fractal
Architecture Description Language (ADL)".
[i.4] ETSI EG 202 009-1 (V1.3.1) (2014-12): "User Group; Quality of telecom services; Part 1:
Methodology for identification of indicators relevant to the Users".
[i.5] ETSI EG 202 009-3 (V1.3.1) (2015-07): "User Group; Quality of ICT services; Part 3: Template
for Service Level Agreements (SLA)".
[i.6] IETF RFC 2617: "HTTP Authentication: Basic and Digest Access Authentication".
[i.7] Lloyd V. ITIL Continual Service Improvement: "The Stationery Office (TSO)". 23 Aug 2011.
ISBN: 9780113313143.
[i.8] ISO/IEC 20000-1:2018: "Information technology -- Service management -- Part 1: Service
management system requirements".
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TR 103 437 V1.1.1 (2020-11)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
InMonitor: component that intercepts incoming service, stores the non-functional information about the requests,
which are then transmitted (unchanged) to the functional component, via the corresponding internal interfaces
micro-service: basic and simple service (with SoA properties) that be combined for the composition of services as
expected by the User
NOTE: The basic concept behind this term is that each service performs a unique feature (e.g. for security,
"authentication" is a micro-service, for discovery, "find" is a micro-service).
OutMonitor: component that intercepts and stores outgoing service requests
profile: information template (model) to provide or to access to personalized services
QoSControl: component that makes the necessary metric analysis and calculations to evaluate the behaviour of the
service component and its conformity with the contract
quality of service: ability of a service to respond by its characteristics to the different needs of its users or consumers
(AFNOR)
service: immaterial performance that can be composed, manifestly displayed and which, in a pre-defined condition of
use, is a source of value for the consumer and the supplier (ISO/IEC 20000-1 [i.8])
3.2 Symbols
For the purposes of the present document, the following symbols apply:
InMonitor Input Monitor
OutMonitor Output Monitor
QoSControl Control of the QoS
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Program Interface
CPU Central Processing Unit
FCAPS Fault, Configuration, Accounting, Performance, Security
GCM Grid Component Model
GDPR General Data Protection Regulation
HMI Human Machine Interface
ICT Information & Communication Technology
IMS IP Multimedia Subsystem
IoT Internet of Things
ISO International Organization for Standardization
ITIL Information Technology Infrastructure Library
LED Light Emitting Device
OpenIMS Open Infrastructure Management System
QoE Quality of Experience
QoS Quality of Service
RAM Random Access Memory
SLA Service Level Agreement
SLO Service Level Objective
SOA Service-Oriented Architecture
TTM Time To Market
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TR 103 437 V1.1.1 (2020-11)
IT Information Technology
IP Internet Protocol
IS Information Systems
4 User in a digital ecosystem
4.0 New user provisioning approach
In a digital ecosystem the provisioning of a wide range of services depends on the orchestration of heterogeneous,
distributed software components, which can be owned by different service providers and operate over diverse networks.
In such a context, designing and providing value-added services, ensuring their nominal quality levels with service
deployment, provisioning, monitoring and management becomes increasingly difficult. Provider resources are shared by
all clients. In the cloud computing context, the outsourcing introduces the need of Service Level Agreement (SLA).
How the mapping between the user demand and the provider supply can be performed?
To answer this problem, the proposed new approach aims to express the user requirements and the provided services
with the same model. The main advantages of this approach are the modelling and the overall management of digital
ecosystem behaviour founded on a new integrated service component that distinguishes itself through a "self-control"
property based on QoS and the "As-a-Service" concept.
4.1 User profile
A good digital user experience is based on always online services, easily accessible anytime and everywhere, on
demand, in real-time, and available in self-service along with a fast helpdesk service response. For the user, that means
a good level of flexibility and control of his digital environment.
In a digital ecosystem the user, according to his level of experience:
• gets the service automatically; or
• makes his choice in the catalogue for a composition of service according to the QoS requested.
USUSERER curscursoror ((llevevelel ooff « « ffrreeedoedomm »»
USEUSERR cucurrssoror ((llevevelel ooff « « ffrreedeedomom »» iin n
iin sn seerrvvice comice composiposittiion)on)
servserviice comce comppoossiittiioonn))
SinSinglegle « « bbuuttttoonn »»
SinSinglegle « « bubuttttoonn »»
TThhe e uuseser fur fullllyy
The user The user ffullyully
EverEveryyththinging is is
EverytEverythinghing is is
ccoompmpoosseses tthhee
ccomomppososeess t thhee
Set-Set-upup
SetSet-u-up p
seservrviicceses
servicesservices
ServService toice to consul consult Tt Travravel el
SServiervice to coce to consult mensult medicdicaall
wwarnarniinng sysg systtemem
-- >> offe offered ared auutomatomaticallytically
-- >> de demamanded bynded by c composomposiittiionon
(S(S11++SS22))
aauthoruthoriizzatiation on (S(S1)1)
mmediediccalal data databasbase ue updatpdate e ( (SS2)2)

Figure 1: User profile
In this context the user services composition can be based on setting, user profile, HMI, QoE and the degree of service
security (authentication, authorization, confidentiality, cryptography, etc.).
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TR 103 437 V1.1.1 (2020-11)
The user profile provides the image of the user defining the user's preference, possibilities and constraints, in a
structured and uniform format. This profile provides an easy access to all necessary data and relevant selection of each
service component according to the user's preference. Each service composition proposed by the provider should be
linked to a user service session.
4.2 Requirements: Service Level Agreement (SLA)
A Service Level Agreement (SLA) is an agreement formally negotiated between two parties.
The SLA serves as a means to formally documenting the service(s), performance expectations, responsibilities and
borders between cloud service providers and their users. It aims to managing service quality through the customer
experience life cycle. This means managing service quality beyond the in-use phase of the life cycle to include sales,
provisioning, in-use phase and service termination aspects.
The objective of the end-to-end QoS is to build and maintain the adequate service over a dedicated user session while
respecting SLA and QoS constraints (Figure 2).

Figure 2: End to end service: conformity with SLA
The SLA parties represent the contracting entities of an SLA contract.
The SLA can be described in two parts:
• The users request their requirements, i.e. SLO and obligation, corresponding to the demand.
• The offer by Cloud provider with the guarantees provided (QoS associated to services offers, penalties)
corresponding to the supply.
On the user side, a SLO aims at expressing the user needs. For example: service is available 7/7 and 24/24, access time
to the application < 1 s in 90 % of cases, a processing time < 2 s if the number of requests per second < 1 000 in 90 %
of cases. The user has the obligation to check the correct functioning of the service.
On the provider side, the services offered are twofold: usage and management. In accordance with the proposed model,
every service component integrates a QoS control. Four criteria are proposed [i.4] to describe the behaviour (QoS):
availability, integrity, time, and capacity.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TR 103 437 V1.1.1 (2020-11)
From the provider point of view, the objective is to meet the required properties based on customer requirements and
needs. In practice, many providers offer the same services that differ in their quality of service levels, price, and in the
way, they are created, deployed, and managed. Therefore, the request and the offer should be entirely and explicitly
documented and guaranteed by the Service Level Agreement (SLA). The approach presented in ETSI
EG 202 009-3 [i.5] allows to model the SLA personalized where user requirements and provider offers converge on a
QoS contract.
5 Service offered
5.0 As-a-Service environment
Digital ecosystem, cloud computing and Internet of Things (IoT) are promising to build a new ecosystem where
everything is provided "As-a-Service". The "As-a-Service" is the main driver to support digital transformation, that can
be translated by "flexibility in the service of business" respecting the quality.
The enterprise should prepare for these changes, which may also require a redesign of its core business, because what
can really lead to success is the design of the customer experience. Quality experiences are based on the customer
empathy, business analysis, and cognitive technologies, all of which can lead to a successful business strategy. It also
means having the ability to meaningfully engage customers and employees, no matter where they are.
This inevitably incorporates the effective use of operational and virtual IT models, which include dynamic provisioning
of the infrastructure, the ability to automatically scale it up, applications in the form of micro-services, and ultimately
"cloudification" of the digital ecosystem.
The services are built through the composition of services that exist today in the enterprises or can be provided by
providers. This approach should be based on:
• designing "As-a-Service";
• building the service by composition; and
• managing it (based on decision-making information).
To comply with the QoS principles, a service should fulfil five important points:
• to be defined through a contract;
• to be evaluated itself through criteria;
• to be measured through significant parameters at each level of visibility;
• to formalize the non-functional aspects of each action;
• to be aggregated for an end-to-end flow.
5.1 Service definition
The service provider is responsible for the creation of a service, to document the functional descriptions in the directory
and to provide the interface. Depending on the level of "freedom wanted by the user" (according to Figure 3) the
composition may be called on in an autonomous way (step by step) or globally (only the final result is provided to the
user).
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TR 103 437 V1.1.1 (2020-11)

•Provider
– « As-a-Service » =>
Micro service
Service profile



– Management Service
– API
– QoS
– Security : GDPR

Figure 3: Service provider
The most important concepts in digital environments are QoS and service composition. This is expected to offer the
maximum number of services among a large set of providers. This means that the following question should be
answered: what can be offered in term of composition (by construction)?
The concepts to achieve maximum provider agility to provide the highest user level of "freedom" in the service
composition are:
• "As-a-Service", micro service, service profile.
• QoS and API (Application Programming Interface) for each micro service and composition.
5.2 "As-a-Service" properties
5.2.0 "As-a-Service" in the new architecture
To better understand the expectations of service creation and management, it is necessary to situate them in the Internet
of Things or Cloud Computing architecture.
The properties of "As-a-Service" components have to comply with a set of requirements. These properties are spread
among the following categories related to:
• The definition of the structure and the formal descriptions of service components, i.e. the nodes themselves.
• The definition or design of the service logic and functional architecture of service components, i.e. the
interactions between the service components.
• The management of the service components.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TR 103 437 V1.1.1 (2020-11)

Figure 4: "As-a-Service" properties
These properties are necessary to design components "as a service" so that from the catalog components can be chosen
and assembled easily. In particular, the structure properties like "stateless" and "mutualization", the "loose link"
property and those of "self-management and ubiquity" management are very important.
5.2.1 Properties related to service structure
Properties related to the service structure are:
• Reuse;
• Mutualization;
• Cohesion;
• Abstraction;
• Invariance;
• Statelessness; and
• Composition.
Reuse: the possibility of reuse is needed to simplify the software development of services that meet the new needs.
Services designed based on this approach and properties (As-a-Service) would be reusable, thanks to the generic
character of their interfaces (usage, control and management). A service component should be reusable to build
different services, in different compositions and different environments.
Mutualization: a service provider should offer the same service component instance As-a-Service to multiple users.
Mutualization stands here for multi-tenancy. Service components should support multi-tenancy in order to be invoked
by multiple users requiring the offered service either simultaneously or not. This reinforces the statelessness and the
loose coupling features. Mutualization requirement calls for a need for loose bindings or connections between service
components to ensure the capacity to provide multiple users and answer multiple service requests autonomously. Thus,
mutualization will help realizing minimum functional coupling and loose coupling between functions.
ETSI

---------------------- Page: 11 ----------------------
12 ETSI TR 103 437 V1.1.1 (2020-11)
Cohesion: service components should be consistent. The service logic offered should be relevant and recognized as a
meaningful business service for potential customers. The service rendered by the component should find all its
functionalities in a logical way internally. This feature could also be called: self-sufficiency, autonomy or even
functional decoupling.
Abstraction: beyond service descriptions that should appear on service catalogues and SLAs, service components
should abstract the internal service logic from outer service environments.
Invariance: a service component should have an identical structure, that would not vary from a level to another in a
hierarchy of service components. That means that the structure is invariant when scalability and elasticity are needed.
Statelessness: a service is stateless if it processes each received request as an independent transaction without any
relationship with the previous ones. A
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.