ETSI GR CIM 024 V1.1.1 (2024-02)

Context Information Management (CIM); NGSI-LD Architecture Deployment Scenarios

DGR/CIM-0024

General Information

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

Standards Content (Sample)

GROUP REPORT
Context Information Management (CIM);
NGSI-LD Architecture Deployment Scenarios
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 024 V1.1.1 (2024-02)

Reference
DGR/CIM-0024
Keywords
architecture, scenarios
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 024 V1.1.1 (2024-02)
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 Overview . 8
5 Deployment scenario #1 - centralized architecture . 8
5.1 Introduction . 8
5.2 NGSI-LD system configuration . 8
5.3 Deployment scenario example - smart parking . 9
5.3.1 Overview . 9
5.3.2 Service component mapping . 9
5.3.3 Scenarios . 10
5.3.3.1 Parking space availability retrieval . 10
6 Deployment scenario #2 - distributed architecture . 12
6.1 Introduction . 12
6.2 NGSI-LD system configuration . 12
6.3 Deployment scenario example #1 - street light control using exclusive mode . 13
6.3.1 Overview . 13
6.3.2 Service component mapping . 13
6.3.3 Scenarios . 14
6.3.3.1 Street light management platform registration . 14
6.3.3.2 Street light information retrieval . 15
6.3.3.3 Street light status control . 17
6.4 Deployment scenario example #2 - national power line using inclusive mode . 19
6.4.1 Overview . 19
6.4.2 Service component mapping . 19
6.4.3 Scenarios . 20
6.4.3.1 Regional power line platform registration . 20
6.4.3.2 Power line status retrieval . 21
6.4.3.3 Power line statistics retrieval. 24
6.5 Deployment scenario example #3 - national disaster warning using redirect mode . 26
6.5.1 Overview . 26
6.5.2 Service component mapping . 27
6.5.3 Scenarios . 28
6.5.3.1 Warning system registration. 28
6.5.3.2 Disaster event trigger . 29
6.5.3.3 Disaster event update . 31
6.6 Deployment scenario example #4 - Off-street parking using auxiliary mode . 32
6.6.1 Overview . 32
6.6.2 Service component mapping . 32
6.6.3 Scenarios . 34
6.6.3.1 Off-street parking agent registration . 34
6.6.3.2 information retrieval of off-street parking lot . 35
ETSI
4 ETSI GR CIM 024 V1.1.1 (2024-02)
7 Deployment Scenario #3 - Federated Architecture . 37
7.1 Introduction . 37
7.2 Architectural Configuration. 37
7.3 Deployment scenario example - national traffic ticket management . 38
7.3.1 Overview . 38
7.3.2 Service component mapping . 38
7.3.3 Scenarios . 41
7.3.3.1 Regional platform registration . 41
7.3.3.2 Information retrieval of traffic violation events . 42
7.3.3.3 Registration information retrieval of vehicle with traffic violations . 44
7.3.3.4 Publish traffic tickets. 46
8 Conclusions . 47
Annex A: Change history . 48
History . 49

ETSI
5 ETSI GR CIM 024 V1.1.1 (2024-02)
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 is intended to provide developers with supplement descriptions based on Next Generation
Service Interface Linked Data (NGSI-LD) architectural considerations that are discussed in the NGSI-LD Application
Programming Interface (API) specification. The aim is to give detailed statements for how to configure NGSI-LD
systems and use the distributed operations of NGSI-LD API in various deployment scenarios using central, distributed,
and federated architecture configurations.
Introduction
While ETSI GS CIM 009 [i.1] provides the distributed architectural concepts with distributed operations. However, it
could be difficult to implement the specifications without further informative deliverables. The present document is
intended to help readers how to configure NGSI-LD systems using a centralized, distributed, or federated architectures.
ETSI
6 ETSI GR CIM 024 V1.1.1 (2024-02)
Each deployment scenario consists of the following:
• Service scenario
• System configuration with components (e.g. national disaster warning platform)
• NGSI-LD entity modelling (e.g. EarthquakeEvent)
• Request message of each distributed operation

ETSI
7 ETSI GR CIM 024 V1.1.1 (2024-02)
1 Scope
The present document provides detailed statements for how to configure NGSI-LD system and use the distributed
operations of NGSI-LD API in the centralized, distributed, and federated architectures. Those architectural
considerations are described in ETSI GS CIM 009 [i.1].
The present document includes the following topics:
• NGSI-LD deployment scenarios and usage of NGSI-LD API operations using the centralized architecture.
• NGSI-LD deployment scenarios and usage of distributed operations of NGSI-LD API using the distributed
architecture.
• NGSI-LD deployment scenarios and usage of distributed operations of NGSI-LD API using the federated
architecture.
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.7.1): "Context Information Management (CIM); NGSI-LD API".
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:
API Application Programming Interface
CSR Context Source Registration
ID IDentifier
ETSI
8 ETSI GR CIM 024 V1.1.1 (2024-02)
NGSI-LD Next Generation Service Interfaces Linked Data
URI Uniform Resource Identifier
4 Overview
The present document supplements the architectural considerations of NGSI-LD API specification (see clause 4.3 in
ETSI GS CIM 009 [i.1]). For this purpose, the present document provides deployment scenarios with NGSI-LD system
configuration and examples.
Table 4-1 shows the relationship between the present document and NGSI-LD API specification.
Table 4-1: Relationship between the present document and NGSI-LD API specification
The NGSI-LD API specification ETSI
Deployment scenario The present document
GS CIM 009 [i.1]
Centralized architecture Clause 5 Clause 4.3.2
Distributed architecture using
Clause 6 Clause 4.3.3 and 4.3.6
exclusive mode
Distributed architecture using inclusive
Clause 6 Clause 4.3.3 and 4.3.6
mode
Distributed architecture using redirect
Clause 6 Clause 4.3.3 and 4.3.6
mode
Distributed architecture using auxiliary
Clause 6 Clause 4.3.3 and 4.3.6
mode
Federated architecture Clause 7 Clause 4.3.4 and 4.3.6

5 Deployment scenario #1 - centralized architecture
5.1 Introduction
The clause 5 describes an NGSI-LD API-based simple data production and consumption using the centralized
architecture (see clause 4.3.2 in ETSI GS CIM 009 [i.1]).
5.2 NGSI-LD system configuration
Figure 5.2-1 shows an NGSI-LD system for simple data production and consumption using the centralized architecture.

Figure 5.2-1: NGSI-LD system for simple data production and consumption using
the centralized architecture
ETSI
9 ETSI GR CIM 024 V1.1.1 (2024-02)
The definition of the central broker, context producer, and context consumer is specified in clause 3.1 of ETSI
GS CIM 009 [i.1].
Context information provision operations are specified in clause 5.6 of ETSI GS CIM 009 [i.1].
Context information consumption operations are specified in clause 5.7 of ETSI GS CIM 009 [i.1].
Context information subscription operations are specified in clause 5.8 of ETSI GS CIM 009 [i.1].
5.3 Deployment scenario example - smart parking
5.3.1 Overview
A building has a number of parking spaces. For each parking space, a vehicle detection sensor is installed and
connected to a smart parking server. Every time the vehicle detection sensor detects a vehicle in its parking space, it
sends a detection event to the smart parking server.
Now, a building customer drives to the building and looks for available parking spaces using the smart parking
application.
5.3.2 Service component mapping
Figure 5.3.2-1 shows a service component mapping to the NGSI-LD system.

Figure 5.3.2-1: Service component mapping to the NGSI-LD system
Table 5.3.2-1 shows an example data model of the entity VehicleDetector. Each vehicle detector has its entity ID and
their context information is persisted in the smart parking server.
Table 5.3.2-1: Example data model of entity VehicleDetector
Name Type Restriction Cardinality Description
id URI 1 Entity identifier (ID) of vehicle detector
type String The value is equal to 1 Entity type
"http://example.org/ngsi-
ld/VehicleDetector"
name String 1 Property for indicating a parking space
isDetected Boolean 1 Property for indicating a vehicle is
detected or not:
• false: not detected
• true: detected
location GeoJSON 0.1 Property for location of the installation
point for the vehicle detection sensor

ETSI
10 ETSI GR CIM 024 V1.1.1 (2024-02)
5.3.3 Scenarios
5.3.3.1 Parking space availability retrieval
Figure 5.3.3.1-1 shows communication flows to get available parking spaces.

Figure 5.3.3.1-1: Communication flows to get available parking spaces
Each step is described as follows:
1) Vehicle detector 1F-A1-01 provisions its context information to the smart parking server.
- The entity creation request (see clause 5.6.1 in ETSI GS CIM 009 [i.1]) includes the entity resource (see
clause 5.2.4 in ETSI GS CIM 009 [i.1]):
{
"id": "urn:ngsi-ld:VehicleDetector:1F:A1:1",
"type": "VehicleDetector",
"name": {
"type": "Property",
"value": "1F-A1-01"
},
"isDetected": {
"type": "Property",
"value": true,
"observedAt": "2023-01-01T12:00:00Z"
},
"location": {
"type": "GeoProperty",
"value": {
"type": "Point",
"coordinates": [127.16019783463986, 37.40378558266181]
}
},
"@context": [
"http://example.org/ngsi-ld/latest/vehicle-detector.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
}
2) Smart parking server sends back the successful response.
3) Vehicle detector 1F-A2-02 provisions its context information to smart parking server.
- The entity creation request (see clause 5.6.1 in ETSI GS CIM 009 [i.1]) includes the entity resource (see
clause 5.2.4 in ETSI GS CIM 009 [i.1]):
{
"id": "urn:ngsi-ld:VehicleDetector:1F:A2:2",
"type": "VehicleDetector",
"name": {
"type": "Property",
"value": "1F-A2-02"
},
ETSI
11 ETSI GR CIM 024 V1.1.1 (2024-02)
"isDetected": {
"type": "Property",
"value": true,
"observedAt": "2023-01-01T12:00:00Z"
},
"location": {
"type": "GeoProperty",
"value": {
"type": "Point",
"coordinates": [127.16019783463986, 37.40378558266181]
}
},
"@context": [
"http://example.org/ngsi-ld/latest/vehicle-detector.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
}
4) Smart parking server sends back the successful response.
5) Smart parking application subscribes for available parking spaces.
- The subscription creation request (see clause 5.8.1 in ETSI GS CIM 009 [i.1]) includes the subscription
resource (see clause 5.2.12 in ETSI GS CIM 009 [i.1]):
{
"type": "Subscription",
"entities": [
{
"type": "VehicleDetector"
}
],
"watchedAttributes": ["name", "isDetected"],
"q": "isDetected==false",
"notification": {
"attributes": ["name", "isDetected"],
"endpoint": "http://smart-parking-application.app.smartphone"
},
"@context": [
"http://example.org/ngsi-ld/latest/vehicle-detector.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
}
6) Smart parking server creates subscription resource and responds with the successful response.
7) Vehicle detector 1F-A1-01 detects a vacancy for its parking space and updates vacancy information to smart
parking server.
- The partial attribute update request (see clause 5.6.4 in ETSI GS CIM 009 [i.1]) for the entity
"urn:ngsi-ld:VehicleDetector:1F:A1:1" is as follows:
{
"isDetected": false
}
8) Smart parking server updates the attributes for the entity resource and responds with the successful response.
9) Smart parking server checks if there is one or more subscription(s) match with the event in step 8, , then the
server notifies to notification endpoint of the subscription.
- There is one subscription that is created in the step 5, according to the notification behaviour (see
clause 5.8.6 in ETSI GS CIM 009 [i.1]), smart parking server notifies to smart parking application with
the following notification resource (see clause 5.3.1 in ETSI GS CIM 009 [i.1]):
{
"id": "urn:ngsi-ld:Notification:1",
"type": "Notification",
"subscriptionId": "urn:ngsi-ld:Subscription:1",
"notifiedAt": "2023-01-01T14:00:00Z",
"data": [
{
"id": "urn:ngsi-ld:VehicleDetector:1F:A1:1",
"type": "VehicleDetector",
ETSI
12 ETSI GR CIM 024 V1.1.1 (2024-02)
"name": {
"type": "Property",
"value": "1F-A1-01"
},
"isDetected": {
"type": "Property",
"value": false,
"observedAt": "2023-01-01T14:00:00Z"
},
"@context": [
"http://example.org/ngsi-ld/latest/vehicle-detector.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
}
],
"@context": [
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
}
6 Deployment scenario #2 - distributed architecture
6.1 Introduction
The clause 6 describes an NGSI-LD API-based interactions using the distributed architecture (see clause 4.3.3 in ETSI
GS CIM 009 [i.1]).
6.2 NGSI-LD system configuration
Figure 6.2-1 shows an NGSI-LD system using the distributed architecture.

Figure 6.2-1: NGSI-LD system using the distributed architecture
The definition of the distribution broker, context producer, context consumer, context source, and context registry are
specified in clause 3.1 of ETSI GS CIM 009 [i.1].
Context information provision operations are specified in clause 5.6 of ETSI GS CIM 009 [i.1].
Context information consumption operations are specified in clause 5.7 of ETSI GS CIM 009 [i.1].
Context information subscription operations are specified in clause 5.8 of ETSI GS CIM 009 [i.1].
Context source registration operations are specified in clause 5.9 of ETSI GS CIM 009 [i.1].
Context source discovery operations are specified in clause 5.10 of ETSI GS CIM 009 [i.1].
Context source registration subscription operations are specified in clause 5.11 of ETSI GS CIM 009 [i.1].
ETSI
13 ETSI GR CIM 024 V1.1.1 (2024-02)
NOTE: In order to show interactions among context registry and others, the present document assumes that the
context broker and context registry are running independently. The functionality of the context broker and
context registry can be integrated. How to integrate context broker and context registry is outside the
scope of the present document.
6.3 Deployment scenario example #1 - street light control using
exclusive mode
6.3.1 Overview
A smart city management office in a metropolitan city has a smart city management platform that controls city
infrastructures. In the city, a number of street lights are installed and connected to street light management platforms,
managed by each vendor. The smart city management platform is interworking with street light management platforms
of different vendors. Information of each street light management platform is contained in smart city management
registry.
Now, a smart city management officer wants to turn on street lights within a specific area of the city using a smart city
management application. The management application controls the status of street lights via the smart city management
platform.
6.3.2 Service component mapping
Figure 6.3.2-1 shows a service component mapping to the NGSI-LD system configuration.

Figure 6.3.2-1: Service component mapping to the NGSI-LD system configuration
Table 6.3.2-1 shows an example data model of the entity StreetLight. How to manage StreetLight entities themselves in
the street light management platform is beyond the scope of the present document. Each street light is mapped with the
StreetLight entity and their context information is persisted in the street light management platform of a specific vendor.
Table 6.3.2-1: Example data model of entity StreetLight
Name Type Restriction Cardinality Description
id URI 1 Entity ID of street light
type String It is equal to 1 Entity type
"http://example.org/ngsi-
ld/StreetLight"
status Boolean 1 Property for on/off status of light:
• false: the light is turned off
• true: the light is turned on
vendorName String 1 Property for the vendor name of
street light
location GeoJSON 0.1 Property for the installed location of
light in a city
ETSI
14 ETSI GR CIM 024 V1.1.1 (2024-02)
An instance of the entity StreetLight is described as follows:
{
"id": "urn:ngsi-ld:StreetLight:VendorA:NewYork:Broadway:1",
"type": "StreetLight",
"status": {
"type": "Property",
"value": false,
"observedAt": "2023-01-01T12:00:00Z"
},
"vendorName": {
"type": "Property",
"value": "A"
},
"location": {
"type": "GeoProperty",
"value": {
"type": "Point",
"coordinates": [-73.990897, 40.734593]
}
},
"@context": [
"http://example.org/ngsi-ld/latest/street-light.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
}
6.3.3 Scenarios
6.3.3.1 Street light management platform registration
Figure 6.3.3.1-1 shows communication flows to register street light management platforms.

Figure 6.3.3.1-1: Communication flows to register street light management platforms
Each step is described as follows:
1) Street light management platform for vendor A registers to smart city management registry, as a context
source:
- The context source registration request (see clause 5.9.2 in ETSI GS CIM 009 [i.1]) includes the
following CsourceRegistration resource (see clause 5.2.9 in ETSI GS CIM 009 [i.1]):
{
"type": "ContextSourceRegistration",
"information": [
{
"entities": [
{
"idPattern": "urn:ngsi-ld:StreetLight:VendorA:*",
"type": "StreetLight"
}
],
"propertyNames": ["status", "vendorName"]
}
],
"mode": "exclusive",
ETSI
15 ETSI GR CIM 024 V1.1.1 (2024-02)
"endpoint": "http://street-light-management-platform.a",
"@context": [
"http://example.org/ngsi-ld/latest/street-light.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
}
2) Smart city management registry creates CsourceRegistration resource and then responds with the registration
ID:
- In this example, the registration ID is "urn:ngsi-ld:ContextSourceRegistration:A".
3) Street light management platform for vendor B registers to smart city management registry, as a context
source:
- The context source registration request (see clause 5.9.2 in ETSI GS CIM 009 [i.1]) includes the
CsourceRegistration resource (see clause 5.2.9 in ETSI GS CIM 009 [i.1]):
{
"type": "ContextSourceRegistration",
"information": [
{
"entities": [
{
"idPattern": "urn:ngsi-ld:StreetLight:VendorB:*",
"type": "StreetLight"
}
],
"propertyNames": ["status", "vendorName"]
}
],
"mode": "exclusive",
"endpoint": "http://street-light-management-platform.b",
"@context": [
"http://example.org/ngsi-ld/latest/street-light.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
}
4) Smart city management registry creates CsourceRegistration resource and then responds with the registration
ID:
- In this example, the registration ID is "urn:ngsi-ld:ContextSourceRegistration:B".
6.3.3.2 Street light information retrieval
NOTE: This scenario assumes that the NGSI-LD system already performed the procedures in clause 6.3.3.1.
Thus, smart city management registry has two context sources: "urn:ngsi-
ld:ContextSourceRegistration:A" and "urn:ngsi-ld:ContextSourceRegistration:B".
Figure 6.3.3.2-1 shows communication flows to retrieve street light information.

Figure 6.3.3.2-1: Communication flows to retrieve street light information
ETSI
16 ETSI GR CIM 024 V1.1.1 (2024-02)
Each step is described as follows:
1) Smart city management application requests street light information to smart city management platform:
- The request is querying entities (see clause 5.7.2 in ETSI GS CIM 009 [i.1]) with entity type StreetLight.
2) Smart city management platform finds matching context information locally, but there is no match.
3) Smart city management platform finds CSR information of the entity type StreetLight from smart city
management registry:
- The request is discovering context source registrations (see clause 5.10.2 in ETSI GS CIM 009 [i.1])
with the entity type StreetLight.
4) Smart city management registry responds with a matching CSR list:
- The CSR list has the following information:
[
{
"id": "urn:ngsi-ld:ContextSourceRegistration:A",
"type": "ContextSourceRegistration",
"information": [
{
"entities": [
{
"idPattern": "urn:ngsi-ld:StreetLight:VendorA:*",
"type": "StreetLight"
}
],
"propertyNames": ["status", "vendorName"]
}
],
"mode": "exclusive",
"endpoint": "http://street-light-management-platform.a",
"@context": [
"http://example.org/ngsi-ld/latest/street-light.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
},
{
"id": "urn:ngsi-ld:ContextSourceRegistration:B",
"type": "ContextSourceRegistration",
"information": [
{
"entities": [
{
"idPattern": "urn:ngsi-ld:StreetLight:VendorB:*",
"type": "StreetLight"
}
],
"propertyNames": ["status", "vendorName"]
}
],
"mode": "exclusive",
"endpoint": "http://street-light-management-platform.b",
"@context": [
"http://example.org/ngsi-ld/latest/street-light.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
}
]
- From this step, the smart city management platform knows the request need to be forwarded to smart
light management platform for vendor A and vendor B.
5) Smart city management platform forwards the request to street light management platform for vendor A.
6) Street light management platform for vendor A responds with a matching entity list:
- The matching entity list contains all entity information that is persisted in the street light management
platform for vendor A.Smart city management platform forwards the request to street light management
platform for vendor B.
ETSI
17 ETSI GR CIM 024 V1.1.1 (2024-02)
7) Street light management platform for vendor B responds with a matching entity list:
- The matching entity list contains all entity information that is persisted in the street light management
platform for vendor B.
8) Smart city management platform aggregates responses from each street light management platform and
responds to smart city management application with an aggregated entity list:
- The aggregated entity list contains the following entities:
[
{
"id": "urn:ngsi-ld:StreetLight:VendorA:NewYork:Broadway:1",
"type": "StreetLight",
"status": {
"type": "Property",
"value": false,
"observedAt": "2023-01-01T12:00:00Z"
},
"vendorName": {
"type": "Property",
"value": "A"
},
"@context": [
"http://example.org/ngsi-ld/latest/street-light.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
},
{
"id": "urn:ngsi-ld:StreetLight:VendorB:NewYork:Broadway:10",
"type": "StreetLight",
"status": {
"type": "Property",
"value": false,
"observedAt": "2023-01-01T12:00:00Z"
},
"vendorName": {
"type": "Property",
"value": "B"
},
"@context": [
"http://example.org/ngsi-ld/latest/street-light.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
}
]
6.3.3.3 Street light status control
NOTE 1: This scenario assumes that the NGSI-LD system already performed the procedures in clause 6.3.3.1.
Thus, smart city management registry has two context
sources: "urn:ngsi-ld:ContextSourceRegistration:A" and "urn:ngsi-ld:ContextSourceRegistration:B".
NOTE 2: This scenario also assumes that smart city management application knows two StreetLight entities
"urn:ngsi-ld:StreetLight:VendorA:NewYork:Broadway:1" and
"urn:ngsi-ld:StreetLight:VendorB:NewYork:Broadway:10".
NOTE 3: How to control actual street lights in street light management platform is outside the scope of the present
document.
Figure 6.3.3.3-1 shows communication flows to turn on street lights.
ETSI
18 ETSI GR CIM 024 V1.1.1 (2024-02)

Figure 6.3.3.3-1: Communication flows to turn on street lights
Each step is described as follows:
1) Smart city management application requests smart city management platform to turn on the street light for the
entity "urn:ngsi-ld:StreetLight:VendorA:NewYork:Broadway:1":
- The partial attribute update request (see clause 5.6.4 in ETSI GS CIM 009 [i.1]) for the entity
"urn:ngsi-ld:StreetLight:VendorA:NewYork:Broadway:1" is as follows:
{
"status": {
"type": "Property",
"value": true,
"observedAt": "2023-09-14T12:00:00Z"
},
"@context": [
"http://example.org/ngsi-ld/latest/street-light.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
}
2) Smart city management platform finds CSR information of the entity type StreetLight from smart city
management registry:
- The request is discovering context source registrations (see clause 5.10.2 in ETSI GS CIM 009 [i.1])
with the entity type StreetLight.
3) Smart city management registry responds with a matching CSR list:
- The CSR list has the following information:
[
{
"id": "urn:ngsi-ld:ContextSourceRegistration:A",
"type": "ContextSourceRegistration",
"information": [
{
"entities": [
{
"idPattern": "urn:ngsi-ld:StreetLight:VendorA:*",
"type": "StreetLight"
}
],
"propertyNames": ["status", "vendorName"]
}
],
"mode": "exclusive",
"endpoint": "http://street-light-management-platform.a",
"@context": [
"http://example.org/ngsi-ld/latest/street-light.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
},
{
"id": "urn:ngsi-ld:ContextSourceRegistration:B",
"type": "ContextSourceRegistration",
"information": [
{
"entities": [
{
ETSI
19 ETSI GR CIM 024 V1.1.1 (2024-02)
"idPattern": "urn:ngsi-ld:StreetLight:VendorB:*",
"type": "StreetLight"
}
],
"propertyNames": ["status", "vendorName"]
}
],
"mode": "exclusive",
"endpoint": "http://street-light-management-platform.b",
"@context": [
"http://example.org/ngsi-ld/latest/street-light.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.7.jsonld"
]
}
]
- From this step, the smart city management platform knows the request need to be forwarded to the smart
light management platform for vendor A.
4) Smart city management platform forwards the partial attribute update request to street light management
platform for vendor A.
5) Street light management platform for vendor A turns on the specified street light and responds with the
successful response to smart city management platform.
6) Smart city management platform forwards the successful response to smart city management application.
6.4 Deployment scenario example #2 - national power line
using inclusive mode
6.4.1 Overview
A country has a national power line platform that manages national power usage and availability. In the platform, power
lines are grouped by geographical regions.
A regional power line company has a power line platform that manages specific power lines in the geographical region.
Now, an administrator of a national power line company wants to know the power line status and statistics of each
region.
6.4.2 Service component mapping
Figure 6.4.2-1 shows a service component mapping to the NGSI-LD system.

Figure 6.4.2-1: Service component mapping to the NGSI-LD system
ETSI
20 ETSI GR CIM 024 V1.1.1 (2024-02)
Table 6.4.2-1 shows an example data model of the entity PowerLine. How to manage PowerLine entities in regional
power line companies is beyond the scope of the present document. Each power line is mapped with PowerLine entity
and their context information is persisted in a regional power line platforms.
Table 6.4.2-1: Example data model of entity PowerLine
Name Type Restriction Cardinality Description
id URI 1 Entity ID of power line
type String It is equal to 1 Entity type
"http://example.org/ngsi-
ld/PowerLine"
usage Float 1 Property for power line usage in kW
availability Float 1 Property for power line availability in kW

An instance of the entity PowerLine is described as follows:
{
...