@@ -947,9 +947,22 @@ Using subscriptions to the resources on the oneM2M system side and the NGSI-LD e
This approach is suitable for cases, where the same information is to be represented in both the oneM2M system and the NGSI-LD Context Broker, and the reosurce structure in the oneM2M system can be freely decided. It is not suitable for the case that information is already available in a oneM2M system using a different resource structure. At least in such a case, the information would have to be duplicated and kept synchronized.
Another issue with the static resource-to-entity mapping is the resource granularity, which plays an important role regarding the number of request needed to retrieve NGSI-LD entity information. In the approach shown in Table 7.3.2.4-1, the granulary is on the NGSI-LD attribute level, i.e. each attribute is mapped to a oneM2M container resource and the attribute values are stored as content instances. Alternatively, there could be a container for each NGSI-LD entity where the whole entity information is stored in a content instance, or there could even be a single resource for a whole group of entities.
Another important aspect of the static resource-to-entity mapping is the resource granularity, which plays an important role regarding the number of request needed to retrieve or update NGSI-LD entity information. In the approach shown in Table 7.3.2.4-1, the granulary is on the NGSI-LD attribute level, i.e. each attribute is mapped to a oneM2M container resource and the attribute values are stored as content instances. Alternatively, there could be a container for each NGSI-LD entity where the whole entity information is stored in a content instance, or there could even be a single resource for a whole group of entities.
Which resource structure is most suitable depends on the typical requests, i.e. in the case of synchronization, what types of updates are to be expected. Updates pertaining to (parts of) entities have to deal with a higher overhead the larger the entity information is that needs to be handled, e.g. only a single value is updated, but a new content instance has to be created for the whole entity or group of entiies. If there are typically batch updates for all entities of the group, having fewer resources is more suitable as otherwise a large number of requests are needed to update the information on an attribute value level.
### 7.3.3 Request-driven approach
In the request-driven approach, the interworking proxy entity does not permanently keep information synchronized, i.e. is triggered whenever information changes, but only acts on a request basis. Only if information is actually requested, it is retrieved from the other system.
In the following, such an approach is sketched where the IPE acts on an NGSI-LD request and then retrieves information from the oneM2M system. The proposal here is to keep the mapping information in the IPE, i.e. the oneM2M itself does not contain any (mapping) information related to NGSI-LD.
Figure 7.3.3-1 shows an IPE with mapping information, where the information in the pointed bracket is retrieved from known oneM2M resources using regular Mca requests.
**Figure 7.3.3-1: Request-driven interworking approach with mapping information in the IPE**
A possible issue with this approach is the number of Mca requests that the IPE needs to execute in order to answer a request. This can range from a few (e.g. retrieval of a single entity with few attributes) to a very large query (e.g. graph query with many entities).
# 8 Mapping between the information stored in oneM2M resources and the NGSI-LD information model
