diff --git a/TS-0041-oneM2M-SensorThings_interworking.md b/TS-0041-oneM2M-SensorThings_interworking.md
index 61e83b543f8d5faa077c2c3dfdd3f1a3feec131c..cef31708bf5ee296a6ae76e9a2b15fc58d8b91f5 100644
--- a/TS-0041-oneM2M-SensorThings_interworking.md
+++ b/TS-0041-oneM2M-SensorThings_interworking.md
@@ -182,12 +182,21 @@ Figure 6.0-1 shows an architecture approach for an Interworking Proxy Entity (IP
 
 The basic interworking enables applications that are connected to an oneM2M-based system to get data from sensors that are connected to an OGC/STA server. Furthermore, an application that is connected to an OGC/STA server will be able to get data from sensors that are connected to an oneM2M-based system.
 
-
 <figure>
   <img src="media/figure6_0__1.png" alt="arch_overview">
   <figcaption>Figure 6.0-1: IPE architecture overview with data flow</figcaption>
 </figure>
 
+## 6.1 OGC/STA-to-oneM2M Data Model Mapping
+
+According to oneM2M TS-0033 [i.4] a representation of a non-oneM2M Proximal IoT function/device in a oneM2M-specified resource instance is to be synchronized with the entity that it represents.
+This means that the OGC/STA data model is represented in the hosting CSE. The data in the OGC/STA server are organized as Sensing Entities [i.3] (see Figure 5.1-1: STA Sensing Entities data model).
+The oneM2M structure for data models is a tree-structure where data are organized in containers or trees of containers. 
+The OGC/STA data model is a relational one, as used in databases, and not hierarchical. Thus, it creates a challenge for full interworking of all data captured in the OGC/STA data model. 
+
+
+
+
 <mark>The following text is to be used when appropriate:</mark>