diff --git a/TS-0035-oneM2M-OSGi_interworking.md b/TS-0035-oneM2M-OSGi_interworking.md
index b7af95130da3d041679a173f0fa9232ffc917dfa..c376f999d3364be3edfc662dc77e0e37fef8ee34 100644
--- a/TS-0035-oneM2M-OSGi_interworking.md
+++ b/TS-0035-oneM2M-OSGi_interworking.md
@@ -1,44 +1,40 @@
-
-
-+----------------------------------------------------------------+
-|**oneM2M** \ |
-|**Technical** **Specification** |
-+:================+:=============================================+
-|Document Number |oneM2M-TS-0035-V-0.0.1 |
-+-----------------+----------------------------------------------+
-|Document Name: |OSGi interworking |
-+-----------------+----------------------------------------------+
-|Date: |<20yy-mm-dd> |
-+-----------------+----------------------------------------------+
-|Abstract: |< An abstract of the document and |
-| |information that may be used in subsequent |
-| |electronic searches> |
-+-----------------+----------------------------------------------+
-|Template Version: January 2020 (Do not modify) |
-+----------------------------------------------------------------+
+
+
++---------------+----------------------------------------------------------------------------------------------------------------+
+|**oneM2M** \ |
+|**Technical Specification** |
++:==============+:===============================================================================================================+
+|Document Number|TS-0035-V5.0.1 |
++---------------+----------------------------------------------------------------------------------------------------------------+
+|Document Name: |OSGi Interworking |
++---------------+----------------------------------------------------------------------------------------------------------------+
+|Date: |2025-05-07 |
++---------------+----------------------------------------------------------------------------------------------------------------+
+|Abstract: |The document defines principles and guidelines on interworking OSGi based devices and gateways to oneM2M system.|
++---------------+----------------------------------------------------------------------------------------------------------------+
+|Template Version: January 2017 (Do not modify) |
++---------------+----------------------------------------------------------------------------------------------------------------+
The present document is provided for future development work within oneM2M only. The Partners accept no liability for any use of this specification.
-The present document has not been subject to any approval process by the oneM2M Partners Type 1. Published oneM2M specifications and reports for implementation should be obtained via the oneM2M Partners' Publications Offices.
+The present document has not been subject to any approval process by the oneM2M Partners Type 1. Published oneM2M specifications and reports for implementation should be obtained via the oneM2M Partners' Publications Offices.
-
-<br />About oneM2M
+About oneM2M
The purpose and goal of oneM2M is to develop technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide.
-More information about oneM2M may be found at: http//www.oneM2M.org
+More information about oneM2M may be found at: http//www.oneM2M.org
Copyright Notification
-(c) 2025, oneM2M Partners Type 1 (ARIB, CCSA, ETSI, TIA, TSDSI, TTA, TTC).
+© 2025, oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC).
All rights reserved.
The copyright extends to reproduction in all media.
-
Notice of Disclaimer & Limitation of Liability
The information provided in this document is directed solely to professionals who have the appropriate degree of experience to understand and interpret its contents in accordance with generally accepted engineering or other professional standards and applicable regulations. No recommendation as to products or vendors is made or should be implied.
@@ -46,196 +42,399 @@ The information provided in this document is directed solely to professionals wh
NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURATE OR SUFFICIENT OR CONFORMS TO ANY STATUTE, GOVERNMENTAL RULE OR REGULATION, AND FURTHER, NO REPRESENTATION OR WARRANTY IS MADE OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR AGAINST INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS. NO oneM2M PARTNER TYPE 1 SHALL BE LIABLE, BEYOND THE AMOUNT OF ANY SUM RECEIVED IN PAYMENT BY THAT PARTNER FOR THIS DOCUMENT, WITH RESPECT TO ANY CLAIM, AND IN NO EVENT SHALL oneM2M BE LIABLE FOR LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES. oneM2M EXPRESSLY ADVISES ANY AND ALL USE OF OR RELIANCE UPON THIS INFORMATION PROVIDED IN THIS DOCUMENT IS AT THE RISK OF THE USER.
-# Contents
+# Contents
-# 1 Scope
-The present document ...
-`EXAMPLE: The present document provides the necessary adaptions to the endorsed document.`
+# 1 Scope
-<mark>The Scope **shall not** contain requirements.</mark>
+The present document defines principles and guidelines on how to interwork devices and gateways that comply to the OSGi framework to the oneM2M system. The interworking includes service exposure between an OSGi device or gateway and the oneM2M system. With the interworking, OSGi defined services can be made available by oneM2M defined resources. As a result, by making requests to oneM2M resources, applications can access the services provided by OSGi devices or gateways.
# 2 References
## 2.1 Normative references
-<mark>The following text block applies.</mark>
+References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
-References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references,only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
+The following referenced documents are necessary for the application of the present document.
-<mark>Clause 2.1 only shall contain normative (essential) references which are cited in the document itself. These references have to be publicly available and in English.</mark>
+- <a name="_ref_1">[1]</a> oneM2M TS-0023: "Home Appliances Information Model and Mapping".
+- <a name="_ref_2">[2]</a> oneM2M TS-0033: "Proximal IoT Interworking".
+ > NOTE: Available at [http://www.onem2m.org/technical/published-drafts](http://www.onem2m.org/technical/published-drafts).
-The following referenced documents are necessary, partially or totally, for the application of the present document. Their use in the context of this TS is specified by the normative statements that are referring back to this clause.
+## 2.2 Informative references
+References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
-- Use the **EX** style, enclose the number in square brackets and separate it from the title with a tab (you may use sequence fields for automatically numbering references, see clause A.4: "Sequence numbering") (see example).
+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.
-`EXAMPLE:`
-- <a name="_ref_1">[1]</a> ETSI TR 102 473: "<Title>".
+- <a name="_ref_i.1">[i.1]</a> oneM2M Drafting Rules.
+ > NOTE: Available at [http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf](http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf).
+- <a name="_ref_i.2">[i.2]</a> OSGi Residential.
+ > NOTE: Available at [https://osgi.org/download/r6/osgi.residential-6.0.0.pdf](https://osgi.org/download/r6/osgi.residential-6.0.0.pdf).
-## 2.2 Informative references
-<mark>The following text block applies.</mark>
+# 3 Abbreviations
-References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references,only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
+For the purposes of the present document, the following abbreviations apply:
-<mark>Clause 2.2 shall only contain informative references which are cited in the document itself.</mark>
+`DAL Device Abstraction Layer`
+`AE Application Entity`
+`CSE Common Services Entity`
+`SDT Smart Device Template`
+`DMT Device Management Tree`
+`IPE Interworking Proxy Entity`
+`HAIM Home Appliance Information Model`
+`UID Unique Identifier`
+`UIDS Unique Identifiers`
+`TS Technical Specification`
-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.
+# 4 Conventions
-- Use the **EX** style, add the letter "i" (for informative) before the number (which shall be in square brackets) and separate this from the title with a tab (you may use sequence fields for automatically numbering references).
+The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in this document are to be interpreted as described in the oneM2M Drafting Rules <a href="#_ref_i.1">[i.1]</a>.
-- <a href="#_ref_i.1">[i.1]</a> oneM2M Drafting Rules (http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf)
-<mark>Delete from the below heading the word(s) which is/are not applicable.</mark>
+# 5 OSGi Interworking General Architecture
-# 3 Definition of terms, symbols and abbreviations
+## 5.1 OSGi Interworking Architecture
-## 3.1 Terms
+<mark>Editor note: The figure number is wrong. It should be 5.1-1</mark>
-<mark>Clause numbering depends on applicability.</mark>
+
-<mark>- A definition shall not take the form of, or contain, a requirement.</mark>
-<mark>- The form of a definition shall be such that it can replace the term in context. Additional information shall be given only in the form of examples or notes (see below).</mark>
-<mark>- The terms and definitions shall be presented in alphabetical order.</mark>
+**Figure 5-1: OSGi Interworking Architecture**
-For the purposes of the present document, the [following] terms and definitions [given in ... and the following] apply:
-<mark>Definition format</mark>
+OSGi Interworking is to interwork services provided by an OSGi based device or gateway to oneM2M entities which may be an AE or CSE. The OSGi services may include an OSGi defined DAL (Device Abstraction Layer) service, SDT (Smart Device Template) service, DMT (device management tree) admin service, other standardized services or proprietary services. The oneM2M-OSGi IPE bundle is in charge of the interworking of OSGi services to oneM2M resources and vice versa.
-<defined term>: <definition>
+The IPE bundle maps the invocation of the OSGi services and changes of state of oneM2M resources. If the OSGi based device or gateway hosts a CSE bundle, the IPE interacts with the CSE bundle internally. The OSGi based device or gateway interacts with the other oneM2M entities through Mca or Mcc reference point. If the OSGi based device or gateway does not host a CSE bundle, the IPE interacts with the CSE through a network interface.
-<mark>If a definition is taken from an external source, use the format below where [N] identifies the external document which must be listed in Section 2 References.</mark>
+The principle of how the interworking should be done shall follow the definition in oneM2M TS-0033 <a href="#_ref_2">[2]</a> proximal IoT interworking. For devices described by HAIM (Home Appliance Information Model) in oneM2M TS-0023 <a href="#_ref_1">[1]</a>, _<flexContainer>_ resources shall be used to represent the OSGi services. oneM2M also allows the transparent interworking of OSGi services through _<container>_ resources, _<AE>_ resources and _<node>_ resources as defined in oneM2M TS-0033 <a href="#_ref_2">[2]</a>.
-<defined term>[N]: <definition>
-example 1: text used to clarify abstract rules by applying them literally
+# 6 Mapping of OSGi DAL
-> NOTE: This may contain additional information.
+## 6.1 Introduction
+The OSGi DAL (Device Abstraction Layer) <a href="#_ref_i.2">[i.2]</a> is an OSGi defined service to unify interfaces for accessing devices. By using the OSGi DAL, application developers do not need to deal with protocol details to interact with different types of devices such as sensors, actuators, etc.
-## 3.2 Symbols
+![Figure 6.1-1: OSGi DAL <a href="#_ref_i.2">[i.2]</a>](media/6.1-1.png)
-<mark>Clause numbering depends on applicability.</mark>
+**Figure 6.1-1: OSGi DAL <a href="#_ref_i.2">[i.2]</a>**
-For the purposes of the present document, the [following] symbols [given in ... and the following] apply:
-<mark>Symbol format</mark>
+OSGi DAL is comprised of several services:
-<symbol> <Explanation>
-<2nd symbol> <2nd Explanation>
-<3rd symbol> <3rd Explanation>
+- Device: represents the registered device in the OSGi framework. The device service contains properties describing the device's metadata and context information. The device service has one or more function services.
+- Function: represents the function provided by the device. The function could be data reporting or actuating. The function provides a set of FunctionData, properties and operations. A property is the data information that can be accessed by the application. An operation is the interface that can be invoked by an application to trigger a certain procedure. The function also posts FunctionEvent.
+- FunctionEvent: represents the asynchronous event of the function. Once the event is triggered, the event is handled by the registered event handler.
+- FunctionData: represents the data structure that contains the property and metadata of the function.
+- PropertyMetadata: represents the metadata of the function property.
+- OperationMetadata: represents the metadata of the function operation.
-## 3.3 Abbreviations
+## 6.2 Device service
-<mark>Abbreviations should be ordered alphabetically.</mark>
+The device service defined by OSGi DAL maps to a oneM2M NoDN and is represented as a specialized _<flexContainer>_ resource and a _<node>_ resource.
-<mark>Clause numbering depends on applicability.</mark>
+The OSGi device service itself shall be mapped to a specialized _<flexContainer>_ resource of a specific device model that the OSGi device service instance represents. The properties of an OSGi device service shall be mapped to the attributes of the _<flexContainer>_ resource, the _<node>_ resource, and its child _[deviceInfo]_ resource.
-For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:
+Once an OSGi device service is registered at the OSGi framework, the IPE shall be responsible for acquiring all OSGi device service properties and other related services (such as OSGi function services) and creating the corresponding resources on the oneM2M CSE.
-<mark>Abbreviation format</mark>
+Upon the registration of an OSGi device service, the IPE should create a _<node>_ resource and a _[deviceInfo]_ specialization as the child resource of the _<node>_ resource. The IPE should also create one_<flexContainer>_ resource with specialized mandatory _[customAttribute]_ as a _'nodeLink'_ attribute, which links to a _<node>_ resource that is hosted on the same hosting CSE of the _<flexContainer>_ . The mapping between OSGi device and oneM2M resources shall be as follows.
-<ABREVIATION1> <Explanation>
-<ABREVIATION2> <Explanation>
-<ABREVIATION3> <Explanation>
+**Table 6.2-1: Mapping of OSGi device service to oneM2M resources**<a name="table_6.2-1"></a>
-# 4 Conventions
+|OSGi|oneM2M|Description|
+|-|-|-|
+|OSGi device service|_<node>_ resource, _[deviceInfo]_ resource, _<flexContainer>_ resource|The _<node>_ , _[deviceInfo]_ and _<flexContainer>_ resources are created upon the available of OSGi device service.|
+|SERVICE\_UID property|See description|Maps to the resourceID of the _<flexContainer>_ allocated by the Hosting CSE, however the value does not need to be same. The mapping between SERVICE\_UID and resourceID is maintained by IPE internally.|
+|SERVICE\_REFERENCE\_UIDS property|See description|Reference device maps to the sub-device defined in oneM2M. Therefore, the reference device in OSGi is mapped to the hierarchical relationship of _<flexContainer>_ resources.|
+|SERVICE\_DRIVER property|_areaNwkType_ attribute of _[areaNwkInfo]_ resource|Service driver maps to the area network type.|
+|SERVICE\_NAME property|_resourceName_ attribute of _<flexContainer>_ resource|The SERVICE\_NAME is used to request resource name of _<flexContainer>_ resource.|
+|SERVICE\_STATUS property|See description|Is maintained by lifecycle management of _<flexContainer>_ resources. The _<flexContainer>_ resource should only be created if the SERVICE\_STATUS of the OSGi device is STATUS\_ONLINE.|
+|SERVICE\_STATUS\_DETAIL property|See description|The status is not visible to oneM2M. The IPE will monitor the status change and reflect the status change in the lifecycle management of the _<flexContainer>_ resource.|
+|SERVICE\_HARDWARE\_VENDOR property|_manufacturer_ attribute of _[deviceInfo]_ resource|-|
+|SERVICE\_HARDWARE\_VERSION property|_hwVersion_ attribute _[deviceInfo]_ resource|-|
+|SERVICE\_FIRMWARE\_VENDOR property|_labels_ attribute of _[deviceInfo]_ resource|-|
+|SERVICE\_FIRMWARE\_VERSION property|_fwVersion_ attribute of _[deviceInfo]_ resource|-|
+|SERVICE\_TYPES property|_deviceType_ attribute of _[deviceInfo]_ resource|-|
+|SERVICE\_MODEL property|_model_ attribute of _[deviceInfo]_ resource|-|
+|SERVICE\_SERIAL\_NUMBER property|_deviceLabel_ attribute of _[deviceInfo]_ resource|-|
+
+
+## 6.3 Function service
+
+### 6.3.1 Introduction
+
+An OSGi function service maps to a specialized _<flexContainer>_ resource that correspond to a moduleClass specified in oneM2M TS-0023 <a href="#_ref_1">[1]</a>. An OSGi function service may be mapped to different _<flexContainer>_ s that correspond to different moduleClasses depending on the OSGi device service that the OSGi function service belongs to.
+
+
+**Table 6.3.1-1: Mapping of OSGi function to oneM2M resources**<a name="table_6.3.1-1"></a>
+
+|OSGi|oneM2M|Description|
+|-|-|-|
+|OSGi function service|moduleClass _<flexContainer>_ resource|The function service is mapped to moduleClass _<flexContainer>_ .|
+|SERVICE\_UID property|See description|Maps to resourceID of _<flexContainer>_ resource. The resourceID is allocated by Hosting CSE. The mapping relationship is maintained by IPE internally.|
+|SERVICE\_TYPE property|See description|Maps to containerDefinition of _<flexContainer>_ resource and is maintained by IPE.|
+|SERVICE\_VERSION property|_labels_ attribute of the _<flexContainer>_ resource|Versioning information of the OSGi service is mapped to _labels_ attribute of the _<flexContainer>_ resource.|
+|SERVICE\_DEVICE\_UID property|See description|Maintained by the parent-child relationship of device model _<flexContainer>_ and moduleClass _<flexContainer>_|
+|SERVICE\_REFERENCE\_UIDS property|_labels_ attribute of the _<flexContainer>_ resource|Mappes to the _labels_ attribute of the _<flexContainer>_ resource.|
+|SERVICE\_DESCRIPTION property|_labels_ attribute of _<flexContainer>_ resource|The description of the service maps to the labels attribute of _<flexContainer>_ resource.|
+|SERVICE\_OPERATION\_NAMES property|_<flexContainer>_ resource for action||
+|SERVICE\_PROPERTY\_NAMES property|_<flexContainer>_ resource for property||
+
+
+### 6.3.2 BooleanControl Function
+
+BooleanControl function is used for switch-type of device functions like a light, door, window or power socket. It maps to the binarySwitch _<flexContainer>_ that is a moduleClass.
+
+
+**Table 6.3.2-1: Mapping of BooleanControl function to binarySwitch moduleClass**<a name="table_6.3.2-1"></a>
+
+|OSGi|oneM2M|Description|
+|-|-|-|
+|inverse|_toggle_|Toggle the switch.|
+|setTrue|Update the _powerState_ to true||
+|setFalse|Update the _powerState_ to false||
+|data|_powerState_|The current state of the switch|
+
+
+### 6.3.3 BooleanSensor Function
+
+BooleanSensor function is used to report the data of a device function such as a light, door, window or power socket. It maps to several different _<flexContainer>_ resources that are moduleClass. It is based on the device type which determines the specialization of _<flexContainer>_ to be mapped to.
+
+
+**Table 6.3.3-1: Mapping of BooleanSensor function to binarySwitch moduleClass**<a name="table_6.3.3-1"></a>
+
+|OSGi|oneM2M|Description|
+|-|-|-|
+|data|_powerState_||
+
+
+**Table 6.3.3-2: Mapping of BooleanSensor function to doorLock moduleClass**<a name="table_6.3.3-2"></a>
+
+|OSGi|oneM2M|Description|
+|-|-|-|
+|data|_doorLock_||
+
+
+**Table 6.3.3-3: Mapping of BooleanSensor function to boiler moduleClass**<a name="table_6.3.3-3"></a>
+
+|OSGi|oneM2M|Description|
+|-|-|-|
+|data|_status_||
+
+
+**Table 6.3.3-4: Mapping of BooleanSensor function to waterSensor moduleClass**<a name="table_6.3.3-4"></a>
+
+|OSGi|oneM2M|Description|
+|-|-|-|
+|data|_alarm_||
+
+
+### 6.3.4 MultiLevelControl Function
+
+The MultiLevelControl Function maps to different moduleClass depending on the device type.
+
+
+**Table 6.3.4-1: Mapping of MultiLevelControl function to brightness moduleClass**<a name="table_6.3.4-1"></a>
+
+|OSGi|oneM2M|Description|
+|-|-|-|
+|data|_brightness_||
+
+
+**Table 6.3.4-2: Mapping of MultiLevelControl function to foaming moduleClass**<a name="table_6.3.4-2"></a>
+
+|OSGi|oneM2M|Description|
+|-|-|-|
+|data|_foamingStrength_||
+
+
+### 6.3.5 MultiLevelSensor Function
+
+The MultiLevelSensor Function maps to different moduleClass depending on the device type.
+
+
+**Table 6.3.5-1: Mapping of MultiLevelControl function to height moduleClass**<a name="table_6.3.5-1"></a>
-The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in this document are to be interpreted as described in the oneM2M Drafting Rules <a href="#_ref_i.1">[i.1]</a>
+|OSGi|oneM2M|Description|
+|-|-|-|
+|data|_height_||
-# 5 User defined clause(s) from here onwards
-<Text>
+**Table 6.3.5-2: Mapping of MultiLevelControl function to weight moduleClass**<a name="table_6.3.5-2"></a>
+|OSGi|oneM2M|Description|
+|-|-|-|
+|data|_weight_||
-## 5.1 User defined subdivisions of clause(s) from here onwards
-<Text>
-<mark>The following text is to be used when appropriate:</mark>
+**Table 6.3.5-3: Mapping of MultiLevelControl function to liquidRemaining moduleClass**<a name="table_6.3.5-3"></a>
+|OSGi|oneM2M|Description|
+|-|-|-|
+|data|_liquidRemaining_||
-# Proforma copyright release text block
-<mark>This text box shall immediately follow after the heading of an element (i.e. clause or annex) containing a proforma or template which is intended to be copied by the user. Such an element shall always start on a new page.</mark>
+**Table 6.3.5-4: Mapping of MultiLevelControl function to brightness moduleClass**<a name="table_6.3.5-4"></a>
-|Notwithstanding the provisions of the copyright clause related to the text of the present document, oneM2M grants that users of the present document may freely reproduce the <proformatype> proforma in this {clause\|annex} so that it can be used for its intended purposes and may further publish the completed <proformatype>.|
-|----|
+|OSGi|oneM2M|Description|
+|-|-|-|
+|data|_brightness_||
-<mark><PAGE BREAK></mark>
+**Table 6.3.5-5: Mapping of MultiLevelControl function to foaming moduleClass**<a name="table_6.3.5-5"></a>
-## <mark>Annexes</mark>
-<mark>Each annex shall start on a new page (insert a page break between annexes A and B, annexes B and C, etc.).</mark>
+|OSGi|oneM2M|Description|
+|-|-|-|
+|data|_foamingStrength_||
-<mark>Use the Heading 9 style for the title and the Normal style for the text.</mark>
-# Annex <A> (Informative/Normative):<mark>Remove Informative or Normative as appropriat</mark> Title of annex <mark>(style H9)</mark>
+### 6.3.6 Meter Function
-<Text>
-<mark><PAGE BREAK></mark>
+The Meter Function maps to different moduleClass depending on the device type.
-# Annex <B> (Informative/Normative):<mark>Remove Informative or Normative as appropriat</mark> Title of annex <mark>(style H9)</mark>
-<Text>
+**Table 6.3.6-1: Mapping of Meter function to energyConsuption moduleClass**<a name="table_6.3.6-1"></a>
-## B.1 First clause of the annex <mark>(style H1)</mark>
+|OSGi|oneM2M|Description|
+|-|-|-|
+|current|_roundingEnergyConsumption_||
+|total|_absoluteEnergyConsumption_ ||
-<Text>
-### B.1.1 First subdivided clause of the annex <mark>(style H2)</mark>
+### 6.3.7 Alarm Function
-<Text>
+The Alarm Function maps to different moduleClass depending on the device type.
-<mark><PAGE BREAK></mark>
-<mark>The following text is to be used when appropriate:</mark>
+**Table 6.3.7-1: Mapping of Alarm function to motionSensor moduleClass**<a name="table_6.3.7-1"></a>
-# Annex <y>:<br />Bibliography
-<mark>The annex entitled "Bibliography" is optional.</mark>
+|OSGi|oneM2M|Description|
+|-|-|-|
+|alarm|_alarm_||
-<mark>It shall contain a list of standards, books, articles, or other sources on a particular subject which are not mentioned in the document itself</mark>
-<mark>It shall not include references mentioned in the document.</mark>
+**Table 6.3.7-2: Mapping of Alarm function to smokeSensor moduleClass**<a name="table_6.3.7-2"></a>
-<mark>Use the Heading 9 style for the title and B1+ or Normal for the text.</mark>
+|OSGi|oneM2M|Description|
+|-|-|-|
+|alarm|_alarm_||
-- <Publication>: "<Title>".
+**Table 6.3.7-3: Mapping of Alarm function to temperatureAlarm moduleClass**<a name="table_6.3.7-3"></a>
-OR
+|OSGi|oneM2M|Description|
+|-|-|-|
+|alarm|_alarm_||
-<Publication>: "<Title>".
-<mark><PAGE BREAK></mark>
+**Table 6.3.7-4: Mapping of Alarm function to waterSensor moduleClass**<a name="table_6.3.7-4"></a>
+
+|OSGi|oneM2M|Description|
+|-|-|-|
+|alarm|_alarm_||
+
+
+### 6.3.8 Keypad Function
+
+The Keypad Function maps to keypad moduleClass of oneM2M.
+
+
+**Table 6.3.8-1: Mapping of Keypad function to keypad moduleClass**<a name="table_6.3.8-1"></a>
+
+|OSGi|oneM2M|Description|
+|-|-|-|
+|key|_keyNumber_||
+
+
+### 6.3.9 WakeUp Function
+
+This Function currently has no corresponding moduleClass in oneM2M.
+
+
+## 6.4 Device service procedure
+
+The IPE is responsible for monitoring the OSGi Device service and synchronizing the properties of the Device service to attributes of the oneM2M resources.
+
+
+
+
+**Figure 6.4-1: Procedure of registering Device service**
+
+
+The mapping of resources shall follow the definition in oneM2M TS-0033 <a href="#_ref_2">[2]</a> proximal IoT interworking. Depending on the available properties of the Device service, _<node>_ resource, _<AE>_ resource, _<container>_ resource or _<flexContainer>_ resource may be used to represent the Device service.
+
+
+## 6.5 Function service procedure
+
+The IPE is responsible for monitoring the Function property and synchronizing the change of the property to oneM2M resources. The IPE is also responsible for monitoring the update of the oneM2M resource that corresponds to the Function operation. Upon receiving the request targeting the resource, the IPE shall invoke the corresponding Function operation.
+
+
+
+
+**Figure 6.5-1: Procedure of registering function service**
+
+
+Monitors the registration: The IPE monitors the registration of the Function service to the OSGi framework.
+
+Create resource: The IPE creates the corresponding resource to the oneM2M CSE.
+
+
+
+
+**Figure 6.5-2: Procedure of changing function property**
+
+
+Change of Function property: The Function property may be changed due to various reasons such as hardware triggered break, sensor change, local application change etc.
+
+Monitors the change: The IPE monitors the change by subscribing to the eventable properties, acquiring the property periodically or by some other internal call back functions.
+
+Update the resource: The IPE updates the corresponding resource of the Function.
+
+
+
+
+**Figure 6.5-3: Procedure of invoking function operation**
+
+
+Update resource: The oneM2M CSE receives update requests from applications to update the resource that corresponds with the Function service.
+
+Monitors the change: The IPE monitors the change by subscribing to the resource and receiving notifications or polling etc.
+
+Invoke the function operation: The IPE invokes the function operation provided by the Function service.
# History
-<mark>This clause shall be the last one in the document and list the main phases (all additional information will be removed at the publication stage).</mark>
+<mark>Table with colspans converted to grid table. Please check and adjust manually if necessary.</mark>
-+-------------------------------------------------------------------------------------+
-|Publication history |
-+:======+:===============+:===========================================================+
-|V1.1.1 |<yyyy-mm-dd> |<Milestone> |
-+-------+----------------+------------------------------------------------------------+
-| | | |
-+-------+----------------+------------------------------------------------------------+
-| | | |
-+-------+----------------+------------------------------------------------------------+
++------+-------------+-----------------------+
+|**Publication history** |
++:=====+:============+:======================+
+|V3.0.0|April 2019 |Release 3 - Publication|
++------+-------------+-----------------------+
+|V4.0.0|February 2023|Release 4 - Publication|
++------+-------------+-----------------------+
+| | | |
++------+-------------+-----------------------+
+| | | |
++------+-------------+-----------------------+
-<mark> Draft history table to be removed on publication </mark>
+
+**Draft history (to be removed on publication)**
+-------------------------------------------------------------------------------------+
|Draft history |
+:======+:===============+:===========================================================+
-|V1.1.1 |<yyyy-mm-dd> |<CR ID> applied - <Summary of changes> |
+|V5.0.0 |2025-04-01 |First draft for Rel-5 based on V4.0.0 |
+-------+----------------+------------------------------------------------------------+
-| | | |
+|V5.0.1 |2025-05-07 |Conversion to markdown format |
+-------+----------------+------------------------------------------------------------+
| | | |
+-------+----------------+------------------------------------------------------------+
+
diff --git a/media/5-1.png b/media/5-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..e53e8e3ae294ae2f2ef08ac4ab1d5b6ca3d3f364
Binary files /dev/null and b/media/5-1.png differ
diff --git a/media/6.1-1.png b/media/6.1-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..7e84ad7dc060b7adfe34345a10e87be47c936409
Binary files /dev/null and b/media/6.1-1.png differ
diff --git a/media/6.4-1.png b/media/6.4-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..f78c6bee53bf540bdf63df69d39ce258611098fc
Binary files /dev/null and b/media/6.4-1.png differ
diff --git a/media/6.5-1.png b/media/6.5-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..f0d35a0f3454c1e7a0cab39e442a61a49ae01656
Binary files /dev/null and b/media/6.5-1.png differ
diff --git a/media/6.5-2.png b/media/6.5-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..c12835a45a5f3671b9ee5e970a5938af94d32ab4
Binary files /dev/null and b/media/6.5-2.png differ
diff --git a/media/6.5-3.png b/media/6.5-3.png
new file mode 100644
index 0000000000000000000000000000000000000000..d364efd0522b2c71bb8fa788429dabfa57b58285
Binary files /dev/null and b/media/6.5-3.png differ