ETSI GR CIM 002 V1.1.1 (2018-09)

Context Information Management (CIM); Use Cases (UC)

DGR/CIM-002-UC

General Information

• Status: Published
• Publication Date: 06-Sep-2018
• Technical Committee: CIM - cross-cutting Context Information Management
• Current Stage: 12 - Completion
• Due Date: 11-Sep-2018
• Completion Date: 07-Sep-2018

Standards Content (Sample)

GROUP REPORT
Context Information Management (CIM);
Use Cases (UC)
Disclaimer
The present document has been produced and approved by the cross-cutting Context Information Management (CIM) ETSI
Industry Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR CIM 002 V1.1.1 (2018-09)

Reference
DGR/CIM-002-UC
Keywords
API, information model, interoperability, IoT,
smart city, 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 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 GR CIM 002 V1.1.1 (2018-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
4 Introduction . 8
4.1 Introduction to Context Information Management . 8
4.2 Information Sources . 10
4.3 Motivation for developing a Context Information Management System . 11
5 Methodology . 12
5.1 Approach to Documenting Use Cases . 12
5.1.1 Purpose . 12
5.1.2 Assumptions about a C3IM Architecture . 13
5.1.3 Use Case Sections . 13
5.2 Composing Use Cases . 15
5.3 Stakeholders . 15
5.4 Example Entity types. 16
5.4.0 Introduction. 16
5.4.1 Geospatial examples . 16
5.4.2 Provenance Data examples . 17
6 Simplified functional reference architecture . 17
7 Smart City Cross-cutting Use Cases . 18
7.1 Use Case 1 Sharing information between parking management systems and traffic management
applications. 18
7.1.1 Use Case 1 Introduction and Assumptions . 18
7.1.2 Use Case 1 Information Flow Diagram . 19
7.1.3 Use Case 1 Stakeholders . 19
7.1.4 Use Case 1 Agents and Data Source/Sink Entities . 20
7.1.5 Use Case 1 Scenario Descriptions and Data Flows . 21
7.1.5.1 Scenario "A": Routing to closest available parking space taking into account both real-time
availability of individual parking spaces across different parking providers AND street
congestion . 21
7.1.5.2 Scenario "B": exit from parking structure taking local traffic into account . 22
7.1.5.3 Scenario "C": Entry to Private Parking Space Rented on Temporary Basis . 23
7.1.5.4 Scenario "D": Smart Parking Facility Manager Queries . 23
7.1.5.5 Scenario "E": Reserved Parking for Care workers responding to in-home monitor alarm . 23
7.1.6 Use Case 1 Entities instances graph . 24
7.2 Use Case 2: Smart Street Lighting . 24
7.2.1 Use Case 2 Introduction and Assumptions . 24
7.2.2 Use Case 2 Information Flow Diagram . 25
7.2.3 Use Case 2 Stakeholders . 25
7.2.4 Use Case 2 Agents and Data Source/Sink Entities . 26
7.2.5 Use Case 2 Scenario Descriptions and Data Flows . 26
7.2.5.1 Scenario "A": Lighting Levels Depending on Traffic Presence . 26
7.2.5.2 Scenario "B": Lighting Levels Depending on Weather Conditions . 26
7.2.5.3 Scenario "C": Lighting Levels Depending on Traffic Management Decisions . 27
7.2.5.4 Scenario "D": Lighting Levels Depending on Crowdsourced Data . 27
ETSI
4 ETSI GR CIM 002 V1.1.1 (2018-09)
7.2.6 Use Case 2 entity instances graph . 28
7.3 Use Case 3: Traffic Management & Pricing based on Air Quality, Congestion and other KPIs . 28
7.3.1 Use Case 3 Introduction . 28
7.3.2 Use Case 3 Information Flow Diagram . 29
7.3.3 Use Case 3 Stakeholders . 29
7.3.4 Use Case 3 Agents and Data Source/Sink Entities . 29
7.3.5 Use Case 3 Scenarios . 30
7.3.5.1 Scenario "A": Traffic Management to reduce Pollution Peak Levels . 30
7.3.5.2 Scenario "B": Traffic Management to reduce Pollution Peak Levels with price incentive . 30
7.3.5.3 Scenario "C": Traffic Routing to Avoid Polluted Routes . 31
7.3.5.4 Scenario "D": Access Price for downtown depends on Congestion and Size of Vehicle . 31
7.3.5.5 Scenario "E": Information Service on Pollution Levels and Pricing . 32
7.3.6 Use Case 3 Entities Instances Graph. 32
7.4 Use Case 4: Crowd Monitoring and Emergency Response . 32
7.4.1 Use Case 4 Introduction and Assumptions . 32
7.4.2 Use Case 4 Information Flow Diagram . 33
7.4.3 Use Case 4 Stakeholders . 33
7.4.4 Use Case 4 Agents and Data Source/Sink Entities . 34
7.4.5 Use Case 4 Scenario Descriptions and Data Flows . 34
7.4.5.1 Scenario "A": Population Evacuation taking into account resort crowd and external traffic info . 34
7.4.5.2 Scenario "B": First aid in resort during emergency taking into account resort crowd and available
resources . 35
7.4.6 Use Case 4 Entity instances graph . 35
7.5 Use Case 5: Management of Optical Fibre Network Deployment . 36
7.5.1 Use Case 5 Introduction and Assumptions . 36
7.5.2 Use Case 5 Information Flow Diagram . 37
7.5.3 Use Case 5 Stakeholders . 37
7.5.4 Use Case 5 Agents and Data Source/Sink Entities . 37
7.5.5 Use Case 5 Scenario Descriptions and Data Flows . 38
7.5.5.1 Scenario "A": Network Deployment Planning . 38
7.5.5.2 Scenario "B": Network In-Field Deployment . 38
7.5.6 Use Case 5 Entities instances graph . 39
8 Smart Agrifood Use Cases . 39
9 Smart Industry Use Cases. 40
Annex A: Selected "Vertical" Use Cases from the Literature . 41
Annex B: Authors & contributors . 43
History . 44

ETSI
5 ETSI GR CIM 002 V1.1.1 (2018-09)
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 Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) cross-cutting Context
Information Management (CIM).
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.

ETSI
6 ETSI GR CIM 002 V1.1.1 (2018-09)
1 Scope
The present document discusses the concepts which are foundational for Cross-Cutting Context Information
Management (C3IM) and their application to a selection of Use Cases from the domains of Smart Cities, Smart
Agrifood and Smart Industry. These areas of application, together with the general area of Internet of Things (IoT)
technology and services, are expected to especially benefit from usage of cross-cutting (cross domain) context
information, and from a set of specifications for the APIs supporting C3IM.
The present document covers the following:
• A definition of terms relevant to cross-cutting Context Information Management (C3IM).
• An introduction to the notions of C3IM and the potential role of C3IM in enabling services in cross-cutting
inter-domain areas, for example Smart Cities, Smart Agrifood, and Smart Industry.
• A motivation for this project's key goal, i.e. defining an API for C3IM.
• A reference diagram illustrating possible architectures and functional entities involved in facilitating C3IM.
• A set of high level Use Cases which can potentially be supported using a C3IM system.
• A subset of detailed Use Cases (scenarios) illustrating potential information flows among functional entities.
• A summary of requirements extracted from the Use Case analysis.
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] INSPIRE Data Specifications Drafting Team, 2008-03-18: "Deliverable D2.3: Definition of Annex
Themes and Scope".
NOTE: Available at
http://inspire.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.3_Definition_of_Annex_Th
emes_and_scope_v3.0.pdf.
[i.2] INSPIRE: "European Data Portal -Training & Library - Use Cases".
NOTE: Available at https://www.europeandataportal.eu/en/training-library/library/training-materials.
[i.3] European Data Portal: "Re-using Open Data: A study on companies transforming Open Data into
economic and societal value", CapGemini, 20170117.
NOTE: Available at https://www.europeandataportal.eu/sites/default/files/re-using_open_data.pdf.
ETSI
7 ETSI GR CIM 002 V1.1.1 (2018-09)
[i.4] "DIGITALEUROPE's views on the Artificial Intelligence, Machine Learning and Robotics",
Brussels, 10 May 2017 Published 20170510.
NOTE: Available at http://www.portugalglobal.pt/PT/Acoes/missoes/Documents/2017/belgica-2nd-innovation-
sessions-digital-europe.pdf.
[i.5] Pohl, Klaus: "Requirements engineering: fundamentals, principles, and techniques". Springer
Publishing Company, Incorporated, 2010.
[i.6] Library of Congress of USA: "PREMIS Data Dictionary for Preservation Metadata version 3.0".
NOTE: Available at http://www.loc.gov/standards/premis/v3/premis-3-0-datadictionary-only.pdf.
[i.7] W3C, PROV Model Primer. Working Group Note 30 April 2013.
NOTE: Available at http://www.w3.org/TR/2013/NOTE-prov-primer-20130430.
[i.8] ITS International: "Substantial savings from smarter street lighting", first published January 2015.
NOTE: Available at http://www.itsinternational.com/sections/general/features/substantial-savings-from-smarter-
street-lighting/.
[i.9] ETSI GS CIM 004 (V1.1.1) (04-2018): "Context Information Management (CIM); Application
Programming Interface (API)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
agent: system, software program or firmware that is a producer, consumer or manipulator of data in a use case
NOTE: That in some use cases, an agent may act on behalf of a human or legal stakeholder.
context: set of entities with which an entity has defined relationships, together with the categories (classes) and
properties of these entities, their relationships and their properties
context information: informational representation of a context
cross-cutting context information: context information that spans multiple distinct application domains
(Cross Cutting) Context Information Management (C3IM): following services provided by a platform: context
information registry, discovery, publication, mediation, modification or notification, and more generally mediation
between context information sources and context information users
NOTE: The acronym C3IM is used only in the present document as a shortcut for, cross cutting context
information management, rather than CIM to avoid confusion with acronyms uses by other SDOs
(e.g. ISO/IEC Common Information Model).
entity: something existing in the real world such as a person, a place such as a building or street corner, an object such
as a car or tree or refrigerator or any equipment or sensor, a document such as a book or legal document, which can be
represented in a context information management platform
NOTE: This is different from the sense in which the oneM2M specification uses the word "entity".
information model: set of types and associated constraints that formally define the classes(categories) used for context
information representation
NOTE: The information model constrains the specific representation of the structure, manipulation and integrity
aspects of the data stored in data management systems such as graph databases, whereby generic cross-
domain and specific domain-dependent terminologies/taxonomies are used for the information elements
and their instantiations.
ETSI
8 ETSI GR CIM 002 V1.1.1 (2018-09)
property: description instance which associates a literal characteristic (e.g. a value in a common data type). to either an
Entity, a Relationship or another Property
relationship: description of a directed link between a subject which is either an Entity, a Property, or another
Relationship on the one hand, and an object, which is an Entity, on the other hand; for example "isAdjacent to",
"isContainedIn", "is ASubSystemOf", "isOwnedby", "isCreatedBy"
stakeholder: person, business or other legal entity who is involved in a service or process of a use case
situation: set of entities and services, and their dynamic states, interacting within a specific geo-temporal range
target domain: set of business activities (e.g. automobile traffic flow planning, energy distribution, etc.) within which
traditional use cases are defined
NOTE: The entities of a target domain may be shared with others (e.g. streets as city entities are shared between
traffic management and lighting management) and this is precisely where cross-cutting context
information comes into play.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ADSL Asymmetric Digital Subscriber Line
AI Artificial Intelligence
AIOTI Alliance for the Internet of Things Innovation
ALPR Automatic License Plate Recognition
API Application Programming Interface
ATM Automated Teller Machine
CAL Climate Associates Limited
EC European Commission
EGM Easy Global Market
EU European Union
EV Electric Vehicle
GHG Green House Gas
GPS Global Positioning System
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
ICD Implantable Cardioverter-Defibrillator
IoT Internet of Things
ISG Industry Specification Group
ISO International Organization for Standardization
KPI Key Performance Indicator
NEC Nippon Electric Company
NGSI Next Generation Service Interfaces
OWL Ontology Web Language
RDF Resource Description Format
SMS Short Message Service
UI User Interface
4 Introduction
4.1 Introduction to Context Information Management
As stated in the scope, the present document concerns the application of cross-cutting contextual information
management to a selection of Use Cases from the domains of Smart Cities, Smart Agrifood and Smart Industry. These
applications are expected to especially benefit from cross-cutting context information and from a set of specifications
for the APIs supporting C3IM.
ETSI
9 ETSI GR CIM 002 V1.1.1 (2018-09)
Cross-cutting Context Information Management (C3IM) is provided by a C3IM platform. A C3IM platform collects
data from IoT devices, lower-level platforms managing such devices, crowdsourced devices, databases and other
sources, and provides as consolidated context information to applications via an API (defined in later documents as
NGSI-LD). The C3IM platform enables use-cases which link together disparate but related information. It is thought
that IoT services will be enriched when applications have access to a full set of context information, as defined in
clause 3. A C3IM system potentially enriches services by bringing together information from a wider set of
service-relevant sources than would otherwise be available to a traditional vertically integrated IoT application.
This is illustrated in figure 4.1-1. In the first figure, an IoT information source such as a sensor provides data to an
application. As an example, an IoT-enabled fitness tracker device reports heart rate and step counts to a user via a
cloud-based "runner fitness" service. The user is simply able to access current values and past statistics for these
measures. For best results and widest interoperability, the transfer of information from the sensor to the cloud
application needs to be accompanied by the semantics and context of the information (i.e. the numbers sent are "heart
rate", not "blood pressure" or some other measure).
The simple example makes clear that the protocol to exchange data should contain (or reference) all context information
needed to correctly interpret that data for a given service (the cloud application) and that the protocol should be
designed to function between widely different kinds of information sources and information "consumers". For widest
interoperability, nothing should be assumed.

Figure 4.1-1: Exchange of (context) information between a source and an application
In figure 4.1-2, the first information source is supplemented by additional contextually relevant information from a
variety of databases or other sources. The Application has access to a wider set of information and can provide a richer
service. To continue the example, an enhanced runner fitness service uses GPS location (from the user's phone sensor),
road inclination (from a municipal database), weather information (from a national government service web-API) and
traffic conditions on the road (from a web API of a popular map application). These are tied together by the application.
The user sees suggested running routes based upon his/her goals and local conditions, can track his/her progress and
speed, and sees graphs of heart rate against estimated calorie burn, speed, or road inclination.

Figure 4.1-2: Merging of several contextual information sources to enhance an application
Access to relevant context information from multiple target domains enables "cross-cutting" applications to present a
richer service to the user. To summarize, a C3IM system may utilize information of the following characteristics:
• information about or from one or more entities;
• static or dynamic information;
• information from database including open data;
ETSI
10 ETSI GR CIM 002 V1.1.1 (2018-09)
• different sources leading to similar information (for example, in some cases temperature may be reported by a
user, in other cases temperature may be reported from a sensor).
The C3IM system is expected to make it easier for applications to access this heterogeneous information by
standardizing the APIs between applications, data aggregation platforms, and entities.
4.2 Information Sources
The purpose of the present document is to help clarify interoperability requirements for transmission and management
of information between different information sources which have been developed under different sets of assumptions
and definitions, particularly for:
a) various kinds of Internet-of-Things sensor/actuator frameworks;
b) various kinds of databases created and maintained for processes within municipalities and governments;
c) various kinds of internet/mobile applications promoting interaction of end users with the digital world, etc.
Everyone talks about the new digital society, digital transformation or fourth industrial revolution, etc. but building it
will require unprecedented trading (not just "sharing") of information in forms which remain correctly interterpretable
at all stages.
It is assumed in the present document that there are actually five broad sources of information about the real world,
made available in the digital world and managed within a context information management platform:
a) IoT Platforms: they mediate raw data originating mostly from various sensors within the target environment.
(e.g. a Smart City, an industrial compound, etc.). This mediation takes place through a two-sided platform that
acquires, aggregates, references and maintains this data as consolidated information in order to make it
available to applications or higher-level platforms operating within this environment.
b) Managed Database Platforms: containing aggregated, consolidated, filtered, etc. information, by
stakeholders such as government agencies, commercial businesses, or subordinate lower-level database
platforms, network servers, gateways, or third-party information services. Typical examples are statistics for
crime, for traffic flow, for environmental pollution, for delays in scheduled public transport, or catalogues of
information such as catalogues of products, of government requests for tender, of properties available for sale.
c) Application Data Platforms: applications delivering extremely varied kinds of data, usually from a multitude
of end users. The kinds of data could be e.g. user-generated gps tracks of cars (input into a traffic flow
database), user-identified locations of dangerous damage to streets (input into a municipal map for roadworks
planning), etc.
NOTE: The difference to a Managed Database Platform is that the application services are not strictly
filtered/managed by a uniform registration process and/or a single organization, and include many
single-user sources of information, often with short validity period e.g. the time immediately after sending
a SMS.
d) Data Analytic Platforms: consist of context information which has been derived from any and all other
available information, including models and simulations, by specialized software. The provenance of such
information needs to be very carefully tracked and taken into account when reaching conclusions (by humans
or machines).
e) Usage Data: based upon roles and permissions for (re)use of the above data sources, accounting and
provenance data accompanying access, logical extrapolations from all such data and usages of that data.
Judging by commercial efforts to develop artificial intelligence platforms, commercial platforms for
information retrieval and commercial platforms for sharing of information between friends and
friends-of-friends, the set of networks of users of specific types of information will itself be a factor in the
digital environment (and economy) for all users, in particular for services involving advertising and/or billing.
ETSI
11 ETSI GR CIM 002 V1.1.1 (2018-09)
4.3 Motivation for developing a Context Information
Management System
It is the goal of ETSI ISG CIM to facilitate consolidation and re-use of the different kinds of data and information
sources, and multiple instances of any of the sources, into a federative platform. Cross-Cutting Contextual Information
Management corresponds to the cross-fertilization and federated use of multiple sources of information, such that the
original meaning and context (definition and provenance) of such information is not lost during transfer.
The term "context information" has a broad definition within the present document, including in principle all additional
information about a bare recorded "fact" which would be needed to interpret that fact unambiguously under all
circumstances. Usually, however, the term "context information" is pragmatically used in the sense of "additional
information which explains the definition of the type of observation and the conditions affecting its observed value
within a specific (set of) situation". This is more practical but also more limited and leads to situations where "one
man's definition of context is another man's definition of irrelevant blather".
What is the meaning of the term "cross cutting" in connection with context information? The term emphasizes that
information from one context may be highly useful in another, particularly if (a) the two contexts belong to disparate
target domains, but also for (b) two very similar or even identical contexts where the information modelling of the
entities, services or roles has developed in a non-identical way. An example of (a) is exchange of information between a
bus timetable planning system and a weather prediction system. An example of (b) is exchange of information between
police departments in two adjacent cities in different nations (example Saarbrueken).
The emphasis on "independent target domains" in C3IM clarifies the term "cross-cutting", indicating that information is
combined from sources which may have only partial overlap - or even conflict - of explicit or implicit information
models. These conflicts may occur even within the same target domain (e.g. the smart home) if description of data
(meaning, provenance, etc.) is ambiguous, changes over time, or changes according to the person/system responsible for
the sourcing of information.
It should be emphasized that the meaning of "context" nowadays (and in the present document) has changed markedly
from the formerly prevailing definition of context originating from the "first wave" of context-awareness that dominated
research in the years 2000-2010, as taken up within the broader "ambient intelligence" research agenda at that time.
Context was then defined in a mostly end-user-centric way, which implicitly assumed that there existed a primary
information source called "content" (typically audiovisual media or multimedia interpersonal communication), and
"context" was defined relative to this user-centric content as anything that provided ancillary information. Typically, the
aim was to enable the user to better "consume" the content, or in general to improve the content with regards to various
criteria.
That end-user-centric view and the context vs content distinction have no relevance in the broader domain of IoT
platforms and Database Platforms that is targeted here, because what is primary content for one application is context to
another, and the C3IM platform is intended to serve all applications irrespective of the primary content they request.
The C3IM platform should thus manage information at a level that makes it possible to consolidate all sources of
potential content and context information jointly.
The above explanation motivates the key criterion in selecting use cases for the present document: they should
demonstrate the benefits of mixing information from different sources, each of which corresponds to a source of
"primary" information dedicated to one application, showing that jointly the combination can be richer, more reliable or
more adaptable.
The barriers for successful cross-cutting context information management are still so high, that a CapGemini survey
[i.3] published in 2017 of companies active in the field found that across 14 categories the correlation matrix of re-use
of open data from two independent domains was only above 50 % for four pairs of categories:
a) Transport with Cities.
b) Environment with Cities.
c) Population and Society with Cities.
d) Population and Society with Environment.
ETSI
12 ETSI GR CIM 002 V1.1.1 (2018-09)
Some examples of cross-domain use cases which require access to information from different domains, that is normally
held separate, are:
• Smart Lighting and Smart Parking so that lighting is only provided when car parking is booked and used in
order to save energy.
• Smart Buildings and Smart Mobility to ensure that power is available to charge electric vehicles when required
(in order to reduce GHG emissions and improve air quality in a neighbourhood).
• Smart Parking and e-Health to ensure that parking spaces are available for health professionals when required.
• Smart Energy and Smart Buildings to improve the buildings environment and energy management based on
information collected on the indoor and outdoor environment including energy consumption and production.
• E-Health and Smart Appliances to monitor appliances to check if they have been 'left on' by the user (detection
of abnormal events).
Various H2020 research projects provide different practical examples of the above types:
• Management of Networked IoT Wearables - Very Large Scale Demonstration of Cultural and Security
Applications - www.monica-project.eu.
• ACTivating InnoVative IoT smart living environments for AGEing well - www.activageproject.eu.
• AUTOmated driving Progressed by Internet of Things - www.autopilot-project.eu.
• Internet of Food and Farm 2020 - www.iof2020.eu.
• Delivering an IoT enabled Digital Single Market for Europe and Beyond - www.synchronicity-iot.eu.
• User Engagement for Large Scale Pilots in the Internet of Things - www.u4iot.eu.
• CRoss FErtilisation through AlignmenT, Synchronization and Exchanges for IoT - www.create-iot.eu.
• VICINITY - www.vicinity2020.eu.
• Wise-IoT - http://wise-iot.eu.
5 Methodology
5.1 Approach to Documenting Use Cases
5.1.1 Purpose
The main purposes of writing down C3IM Use Cases document are:
• to provide examples of services which require the use of a C3IM platform;
• to understand the requirements for an appropriate API and Information Model.
The list of Use Cases presented is not meant to be exhaustive, but to provide example services in the Smart City and
other topic areas.
ETSI
13 ETSI GR CIM 002 V1.1.1 (2018-09)
5.1.2 Assumptions about a C3IM Architecture
In documenting Use Cases, several assumptions regarding the C3IM Architecture are made:
• It is assumed that C3IM platforms have an appropriateAPI through which they can query other systems,
provide notifications, and receive responses to queries. For example, a ParkingManagementSystem could
query a TrafficManagementSystem about road occupancy at a particular egress gate. No particular format of
these transactions is assumed or specified in the present document, however detailed specifications are
provided in the API document [i.9].
• It is assumed that means are available for C3IM platforms to discover, register, and report existence of entities
and relationships within and across several instances of platforms. Distributed C3IM platform instances need
also to be able to reconcile the identity of entities referenced in the different systems. The mechanisms to do so
are not described in the present document.
• An Information Model specifying the classes of entities, relationships and properties is assumed to be used by
a C3IM system. An Instance Graph showing properties and relevant contextual relationships of specific
entities is shown for each Use Case. The methods by which the Information Model is created are not discussed
in the present document.
5.1.3 Use Case Sections
Each Use Case description includes the following sections.
Introduction and Assumptions
An overview of the Use Case, important assumptions and links to external references if applicable, are described.
Information Flow Diagram
A coarse-grain Information Flow Diagram depicts for each Use Case the usage scenarios and types of information
exchanged among the Agents of the involved in the Use Case, as well as some of the external entities associated with
each use case as either data sources (typically sensors or input user interfaces) or data sinks (typically actuators or
output user interfaces).
Agents are depicted as ovals with a dotted outline. Entities are represented by solid rectangles.
In this diagram, the Agents are presumed to communicate through an appropriateAPI (called NGSI-LD in later
documents) to a C3IM platform. Through this NGSI-LD API, Agents provide context information of Entities associated
with them, or receive context information about Entities associated with other Agents, or do both. The C3IM platform is
represented as a cylinder connected to the Agents. No assumption is made about the architecture of the C3IM platform,
for example if it is centralized or distributed.
Figure 5.1.3-1 shows the relative roles of a C3IM platform, a data consuming Agent and a data providing Agent.

Figure 5.1.3-1: Roles in a C3IM platform, for a data consuming Agent and a data providing Agent
ETSI
14 ETSI GR CIM 002 V1.1.1 (2018-09)
Stakeholders
The Stakeholders and a description of their assumed role and/or interest in the Use Case are provided. Examples of
Stakeholders are Parking Manager and Smart City Planning Authority.
Agents and Data Source/Sink Entities
The Agents (which may be systems) and associated entities which are data sources and data sinks, together with a
description of data handling by the agents within the Use Case, are presented in a table.
Examples of Agents are ParkingManagementSystem and TrafficManagementSystem. Examples of data source/sink
entities are devices such as parking gate actuators, road sensors and cameras.
Scenarios
Each Use Case involves one or more Scenarios, which each describe a particular service and information flow within
the Use Case. Scenarios do not necessarily involve every Agent or entity shown in the Use Case.
Data exchanges between pairs of Agents that are required to achieve the Scenario are shown in tabular format.
Entities
...