ETSI GR CIM 020 V1.1.1 (2022-12)

Context Information Management (CIM); NGSI-LD; Guidelines for the deployment of Smart City and Communities data platforms

DGR/CIM-0020

General Information

• Status: Not Published
• Technical Committee: CIM - cross-cutting Context Information Management
• Current Stage: 12 - Completion
• Due Date: 14-Dec-2022
• Completion Date: 20-Dec-2022

Standards Content (Sample)

GROUP REPORT
Context Information Management (CIM);
NGSI-LD;
Guidelines for the deployment of Smart City
and Communities data platforms
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 020 V1.1.1 (2022-12)

Reference
DGR/CIM-0020
Keywords
interaction, interoperability, NGSI-LD, platforms,
smart city
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

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
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
arranty is made of merchantability or fitness
and/or governmental rule and/or regulation and further, no representation or w
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2022.
All rights reserved.
ETSI
3 ETSI GR CIM 020 V1.1.1 (2022-12)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Executive summary . 5
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 9
3.3 Abbreviations . 9
4 Basics for building a smart city platform . 10
4.0 Introduction . 10
4.1 Objectives of implementing a smart city platform . 10
4.2 NGSI-LD-based smart city platform architecture . 11
4.3 Smart city and communities . 12
4.4 Public lights in smart city example use case . 13
5 Data sources for smart cities . 14
5.0 Introduction . 14
5.1 Integrating data sources in an NGSI-LD platform . 15
5.2 Non-NGSI-LD-compliant data source management . 16
5.3 Document management and cloud object storage . 20
5.4 Data source authorization over NGSI-LD . 21
5.5 Criteria of interest to NGSI-LD . 24
6 Digital Twins for smart cities . 26
6.0 Introduction . 26
6.1 Digital Twin Definition Language . 26
6.2 Implementing digital twins with NGSI-LD . 26
6.2.0 Introduction. 26
6.2.1 Digital Twin description . 27
6.2.2 Recommendations to NGSI-LD . 27
7 Smart cities and Data Spaces . 28
7.1 Relationship among Data Spaces, Digital Twins and Context information . 28
7.2 Relevance to Smart Cities . 28
7.3 Data Spaces overview with NGSI-LD. 29
7.4 Integration of Data Spaces with NGSI-LD . 29
7.4.0 Introduction. 29
7.4.1 Challenges. 30
7.4.2 Recommendations . 30
7.4.3 Common attributes grouping . 31
7.4.4 Grouping of Attribute Groups . 32
8 OASC Minimal Interoperability Mechanisms. 32
8.1 Understanding the MIM Framework . 32
8.2 Analysis for NGSI-LD . 33
9 GIS tools integration . 33
9.0 Introduction . 33
9.1 GIS and NGSI-LD . 34
9.2 Compatibility with OGC API . 35
ETSI
4 ETSI GR CIM 020 V1.1.1 (2022-12)
9.3 GeoJSON as an exchange between OGC and NGSI-LD . 35
9.4 Integration feasibility study with popular GIS tools . 36
10 Data Sovereignty, Trust and Privacy . 36
10.1 Overview . 36
10.2 Status of Data Sovereignty with NGSI-LD . 36
10.3 MyData Study . 36
10.4 Recommendations . 37
10.4.0 Introduction. 37
10.4.1 Grouping attributes . 38
10.4.2 Data Provider has full usage control in real-time . 40
10.4.3 Data access architectural recommendations using CBAC . 40
10.5 Summary of recommendations . 41
11 Linked Open Data for smart cities . 41
11.1 Review of Semantic Web Standards . 41
11.1.0 Introduction. 41
11.1.1 W3C Semantic Web Standards (SWS) . 42
11.1.2 Linked Open Data (LOD) . 42
11.2 Existing LODs Platforms . 42
11.2.1 Europeana Pro . 42
11.2.2 DBPedia . 43
11.2.3 Bio2RDF . 43
11.2.4 Seoul Open Data Plaza LOD service . 43
11.3 LOD with NGSI-LD . 44
11.3.1 Implementing LOD service with NGSI-LD . 44
11.3.2 Recommendations . 46
Annex A: Injecting NGSI-LD data to a CityGML-based 3D representation . 47
History . 49

ETSI
5 ETSI GR CIM 020 V1.1.1 (2022-12)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
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.
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.
Executive summary
The present document presents ideas and state-of-the-art solutions, based on the NGSI-LD eco-system (specifically the
NGSI-LD API in ETSI GS CIM 009 [i.2], information model in ETSI GS CIM 006 [i.3] and security and privacy in
ETSI GR CIM 007 [i.4]), in the area of smart cities, i.e. the area of software platforms which, based on real-time data
flows, make it possible to better manage cities and communities.
ETSI
6 ETSI GR CIM 020 V1.1.1 (2022-12)
Introduction
A smart city platform helps to systematically manage and utilize various data generated in the city. It may improve the
quality of life of citizens by creating new businesses and services and continuously developing the city.
Concepts like "federation", "interoperability", and "security" should be considered for smart city services. Through an
NGSI-LD based smart city platform, the various data generated in the city are systematically managed, and through
this, the digital industry ecosystem can be activated by creating new services and business models, or by creating added
value to the existing ones.
ETSI
7 ETSI GR CIM 020 V1.1.1 (2022-12)
1 Scope
The present document presents ideas and state-of-the-art solutions in the area of smart cities, that is in the area of
software platforms which, based on (near) real-time data flows, make it possible to better manage cities and
communities.
Specifically, the solutions are centred on the NGSI-LD API [i.2] and information model [i.3], as a means to achieve
cross-domain interoperability among data coming from different sectors and the different (possibly pre-existing) data
sources installed in public spaces, utilities and infrastructures.
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] OASC Minimal Interoperability Mechanisms.
NOTE: Available at https://mims.oascities.org.
[i.2] ETSI GS CIM 009 (V1.6.1): "cross-cutting Context Information Management (CIM); NGSI-LD
API".
NOTE: Available at
https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.06.01_60/gs_CIM009v010601p.pdf.
[i.3] ETSI GS CIM 006 (V1.1.1): "Context Information Management (CIM); Information Model
(MOD0)".
NOTE: Available at
https://www.etsi.org/deliver/etsi_gs/CIM/001_099/006/01.01.01_60/gs_CIM006v010101p.pdf.
[i.4] ETSI GR CIM 007 (V1.1.2): "Context Information Management (CIM); Security and Privacy".
NOTE: Available at
https://www.etsi.org/deliver/etsi_gr/CIM/001_099/007/01.01.02_60/gr_CIM007v010102p.pdf.
[i.5] IoT Agent Library.
NOTE: Available at https://github.com/telefonicaid/iotagent-node-lib.
[i.6] The Digital Twins Definition Language (DTDL).
NOTE: Available at https://github.com/Azure/opendigitaltwins-dtdl.
[i.7] Digital Twins Definition Language (DTDL) ontology for Smart Cities.
NOTE: Available at https://github.com/Azure/opendigitaltwins-smartcities/blob/main/README.md.
ETSI
8 ETSI GR CIM 020 V1.1.1 (2022-12)
[i.8] FIWARE for Data Spaces.
NOTE: Available at https://www.fiware.org/wp-content/uploads/FF_PositionPaper_FIWARE4DataSpaces.pdf.
st
[i.9] ETSI White Paper no. 42: "Guidelines for Modelling with NGSI-LD". 1 edition - March 2021.
NOTE: Available at https://www.etsi.org/images/files/ETSIWhitePapers/ETSI_WP_42_NGSI_LD.pdf.
[i.10] The Business API Ecosystem.
NOTE: Available at https://business-api-ecosystem.readthedocs.io/en/latest/.
[i.11] GIS Industry: "How GIS Supports the Planning and Development of Smart Cities". Sangeeta
Deogawanka. February 8, 2016.
NOTE: Available at https://www.gislounge.com/how-gis-supports-the-planning-and-development-of-smart-cities.
[i.12] INSPIRE Directive: "Infrastructure for Spatial Information in Europe. D2.5: Generic Conceptual
Model, Version 3.4rc3".
NOTE: Available at https://inspire.ec.europa.eu/documents/Data_Specifications/D2.5_v3.4rc3.pdf.
[i.13] Smart Data Models Program.
NOTE: Available at https://smartdatamodels.org/index.php/about/.
[i.14] QGIS Topology Introduction.
NOTE: Available at https://docs.qgis.org/3.22/en/docs/gentle_gis_introduction/topology.html.
[i.15] W3C Recommendation 04 February 2020: "Data Catalog Vocabulary (DCAT) - Version 2".
NOTE: Available at https://www.w3.org/TR/vocab-dcat-2/#Class:Resource.
[i.16] IETF RFC 8428: "Sensor Measurement Lists (SenML)", August 2018.
NOTE: Available at https://www.rfc-editor.org/rfc/rfc8428.
[i.17] IETF RFC 7946: "The GeoJSON Format", August 2016.
NOTE: Available at https://www.rfc-editor.org/rfc/rfc7946.
[i.18] TopoJSON API Specification.
NOTE: Available at https://github.com/topojson/topojson/blob/master/README.md.
[i.19] Antti Poikola, Kai Kuikkaniemi, Harri Honko: "A Nordic Model for human-centered personal data
management and processing". ISBN: 978-952-243-455-5.
NOTE: Available at https://julkaisut.valtioneuvosto.fi/bitstream/handle/10024/78439/MyData-nordic-model.pdf.
[i.20] SAREF: Smart Applications REFerence Ontology, and extensions: Official ETSI portal for
SAREF.
NOTE: Available at https://saref.etsi.org/.
[i.21] OGC API Overview.
NOTE: Available at https://www.ogc.org/standards/ogcapi-features.
[i.22] OGC Open Geospatial Consortium.
NOTE: Available at https://ogcapi.ogc.org.
[i.23] W3C Semantic Web Standards.
NOTE: Available at https://www.w3.org/standards/semanticweb/.
ETSI
9 ETSI GR CIM 020 V1.1.1 (2022-12)
[i.24] DBPedia LodLive.
NOTE: Available at https://github.com/LodLive/LodLive.
[i.25] OGC City Geography Markup Language (CityGML) 3.0 Conceptual Model Users Guide,
th
13 September 2021.
NOTE: Available at https://docs.ogc.org/guides/20-066.html.
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3D Three Dimensional
AI Artificial Intelligence
API Application Programming Interface
ArcGIS Graphical Information Software
NOTE From the organization ESRI, see https://www.esri.com.
CBAC Context-Based Access Control
CSV Comma Separated Value
DCAT Data CATalogue vocabulary
DTDL Digital Twins Definition Language
EDM Europeana Data Model
NOTE: An initiative funded since 2005 by the EU.
FTP File Transfer Protocol
GIS Graphical Information System
GML Geography Markup Language
HTTP HperText Transfer Protocol
ICT Information and Communications Technology
ID IDentifier
IoT Internet of Things
IUDX Indian Urban Data Exchange
JSON Java Script Notation Object
LD Linked Data
LOD Linked Open Data
MIM Minimal Interoperability Mechanism(s)
MQTT Message Queue Telemetry Transport
NGSI Next Generation Service Interface
OASC Open and Agile Smart Cities
OGC Open Geospatial Consortium
OKG Open Knowledge Graph
OWL W3C Web Ontology Language
PDP Policy Decision Point
PEP Policy Enforcement Point
RBAC Role-Based Access Control
ETSI
10 ETSI GR CIM 020 V1.1.1 (2022-12)
RDBMS Relational DataBase Management System
RDF Resource Description Format
REST REpresentational State Transfer
senML Sensor Measurement Lists
SKOS Simple Knowledge Organization System
SMS Short Message Service
SPARQL SPARQL Protocol and RDF Query Language
SQL Structured Query Language,
SWS Semantic Web Standards
URI Uniform Resource Identifier
URL Uniform Resource Locator
W3C World Wide Web Consortium
WCS OGC Web Coverage Service
WFS OGC Web Feature Service
WMS OGC Web Map Service
WPS OGC Web Processing Service
4 Basics for building a smart city platform
4.0 Introduction
To implement a data-based smart city, a software platform that can systematically manage and utilize the various kinds
of data generated in the city is required. Smart city platforms process, store, and convert data collected by the city, and
provide it to city services that extract useful information out of data, for example by carrying out predictive analysis
based on AI. In this way, the city can provide the building blocks for various types of applications according to the
emergence of information out of real-time data such as car/motor traffic volume or other data collected by new
technologies. For this purpose, it is necessary to ensure a continuous data flow to the platform, and therefore data
collected from various systems and domains would benefit from inter-linking.
Towards this goal, a smart city platform based on the NGSI-LD ecosystem would ensure data interoperability by using
and exploiting the NGSI-LD [i.2] API and its associated, cross-domain data model [i.3] to store and deliver data.
4.1 Objectives of implementing a smart city platform
The purpose of the smart city platform is to manage urban data that provides a data-based collaboration, analysis, and
decision-making environment, by establishing a real-time linkage of vast amounts of information generated by
infrastructure, administration, and civil communities that make up the urban environment through the horizontal/vertical
convergence of smart city technologies.
High-level objectives are summarized as follows:
• Establish an urban management model that supports the collective acquisition and sharing of information
about various smart city infrastructures and urban conditions required by industry-specific services.
• Create an urban data industry ecosystem for integrated storage, analysis, and utilization of large amounts of
data in collaboration with cloud infrastructures.
• Support the interoperability between different domains so that added value emerges.
• Collect city data from heterogeneous data sources such as legacy systems, IoT platforms, and GIS, in order to
process, analyse, and distribute data to city services and other external systems.
• Link the data via semantic web technologies for better data usage, cost minimization for the services, and
improved usability of data from various domains.
ETSI
11 ETSI GR CIM 020 V1.1.1 (2022-12)
The expected features of a smart city platform are:
• Data ingestion & integration from various domains
• Cloud-based document and multimedia storages
• Assets management
• Data analysis and monitoring
• Security & Access control for users
4.2 NGSI-LD-based smart city platform architecture
The smart city platform needs to implement technologies to collect data from a variety of external platforms and
convert and adapt it to already existing data models for smart cities, e.g. Smart Data Models [i.13].
Using data models which are compatible with the NGSI-LD cross-domain information model allows a high degree of
data inter-linking when an NGSI-LD broker is used as the central piece of this architecture.
Various external IoT data sources (e.g. based on oneM2M), Geographical Information Systems, legacy systems, as well
as other smart city platforms can be considered as input to the smart city platform, which is then implemented as a
cloud-based system that collects, processes, and stores information about the various smart city infrastructures and
urban situations.
City Specific
Data marketplace Applications
Data portals
services
(Context Consumers)
NGSI-LD API
NGSI-LD API NGSI-LD API
Security & Access Control (IdP, Auth.)
S
e
Analytics & Monitoring &
Data
c
Semantics
u
management r
service A.I.
i
t
y
&
NGSI-LD API
A
c
c
N e Smart city
G s
s
Internal S NGSI-LD
platform
I
- C
L
o
D NGSI-LD API
Context Context
n
A
t
P
Consumers Broker r
I
o
l
(
I
d
P
NGSI-LD API
,
A
u
t
h
Data ingestion & integration
.
.
)
Security & Access Control (IdP, Auth.)
External
Legacy systems Other Data Spaces or Other
data sources
(IoT, GIS, open APIs…) Smart City Platforms

Figure 4.2-1: The structure of an NGSI-LD-based smart city platform
In Figure 4.2-1 the overall architecture of a typical smart city platform is depicted. The platform itself is represented by
the middle box, which collects data from external sources and peer platforms (at the bottom, grey boxes), and feeds
information to external applications on top (blue boxes).
ETSI
12 ETSI GR CIM 020 V1.1.1 (2022-12)
Logical functions, the green boxes, which are part of the structure of the smart city platform are:
• Data ingestion & integration: collects, transform, and load heterogeneous data from several types of systems
such as IoT platforms, RDBMS, and open APIs. When data needs to be transformed to fit the NGSI-LD
information model used by the smart city platform, this function could be used as an adapter to load the data.
• NGSI-LD Context Broker: ensuring data interoperability by applying NGSI-LD API and information model to
data storage and provision.
• Semantics: supports the construction and utilization of semantic data of the smart city platform. This function
converts city data to semantic (RDF triples) data, based on smart city ontologies, to support application
services such as Linked Open Data (LOD). Since new knowledge could be extracted through semantic
technologies such as semantic mashup and semantic reasoning, it has a bidirectional connection with the
NGSI-LD context broker. See LOD, described in clause 11.
• Analytics & Artificial Intelligence (AI): supports the development of a convergence analysis/prediction service
of city data. This function analyses the data stored in the smart city platform and creates a machine learning
model, and execution of the generated model enables the generation of prediction information. See Digital
Twins for smart cities, described in clause 6.
• Monitoring & management: provides real-time integrated monitoring and system operation management such
as public/private data and cloud management, devices and database management in the smart city platform.
See clause 5.
• Security & Access Control: provides authentication for smart city platform users and applications, access
control policy management, and access control token management functions. See Data Sovereignty, Trust and
Privacy, described in clause 10.
4.3 Smart city and communities
Collaboration is the key component in a smart city with technology and citizen involvement. Because each smart city
platform is different in many ways, exchanging knowledge or data and experience is necessary for smart and
sustainable cities and communities. Smart cities could be smarter together and build on their strengths through sharing
and reuse of resources and knowledge with communities. The city context broker could have a federated/distributed
structure that is shared with other brokers, allowing distributed collection according to domains or data types such as
IoT, infrastructure, and document, which it then provides the smart city services.
Figure 4.3-1 presents an example of federated context brokers. It is based on one city context broker that is federated
with a set of community context brokers. The community context brokers may share (some or) all their data with the
city context broker. This is according to the hierarchical relation between cities and communities. When communities
are physically sharing some resources, such as a river or roads, it is possible to create s secure channel between
community context brokers to partially share common data. A community context broker can, in turn, be built on a
federated architecture where the sub-context broker is defined according to the dedicated domain. The federated and
distributed architecture of the NGSI-LD context brokers fully supports this desired hierarchy relation between cities and
communities.
ETSI
13 ETSI GR CIM 020 V1.1.1 (2022-12)

Figure 4.3-1: The distributed/federated structure of smart city and communities
A more complex approach to federation is gaining traction in the past few years, implemented in practice using the
concept of a Data Space composed of many building blocks. The concept of federation needs to be augmented with
Trust and Identity Providers, in order to form an effective, shared Data Space, as explained in clause 7.
4.4 Public lights in smart city example use case
This clause describes an example of the lifecycle of a public tender implemented and managed through an NGSI-LD
context broker in a smart city. It details the main actions requested for a public lighting tender. Figure 4.4-1 presents an
overview of how it would be possible to manage a public tender in an NGSI-LD-based city platform. The tender's life
cycle progress, steps, and its projection on NGSI-LD are detailed in the following.

Figure 4.4-1: Scenario overview for managing a public tender in a NGSI-LD-based city platform
• Submitting the public tender on the city platform:
After agreeing on the public tender internally, the city will start by publishing it on its platform. A public
tender is usually detailed by documents, objects (videos, images, etc.) and limited by deadlines. For
multimedia and object storage using context brokers refer to clause 5.3. Tender metadata (short description,
budget, deadline, requirement, etc.) and relations (responsible, related cities, etc.) may be modelled as
NGSI-LD Properties and Relationships.
ETSI
14 ETSI GR CIM 020 V1.1.1 (2022-12)
• Publishing the public tender on official government open data:
To make the tender public, its description and related objects should be published in official government open
data platforms. Official government APIs will have the access to the public tender details on the city platform.
This requires the adaptation of these APIs or the use of external services that publish the tender from the city
context broker to the open government data platforms. This external service for an open government data
platform could be one of the data portals in Figure 4.2-1.
• Applying for the public tender:
Using the official government APIs, public or private persons may apply to this tender with an offer that meets
the needs of this public tender in terms of supplies, services, and works. Offer details (description and objects)
and organizations need to be injected on the city platform and related to the concerned tender. The offer
information (applier, method, goal, etc.) may be modelled as NGSI-LD Properties and Relationships so that
every offer could be managed via the NGSI-LD context broker.
• Project management and progress monitoring:
Once the public tender deadline is reached, the city will select one of the available offers to be the winner of
the tender. Project deadlines, technical aspects, milestone monitoring, and budget progress may be monitored
by the NGSI-LD compliant city platform by injecting data. This kind of process could be a practical example
of monitoring in the smart city platform mentioned in clause 4.2.
• Project implementation:
The project may require a dedicated context broker that collects data related to public lights in the smart city
through oneM2M, open APIs, and other legacy systems connected to the city context broker with distributed
and/or federated structures with the city data platform. An application layer maybe then built on top of the
dedicated context broker for executing smart data-based applications. To develop, for instance, a dashboard or
an application meeting the requirements of the domain specific project, access control of each dedicated
context broker over the city context broker should be managed, as outlined in clause 10.
The public lights in the smart city use case is an example of a scenario that could currently be implemented with
NGSI-LD-based technologies introduced in the present document. The distributed structure referred to in clause 4.3
supports domain specific dedicated context brokers that can be given access to the developer, and the object storage
referred to in clause 5.3 makes it possible to manage not only the text of the project offer of the tender, but also various
multimedia materials.
5 Data sources for smart cities
5.0 Introduction
External data sources are crucial for smart cities and are used for injecting data. These data sources are considered as
the location where pieces of data are sourced. Technically, data sources can be simple systems or even complex
platforms, and using a variety of technologies, such as:
• Other NGSI-LD context brokers that are federated with the one(s) running the smart city platform.
• Message brokers (e.g. an MQTT broker), for attaching to raw streams of data.
• Open data platforms such as the ones hosting open government data.
• REST APIs-based Internet services such as weather or traffic APIs.
• IoT platforms such as complex oneM2M-based deployments.
• File content on a server such as text, CSV, spreadsheets, SQL dumps, etc.
• Multimedia objects on a server such as images and videos (could also be real-time).
ETSI
15 ETSI GR CIM 020 V1.1.1 (2022-12)
The goal, when integrating a data source within a smart city platform, is to be able to interface the platform with the
world of connected objects and data. Incoming data from external data sources is characterized by:
• An upstream data flow
• Heterogenous data formats
• Heterogenous data sources
• Highly variable data sending cycles/rates
• A potentially large number of sensors in the case of IoT platforms
5.1 Integrating data sources in an NGSI-LD platform
In this clause, the discussion assumes that the city platform is NGSI-LD compliant (thus, with an NGSI-LD context
broker at the centre of its architecture, as depicted in Figure 4.2-1), and possible ways of integrating it with external data
sources are depicted. Several modes of data source integration can be considered by the city, each option having
different technical and business impacts. Figure 5.1-1 details these modes of integration:
Option A: The data source is deployed by a third party (municipality, etc.) or maintained by the same city, by following
the principles of federated context brokers presented in clause 4.2. External applications, in this case, are expected to
communicate with the city platform via the NGSI-LD API.
Option B: The data source, in this case, is expected to be non-compliant to the NGSI-LD system. The data source could
be a oneM2M based IoT platform, or a stream of Linked Open Data for example (see clause 11). The city's platform
then should provide aggregators and interworking proxies capable of adapting to the different protocols, data models
and security modes used by the data source platform to NGSI-LD compliant format.
Option C: Equivalent to option B with the application layer developed by a third party and assumed to be
non-compliant with NGSI-LD. The application backend will be in charge of consuming data from the city data platform
and providing it to the application.
Option D: The entire chain from the data source to the application is not NGSI-LD compliant in this case. The data
source could be an open government data portal, or a stream of Linked Open Data for example. Data sources inject data
directly to the backend applications, and data is then, in turn, injected into the city's NGSI-LD context broker by the
application backend.
Figure 5.1-1: Integrating external data source platforms with an NGSI-LD compliant data platform
ETSI
16 ETSI GR CIM 020 V1.1.1 (2022-12)
5.2 Non-NGSI-LD-compliant data source management
This clause presents one of the possible ways for integration of non NGSI-LD compliant data sources with the city
platform.
Note that the following clauses should be seen as guidelines, and they are showing only one of the possible ways for
integrating of data source platforms with NGSI-LD compliant ones.
In this clause, an example of integrating an external data source with NGSI-LD data platform is presented. The proposed
approach follows partially the IoT Agent node library [i.5] approach, augmented with a full NGSI-LD-based provisioning.
Specifically, based on the features of the NGSI-LD API, the context broker could play the role of managing data sources
by means of creating correspondent entities. To consume data from data source, an external "data source management
layer" is needed. The data source management layer is in charge to register on the data platform and then to consume and
produce NGSI-LD compliant data. Figure 5.2-1 details the main architecture of integrating a data source platform and
management layer with the NGSI-LD compliant platform. The steps toward this integration are as follows:
• Register the data source management layer on the city platform by creating its correspondent entity.
• Create data source and mapping entities on the city platform.
• Extract and consume data about the created data source and mapping entities by the data source management
layer.
• Subscribe or connect on the data source platform by the data source management layer.
• Consume raw data from source platform.
• Format this raw data to follow the NGSI-LD structure with the help of details from the correspondent mapping
entity.
• Query the city data platform to inject this data.

Figure 5.2-1: Example of integrating Data Source platform and Managemen
...