Fixed typos and added clarifications:

- proposed structural mapping in 7.3.2.4 is just an example, other mappings are possible, e.g. using flexContainers
- replaced resourceID in table 7.3.2.4-1 by label and replaced "guideline" by "example" in the caption
- explained that request-based approach could also be used in the opposite direction, i.e. triggered by oneM2M system
- updated general oneM2M-NGSI-LD Broker interworking figure that also the other CSE could be an ASN

TR-0076-Integrating_NGSI-LD_API_in_oneM2M.md

@@ -937,9 +937,9 @@ The IPE uses semantic discovery to find the relevant resources, retrieves the in
 
 #### 7.3.2.4 Static, bi-directional resource-to-entity mapping
 
-An approach, originally proposed by the Fed4IoT project <a href="#_ref_i.7">[i.7]</a>, is to map entities to oneM2M resource structures and labels in a bi-directional way. Table 7.3.2.4-1 shows the proposed mapping between NGSI-LD entities and oneM2M Resources.
+An approach, originally proposed by the Fed4IoT project <a href="#_ref_i.7">[i.7]</a>, is to map entities to oneM2M resource structures and labels in a bi-directional way. Table 7.3.2.4-1 shows an example for such a mapping between NGSI-LD entities and oneM2M Resources. This is not the only possible mapping, e.g. it would also be possible to define specific flexContainers for the purpose.
 
-**Table 7.3.2.4-1 Static resource to entity mapping guidelines**
+**Table 7.3.2.4-1 Static resource to entity mapping example**
 
 ![Static resource to entity mapping guidelines](media/Mapping-NGSI-LD-Entities-to-Resources.png)
 
@@ -947,12 +947,12 @@ 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 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.
+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 granularity 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 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. If suitable request forwarding mechanisms are available in oneM2M, the request-driven approach could also be used in the opposite direction.
 
 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.
 
@@ -970,7 +970,7 @@ In clauses 7.2 a mapping-based approach is described that proposes to integrate
 
 The general aspects that have to be taken into account for the comparison is efficiency and avoidance of information duplication on the one side and the complexity of the implementation on the other side.
 
-The integrated approach described in clause 7.2 generally enables more efficient access as many of the steps are internal and do not have to go via the external binding. Also, internally, more implementation optimizaions are possible, e.g. indexing, pre-fetching of information and pre-processing.
+The integrated approach described in clause 7.2 generally enables more efficient access as many of the steps are internal and do not have to go via the external binding. Also, internally, more implementation optimizations are possible, e.g. indexing, pre-fetching of information and pre-processing.
 Furthermore, there is no need to duplicate information. However, there is a significant complexity of implementation that has to be handled by the implementor of the oneM2M system.
 
 The synchronization based interworking approaches all duplicate information, so the respective applications can efficiently access the information. The efficiency of the information access by the Interworking Proxy is worse than in the integrated approach as there is the overhead of the binding for each request and there are less optimization possibilities as in the internal case.