ETSI GR CIM 023 V1.1.1 (2024-01)

Context Information Management (CIM); NGSI-LD; Case Study of NGSI-LD Adoptions

DGR/CIM-0023

General Information

• Status: Not Published
• Technical Committee: CIM - cross-cutting Context Information Management
• Current Stage: 12 - Completion
• Due Date: 03-Jan-2024
• Completion Date: 02-Jan-2024

Standards Content (Sample)

GROUP REPORT
Context Information Management (CIM);
NGSI-LD;
Case Study of NGSI-LD Adoptions
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 023 V1.1.1 (2024-01)
Reference
DGR/CIM-0023
Keywords
application, smart city, smart water, use case
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:
https://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
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
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 2024.
All rights reserved.
ETSI
3 ETSI GR CIM 023 V1.1.1 (2024-01)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Executive summary . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Adoption Case Study 1: Smart City Data Hub (South Korea) . 8
4.1 Introduction . 8
4.2 System Architecture . 9
4.3 NGSI-LD Adoptions . 11
4.4 Extensions . 12
4.5 Interworking and Modelling Requirements . 14
4.6 Potential API Requirements . 14
4.7 Conclusions and Recommendations . 14
5 Adoption Case Study 2: Water DNA . 16
5.1 Introduction . 16
5.2 System Architecture . 17
5.3 NGSI-LD Adoptions . 18
5.4 Extensions . 19
5.5 Interworking and Modelling Requirements . 19
5.6 Potential API Requirements . 19
5.7 Conclusions and Recommendations . 19
6 Adoption Case Study 3: ODALA . 19
6.1 Introduction . 19
6.2 System Architecture . 20
6.3 NGSI-LD Adoptions . 21
6.4 Conclusions and Recommendations . 22
7 Adoption Case Study 4: SALTED . 22
7.1 Introduction . 22
7.2 System Architecture . 23
7.3 NGSI-LD Adoptions . 23
7.4 Conclusions and Recommendations . 24
8 Adoption Case Study 5: India Urban Data Exchange (IUDX) . 24
8.1 Introduction . 24
8.2 System Architecture . 25
8.2.1 Architecture Overview . 25
8.2.2 Catalogue Server . 26
8.2.3 Authorization Server . 27
8.2.4 Resource Server . 28
8.3 NGSI-LD Adoptions . 28
8.4 Extensions . 28
8.4.1 API response extensions . 28
8.4.2 Additional APIs . 29
8.5 Interworking and Modelling Requirements . 30
ETSI
4 ETSI GR CIM 023 V1.1.1 (2024-01)
9 Conclusion . 31
History . 32

ETSI
5 ETSI GR CIM 023 V1.1.1 (2024-01)
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 NGSI-LD specification [i.1] has been implemented and deployed globally. The present document provides several
adoption cases as a proof of disseminations and serves as the reference material for the future users of NGSI-LD. Each
adoption case illustrates what is a deployed system and services, how the NGSI-LD standard is used. Not all the
adoptions are not listed here but there are more open sources that implement NGSI-LD and more deployments out there.
Therefore, the present document would be revised later to have more cases.
Introduction
The NGSI-LD specifications provide data management for different systems (e.g. smart city) leveraging Linked Data.
While the NGSI-LD Primer provides the developer guide, the present document provides where and how NGSI-LD are
used in real deployments.
ETSI
6 ETSI GR CIM 023 V1.1.1 (2024-01)
Having adoption cases in the present document is helpful for delegates of ETSI ISG CIM group as well as users of
NGSI-LD. With the description for each adoption, it is better understandable how to apply the standard for data
management platform in different services. The feedback from the deployments such as extensions, potential API and
each conclusion are for the delegates to consider future contributions to the specifications.
So far, the adoption cases cover Korean, Indian and European deployments including smart city, data marketplace and
water management domains. This would be extended to cover other regional adoptions soon with different open source
or commercial implementations.

ETSI
7 ETSI GR CIM 023 V1.1.1 (2024-01)
1 Scope
The present document provides the case studies of NGSI-LD adoptions. Basically, each case study consists of each
deployed system introduction with its architecture and adopted specifications. Then it is followed by implementation
extensions other than the NGSI-LD specifications, also interworking and modelling aspects. Based on the analysis, the
case study provides new functional requirements and recommendations for the future NGSI-LD standardizations if
there is any.
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 GS CIM 009 (V1.6.1): "Cross-cutting Context Information Management (CIM); NGSI-LD
API".
[i.2] ETSI GS CIM 013 (V1.1.1): "Context Information Management (CIM); NGSI-LD Test Purposes
Descriptions".
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:
AI Artificial Intelligence
AMQP Advanced Message Queuing Protocol
API Application Programming Interface
CCTV Closed-Circuit TeleVision
CPS Cyber-Physical System
CRUD Create Read Update and Delete
DNA Data, Network and AI
ETSI
8 ETSI GR CIM 023 V1.1.1 (2024-01)
EISS Epidemiological Investigation Support System
ETL Extract, Transform, Load
ID IDentifier
IoT Internet of Things
IUDX India Urban Data eXchange
KDCA Korea Disease Control & Prevention Agency
KETI Korea Electronics Technology Institute
LPWA Low Power Wide Area
ML Machine Learning
MQTT Message Queuing Telemetry Transport
NGSI-LD Next Generation Service Interface-Linked Data
ODALA Collaborative, Secure, and Replicable Open Source Data Lakes for Smart Cities
OIDC OpenID Connect
R&D Research and Develoment
RDF Resource Description Framework
REST REpresentational State Transfer
SAREF Smart Applications REFerence ontology
SEAS Smart Energy Aware System
TLS Transport Layer Security
UI User Interace
URI Uniform Resource Identifier
URN Uniform Resource Name
4 Adoption Case Study 1: Smart City Data Hub (South
Korea)
4.1 Introduction
In 2018, the National Smart City Strategic Program was launched and more than 100 organizations and 2 pilot cities
joined the program. It consists of 3 projects having 1 R&D project and 2 pilot projects in Siheung and Daegu city. The
st
role of the 1 project in the program is the technology provider and the scope of the core technology includes smart city
nd rd
data hub, massive IoT and digital twin. The Smart City Data Hub has been deployed by the 2 and 3 projects in the
two cities with smart city service implementations (e.g. disaster management).
The main motivation of the smart city program is to build data-driven smart cities upon the digital transformed cities.
To enable data-driven smart cities, a data centric smart city platform is the key and in case of South Korea, it is Smart
City Data Hub. The main role of the city data platform is to gather city data from heterogeneous data sources
(e.g. public data portal, legacy systems) and then process, analyse and distribute data to city services and external
systems.
There are many different data, in terms of syntax, semantics and periodicity, that gets collected to the city data platform.
Converting those data into common data models is necessary process for better data usage and less cost by service
applications. Also, for further usability of various domain data, linked data concept is considered. From ETSI
GS CIM 009 [i.1], NGSI-LD standard interfaces which fulfilled basic requirements to manage city linked data. To
leverage the linked data in the Smart City Data Hub, semantic web technologies with a smart city core ontology have
been used to see the potential of linked data.
ETSI
9 ETSI GR CIM 023 V1.1.1 (2024-01)

Figure 4.1-1: Overview of National Smart City Strategic Program in South Korea
4.2 System Architecture
st
Korea Electronics Technology Institute (KETI) consortium in the 1 project designed the reference architecture of
Smart City Data Hub as illustrated in Figure 4.2-1, which has been used the other two projects for their pilot
deployments. The architecture has been implemented by the consortium and has been released as open source, named
City Data Hub.
As intended by the NGSI-LD technology, the data hub collects city data from existing data systems. There are different
types of data sources, for instance IoT platforms (e.g. oneM2M), open data from public portals, legacy databases. that
are providing data to the data hub. The data hub manages collected data and utilizes the data in different purposes
(e.g. analytics) so it can be used in different city services. Also as a data platform, it provides security and other
management capabilities.
From the reference architecture, there are eight functional modules including the API gateway. City data gets collected
by the data ingest module and be stored in and managed by the data core module. The analytics, marketplace and
semantic modules consume data from the data core via NGSI-LD APIs and provides their functionalities to users. Other
non-data-handling modules provide platform managements.
The API gateway protects the platform from external applications/clients with token authentication with the security
module, API routing/blocking and request rate limit. The security module provides user account and client management
so it supports authentication and authorization with OAuth 2.0. The cloud management module enables system
administrator to monitor and manage the cloud infrastructure to run the Smart City Data Hub. Hybrid cloud, which uses
private and public clouds together, infra can be set up and managed such as monitoring and metering.
ETSI
10 ETSI GR CIM 023 V1.1.1 (2024-01)

Figure 4.2-1: Reference Architecture and Data Flow of Smart City Data Hub
The data stored by the data broker, that implements NGSI-LD APIs, interworks with other modules in the data hub.
Therefore, NGSI-LD APIs been used also to provide interoperability internally to the system. It is an important aspect
of extensibility since other data utilization modules can be added, and they implement NGSI-LD APIs for
interoperability. Also, the data core module serves city data to the external services/systems so having standard
interfaces is beneficial.
The analytics module provides AI/ML based analytics and prediction while providing data pre-processing, model
training/testing and model batch deployment capabilities. Data for model training and batch inference is provided by the
data core module. During the training dataset preparation, multiple datasets, possibly from different domains, get
mashed-up (e.g. parking events and weather). Several data pre-processing and training algorithms are supported so user
can build AI/ML models for different service needs. Each trained models can be deployed with batch schedules. On
each schedule, a model gets inference input data from the data core and ETL procedure and perform inference.
Inference result (e.g. parking congestion prediction) from ML models can be also stored into the data core, so it can be
used by other city applications as well.

Figure 4.2-2: City Data Utilization on Smart City Data Hub
ETSI
11 ETSI GR CIM 023 V1.1.1 (2024-01)
The data marketplace module is the back-end of the data marketplace portal. The data portal is also implemented to
rd
boost data distribution between data providers and consumers. It has been said that distributing data to 3 parties to
realize data-driven smart city is more important than just gathering big data from city infrastructures. A data provider
can sell data products which is stored in the data core. The marketplace module sends NGSI-LD queries to find user's
dataset, so selected data can be prepared as data products. When preparing the product, by the provider's preference,
specific attributes can be selected and even attribute names can be changed from the original NGSI-LD entity instances.
Purchased data can be used by fetching and receiving asynchronous notification which leverages NGSI-LD entity
retrieval and subscription/notification features.
The semantic module includes a triple store which get RDF triple data from a semantic annotator. The annotator gets
data over NGSI-LD APIs from the data core module and creates annotations with smart city ontologies. There has been
defined the smart city core ontology for domain extensions (e.g. parking ontology).
Following the reference architecture designed in the program, in Daegu, commercial data hub implementation, other
than open source based, has been deployed. Figure 4.2-3 describes the reference architecture of the Daegu case. As the
extension to the reference model to meet the requirements for Daegu such as legacy system interfaces and video stream
management in the data ingest module. For the data hub in the pilot city, several AI-based services have been tested.
City bus routes have been optimized for citizens and safety services like police patrol routes planning and CCTV
deployment optimization also been successfully deployed. With the data driven safety services as one of the best
practices for smart city data hub, the services have been disseminated in other cities with data hub deployments.

Figure 4.2-3: Reference Architecture of Daegu Smart City Data Hub
4.3 NGSI-LD Adoptions
City Data Hub, open source implementation of the Smart City Data Hub, adopts the essential NGSI-LD APIs as
summarized in Table 4.3-1. The NGSI-LD API specification defines temporal data manipulation such as POST to
"/temporal/entities/{entityId}" resource. In case of City Data Hub, as the specification also allows as a deployment
scenario, data manipulation gets handled over "/entities/" and its sub-resources. Only the historical data query is used
via "/temporal/entities" and "/temporal/entities/{entityId}" resources.
ETSI
12 ETSI GR CIM 023 V1.1.1 (2024-01)
Table 4.3-1: Supported NGSI-LD APIs by City Data Hub
REST Resource Operation Notes
/entities/ POST, GET
/entities/{entityId} GET , DELETE
/entities/{entityId}/attrs POST, PATCH
/entities/{entityId}/attrs/{attrId} PATCH, DELETE
Only GET operation is supported, context
/temporal/entities/ GET
consumption is provided with "/entities"
Only GET operation is supported, context
/temporal/entities/{entityId} GET consumption is provided with
"/entities/{entityId}" and its sub-resources
/subscriptions POST, GET
subscriptions/{subscriptionId} GET, PATCH, DELETE
/csourceRegistrations POST, GET
/csourceRegistrations/{registrationId} GET, PATCH, DELETE
/csourceSubscriptions POST, GET
/csourceSubscriptions/{subscriptionId} GET, PATCH, DELETE

Additional features like multi-attribute support with datasetId attribute and multi-typing are not supported in the City
Data Hub v1. The first version as minimum deployable solution focuses more on necessary capabilities for service
deployments over the Smart City Data Hub.
The context broker implementation has been validated with ETSI NGSI-LD tester prototype based on robot framework
and included test suites which implements conformance test cases in ETSI GS CIM 013 [i.2].
4.4 Extensions
Extending the API specifications in ETSI GS CIM 009 [i.1], the data hub architecture provides additional features. Data
schema management is one of the data core feature which also provides more expressivity than JSON Schema with
respect to data validation.
One major role of Smart City Data Hub is to provide data which fits to common data models. To use a new type of data
in the data hub, a new schema needs to be registered in the data core module. In ETSI GS CIM 009 [i.1], @context is
defined to represent linked data. However, there is no concept of schema management which is basically the binding
between Entity type information with corresponding attributes (i.e. Property and Relationship). To guarantee data-level
interoperability, when there is a new data ingested into the data core, before storing it in the data broker, optional data
schema validation can be performed.
ETSI
13 ETSI GR CIM 023 V1.1.1 (2024-01)

Figure 4.4-1: Data schema management UI
From the deployment experiences, mostly bulk data in the same data model is sent by the data sources. For instance,
fine dust sensor measurements from hundreds of devices are provided by an IoT platform. From the proxy point of
view, it is much simpler to implement not to remember whether a measurement, NGSI-LD Entity instance, has been
provided to NGSI-LD broker. Mapping between the IoT sensors and Entity instances is not required when Upsert
operation is supported. Therefore, Upsert operation per group of NGSI-LD instances was supported by the name of
dataset. After this feature implementation, different concept but same terminology as dataset has been added to the
NGSI-LD specification to support the multi attribute concept. It would be better to be discussed as data group for
example to avoid any confusion.
Access control per data group, called "dataset" in the Smart City Data Hub, also been implemented. A new data schema
is applied to the data core module, if needed, and then create a new data group for new data ingest. Then the data is
accessible by the data owner, who is authenticated by the security module and so is authorized for the data group in
terms of access control.
The data hub dataset manages metadata as depicted in Figure 4.4-2. REST APIs for dataset, as well as data model,
management have been defined and implemented. Per dataset schema validation and lifecycle can be configured. Also
targeted data storage per dataset can be selected (e.g. PostgreSQL, Hive, HBase).

Figure 4.4-2: Dataset management UI
ETSI
14 ETSI GR CIM 023 V1.1.1 (2024-01)
4.5 Interworking and Modelling Requirements
In the data broker, that uses NGSI-LD REST APIs, data models been defined using core NGSI-LD ontologies and those
includes service specific Entity attributes. In case of the semantic module, the smart city core ontology was designed by
analysing on SAREF4City and Smart Energy Aware Systems (SEAS) ontologies. As the proof-of-concept, parking
service data has been semantically described in RDF format with the parking ontology by extending the smart city core
ontology.
Figure 4.5-1: Parking ontology extending smart city core ontology
4.6 Potential API Requirements
From the Korean Smart City Data Hub system development, additional functional requirements for the NGSI-LD
system have been derived as Table 4.6-1.
Table 4.6-1: Potential API Requirements
Number Requirement
API-1 The NGSI-LD System shall be able to support data collection with grouping methods.
API-2 The NGSI-LD System shall be able to manage meta-data for a group of data.
API-3 The NGSI-LD System shall be able to manage schemas of data models.
API-4 The NGSI-LD System shall be able to support access control mechanisms per data group.
API-5 The NGSI-LD System shall be able to support the OAuth protocol for group-based access control.

4.7 Conclusions and Recommendations
Smart City Data Hub systems have been successfully deployed with smart city service pilots in Korean. For the City
Data Hub open source, parking congestion prediction service was implemented as proof-of-concept. Six different data
models were defined and data has been stored into the data core module. Collected data has been used by the analytics
module to build the AI model and feed the model for inference. Inference result, which is the parking congestion level,
also gets stored into the core via NGSI-LD API and shown as graphs on a parking service application.
ETSI
15 ETSI GR CIM 023 V1.1.1 (2024-01)

Figure 4.7-1: Parking Congestion Prediction with City Data Hub
In 2020, COVID-19 EISS (Epidemiological Investigation Support System) was built upon City Data Hub and being
operated by Korea Disease Control & Prevention Agency (KDCA). The motivation was to provide data-driven
epidemiological investigation support system which shortens the COVID-19 confirm case tracking process with the
help of City Data Hub. It collects data from external systems such as mobile operators, credit card companies. Then
pre-processing filtered the raw data so past few days routes of a confirmed person get created for investigators. With
further analytics, intersections have been analysed for different confirmed case and been used to prepare preventive
measures against epidemics by authorities. Those processed data get stored into the data core module and be used by the
EISS portal over NGSI-LD APIs.

Figure 4.7-2: COVID-19 EISS over City Data Hub
ETSI
16 ETSI GR CIM 023 V1.1.1 (2024-01)
NGSI-LD, adopted for in the Smart City Data Hub system, has potential with linked data since there are ton of scattered
and fragmented data in smart cities. Therefore linking cross-domain data from different sources is being encouraged to
have value-added data/information so it can be used to solve city problems.
Since NGSI-LD APIs support JSON as well as JSON-LD format, ordinary web developers could have easily
implemented their services with minimum developer guides. From their point of view, someone else manages @context
so they do not worry about @context definitions but use a common URI per system guide.
Leveraging linked data like graph traversal over multiple NGSI-LD Entities could be candidate scenario to be
considered. Currently NGSI-LD REST APIs provides query per single Entity instance.
Federation of the data hub is one of the main features for the next version of the system and that elaborates the different
deployment configurations concepts (e.g. federated context brokers) in the ETSI CIM GS 009 [i.1]. There would be
many use cases for data sharing or federation among data hubs (e.g. public transportation across several cities), it is one
of the key requirements for the successful data hub deployments.
5 Adoption Case Study 2: Water DNA
5.1 Introduction
From 2019 to 2022, the intelligent urban water resource management program, funded by the Ministry of Environment
has been performed in South Korea. The program consists of the projects such as a pilot for intelligent urban water
resource management operation with digital twin, integrated water data management, and decision-making support with
CPS simulations. The water data management platform with the NGSI-LD APIs has been deployed for the testbed,
which is the Haemil district in Sejong city.

Figure 5.1-1: Urban water resource management with digital twin
From the data management point of view the goal of the project is to collect, store and serve water resource data for the
entire urban water cycle. In brief, when raw water is taken at pump stations, it gets purified. To distributed to
households and buildings, the water firstly is delivered to reservoirs. Storm water is also used in a city and sewage is
treated at sewage treatment plants. After that, the treated water is released in rivers.
Each component of the water cycle is operated by different organizations hence water resource data is fragmented in
different systems. The required data for the pilot services in the program, data from different sources has been collected
and stored in the data platform named Water DNA (Data, Network and AI). The Water DNA platform gathers the water
data from different systems and provides them to different applications (e.g. CPS simulations) in the program.
ETSI
17 ETSI GR CIM 023 V1.1.1 (2024-01)

Figure 5.1-2: Urban water cycle and water resources
5.2 System Architecture
Heterogeneous water resource data from different data sources are collected with each data adapter.
Data pertaining to the water cycle segments other than the testbed (e.g. households) is publicly available with open
APIs. The flowrate data per building is gathered from the local proprietary system interworking to the Water DNA. IoT
devices (e.g. water quality sensor) are also deployed in the pilot area and sensing data was transmitted over a private
LPWA network. All the gathered data is stored in the NGSI-LD based data platform. In the Water DNA, the NGSI-LD
compatible water data models have been defined, which are contributed to water domain data models in Smart Data
Models initiative (http://smartdatamodels.org). With the data model schemas, data quality management have been done.
ETSI
18 ETSI GR CIM 023 V1.1.1 (2024-01)

Figure 5.2-1: Water DNA with urban water management systems
The platform also provides common applications (e.g. water data portal) in terms of water data management. The user
data portal provides 3D facility (e.g. water purification plant) management as well as data query and monitoring. The
common data models applied in the water data platform has been guarantee data-level interoperability with other
systems as depicted in Figure 5.2-1.
Not just raw data collected but synthetic data has also been generated and used. In the platform, AI data analytics
feature creates water resource prediction (e.g. water demands in next 24 hours) and the results get stored in the
platform. The CPS decision-making support system performs simulations and generate data which cannot be physically
monitored (e.g. pressure in the pipe without physical sensors) due to limitations in the testbed. Those synthetic data and
physical raw data are all monitored on the digital twin based urban water operation system.
5.3 NGSI-LD Adoptions
The Water DNA platform leverages the NGSI-LD open source implementation in Korea, which is the City Data Hub
(see clause 5.2). In the system deployment, the central broker model was deployed and the NGSI-LD APIs summarized
in Table 5.3-1 that is a subset of Table 4.3-1, are used.
Table 5.3-1: Supported NGSI-LD APIs by Water DNA
REST Resource Operation Notes
/entities/ POST, GET
/entities/{entityId} GET , DELETE
/entities/{entityId}/attrs POST, PATCH
/entities/{entityId}/attrs/{attrId} PATCH, DELETE
Only GET operation is supported, context
/temporal/entities/ GET
consumption is provided with "/entities"
Only GET operation is supported, context
/temporal/entities/{entityId} GET consumption is provided with
"/entities/{entityId}" and its sub-resources
/subscriptions POST, GET
subscriptions/{subscriptionId} GET, PATCH, DELETE

ETSI
19 ETSI GR CIM 023 V1.1.1 (2024-01)
5.4 Extensions
Since the Water DNA platform is based on the City Data Hub open source S/W, extensions to the NGSI-LD are
basically the same. In terms of query capabilities, the entity query per dataset ID and data storage type is supported.
5.5 Interworking and Modelling Requirements
The targets of NGSI-LD Entity modelling are two types: water facilities and water sensors. A water facility has a
Property which is related to Properties from sensors. For instance, at a pump station, an intake flowrate is defined for
the pump station which is measured by a flowmeter in the plant. NGSI-LD Relationships are defined for this
facility-sensor relationships.
From the pilot services, a common NGSI-LD Property "isVirtual" defined. This can be applied to any virtual data
observation. For example, a water pressure value as a simulation result is marked as virtual. By some applications it
could be an important information where real vs. virtual data distinction is important. For different simulation scenarios,
sometimes physical observation can be used as input, but to test other scenarios, virtual data can be generated, stored in
the NGSI-LD data platform and finally served as simulation inputs.
5.6 Potential API Requirements
From the Water DNA platform that interworks with other water systems deployment, additional functional requirements
for the NGSI-LD system have been derived as Table 5.6-1.
Table 5.6-1: Potential API Requirements
Number Requirement
The NGSI-LD System shall be able to support meta data to indicate synthetic/virtual data over physical
API-1
data.
The NGSI-LD System shall be able to support common methods to associate synthetic data with
API-2
physical data.
5.7 Conclusions and Recommendations
In water domain, which is still a single domain, data systems in the water cycle are fragmented. The Water DNA
platform with the NGSI-LD standard interfaces and common data models integrate heterogeneous water data from
different data sources to enable integrated urban water resource management. When the water data is managed by the
standard compatible data platform, other water applications do not need to collect data each time with different
interfaces/protocols.
From urban water management perspective, the other environmental data and smart city data should be considered for
value-added service implementations in the future. Water data modelling which related to those domain data models
and leveraging those Relationships with the extended standard interfaces would be the one of the way forwards.
6 Adoption Case Study 3: ODALA
6.1 Introduction
The Connecting Europe Facility (https://cinea.ec.europa.eu/programmes/connecting-europe-facility_en) is a key EU
funding instrument to promote growth, jobs and competitiveness through infrastructure investment at European level. In
this context, the ODALA (Collaborative, Secure, and Replicable Open Source Data Lakes for Smart Cities) project has
been funded.
ETSI
20 ETSI GR CIM 023 V1.1.1 (2024-01)
ODALA was launched in September of 2020 to run for a duration of three years. It is a collaboration between European
cities, different private companies and research institutes, and the goal is to improve data management and sharing
between cities and regions. According to Jonas Dageförde, Chief Digital Officer, City of Kiel, and coordinator of
ODALA, the goal is to create "a virtual place to bring data together in a secure and trusted way and to make it usable
for the city but also for third parties". A core goal is to facilitate decision making in public administrations, with a focus
on mobility and environmental aspects of a smart city.
To achieve this, ODALA aims to provide a set of components for cities to pick and choose for their use cases. The
ODALA Connected Broker implemented based on the Scorpio NGSI-LD Broker is at the core of the ODALA
architecture as shown in Figure 6.1-1. Input is provided by many different sources and output is provided to many
components and applications that extract higher-level information and make it available to users in a suitable way,
enabling better decision making. ODALA uses NGSI-LD compliant Smart Data Models (https://smartdatamodels.org/).

Figure 6.1-1: High-level ODALA Architecture
...