diff --git a/.DS_Store b/.DS_Store
new file mode 100644
index 0000000000000000000000000000000000000000..6c203b944a5fd638cff3cee28506e97c3efefae2
Binary files /dev/null and b/.DS_Store differ
diff --git a/TS-0014-oneM2M-LWM2M-Interworking.md b/TS-0014-oneM2M-LWM2M-Interworking.md
index 7c29e0c9fb784e221a8a7467c9183a947e52a7ab..713116142f2484aa1df1ffbdcf3b953a1cf500f3 100644
--- a/TS-0014-oneM2M-LWM2M-Interworking.md
+++ b/TS-0014-oneM2M-LWM2M-Interworking.md
@@ -1,230 +1,1345 @@
+
-|oneM2M<br/>Technical Specification |oneM2M<br />Technical Specification |
-|-|-|
-|Document Number |TS-0014-V-0.0.1 |
-|Document Name: |oneM2M LWM2M Interworking<br /> |
-|Date: |<20yy-mm-dd> |
-|Abstract: |< An abstract of the specification and information that may be used in subsequent electronic searches> |
-|Template Version: | January 2020 (do not modify) |
+|**oneM2M**<br />**Technical** **Specification** |**oneM2M**<br />**Technical** **Specification** |
+|-|-|
+|Document Number |TS-0014-V4.0.0 |
+|Document Name: |LWM2M Interworking |
+|Date: |2023-02-21 |
+|Abstract: |The present document specifies the interworking capabilities of the M2M Service Layer between ASN/IN/MN CSEs and LWM2M Endpoints. |
-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.
+This Specification 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.
-<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.
+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) 2020, oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC).
-
-All rights reserved.
+No part of this document may be reproduced, in an electronic retrieval system or otherwise, except as authorized by written permission.
-The copyright extends to reproduction in all media.
+The copyright and the foregoing restriction extend to reproduction in all media.
+(c) 2023, oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC).
+All rights reserved.
-Notice of Disclaimer & Limitation of Liability
+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.
+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.
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.
+<mark>Editors's Note: Convert sequence diagrams to PlantUML</mark>
+
+# Contents
-# Contents
# 1 Scope
-The present document ...
+The present document specifies the interworking capabilities of the M2M Service Layer between ASN/IN/MN CSEs and LWM2M Endpoints using the architecture identified in Annex F of oneM2M TS-0001 <a href="#_ref_2">[2]</a> for the following interworking scenarios:
-`EXAMPLE: The present document provides the necessary adaptions to the endorsed document.`
-<mark>The Scope **shall not** contain requirements.</mark>
+- Interworking for transparent transport of encoded LWM2M Objects and commands in Content Sharing Resources between LWM2M Endpoints and M2M Applications.
+- Interworking with full mapping of LWM2M Objects in LWM2M Endpoints to semantically enabled Content Sharing Resources that are utilized by M2M Applications.
+- Interworking with one-to-one mapping of LWM2M Objects with oneM2M <mgmtObj> resources
+> NOTE: The present document limits Content Sharing Resources to <container> and <contentInstance> resources.
# 2 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.
-
## 2.1 Normative references
-<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>
-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.
+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 reference document (including any amendments) applies.
+The following referenced documents are necessary for the application of the present document.
-- 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).
+- <a name="_ref_1">[1]</a> oneM2M TS-0011: "Common Terminology".
+- <a name="_ref_2">[2]</a> oneM2M TS-0001: "Function Architecture".
+- <a name="_ref_3">[3]</a> OMA-TS-LightweightM2M-V1\_0-20150318-D: "Lightweight Machine to Machine Technical Specification".
+- <a name="_ref_4">[4]</a> oneM2M TS-0003: "Security Solutions".
+- <a name="_ref_5">[5]</a> oneM2M TS-0005: "Management Enablement (OMA)".
+- <a name="_ref_6">[6]</a> IETF RFC 3986: " Uniform Resource Identifier (URI): Generic Syntax".
-`EXAMPLE:`
-- <a name="_ref_1">[1]</a> ETSI TR 102 473: "<Title>".
## 2.2 Informative references
-<mark>Clause 2.2 shall only contain informative references which are cited in the document itself.</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 reference document (including any amendments) applies.
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.
+- <a name="_ref_i.1">[i.1]</a> oneM2M Drafting Rules ([http://member.onem2m.org/Static\_pages/Others/Rules\_Pages/oneM2M-Drafting-Rules-V1\_0.doc](http://member.onem2m.org/Static\_pages/Others/Rules\_Pages/oneM2M-Drafting-Rules-V1\_0.doc)
+- <a name="_ref_i.2">[i.2]</a> IETF RFC 7252: "Constrained Application Protocol (CoAP)".
+- <a name="_ref_i.3">[i.3]</a> IETF RFC 6347: "Datagram Transport Layer Security Version 1.2".
+- <a name="_ref_i.4">[i.4]</a> OMA OMA-RD-LightweightM2M-V1\_0: "OMA Lightweight Machine to Machine Requirement".
+- <a name="_ref_i.5">[i.5]</a> oneM2M TS-0012: "Base Ontology".
-- 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).
-- <a href="#_ref_i.1">[i.1]</a> oneM2M Drafting Rules (http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf)
+# 3 Definitions and abbreviations
+## 3.1 Definitions
-# 3 Definition of terms, symbols and abbreviations
+For the purposes of the present document, the terms and definitions given in oneM2M TS-0011 <a href="#_ref_1">[1]</a>, oneM2M TS0002 <a href="#_ref_2">[2]</a> apply. A term defined in the present document takes precedence over the definition of the same term, if any, in oneM2M TS-0011 <a href="#_ref_1">[1]</a> and oneM2M TS-0001 <a href="#_ref_2">[2]</a>.
-<mark>Delete from the above heading the word(s) which is/are not applicable.</mark>
+## 3.2 Abbreviations
-## 3.1 Terms
+For the purposes of the present document, the terms and definitions given in oneM2M TS-0011 <a href="#_ref_1">[1]</a> and the following apply:
-<mark>Clause numbering depends on applicability.</mark>
+`LWM2M Lightweight M2M`
+`OMA Open Mobile Alliance`
-<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>
-For the purposes of the present document, the [following] terms and definitions [given in ... and the following] apply:
+# 4 Conventions
-<mark>Definition format</mark>
+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>.
-<defined term>: <definition>
-<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>
+# 5 Architecture Model
-<defined term>[N]: <definition>
+## 5.1 Introduction
-example 1: text used to clarify abstract rules by applying them literally
+The architecture model followed in the present document is based on the architecture model in Annex F of oneM2M TS-0001 <a href="#_ref_2">[2]</a> that describes how interworking between CSEs and non-oneM2M solutions and protocol using specialized Interworking Proxy application Entities (IPE). The present document describes the LWM2M IPE that supports the following scenarios.
-> NOTE: This may contain additional information.
+
+**Figure 5.1-1: LWM2M Interworking Scenarios**
-## 3.2 Symbols
-<mark>Clause numbering depends on applicability.</mark>
+In the scenarios depicted in Figure 5.1-1, the Hybrid and LWM2M Applications represent applications that implement the LWM2M Client role defined in the LWM2M Protocol <a href="#_ref_3">[3]</a>.
-For the purposes of the present document, the [following] symbols [given in ... and the following] apply:
-<mark>Symbol format</mark>
+## 5.2 Reference Model
-<symbol> <Explanation>
-<2nd symbol> <2nd Explanation>
-<3rd symbol> <3rd Explanation>
+The LWM2M Interworking reference model utilizes the Functional Architecture's reference model in oneM2M TS0001 <a href="#_ref_2">[2]</a>; augmenting the oneM2M TS-0001 <a href="#_ref_2">[2]</a> reference model with capabilities provided by the LWM2M IPE.
-## 3.3 Abbreviations
+
+**Figure 5.2-1: LWM2M Reference Model**
-<mark>Abbreviations should be ordered alphabetically.</mark>
+> NOTE: The AE in the reference model could be registered with the same CSE as the LWM2M IPE.
-<mark>Clause numbering depends on applicability.</mark>
-For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:
+## 5.3 Types of Interworking
-<mark>Abbreviation format</mark>
+LWM2M IPEs provide the following types of interworking:
-<ABREVIATION1> <Explanation>
-<ABREVIATION2> <Explanation>
-<ABREVIATION3> <Explanation>
+1. Interworking using the Content Sharing Resource for transparent transport of encoded LWM2M Objects that are available to AEs as depicted in Figure 5.3-1.
+2. Interworking with full mapping of the semantics of LWM2M Objects to semantically enabled resources that are available to AEs as depicted in Figure 5.3-2.
+3. Interworking with one-to-one mapping of LWM2M Objects to oneM2M <mgmtObj> resources as depicted in Figure 5.3-3.
-# 4 Conventions
+While depicted outside the hosting CSE, the Content Sharing Resources are hosted in a CSE (e.g. CSE1).
-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>
+
+**Figure 5.3-1: LWM2M Transparent Interworking Function**
-# 5 User defined clause(s) from here onwards
-<Text>
+In Figure 5.3-1, the LWM2M Objects are provided by the LWM2M Application to the LWM2M IPE using the LWM2M Protocol. The LWM2M IPE then encapsulates the LWM2M Objects in Content Sharing Resources and then hosts the Content Sharing Resources in a CSE using the Mca reference points for use by AEs. The AE accesses the Content Sharing Resource from the CSE that hosts the resource using the Mca reference point. Once the AE receives the Content Sharing Resource, the AE extracts the LWM2M Object from the Content Sharing Resource for the AE's purpose. Clause 7 describes this type of interworking in greater detail.
+
-## 5.1 User defined subdivisions of clause(s) from here onwards
-<Text>
+**Figure 5.3-2: LWM2M Semantically Enabled Interworking Function**
-<mark>The following text is to be used when appropriate:</mark>
+In Figure 5.3-2, the LWM2M Objects are provided by the LWM2M Application to the LWM2M IPE using the LWM2M Protocol. The LWM2M IPE then interworks the LWM2M Objects into Content Sharing Resources. The Content Sharing Resources are based on the oneM2M defined Semantic Ontology. The LWM2M IPE hosts the Content Sharing Resource in a CSE across the Mca reference for use by other AEs. The AE accesses the Content Sharing Resource from the CSE that hosts the resource using the Mca reference point. Once the AE receives the Content Sharing Resource, the AE encodes the information using the Semantic Ontology for the AE's purpose. Clause 8 describes this type of interworking in greater detail.
-# 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>
+
+**Figure 5.3-3: LWM2M Translation Interworking Function**
-|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>.|
-|----|
-<mark><PAGE BREAK></mark>
+In Figure 5.3-3, the IPE is provisioned with knowledge of the resource definition for a LWM2M Object and the corresponding oneM2M <mgmtObj> XSD, which shall be generated as described in TS-0005 <a href="#_ref_5">[5]</a>. The XSD shall map each LWM2M resource of a particular LWM2M Object ID to an [objectAttribute] in the corresponding oneM2M <mgmtObj>. The ordering of the [objectAttribute] in the XSD shall match the same order of resources defined in the corresponding LWM2M Object. For a given LWM2M Object, the IPE shall create a corresponding <mgmtObj> resource on the CSE and configure the _mgmtSchema_ attribute with a URI of the XSD file for that <mgmtObj>. All AEs can then access the <mgmtObj> the same way they access other oneM2M resources. Clause 9 describes this type of interworking in more details.
+An instance of a LWM2M IPE shall provide the capability for transparent transport of encapsulated LWM2M Objects as Content Sharing Resources and/or translation of LWM2M Objects as oneM2M semantically enabled Content Sharing Resources or as mapped oneM2M <mgmtObj> resources.
-## <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>
-<mark>Use the Heading 9 style for the title and the Normal style for the text.</mark>
+## 5.4 Composition of the Interworking Proxy Entity
-# Annex <A> (Informative/Normative):<mark>Remove Informative or Normative as appropriat</mark> Title of annex <mark>(style H9)</mark>
+The LWM2M IPE participation in the LWM2M Protocol as described in clause 5 does so in the role of a LWM2M Server to which LWM2M Applications (LWM2M Clients) interact. For each LWM2M Client (Endpoint) that is maintained by the LWM2M Server in the LWM2M IPE, the LWM2M IPE shall instantiate and maintains an instance of a Resource of type <AE>.
-<Text>
-<mark><PAGE BREAK></mark>
+
-# Annex <B> (Informative/Normative):<mark>Remove Informative or Normative as appropriat</mark> Title of annex <mark>(style H9)</mark>
+**Figure 5.4-1: LWM2M IPE Architecture**
-<Text>
-## B.1 First clause of the annex <mark>(style H1)</mark>
+# 6 Architecture Aspects
-<Text>
+## 6.1 Introduction
-### B.1.1 First subdivided clause of the annex <mark>(style H2)</mark>
+The LWM2M IPE participation in the LWM2M Protocol as described in clause 5 does so in the role of a LWM2M Server to which LWM2M Applications (LWM2M Clients) interact. As a LWM2M Server, the IPE provides the following Architecture Aspects based on the LWM2M Protocol Aspects described in clause A.2:
-<Text>
+- LWM2M Device and Endpoint Lifecycle (Client Registration).
+- LWM2M Object Discovery (Client Registration, Device Management and Service Enablement).
+- LWM2M Object Transport and Interworking (Device Management and Service Enablement).
+- LWM2M Object Subscription and Notification (Information Reporting).
+- LWM2M Interworking Proxy Entity Administration.
+- LWM2M Client Provisioning (Bootstrap).
+- LWM2M Object Security (Device Management and Service Enablement).
-<mark><PAGE BREAK></mark>
-<mark>The following text is to be used when appropriate:</mark>
+## 6.2 LWM2M Device and Endpoint Lifecycle
-# Annex <y>:<br />Bibliography
-<mark>The annex entitled "Bibliography" is optional.</mark>
+### 6.2.1 Introduction
-<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>
+As the LWM2M IPE discovers LWM2M Endpoints when the LWM2M IPE interacts with the LWM2M Client over the LWM2M protocol's Bootstrap and Client Registration interfaces, the LWM2M IPE shall maintain the associated resources in the CSE that represents the LWM2M Device and Endpoint.
-<mark>It shall not include references mentioned in the document.</mark>
-<mark>Use the Heading 9 style for the title and B1+ or Normal for the text.</mark>
+### 6.2.2 LWM2M Device and Endpoint Resource Representation
+#### 6.2.2.1 Introduction
-- <Publication>: "<Title>".
+LWM2M Endpoint provides the management and control functions for an M2M Application on a device. As such, the CSE that hosts the M2M Application shall represent the LWM2M Endpoint as a <AE> resource (LWM2M Endpoint <AE> resource). The LWM2M Device that hosts the LWM2M Endpoint shall be represented as a <node> resource.
-OR
-<Publication>: "<Title>".
+#### 6.2.2.2 LWM2M Device and Endpoint Resource Identification
-<mark><PAGE BREAK></mark>
+LWM2M Endpoints are identified by their Endpoint Client Name described in clause 6.2.1 of the LWM2M Technical Specification <a href="#_ref_3">[3]</a>. The Endpoint Client Name URN without the "urn:" sequence is used as the AE-ID of the associated <AE> resource that represents the LWM2M Client.
+In most deployment scenarios, LWM2M Devices host one (1) LWM2M Endpoint. In this scenario the LWM2M Device's <node> resource's M2M-Node-ID should be the same as the LWM2M Endpoint Client Name URN without the "urn:" sequence. When a LWM2M Device host's more than one (>1) LWM2M Endpoint, the determination of the <node> resource's M2M-Node-ID is implementation specific. In all deployment scenarios, the <AE> resource is linked with the <node> resource as described in oneM2M TS-0001 <a href="#_ref_2">[2]</a>.
-# 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>
+As the LWM2M Endpoint is represented as an <AE> resource and a LWM2M Object is represented as a Content Sharing Resource in the M2M Service Layer, a reference shall be made between the <AE> resource that represents the LWM2M Endpoint and the Content Sharing Resources which represents the list of LWM2M Objects and Object Instances available in that LWM2M Client.
+In order to identify interworked entities hosted in a CSE for the LWM2M technology described in this present document, the <AE> resource that represents the LWM2M Endpoint and the Content Sharing Resources which represent the list of LWM2M Objects and Object Instances available in that LWM2M Client, shall have a Iwked\_Technology _labels_ attribute set to LWM2M.
-|Publication history |Publication history |Publication history |
-|-|-|-|
-|V1.x.x |<yyyy-mm-dd > |<Milestone> |
-| | | |
-| | | |
-| | | |
-| | | |
+For the case where a LWM2M Endpoint is represented as an <AE> resource and LWM2M Objects are represented as <mgmtObj> resources in the M2M Service Layer, each <mgmtObj> resource shall be a child of the <node> resource representing the LWM2M Device that hosts the LWM2M Endpoint. In this case, the _nodeLink_ attribute of the <AE> resource representing the LWM2M Endpoint shall reference the <node> resource representing the LWM2M Device.
+
+In addition the <AE> resource uses the Hierarchical and Non-Hierarchical mechanisms for Resource Addressing as defined in clause 9.3.1 of oneM2M TS-0001 <a href="#_ref_2">[2]</a> where the _resourceName_ attribute of the <AE> resource shall be a Endpoint Client Name URN without the "urn:" sequence.
+
+
+#### 6.2.2.3 LWM2M Endpoint Lifecycle
+
+LWM2M Endpoint's are discovered when the LWM2M Client is successfully registers with the LWM2M Server using the LWM2M Register operation. In addition to the LWM2M Register operation, the LWM2M Client can periodically refresh the LWM2M Client's registration with the LWM2M IPE using the LWM2M Update operation. Finally a LWM2M Client can deregister when the LWM2M Client issues a De-register operation to the LWM2M IPE or the LWM2M Client's registration lifetime expires.
+
+The LWM2M Client Registration interface's operations and the registration lifetime expiration event maps to the following operations on the <AE> and <node> resources.
+
+
+**Table 6.2.2.3-1: LWM2M Endpoint Lifecycle Translation - Client Registration Interface**<a name="table_6.2.2.3-1"></a>
+
+| LWM2M Operation<br />Client Registration Interface | oneM2M Resource and Operation |
+|----------------------------------------------------|----------------------------------|
+| Register | create <AE>, create <Node> |
+| Update | update <AE>, update <Node> |
+| De-register | delete <AE>, delete <Node> |
+
+
+**Table 6.2.2.3-2: LWM2M Endpoint Lifecycle Translation - LWM2M Server Events**<a name="table_6.2.2.3-2"></a>
+
+| LWM2M Server Events | oneM2M Resource and Operation |
+|----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| client lifetime expiration | delete <AE>, delete <Node>, delete <container> resources associated with the <AE> resource, delete <mgmtObj> resources associated with <node> resource. |
+
+
+**Table 6.2.2.3-3: LWM2M Endpoint Lifecycle Attribute Translation**<a name="table_6.2.2.3-3"></a>
+
+| LWM2M Attributes<br />Client Registration Interface | oneM2M Resource Attribute |
+|-----------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|
+| Endpoint Client Name | <AE>: AE-ID, resourceName<br /><Node>: M2M-Node-ID when the Device only supports one Endpoint; resourceName |
+| Lifetime | <AE>, <Node>: expirationTime |
+| LWM2M Version | <AE>, <Node>: labels. Value is "Iwked-Entity-Version:"appended with the value of the LWM2M Version. |
+| Binding Mode | Not Applicable |
+| SMS Number | Not Applicable |
+
+
+
+
+**Table 6.2.2.3-4: LWM2M Endpoint Lifecycle Response Code Translation**<a name="table_6.2.2.3-4"></a>
+
+| LWM2M Errors<br />Client Registration Interface | oneM2M Resource Operation Response |
+|-----------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
+| Register<br />2.01 Created:<br />4.00 Bad Request<br />4.03 Forbidden | create <AE>, create <Node><br />2001 Created<br />All other codes<br />4105 Conflict |
+| Update<br />2.04 Changed<br />4.00 Bad Request<br />4.04 Not Found | update <AE>, update <Node><br />2004 Changed<br />All other codes<br />4000 Not Found |
+| De-register<br />2.02 Deleted<br />4.04 Not Found | delete <AE>, delete <Node><br />2002 Deleted<br />4004 Not Found |
+
+
+##### 6.2.2.4 Configuration of CMDH Policies
+In the present document, the CMDH Policies associated with the <Node> resource for the AE is implementation specific.
+
+
+##### 6.2.2.5 Registering a Registered LWM2M Endpoint
+In the scenario where a LWM2M Client issues a Register operation for an AE that is already created, the LWM2M IPE shall treat the operation as if the LWM2M Client requested a De-Register (Delete <AE> resource) prior this Register operation (Create <AE> resource) as described in Table 6.2.2.3-1. The procedure for the LWM2M Server is defined in clause 5.3.1 of the LWM2M Technical Specification <a href="#_ref_3">[3]</a>.
+
+
+## 6.3 LWM2M Object Discovery
+
+### 6.3.1 Introduction
+
+The LWM2M Client uses the Registration Interface to provide the properties required by the LWM2M Server of the IPE to contact the LWM2M Client (e.g. Endpoint Name) and to maintain the session between these two LWM2M entities (e.g. Lifetime, Queue Mode).In addition, the LWM2M Client also provides the knowledge of the supported Objects and existing Object Instances across the Registration Interface.
+
+The LWM2M IPE uses the information exchange across this interface to synchronize which LWM2M Objects supported by the LWM2M Endpoint and what is defined in the hosting CSE for the M2M Application representing the LWM2M Endpoint. This clause specifies how discovered LWM2M Objects identifiers are translated to discoverable oneM2M resources along with the associated linkages to other oneM2M resources.
+
+
+### 6.3.2 LWM2M Object Identifier Representation
+
+#### 6.3.2.1 Introduction
+
+Through the Registration Interface, the LWM2M Client provides the list of supported LWM2M Objects and existing LWM2M Object Instances. Each element of the list is described by its path, which can be the path of an Object or an Object Instance.
+
+For example the LWM2M Client could provide the following list of paths: </1/0>, </1/1>, </2/0>, </2/1>, </3/0>, </4/0>, </5>. This list of paths is a valid list of LWM2M Objects and LWM2M Object Instances in the CoRE Link Format [RFC6690], specifying that LWM2M Objects with OMNA Identifiers 1, 2, 3,4, and 5 are supported. The respective OMNA references are : urn:oma:lwm2m:oma:1, urn:oma:lwm2m:oma:2, urn:oma:lwm2m:oma:3, urn:oma:lwm2m:oma:4, urn:oma:lwm2m:oma:5.
+
+Additionally, information is provided that LWM2M Object 1 (Server Object) and LWM2M Object 2 (Access Control Object) have 2 instances (Instance Identifiers 0 and 1); LWM2M Object 3 (Device Object) and LWM2M Object 4 (Connectivity Monitoring Object) have 1 instance each (0); LWM2M Object 5 is supported but no instance has been created yet for that LWM2M Object.
+
+Optionally other information can be carried by that list as the capability for all the Objects in the LWM2M Client to support:
+
+- an alternate root path (default root path is '/');
+- a specific Content-Format (e.g. LWM2M JSON Content-Format).
+
+For discovery of LWM2M Objects by M2M Applications, the properties carried by LWM2M Objects list (i.e. technology, Objects and LWM2M Object Instances Identifiers, optional alternate rootpath, supported Content-Format) shall be translated into the labels attribute of the Content Sharing Resource as separate entries with the following format:
+
+- Iwked-Technology:LWM2M
+- Iwked-Entity-Type:Resource Type
+- LWM2M-PATH:Resource Root Path (for LWM2M default rootpath is "/").
+- Iwked-Entity-ID:Resource Path Object Identifier and Instance Identifier.
+- Iwked-Content-Type: Supported Content Format (LWM2M default Supported ContentFormat is LWM2M TLV other can be LWM2M JSON).
+
+For the case where LWM2M Objects are represented as <mgmtObj> resources in the M2M Service Layer, the properties carried by the LWM2M Objects list shall be translated into the labels attribute of the <node> resource using the above format.
+
+For example if the LWM2M Endpoint provided the following LWM2M Objects as part of the Client Registration Interface: </lwm2m>;rt="oma.lwm2m";ct=LWM2M+JSON,</1/0> would translate into a <container> resource with the following entries in the labels attribute: Iwked-Technology:LWM2M Iwked-Entity-Type:"urn:oma:lwm2m:oma:1" LWM2MPTH:"/lwm2m" Iwked-Entity-ID: "/1/0" Iwked-Content-Type:LWM2M+JSON (see note).
+
+> NOTE: LWM2M+JSON is an entry (numerical ID) in the CoAP Content-Format Registry representing the media-type "application/vnd.oma.lwm2m+json" used in LWM2M TS 1.0 enabler and currently engaged in the IANA registration process.
+
+The CoAP Resource Type may also be used as the semantic ontology of the <container> resource by inserting this value in the ontologyRef attribute of the <container> or other translated oneM2M resource.
+
+For the case where LWM2M Objects are represented as <mgmtObj> resources in the M2M Service Layer, the IPE shall use information carried in the LWM2M Objects list to configure not only the _labels_ and _description_ attributes but also the _objectID_ and _objectPath_ attributes of the <mgmtObj> resources since _objectID_ and _objectPath_ can also be helpful for discovery of the supported LWM2M Objects. For the case that 1:1 mapping of LWM2M Object to oneM2M <mgmtObj> is desired, the _objectIDs_ attribute shall contain the URN of the corresponding LWM2M Object and the _mgmtSchema_ attribute shall contain a URI of the schema file for the new <mgmtObj> specialization as outlined in Clause 6.7 of TS-0005 <a href="#_ref_4">[4]</a>.
+
+LWM2M Object Resources are identified by their URI within the context of the LWM2M Endpoint described in clause 6.2.1 of the LWM2M Technical Specification <a href="#_ref_3">[3]</a>.
+
+As the LWM2M Endpoint is represented as an <AE> resource and a LWM2M Object is represented as a oneM2M resource in the M2M Service Layer, a reference shall be made between the <AE> resource that represents the LWM2M Endpoint and the oneM2M resource which represent the list of LWM2M Objects and Object Instances available in the LWM2M Client.
+
+For the case where a LWM2M Object is represented as a <mgmtObj> resource, this reference is already provided by the AE's nodeLink attribute.
+
+In addition, oneM2M resources that represents the LWM2M Object or LWM2M Object Instance uses the Hierarchical and Non-Hierarchical mechanisms for Resource Addressing as defined in clause 9.3.1 of oneM2M TS0001 <a href="#_ref_2">[2]</a> where the _resourceName_ attribute of the Content Sharing or oneM2M resource shall be the value of the LWM2MURI. All characters that are not in the unreserved character set defined in clause 2.3 of the of IETF RFC 3986 <a href="#_ref_6">[6]</a> shall be percent encoded as defined in clause 2.1 of the same IETF RFC, specifically the forward slash (/) character.
+
+For example if the LWM2MURI is "/1/0 and the LWM2MPTH is "/" then the _resourceName_ attribute of the oneM2M resource could be "%2F1%2F0".
+
+For the case where <mgmtObj> resources are used, the "/1/0" LWM2MURI is mapped to the <mgmtObj>'s objectPath attribute. All characters that are not in the unreserved character set shall be percent encoded as well.
+
+
+#### 6.3.2.2 Void
+#### 6.3.2.3 LWM2M Object Lifecycle
+LWM2M Endpoint's are discovered when the LWM2M Client is successfully registers with the LWM2M Server using the LWM2M Register operation. In addition to the LWM2M Register operation, the LWM2M Client can periodically refresh the LWM2M Client's registration with the LWM2M IPE using the LWM2M Update operation. Finally a LWM2M Client can deregister when the LWM2M Client issues a De-register operation to the LWM2M IPE or the LWM2M Client's registration lifetime expires.
+The LWM2M Client Registration interface's operations and the registration lifetime expiration event maps to the following operations on the resource.
+**Table 6.3.2.3-1: LWM2M Object Lifecycle Translation - Client Registration Interface**<a name="table_6.3.2.3-1"></a>
+| LWM2M Operation<br />Client Registration Interface | oneM2M Resource and Operation |
+|----------------------------------------------------|----------------------------------------------------------------|
+| Register | create <container>, oneM2M resource |
+| Update | update <container> , delete <container>, oneM2M resource |
+| De-register | delete <container>, oneM2M resource |
-|Draft history (to be removed on publication) |Draft history (to be removed on publication) |Draft history (to be removed on publication) |
+**Table 6.3.2.3-2: LWM2M Object Lifecycle Translation - LWM2M Server Events**<a name="table_6.3.2.3-2"></a>
+
+| LWM2M Server Events | oneM2M Resource and Operation |
+|----------------------------|----------------------------------------|
+| Client lifetime expiration | delete <container>, oneM2M resource |
+
+
+**Table 6.3.2.3-3: LWM2M Object Lifecycle Attribute Translation**<a name="table_6.3.2.3-3"></a>
+
+| LWM2M Attributes<br />Client Registration Interface | oneM2M Resource Attribute |
+|-----------------------------------------------------|-------------------------------------------------|
+| Endpoint Client Name | Not Applicable |
+| Resource Links | <container>, oneM2M resource resourceName |
+| Lifetime | <container> , oneM2M resource expirationTime |
+| LWM2M Version | Not Applicable |
+| Binding Mode | Not Applicable |
+| SMS Number | Not Applicable |
+
+
+**Table 6.2.2.3-4: LWM2M Object Lifecycle Response Code Translation**<a name="table_6.2.2.3-4"></a>
+
+| LWM2M Errors<br />Client Registration Interface | oneM2M Resource Operation Response |
+|-----------------------------------------------------------------------|----------------------------------------------------------------------------------|
+| Register<br />2.01 Created:<br />4.00 Bad Request<br />4.03 Forbidden | create <container><br />2001 Created<br />All other codes<br />4105 Conflict |
+| Update<br />2.04 Changed<br />4.00 Bad Request<br />4.04 Not Found | update <container><br />2004 Changed<br />All other codes<br />4000 Not Found |
+| De-register<br />2.02 Deleted<br />4.04 Not Found | delete <container><br />2002 Deleted<br />4004 Not Found |
+
+
+## 6.4 LWM2M Object Transport and Interworking
+
+### 6.4.1 Introduction
+
+When an oneM2M request is addressed from a CSE/AE to a hosting CSE containing the representation of a LWM2M Client, the oneM2M response to the Originator of the request is returned through the cooperation of the hosting CSE and the IPE.
+
+The LWM2M Client uses the Device Management & Service Enablement interface to provide the capabilities for the LWM2M Server of the IPE to access LWM2M Objects, Objects Instances and Resources available from the LWM2M Client.
+
+A hosting CSE maintains a representation of the LWM2M Data Model of LWM2M Object, Object Instance or Resources as instances of oneM2M resource types. These Content Sharing Resources are instantiated and registered as described in clause 6.3 allowing oneM2M AEs and CSEs to exchange data with LWM2M Clients.
+
+In reference to clause 6.3, at the end of the registration phase all declared LWM2M Object Instances and LWM2M Objects are associated to a Content Sharing Resource created with the resourceName attribute set accordingly to the proper LWM2M Object Instance path (e.g. /9/1) or to the LWM2M Object path (e.g. /9).
+
+
+### 6.4.2 LWM2M Interworking Mechanisms
+
+#### 6.4.2.1 Introduction
+
+Cooperation between IPE and the oneM2M hosting CSE requires efficient mechanisms to maintain the latest state of the targeted LWM2M Objects, Object Instances and Resources. These mechanisms include data synchronization between the IPE and hosting CSE.
+
+Data synchronization relies on the oneM2M Subscription/Notification and LWM2M Observation/Notification mechanisms. For automated data synchronization between the IPE and hosting CSE to be achieved, the solution shall be granular enough to allow data synchronization for each LWM2M Object Instance.
+
+Access Control mechanisms relies on an interworking between oneM2M and LWM2M Access Control Policies.
+
+LWM2M and oneM2M mechanisms used to achieve Data Synchronization and Access Control is specified in more details in clauses 6.5 and 6.6.
+
+These following sub-clauses specify the sequences of operations involved for each type of supported oneM2M requests following the general procedures specified in clause 10 (CREATE,RETRIEVE, DELETE) as used within the context of the interworking for the present document
+
+
+#### 6.4.2.2 Relevant Interworked Resource Settings
+
+A LWM2M Object Instance that is represented in oneM2M as a <container> resource has 2 direct children resource types: a <subscription> resource and a <contentInstance> resource when used with a <container> resource.
+
+A LWM2M Object Instance that is represented in oneM2M as a <mgmtObj> resource may have 1 direct child resource of type <subscription>.
+
+For supporting the LWM2M interworking process, a few attributes for the <container> resource and the <subscription> resource shall have a specified set of parameters.
+
+
+a) Attributes of <container> resource
+
+**Table 6.4.2.2-1: <container> resource - Relevant Interworked Attributes**<a name="table_6.4.2.2-1"></a>
+
+| Attributes of _<container>_ resource | Value |
+|-----------------------------------------|--------------------------|
+| _accessControlPolicyIDs_ | ACP set (see Clause 6.6) |
+| _maxNrOfInstances_ | 1 |
+
+
+b) Child resource types of _<container>_ resource
+
+**Table 6.4.2.2-2: <container> resource - Relevant Child resource types**<a name="table_6.4.2.2-2"></a>
+
+| Child resources of _<container>_ resource |
+|-----------------------------------------------|
+| _<contentInstance>_ _resource_ |
+| _<subscription>_ _resource_ |
+
+
+c) Attributes of _<subscription>_ resource
+
+**Table 6.4.2.2-3: <subscription> resource - Relevant Interworked Attributes**<a name="table_6.4.2.2-3"></a>
+
+| Attributes of _<subscription>_ _resource_ | Description / Value |
+| -------------------------------------------- | ------------------------------------------------------------ |
+| _notificationURI_ | IPE URI |
+| _eventType_ | B. Deletion of the subscribed-to resource;<br />C. Creation of a direct child of the subscribed-to resource;<br />E. An attempt to retrieve a <contentInstance> direct-child-resource of a subscribed-to <container> resource is performed while this child is an obsolete resource or the reference used for retrieving this resource is not assigned.This retrieval is performed by a RETRIEVE request targeting the subscribed-to resource with the _Result Content_ parameter set to either "child-resources" or "attributes+child-resources". |
+
+
+#### 6.4.2.3 oneM2M RETRIEVE Procedure
+
+This procedure describes the retrieval of a resource using the oneM2M RETRIEVE request. The information contained within the resource is related to the LWM2M Objects Instances that are interworked through the IPE. This clause shall be treated in conformance with the RETRIEVE Procedure specified in oneM2M TS-0001 <a href="#_ref_2">[2]</a>, clauses 10.1.2 and 10.2.4.2.
+
+The Receiver performs local processing to verify the existence of requested Resource and checks privileges for retrieving the information related to the resource. After successful verification, the Receiver shall return the requested information according to the procedures for the type of interworking (e.g. Transparent, Semantically Enabled, or Management Objects) as described in clause 7, 8, and 9, otherwise an error response shall be returned to the Originator.
+
+
+
+**Figure 6.4.2.3-1: Procedure for Retrieving a Resource (oneM2M TS-0001 <a href="#_ref_2">[2]</a>, clause 10)**
+
+The target of the request is a <container> or <mgmtObj> resource, the ResultContent and FilterCriteria parameters of the request (oneM2M TS0001 <a href="#_ref_2">[2]</a>, clause 8.1.2) specify the nature of the information to retrieve.
+
+**Table 6.4.2.3-1: Effect of Request Parameters on Retrieval Request**<a name="table_6.4.2.3-1"></a>
+
+|Request parameter : ResultContent |Request parameter : FilterCriteria |Effect |
|-|-|-|
-|V1.x.x |<yyyy-mm-dd > |<CR ID> applied - <Summary of changes> |
-| | | |
-| | | |
-| | | |
-| | | |
+|child-resources |resourceType = contentInstance |Retrieval of LWM2M Object Instance |
+|attributes (default) |labels, attribute |Metadata retrieval of LWM2M Object Instance. |
+
+
+Specific steps of the Receiver Processing according to the interworking process shall be followed:
+
+**Step 001:** Find and verify the targeted <container> or <mgmtObj> resource of the request : the resourceName corresponds to clause 6.3.2.
+
+**Step 002:** Using the Hosting CSE Access Control mechanisms, check for Access Control Policy attached to the <container> or <mgmtObj> resource of the request
+
+**Step 003:** On successful validation of the Access Control Policy, proceed to fetch the requested information:
+
+a) If "ResultContent" is "attributes", jump to Step 4.
+b) If "ResultContent" is "child-resources" and "FilterCriteria" is "contentInstance", the associated <contenInstance> resource of the targeted container is considered.
+
+- **Step 003.1:** if the <contentInstance> resource is obsolete or its reference is not assigned, an event for Retrieval attempt (eventType 'E') is triggered to the Entity that subscribed to the event (i.e. IPE); as a Blocking Procedure, the Hosting CSE shall monitor the arrival of the new data or decide to report a timeout error in jumping to Step 004:
+ - **Step 003.1.1:** On receiving the event of type 'E' (eventType 'E') the IPE performs a LWM2M READ request on the Object Instance of the targeted LWM2M Client.
+ - **Step 003.1.2:** Once the targeted Object Instance is available to IPE, the IPE creates and populates with that data the <contentInstance> child-resource of the requested <container> resource.
+- **Step 003.2:** the up-to-date information is available in the <contentInstance> resource.
+
+**Step 004:** The Hosting CSE returns the appropriate response back to the Originator (e.g. Errors, or Data).
+
+> NOTE: As an OBSERVATION has been set up on the targeted LWM2M Object Instance, the automatic synchronization between the Object Instance and its representation in the Hosting CSE is performed. Further oneM2M accesses to the resource should be simplified in minimizing impact of Step003 (up-to-date data already present from the Hosting CSE resources).
+
+**General Exceptions:**
+
+1. The targeted resource/attribute in **_To_** parameter does not exist. The Receiver shall respond with an error.
+2. The Originator does not have privileges to retrieve information stored in the resource on the Receiver. The Receiver shall respond with an error.
+3. A timer has expired. The Receiver shall respond with an error.
+
+
+#### 6.4.2.4 oneM2M CREATE Procedure
+
+This procedure describes the update of a LWM2M Object Instance in a LWM2M Client using the oneM2M CREATE request The information contained in the request via the Content parameter (oneM2M TS-0001 <a href="#_ref_2">[2]</a>, clause 8.2.1) will be used to update an Object Instance in the LWM2M context.
+
+This clause shall be treated in conformance with the CREATE Procedure specified in oneM2M TS-0001 <a href="#_ref_2">[2]</a>, clauses 10.1.2 and 10.2.4.1.
+
+
+
+
+**Figure 6.4.2.4-1: Procedure for Creating a Resource (oneM2M TS-0001 <a href="#_ref_2">[2]</a>, clause 10)**
+
+The target of the request is a <container> or <node> resource, the ResourceType parameters of the request (oneM2M TS-0001 <a href="#_ref_2">[2]</a>, clause 8.1.2) specifies the type of the resource to create.
+
+**Table 6.4.2.4-1: Effect of Request Parameters on Create Request**<a name="table_6.4.2.4-1"></a>
+
+| Request parameter :ResourceType | Effect |
+|---------------------------------|-----------------------------------------------------------------------------------------|
+| ContentInstance | Replacement of the <latest> resource by a new one |
+| MgmtObj | Creation of new <mgmtObj> resource or appropriate error message if one already exist |
+
+
+In LWM2M Interworking context, if there is already an existing <contentInstance> resource, creating a new one shall violates the policy defined in the parent <container> resource regarding the maxNrOfInstances which shall be set to 1. Then the oldest <contentInstance> resources shall be removed from the <container> to enable the creation of the new <contentInstance> resource.
+
+In any case, a notification is sent to the IPE, which subscribed to the parent <container> or <node> resource with the eventType 'C' (Creation of a direct child of the subscribed-to resource). The IPE shall use that notification to update the LWM2M resource model with the new data received ("Content" parameter of the request).
+
+Specific steps of the Receiver Processing according to the interworking process shall be as followed:
+
+**Step 001:** Find and verify the <container> or <node> resource of the request : the resourceName corresponds to clause 6.3.2.
+
+**Step 002:** Using the Hosting CSE Access Control mechanisms, check for Access Control Policy attached to the <container> or <node> resource of the request.
+
+**Step 003:** On unsuccessful validation of the Access Control Policy, jump to step 4:
+
+- **Step 003.1:** When according to the request, a <contentInstance> or <mgmtObj> resource is created, an event for Child Creation (eventType 'C') is triggered to the Entity that subscribed to that event (i.e. IPE).
+- **Step 003.2:** On receiving the event of type 'C' the IPE - via the Mca reference point - get the data from the created <contentInstance> or <mgmtObj> resource and propagates the updated data to the related Object Instance in the LWM2M Client.
+
+**Step 004:** The Hosting CSE returns the appropriate response back to the Originator (e.g. Acknowledgment, Errors).
+
+**General Exceptions:**
+
+1. The Originator does not have the privileges to create a resource on the Receiver, the Receiver shall respond with an error.
+2. The resource with the specified name (if provided) already exists at the Receiver, the Receiver shall response with an error.
+3. The provided information in **_Content_** is not accepted by the Receiver (e.g. missing mandatory parameter), the Receiver shall respond with an error.
+
+
+#### 6.4.2.5 oneM2M UPDATE Procedure
+
+This procedure describes the update of a LWM2M Object Instance or Resource in a LWM2M Client using the oneM2M UPDATE request. The information contained in the request via the Content parameter (TS-0001 Clause 8.1.2) shall be used to update an Object Instance or Resource in the LWM2M context.
+
+This clause shall be treated in conformance with the UPDATE Procedure specified in TS-0001 <a href="#_ref_2">[2]</a> clause 10.1.3 and 10.2.8.4.
+
+
+
+
+**Figure 6.4.2.5-1: Procedure for UPDATing a Resource (TS-0001 Clause 10)**
+
+
+The target of the request is the <mgmtObj> resource itself.
+
+Specific steps of the Receiver Processing according to the interworking process shall be as followed:
+
+**Step 001:** Find and verify the <mgmtObj> resource of the request : the resourceName corresponds to clause 6.3.2
+
+**Step 002:** Using the Hosting CSE Access Control mechanisms, check for Access Control Policy attached to the <mgmtObj> resource of the request.
+
+**Step 003:** On unsuccessful validation of the Access Control Policy, jump to step 4
+
+**Step 003.1:** When according to the request, a <mgmtObj> attribute is updated, an event for update to attributes (eventType 'A') is triggered to the Entity that subscribed to that event (i.e. IPE).
+
+**Step 003.2** **:** On receiving the event of type 'A', the IPE - via the Mca reference point - gets the data from the attribute and propagates the updated data to the related Object Instance or Resource in the LWM2M Client.
+
+**Step 004:** The Hosting CSE returns the appropriate response back to the Originator (e.g. Acknowledgment, Errors)
+
+**General Exceptions:**
+
+1. The targeted resource in **_To_** parameter does not exist. The Receiver responds with an error.
+2. The Originator does not have the privilege to modify the resource, create attributes or delete attributes on the Receiver. The Receiver responds with error.
+3. The provided information in the **_Content_** is not accepted by the Receiver. The Receiver responds with error.
+
+
+#### 6.4.2.6 oneM2M DELETE Procedure
+
+This procedure describes the removal of a LWM2M Object Instance within a LWM2M Client using the oneM2M DELETE request.
+
+This clause shall be treated in conformance with the DELETE Procedure specified in oneM2M TS-0001 <a href="#_ref_2">[2]</a>, clauses 10.1.4 and 10.2.4.4.
+
+
+
+
+**Figure 6.4.2.6-1: Procedure for Deleting a resource (oneM2M TS-0001 <a href="#_ref_2">[2]</a>, clause 10)**
+
+
+Specific steps of the Receiver Processing according to the interworking process shall be as followed:
+
+**Step 001:** Find and verify the <container> or <mgmtObj> resource of the request : the resourceName corresponds to clause 6.3.2.
+
+**Step 002:** Using the Hosting CSE Access Control mechanisms, check for Access Control Policy attached to the <container> or <mgmtObj> resource of the request.
+
+**Step 003:** On unsuccessful validation of the Access Control Policy, jump to step 4:
+
+- **Step 003.1:** When the <container> or <mgmtObj> resource is deleted an event (eventType 'B': Deletion of subscribed-to resource) is triggered to the Entity that subscribed to that event (i.e. IPE).
+- **Step 003.2:** On receiving the event type 'B', the IPE requests the LWM2M Client to delete the Object Instance related to the <container> or <mgmtObj> resource.
+- **Step 003.3:** On Object Instance deletion, the LWM2M Client performs a De-Registration operation to the IPE.
+- **Step 003.4:** Via the Mca reference point, the IPE communicates to the Hosting CSE the status of this DeRegistration.
+
+**Step 004:** The Hosting CSE returns the appropriate response back to the Originator (e.g. Success, Errors).
+
+
+### 6.4.3 oneM2M Resource Operation Responses
+
+**Table 6.4.3-1: LWM2M Response Codes to oneM2M Resource Operation Response Codes**<a name="table_6.4.3-1"></a>
+
+| LWM2M Client<br />Response Codes on<br />Device Management & Service Enablement interface | oneM2M Resource Operation Response |
+|------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------|
+| Create<br />2.01 Created:<br />4.00 Bad Request<br />4.01 Unauthorized<br />4.04 Not Found | <br />2001 Created<br />4000<br />4103<br />4004 |
+| Read<br />2.05 Content:<br />4.01 Unauthorized<br />4.04 Not Found<br />4.05 Method Not Allowed | <br />2000 OK<br />4103<br />4004<br />4005 |
+| Write<br />2.04 Changed<br />4.00 Bad Request<br />4.01 Unauthorized<br />4.04 Not Found<br />4.05 Method Not Allowed | <br />2004 Changed<br />4000<br />4103<br />4004<br />4005<br />4102 |
+| Delete<br />2.02 Deleted<br />4.00 Bad Request<br />4.01 Unauthorized<br />4.04 Not Found<br />4.05 Method Not Allowed | <br />2002 deleted<br />4103<br />4103<br />4004<br />4005 |
+
+
+## 6.5 LWM2M Object Subscription and Notification
+
+### 6.5.1 Introduction
+
+The LWM2M Server uses the Information Reporting Interface to provide the capabilities for a LWM2M Server to subscribe to changes to the LWM2M Objects, LWM2M Object instances and the associated LWM2M Object's resources. Likewise the LWM2M Client uses the Information Reporting Interface to notify subscribed LWM2M Server's when the LWM2M Object, LWM2M Object instance and/or LWM2M Object's resources change and to cancel the subscription on LWM2M Objects, LWM2M Object instances and the associated LWM2M Object's resources.
+
+The LWM2M Server uses the Device Management & Service Enablement Interface to set the notification criteria for a subscription.
+
+The oneM2M Subscription capabilities permit subscription changes to an oneM2M resource's attributes and its direct child resources. Likewise, the oneM2M Notification capabilities include a rich set of criteria for when a subscribed-to oneM2M resource is notified of a change.
+
+
+### 6.5.2 LWM2M Subscription Procedure
+
+The LWM2M IPE interworks the oneM2M resource's <subscription> child resource with the corresponding LWM2M Object using the oneM2M <subscription> resource's attributes and the corresponding LWM2M Object resource's Notification class Attributes.
+
+> Note: Each LWM2M Object resource has an associated set of Notification class Attributes that are used for defining the applicable subscription and notification criteria.
+
+When the LWM2M IPE creates a oneM2M Content Sharing Resource, the LWM2M IPE creates a subscription on the Content Sharing Resource to be notified whenever the oneM2M resource's subscription attribute is changed by setting the <subscription> resource's attributes as follows.
+
+
+**Table 6.5.2-1: LWM2M Subscription Procedure - <subscription> resource**<a name="table_6.5.2-1"></a>
+
+| Attributes of _<subscription>_ | Description |
+|-----------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| _accessControlPolicyIDs_ | Link a <accessControlPolicy> resource with the privileges:<br />accessControlOriginator originatorID set to the LWM2M IPE AE's AE-ID<br />accessControlOperations: Set to RETRIEVE, CREATE, UPDATE, DELETE, DISCOVER, NOTIFY |
+| _pendingNotification_ | Set to "sendLatest" |
+| _latestNotify_ | Set to "latest". |
+| _notificationContentType_ | Set to "resource" |
+| _<schedule>_ | Set to immediate notification |
+
+
+Whenever another AE or CSE creates or deletes a subscription to the <container> resource, the LWM2M IPE shall be notified of the change and shall perform the following steps:
+
+**Step 001:** Find the associated LWM2M Object or Object Instance for notification's subscriptionReference.
+
+**Step 002:** If the oneM2M notification indicates a subscription deletion:
+
+- **Step 002a:** If the associated LWM2M Object or Object Instance has an outstanding Observation request from the LWM2M IPE then issue the LWM2M Cancel Observation operation.
+
+**Step 003:** If the oneM2M notification indicates a subscription creation:
+
+- **Step 003a:** If the associated LWM2M Object or Object Instance does not have an outstanding Observation request from the LWM2M IPE then:
+
+ - **Step 003a001:** Retrieve the Parent resource of the <subscription> resource from the notification's subscriptionReference.
+ - **Step 003a002:** Determine the LWM2M Notification class Attributes to set from the set of subscriptions of the Parent resource using the <schedule> resource associated with each of the Parent resource's subscriptions.
+ - **Step 003a003:** Issue the LWM2M Observe operation with the LWM2M Notification class attributes.
+
+**General Exceptions:** The processing for recovery of a failed LWM2M Cancel Observation or Observation operation is vendor specific.
+
+
+**Table 6.5.2-2: LWM2M Subscription Procedure - Information Reporting Interface**<a name="table_6.5.2-2"></a>
+
+| LWM2M Operation<br />Information Reporting Interface | oneM2M Resource and Operation |
+|------------------------------------------------------|------------------------------------------------------|
+| Observe | NOTIFY (m2m:notification subscriptionDeletion=false) |
+| Cancel Observation | NOTIFY (m2m:notification subscriptionDeletion=true) |
+
+
+**Table 6.5.2-3: LWM2M Subscription Procedure Attribute Translation**<a name="table_6.5.2-3"></a>
+
+| LWM2M Operation<br />DM and SE Interface<br />Notification class Attributes | oneM2M <subscription> Attribute |
+|-----------------------------------------------------------------------------|------------------------------------|
+| Minimum Period | <schedule> resource |
+| Maximum Period | <schedule> resource |
+| Greater Than | Not Applicable |
+| Less Than | Not Applicable |
+| Step | Not Applicable |
+
+
+### 6.5.3 LWM2M Notification Procedure
+
+When the LWM2M IPE is notified by the LWM2M Client of a change in a LWM2M Object or Object Instance the LWM2M IPE creates a new <contentInstance> for the associated <container> resource according to the procedures for the type of interworking (e.g. Transparent, Semantic) as described in clause 7 or 8.
+
+For the case where LWM2M Objects are represented as <mgmtObj> resources in the M2M Service Layer and when the LWM2M IPE is notified by the LWM2M Client of a change in a LWM2M Object or Object Instance, the LWM2M IPE updates the corresponding <mgmtObj> resource according to the procedures described in clause 9.
+
+
+## 6.6 LWM2M Object Security
+
+### 6.6.1 Introduction
+
+OMA-LWM2M and oneM2M Access Control Policies shall collaborate in order to assure the interworked resources are accessible according to the oneM2M Authorisation Procedure specified in clause 11.3.4 (M2M Authorization Procedure) of oneM2M TS-0001 <a href="#_ref_2">[2]</a> and clause 7 (Authorization) of oneM2M TS-0003 <a href="#_ref_5">[5]</a>.
+
+
+### 6.6.2 LWM2M Interworking Access Control Policy
+
+The oneM2M Access Control Policy mechanisms specified in clause 7 of oneM2M TS-0003 <a href="#_ref_5">[5]</a>, shall be used to check and validate the parameters of a request message against the ACPs (<accessControlPolicy> resources) which have been assigned to the accessed resource.
+
+In order to assure a proper LWM2M Interworking with oneM2M, the IPE shall setup the hosting CSE by:
+
+1. providing a mandatory set of <accessControlPolicy> (ACPs) resources
+2. assigning a proper set of ACPs to the accessControlPolicyIDs attribute of each <container> resource allocated during the CSE registration phase (clause 6.3 LWM2M Object Discovery)
+
+The process for provisioning the IPE in order to perform such a setup is described in clause 6.6.3 "IPE and Object Security provisioning" of the present document.
+
+In addition, the Access Control Policy mechanisms specified in clause 7 of oneM2M TS-0003 <a href="#_ref_5">[5]</a> are fully applicable in this LWM2M interworking context.
+
+
+### 6.6.3 IPE and Object Security provisioning
+
+In order to provide oneM2M information specified in the clause 6.6.2 (set of <accessControlPolicy> (ACPs) resources, assignment of accessControlPolicyIDs), the LWM2M IPE shall be supplied by information such as:
+
+- a list of oneM2M originators and their associated Access Control Rules likely to be exercised on the Hosting CSE resources
+- a list of oneM2M originators likely to contact the LWM2M Clients with the associated set of authorized operations
+
+In combining such an information with the Access Control Policy specified in a given LWM2M Client (clause 6.8 LWM2M Client Provisioning) the LWM2M IPE shall be able to provide to the Hosting CSE, the oneM2M Access Control Policy materials needed for properly registering LWM2M Objects representation. In the current release of this Specification, this procedure of how the Access Control Policy materials are provided is implementation specific.
+
+
+## 6.7 LWM2M IPE Administration and Maintenance
+
+### 6.7.1 Introduction
+
+The IPE described in clause 5.4 is comprised functionality that includes the LWM2M Server and the IPE's AE. This clause describes the administration and maintenance of these functional elements.
+
+
+### 6.7.2 Administration and Maintenance of the LWM2M Server Functionality
+
+#### 6.7.2.1 Introduction
+
+The LWM2M IPE provides the functionality that plays the role of the LWM2M Server in order to communicate with LWM2M Clients.
+
+In order for communication to be established information needs to be provisioned into the LWM2M Client and LWM2M Server where the following artefacts are necessary to be established for the LWM2M Server:
+
+- LWM2M Server and Client Credentials.
+- LWM2M Access control lists.
+
+In addition, the LWM2M Server maintains information about each LWM2M Client and has actions that are used to maintain the LWM2M Server.
+
+These aspects of the LWM2M Server are further described in clause E.2 of the LWM2M Server resource <a href="#_ref_3">[3]</a>.
+
+The mechanisms used to administer and maintain the LWM2M Server functionality within the LWM2M IPE is out of scope of the present document.
+
+
+#### 6.7.2.2 LWM2M Server Maintenance
+
+The LWM2M Server maintains a set of LWM2M Server account information for each LWM2M Client that allows the LWM2M Server to access and communicate with LWM2M Client. These are:
+
+- LWM2M Server identifier associated with and assigned by the LWM2M Client (LWM2M Server identifier, registration lifetime).
+- Policies for default observation behavior.
+
+The following actions can also be performed that affects the state of the LWM2M Server's interaction with the LWM2M Client:
+
+- On-demand request for the LWM2M Client to update its registration.
+
+
+### 6.7.3 Maintenance of the LWM2M IPE AE Context
+
+#### 6.7.3.1 Introduction
+
+The LWM2M IPE AE maintains information related to the operational context of the LWM2M IPE AE. Specifically the following elements are maintained for the LWM2M IPE AE:
+
+
+- List of currently registered LWM2M Endpoints.
+- Configuration of the Interworking Functions to be used for the LWM2M Objects and Object Instances.
+
+#### 6.7.3.2 LWM2M Endpoint List
+
+Whenever an LWM2M Endpoint <AE> resource is created, updated or deleted as described in clause 6.2, the LWM2M IPE also manages the list of LWM2M Endpoint <AE> resources using a oneM2M <group> resource.
+
+The oneM2M <group> resource's lifecycle is linked to the LWM2M IPE <AE> resource's lifecycle.
+
+
+**Table 6.7.3.2-1: LWM2M IPE <AE> resource - Group Lifecycle**<a name="table_6.7.3.2-1"></a>
+
+| LWM2M IPE <AE> resource Operation | oneM2M Resource and Operation |
+|--------------------------------------|------------------------------------------------------------------------------------------|
+| create | create <group>. The group resourceName is the AE-ID of the LWM2M IPE <AE>.resource |
+| update | update <group> |
+| delete | delete <group> |
+
+The LWM2M Endpoint <AE> resources' lifecycle operation maps to the following operations on the oneM2M <group> resource.
+
+
+**Table 6.7.3.2-2: LWM2M Endpoint <AE> resource - Group member Lifecycle**<a name="table_6.7.3.2-2"></a>
+
+| LWM2M Endpoint <AE> resource Operation | oneM2M Resource and Operation |
+|-------------------------------------------|-----------------------------------|
+| Create | update <group> (add member) |
+| Delete | update <group> (delete member) |
+
+
+#### 6.7.3.3 Configuration of Interworking Functions
+
+Clause 5.3 describes the types of interworking functions as Transparent Interworking Function and Semantically Enabled Interworking Function. An IPE provides the capability to perform one or both types of interworking functions. The granularity (e.g. Object/Object Instance, IPE) that is used to define which interworking function(s) to use is implementation specific.
+
+
+## 6.8 LWM2M Client Provisioning (Bootstrap)
+
+This present document makes assumptions that the LWM2M Clients and LWM2M Servers functionality of the IPE have been provisioned with the proper LWM2M credential materials in accordance to the LWM2M specification (A.5.3.1. Bootstrap) in order to securely communicate between the LWM2M Client and LWM2M Server.
+
+Additionally, a LWM2M Client connected to a LWM2M IPE, should be provisioned with the LWM2M Access Control Policy information associated to the Object Instances contained in the LWM2M Client as described in clause 6.6 LWM2M Object Security. Additionally, in current release of this present document, the LWM2M Server role of the LWM2M IPE does not contain the LWM2M Bootstrap Server capability, consequently the LWM2M Client provisioning operations shall be part of an out-of-band process.
+
+
+# 7 Transparent Interworking Function
+
+## 7.1 Introduction
+
+Clause 5.3 introduced the Transparent Interworking function as depicted in Figure 5.3-1. This clause specifies the mappings of the attributes of the <contentInstance> resource for a <container> resource in order to allow an AE that uses the Content Sharing Resource to understand that the Content Sharing Resource has an encapsulated LWM2M Object or Object Instance.
+
+
+## 7.2 Attribute Mapping for the <contentInstance> Resources
+
+When an AE accesses a <contentInstance> resource, the AE needs to know that the <contentInstance> resource encapsulates a LWM2M Object or Object Instance as well as how the LWM2M Object or Object Instance is encoded.
+
+
+**Table 7.2-1: Transparent Interworking Function Mapping**<a name="table_7.2-1"></a>
+
+| Interworking Function Mapping | oneM2M Resource Attribute |
+|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------|
+| Indication that a LWM2M Object or Object Instance is encapsulated in the <contentInstance> resource with the content type and encoding of the LWM2M Object or Object Instance. | <contentInstance> resource: labels. Value is "LWM2M-Object-Encapsulation" |
+| The content type of the LWM2M Object or Object Instance based on the Content-Type option | <contentInstance>: contentInfo. Possible contentInfo values are translated from the LWM2M Content-Type option (see note). |
+| NOTE: The LWM2M Technical Specification <a href="#_ref_3">[3]</a> defines the value to be used for the [encoding] if the Content-Type option is not present. | |
+
+
+
+
+# 8 Semantically Enabled Interworking Function (Informative)
+
+## 8.1 Introduction
+Clause 5.3 introduced the Semantically Enabled Interworking function as depicted in Figure 5.3-2. This clause specifies how LWM2M Objects and their associated LWM2M Resources are organized as <container> resources in order for values associated with the LWM2M Resources be translated into <contentInstance> resources. In addition, this clause specifies the mapping of Content Sharing Resources the oneM2M Base Ontology <a href="#_ref_i.5">[i.5]</a>.
+
+
+## 8.2 Organization of Semantically Enabled Content Sharing Resources
+
+### 8.2.1 Introduction
+
+Semantically enabled Content Sharing Resources represent the structure and content of LWM2M Objects and Object Instances by translating LWM2M Objects, Object Instances and their LWM2M Resources and LWM2M Resource Instances into a hierarchy of Content Sharing Resources using the Content Sharing Resource's parent-child relationship described in oneM2M TS-0001 <a href="#_ref_2">[2]</a>. In addition, the LWM2M Resources values are contained within the <contentInstance> resource for <container> resources.
+
+When the LWM2M Resource is of type LWM2M Object Link, the <contentInstance> resource that represents the LWM2M Resource is used to represent the LWM2M Object Link by assigning the destination of the LWM2M Object Link reference to another LWM2M Object's Content Sharing Resource. The reference is assigned using the <contentInstance> resource's contentRef attribute where the name of the attribute is "ObjectLink" and the value of the attribute is the URI of the destinaton Content Sharing Resource.
+
+
+
+
+**Figure 8.2.1-1: Relationships of LWM2M Semantically Enabled Content Sharing Resources**
+
+
+### 8.2.2 Lifecycle of Semantically Enabled Content Sharing Resources
+
+Clauses 6.3 and 6.4 describe how LWM2M Objects and Object Instances are discovered and instantiated. The Semantic Interworking function uses these procedures for instantiation of the Content Sharing Resource for the LWM2M Objects and Object Instances.
+
+The Content Sharing Resources for LWM2M Resources and Resource Instances are created as child resources of the parent Content Sharing Resource when the LWM2M Object and Object Instance are created. Likewise these child Content Sharing Resources are deleted when the parent Content Sharing Resource is deleted.
+
+Creation, update or deletion of one or more <contentInstance> resources for the LWM2M Resource or Resource Instances that are not caused by the creation or deletion of the parent LWM2M Object or Object Instance Content Sharing Resource maps to the following operations on the LWM2M Client.
+
+
+**Table 8.2.2-1: LWM2M Resource Content Sharing Resource Lifecycle Translation**<a name="table_8.2.2-1"></a>
+
+| LWM2M Operation<br />Device Management & Service Enablement Interface | oneM2M Resource and Operation<br />LWM2M Resource or Resource Instance<br /> Child Content Sharing Resource |
+|-----------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Write | create child Content Sharing Resource for new Resource or Resource Instance. The name of the Content Sharing Resource shall be the Resource Id for a singleton LWM2M Resource. The name of the Content Sharing Resource shall be the LWM2M Resource ID and LWM2M Resource Instance Id.<br /><br />When the LWM2M Resource is of type LWM2M Object Link, the <contentInstance> resource that represents the LWM2M Resource is used to represent the LWM2M Object Link by assigning the destination of of the LWM2M Object Link reference to another LWM2M Object's Content Sharing Resource. The reference is assigned using the <contentInstance> resource's contentRef attribute where the name of the attribute is "ObjectLink" and the value of the attribute is the URI of the destination <contentInstance> resource. |
+| Not applicable | update Content Sharing Resource |
+| Write | delete Content Sharing Resource for Resource or Resource Instance |
+| Not Applicable | read Content Sharing Resource |
+
+
+**Table 8.2.2-2: LWM2M Resource <contentInstance> Lifecycle Translation**<a name="table_8.2.2-2"></a>
+
+| LWM2M Operation<br />Device Management & Service Enablement Interface | oneM2M Resource and Operation<br />LWM2M Resource or Resource Instance <contentInstance> resource |
+|-----------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|
+| Write | create <contentInstance> |
+| Write - Sets the Resource to default value | delete <contentInstance> |
+| Read | read <contentInstance> |
+
+
+### 8.2.3 Mapping for the Encoding of the <contentInstance> Resource
+
+When an AE accesses a <contentInstance> resource, the AE needs to know how the value of the Resource or Resource Instance is encoded.
+
+
+**Table 8.2.3-1: Mapping of Resource or Resource Instance Encoding**<a name="table_8.2.3-1"></a>
+
+| Interworking Function Mapping | oneM2M Resource Attribute |
+|------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| The encoding of the LWM2M Resource or Resource Instance based on the Content-Type option | <contentInstance>: contentInfo.<br />Possible contentInfo values are translated from the LWM2M Content-Type option. Note: The LWM2M Technical Specification <a href="#_ref_3">[3]</a> defines the value to be used for the [encoding] if the Content-Type option is not present. |
+
+
+## 8.3 Guidelines for Mapping to the Base Ontology
+
+### 8.3.1 Introduction
+
+Clause 8.2 describes the structure and relationships of the LWM2M Objects and Object Instances along with their associated Resources and Resource Instances. Using that structure this clause provides guidance on mapping the Base Ontology described by <a href="#_ref_i.5">[i.5]</a> onto that resource structure. As ontologies are created for specific applications of LWM2M Objects (e.g. Device Management, Home Automation), this clause can only be used for a basis of creating the application specific ontology because certain elements of base ontology (e.g. Aspects, Functionality, Services) cannot be inferred by the LWM2M definitions of LWM2M Objects, Object Instances, Resources or Resource Instances.
+
+
+### 8.3.2 Mapping of the LWM2M Client
+
+LWM2M Clients are represented as <AE> resources and are mapped to an InterworkedDevice. <AE> resources exposed by the LWM2M Server associated with the IPE are mapped to the same Area Network.
+
+
+### 8.3.4 Mapping of the LWM2M Object, Object Instance. Resource and Resource Instance
+
+#### 8.3.4.1 Introduction
+
+<mark>Editor's note: Is a single sub-clause allowed?</mark>
+
+Mapping the LWM2M Object, Object Instance. Resource and Resource Instance to the Base Ontology is based on the following guidelines:
+
+- LWM2M Clients are mapped to InterworkedDevices
+- LWM2M Objects are mapped to Services and Functionality
+- LWM2M Resources that represent static (configured) properties of LWM2M Objects are mapped to ThingProperties.
+- LWM2M operation of Execute map to Operation and Command
+- LWM2M Create, Update, Retrieve and Delete operations permitted for the LWM2M Object or Object Instances map to Operation and Command
+- LWM2M Resources (including those of type Object Link) are mapped to Input- / OutputDataPoints.
+ - Sub-structures of LWM2M Resources are mapped to Variables that are sub-structures of Input- / OutputDataPoints (via the hasSubStructure relation).
+ - Read-only LWM2M Resources map to Output DataPoint.
+ - Write-only LWM2M Resources map to Input DataPoint.
+ - Read-write LWM2M Resources map to Input Datapoint and Output Datapoint with the same instance of a Variable
+ - If the LWM2M Object doesn't have a command state, the IPE will instantiate and maintain a <container> resource for command's state. In both instances the LWM2M Resource that represents the command state maps to Output DataPoint.
+
+# 9 oneM2M Management Object-based Interworking Function
+
+## 9.1 Introduction
+
+Clause 5.3 introduced the Management Object-based Interworking function as depicted in Figure 5.3-3. This clause specifies the mappings of the attributes of oneM2M resources to LWM2M objects in order to allow an AE to use the oneM2M resource without needing to understand the underlying LWM2M Object, Object Instance or Resource syntax or semantics.
+
+
+## 9.2 Translation of oneM2M Management Resource Types
+
+### 9.2.1 Introduction
+
+These mappings and procedures are used to translate between LWM2M Objects, Object Instances and Resources and the applicable management-related oneM2M resource types.
+
+
+### 9.2.2 Translation to <mgmtObj> Resource Types
+
+#### 9.2.2.1 Mapping to <mgmtObj> Resource Types
+
+TS-0005 <a href="#_ref_4">[4]</a> provides the procedures and mappings needed to translate LWM2M Objects, Object Instances and Resources into <mgmtObj> resource types. Relevant clauses include:
+
+- Clause 6.1 and 6.3 of TS-0005 <a href="#_ref_4">[4]</a> provides mapping LWM2M Objects, Object Instances and Resources into <mgmtObj> resource types.
+- Clause 6.2.1 of TS-0005 <a href="#_ref_4">[4]</a> provides a mapping of the LWM2M Endpoint Client Name to the M2M-Node-ID.
+- Clauses 6.2.2 and 6.2.3 of TS-0005 <a href="#_ref_4">[4]</a> provides mapping of the LWM2M Object and Instance Identifiers to the <mgmtObj> resource's objectId and objectPath attributes.
+- Clause 6.7 of TS-0005 <a href="#_ref_4">[4]</a> provides a set of guidelines that shall be followed for one-to-one mapping of a a LWM2M Object and its resources to a corresponding oneM2M <mgmtObj> and its [objectAttribute]s.
+
+LWM2M IPEs shall implement clause 6.1 and 6.3 or clause 6.7 of TS-0005 <a href="#_ref_4">[4]</a> when translating between LWM2M Objects, Object Instances and Resources and <mgmtObj> resource types.
+
+Clause 6.2.2.2 of this present document provides the normative language that addresses the mapping of the LWM2M Endpoint Client Name used for naming the <node> resource type associated with the LWM2M Client. This is because Clause 6.2.1 of TS-0005<a href="#_ref_4">[4]</a> does not allow for multiple LWM2M Clients to be hosted on the same device.
+
+Clause 6.3 of this present document provides normative language that addresses how LWM2M Object and and Instance identifiers are mapped for oneM2M resource naming and discovery. For <mgmtObj> resources, LWM2M IPEs shall implement clause 6.2.2 and 6.2.3 of TS-0005 <a href="#_ref_4">[4]</a> along with clause 6.3 of this present document.
+
+
+#### 9.2.2.2 Interworking of <mgmtObj> Resources
+
+#### 9.2.2.2.1 Introduction
+
+Clause 10.2.8 of TS-0001 <a href="#_ref_2">[2]</a> discusses the procedures for the _<mgmtObj>_ resources as well as where the resources are hosted and the _<mgmtObj>_ resource's relationship with its parent _<node>_ resource. As the _<node>_ resource is the parent resource of the _<mgmtObj>_ resources for the node, clause 6.4.2, 6.5.2 and 6.5.3 of this present document is unable to address the relevant interworked resource settings and procedures that allows the LWM2M IPE to be notified of changes to _<mgmt_ _O_ _bj>_ resources or to secure the _<mgmtObj>_ resource. This clause provides the mapping to the settings and procedures necessary to accomplish this interworking.
+
+
+#### 9.2.2.2.2 Interworking of <mgmtObj> Resource Settings
+
+For supporting the LWM2M interworking process, a few attributes for the <node> resource, _<mgmtObj>_ resource and the _<subscription>_ resource shall have a specified set of parameters.
+
+a) Attributes of _<node>_ resource
+
+**Table 9.2.2.1.2-1: _<node>_ resource - Relevant Interworked Attributes**<a name="table_9.2.2.1.2-1"></a>
+
+| Attributes of _<mgmtObj>_ resource | Value |
+|---------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| _accessControlPolicyIDs_ | ACP set (see Clause 6.6) |
+| _nodeID_ | The M2M-Node-ID of the node which is represented by this _<node>_ resource. |
+| _hostedCSELink_ | The resource ID of a resource where all of the following applies:<br />- The resource is a _<CSEBase>_ resource or a _<remoteCSE>_ resource.<br />- The resource is hosted on the same CSE as the present _<node>_ resource.<br />The resource represents the CSE which resides on the specific node that is represented by the current _<node>_ resource. |
+| _mgmtClientAddress_ | Represents the physical address of management client of the node which is represented by this <node> resource.<br /><br />This attribute is absent if management server is able to acquire the physical address of the management client. |
+
+b) Attributes of _<mgmtObj>_ resource
+
+**Table 9.2.2.1.2-2: _<mgmtObj>_ resource - Relevant Interworked Attributes**<a name="table_9.2.2.1.2-2"></a>
+
+| Attributes of _<mgmtObj>_ resource | Value |
+|---------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| _accessControlPolicyIDs_ | ACP set (see Clause 6.6) |
+| _mgmtDefinition_ | Examples are software, firmware, memory. The list of the value of the attribute can be seen in annex D of TS-0001. |
+| _mgmtSchema_ | Contains a URI to the <_mgmtObj_ > schema definition which shall be used by the Hosting CSE to validate the syntax of incoming primitives targeting this _<mgmtObj>_ resource.<br /><br />This URI may refer to a oneM2M specified <_mgmtObj_ > definition as well as other <mgmtObj> definitions. |
+| _objectIDs_ | Contains the list of URNs that uniquely identify the technology specific data model objects used for this _<mgmtObj>_ resource as well as the managed function and version it represents. |
+| _objectPaths_ | Contains the list of local paths of the technology specific data model objects on the managed entity which is represented by the _<mgmtObj>_ resource in the Hosting CSE. An example is:<br /> /5/0<br />The combination of the _objectPaths_ and the _objectIDs_ attribute, allows to address the technology specific data model. |
+| _mgmtLink_ | This attribute contains reference to a list of other _<mgmtObj>_ resources in case a hierarchy of _<mgmtObj>_ is needed. |
+| _[objectAttribute]_ | Each _[objectAttribute]_ is mapped from a leaf node of a hierarchical structured technology specific data model object (including oneM2M data model and the technology specific data model objects) based on the mapping rules below the table. |
+| _description_ | Text format description of <_mgmtObj>_. |
+
+
+#### 9.2.2.2.3 Synchronization _<mgmtObj>_ resources
+
+_<mgmtObj>_ resources can be maintained by AEs and/or the LWM2M IPE on behalf of the LWM2M client. Since AEs can maintain _<mgmtObj>_ resources, the request originator (i.e., AE, LWM2M IPE AE) shall create a subscription to notify the LWM2M IPE when the _<mgmtObj>_ resource is created, deleted or updated using the setting as described in Table 9.2.2.1.3-1.
+
+
+**Table 9.2.2.1.3-1: Subscription Procedure - <subscription> resource**<a name="table_9.2.2.1.3-1"></a>
+
+| Attributes of _<subscription>_ | Description |
+|-----------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| _accessControlPolicyIDs_ | Link a <accessControlPolicy> resource with the privileges:<br />accessControlOriginator originatorID set to the LWM2M IPE AE's AE-ID<br />accessControlOperations: Set to RETRIEVE, CREATE, UPDATE, DELETE, DISCOVER, NOTIFY |
+| _pendingNotification_ | Set to "sendLatest" |
+| _latestNotify_ | Set to "latest". |
+| _notificationContentType_ | Set to "resource" |
+| _<schedule>_ | Set to immediate notification |
+
+
+#### 9.2.2.3 Example of creating new specialized <mgmtObj> resources
+
+Using the generic guidelines outlined in Clause 6.7 of TS-0005 <a href="#_ref_4">[4]</a>, new <mgmtObj> specialization resources may be created on the CSE. Figure 9.2.2.3-1 shows the procedure a Hosting CSE executes to create a new <mgmtObj> specialization resource using the _mgmtSchema_ attribute. The URI of the schema file for the <mgmtObj> specialization resource is provided in the _mgmtSchema_ attribute of the request to create the <mgmtObj> resource. The Hosting CSE then retrieves the schema file using the URI and process the request as outlined below.
+
+
+**Figure 9.2.2.3-1: Procedure for CSE to Support New Specialized <mgmtObj> Resources**
+
+
+**Step 001:** The Originator shall send mandatory parameters and may send optional paramters in the Request message for a CREATE operation of a <mgmtObj> specialization resource. The specialized <mgmtObj> resource contains a full mapping of the underlying LWM2M Object and includes the URI of the XSD for the new specialized resource in the _mgmtSchema_ attribute.
+
+**Step 002:** The Receiver shall:
+
+1. Check if the Originator has the appropriate privileges for performing the request.
+2. Verify that the name for the created resource as suggested by the _resourceName_ parameter does not already exist among child resources of the targeted resource.
+
+**Step 003:** The Receiver shall check if the type <mgmtObj> specialization is present in the supportedResourceType attribute of the CSEBase. If found in the _supportedResourceType_ attribute, go to Step 8; otherwise, go to Step 4.
+
+**Step 004:** The Receiver extracts the contents of the _mgmtSchema_ attribute and retrieves an XSD from the XSD Repository.
+
+**Step 005:** The XSD Repository returns the XSD for the specialized <mgmtObj> resource.
+
+**Step 006:** The Receiver checks the received XSD is well formed and if it is, saves the XSD to the Receiver's local XSD repository.
+
+**Step 007:** The Receiver updates the _supportedResourceType_ attribute with the type of the specialized <mgmtObj>.
+
+**Step 008:** The Receiver completes processing the CREATE request.
+
+1. Assign a Resource-ID to the resource to be created.
+2. Assign values for mandatory RO mode attributes of the resource and override values provided for other mandatory attributes and where allowed by the resource type definition and if not provided by the Originator itself.
+3. The Receiver shall assign a value to the following common attributes:
+
+ a. _parentID_;
+ b. _creationTime_;
+ c. _expirationTime_: if not provided by the Originator, the Receiver shall assign the maximum value possible (within the restriction of the Receiver policies). If the value provided by the Originator cannot be supported, due to either policy or subscription restrictions, the Receiver will assign a new value;
+ d. _lastModifiedTime_: which is equals to the creationTime;
+ e. Any other RO (Read Only) attributes within the restriction of the Receiver policies.
+
+4. The Receiver shall check whether a _creator_ attribute is included in the **_Content_** parameter of the request. If included, the _creator_ attribute shall not have a value in the **_Content_** parameter of the request. On the other hand if the _creator_ attribute is not included in the **_Content_** parameter of the request, then the Receiver shall not include the _creator_ attribute in the resource to be created.
+5. On successful validation of the Create Request, the Receiver shall create the requested resource.
+6. The Receiver shall check if the created child resource leads to changes in its parent resource's attribute(s), if so the parent resource's attribute(s) shall be updated.
+
+**Step 009:** The Receiver shall respond with mandatory parameters and may send optional parameters in Response message for CREATE operation.
+
+**General Exceptions:**
+
+<mark>Editor's note: Is the following numbering correct? Does it refer to the previous steps?</mark>
+
+4. The Originator does not have the privileges to create a resource on the Receiver. The Receiver responds with an error.
+5. The resource with the specified name (if provided) already exists at the Receiver. The Receiver responds with an error.
+
+- The provided information in _Content_ is not accepted by the Receiver (e.g. missing mandatory parameter). The Receiver responds with an error.
+
+
+#### 9.2.2.4 LWM2M Interworking Procedure
+
+Figure 9.2.2.4-1 shows an example end-to-end procedure demonstrating how the procedures shown in Figure 9.2.2.3-1 can be utilized as part of LWM2M Interworking. The LWM2M Server and the IPE are co-located, and together they perform oneM2M procedures on behalf of the LWM2M Device. A LWM2M Device will initially register to the LWM2M Server and provides a list of all the LWM2M objects it supports. The LWM2M Server/IPE will then perform a oneM2M registration on behalf of the device and requests to create an <AE> resource. Once the <AE> resource is created, the IPE will then create a <node> resource to host all the <mgmtObj> resources for the device. As part of this step, the nodeLink attribute of the <AE> resource will be updated to point to the newly created <node> resource. The IPE then proceeds to create a specialized <mgmtObj> resource for each LWM2M objects the device supports. The specialized <mgmtObj> resource will directly map to the corresponding LWM2M Object using the _objectAttribute_ attribute of the <mgmtObj>. This will allow for one-to-one mapping of LWM2M resources to oneM2M attributes. Once all the <mgmtObj> specializations are created, the IPE/LWM2M Server returns an appropriate response to the LWM2M Device.
+
+NOTE: The following procedure shows only a high level call flow of the interactions among the LWM2M Device, the LWM2M Server/IPE, and the Hosting CSE. It does not detail all the steps required to perform the indicated operations.
+
+
+
+
+**Figure 9.2.2.4-1: End-to-end LWM2M Interworking Procedure**
+
+
+**Step 001:** A LWM2M device registers to the LWM2M Server and provides a list of supported LWM2M Objects. Co-located with the LWM2M Server is the IPE.
+
+**Step 002:** In response to the LWM2M registration, the IPE requests to create an <AE> resource on the Hosting CSE on behalf of the LWM2M Device.
+
+**Step 003:** The Hosting CSE evaluates the request, performs the appropriate checks, and creates the <AE> resource.
+
+**Step 004:** A response is sent to the IPE indicating the <AE> resource was created.
+
+**Step 005:** The IPE proceeds to create a <node> resource for the LWM2M Device so <mgmtObj> specialization resources can be created for AE's to manage the device. As part of this multi-step procedure, the _nodeLink_ attribute of the <AE> resource created in Step 003 is updated to point to the newly created <node> resource.
+
+**Step 006:** The Hosting CSE creates the <node> resource and updates the <AE>'s _nodeLink_ attribute as well.
+
+**Step 007:** The Hosting CSE returns an appropriate response for creating the <node> resource.
+
+**Step 008:** For each of the LWM2M Objects supported by the LWM2M Device, the IPE creates an appropriate specialized <mgmtObj> resource as a child of the <node> resource. This <mgmtObj> specialization maps one-for-one with the corresponding LWM2M Object.
+
+**Step 009** **:** .The Hosting CSE creates the <mgmtObj> specialization resource.
+
+**Step 010:** An appropriate response is returned to the IPE for the creation of the <mgmtObj> specialization resource.
+
+**Step 011:** The IPE/LWM2M Server completes the LWM2M registration procedure by sending the LWM2M Device an appropriate response.
+
+
+#### 9.2.2.5 Use of oneM2M attribute level subscription in LWM2M Interworking
+
+Once the <mgmtObj> resources are created, attribute level subscriptions can be created to get notifications for certain desired operation such as a firmware update process. With the one-to-one mapping relationship between LWM2M resources and oneM2M [objectAttribute], attribute level subscriptions can be made. Table 9.2.2.5-1 shows a mapping of the LWM2M Firmware Update object to a new oneM2M Firmware <mgmtObj> with all the LWM2M resources mapped one for one to oneM2M attributes.
+
+
+**Table 9.2.2.5-1: LWM2M Firmware Update Object 1:1 Mapping to oneM2M <mgmtObj> Resource**<a name="table_9.2.2.5-1"></a>
+
+| LWM2M Resource Name | LWM2M Resource # | [objectAttribute] |
+|----------------------------------|------------------|-------------------------------|
+| Package | 0 | package |
+| Package URI | 1 | pkgURI |
+| Update | 2 | update |
+| State | 3 | state |
+| Update Result | 5 | updateResult |
+| Pkg Name | 6 | pkgName |
+| Pkg Version | 7 | pkgVersion |
+| Firmware Update Protocol Support | 8 | firmwareUpdateProtocolSupport |
+| Firmware Update Delivery Method | 9 | firmwareUpdateDeliveryMethod |
+
+
+The call flow below uses the updated Firmware Update object mapping in Table 9.2.2.5-1 to allow an AE to monitor the state of a firmware update on a LWM2M device. Prior to initiating a firmware update, the AE can subscribe to the **_state_** attribute of the 1:1 mapped **_firmware_** <mgmtObj> to get notifications of the firmware update process. Figure 9.2.2.5-1 shows the end-to-end use case of using oneM2M's attribute level subscription to get notifications for the state of the firmware update.
+
+
+
+
+**Figure 9.2.2.5-1: oneM2M Attribute Level Subscription Use Case**
+
+
+**Step 001:** AE subscribes to the **_state_** attribute of the **_firmware_** <mgmtObj> associated with LWM2M Device.
+
+**Step 002:** Hosting CSE grants the subscription and sends a successful response.
+
+**Step 003:** AE sends a firmware update request to update the firmware on the LWM2M Device.
+
+**Step 004:** Hosting CSE processes the request and performs the following:
+
+a) Hosting CSE sends a Notify message to the IPE of the firmware update request.
+b) Hosting CSE sends a successful response to the AE.
+
+**Step 005:** The LWM2M Server/IPE sends a firmware update command to the LWM2M Device.
+
+**Step 006:** The LWM2M Device receives the command and performs the download of the firmware image.
+
+a) The LWM2M Device sends an update to the LWM2M Server with status that **_state = Downloading_**
+b) The LWM2M Server/IPE sends an update to the Hosting CSE with status that **_state = Downloading_**.
+c) The Hosting CSE sends a notify to the AE with status that **_state = Downloading_**.
+
+**Step 007:** The LWM2M Device completes the download and updates its state resource.
+
+a) The LWM2M Device sends an update to the LWM2M Server with status that **_state = Downloaded_**.
+b) The LWM2M Server/IPE sends an update to the Hosting CSE with status that **_state = Downloaded_**.
+c) The Hosting CSE sends a notify to the AE with status that **_state = Downloaded_**.
+
+**Step 008:** The LWM2M Device begins updating the firmware and updates its state resource.
+
+a) The LWM2M Device sends an update to the LWM2M Server with status that **_state = Updating_**.
+b) The LWM2M Server/IPE sends an update to the Hosting CSE with status that **_state = Updating_**.
+c) The Hosting CSE sends a notify to the AE with status that **_state = Updating_**.
+
+**Step 009:** The LWM2M Device completes updating the firmware successfully and updates its state resource.
+
+a) The LWM2M Device sends an update to the LWM2M Server with status that **_state = Idle_**.
+b) The LWM2M Server/IPE sends an update to the Hosting CSE with status that **_state = Idle_**.
+c) The Hosting CSE sends a notify to the AE with status that **_state = Idle_**.
+
+
+# Annex A (Informative): Introduction to OMA LightweightM2M (LWM2M)
+
+## A.1 Introduction
+
+OMA Lightweight M2M is a protocol for device and service management for M2M. The main purpose of this technology is to address service and management needs for constrained M2M devices, over UDP and SMS bearers.
+
+> NOTE: This annex provides an overview of the LWM2M protocol. The authoritative source for the protocol is provided by the LWM2M Technical Specification <a href="#_ref_3">[3]</a>.
+
+The crucial aspects in this work are the:
+
+- Target devices for this protocol are resource constraint devices (e.g. 8-16bit MCU, RAM is in tens of KB and flash is in hundreds of KB).
+- Ability to perform Data collection and remote control of devices without the need for complex computing and UI operations.
+- Optimization of network resources to allow a large numbers of devices may be connected to the communication network simultaneously.
+- Fusion of device functionalities management and service manipulation into a single protocol.
+
+From the implementation view LWM2M has the following features:
+
+- Suitable for resource constraint devices.
+- Usage of compact binary packets.
+- Support for multiple data encoding formats that include Binary , JSON, plain text and opaque data formats.
+- Support for reporting information from the Server to the Client when specified condition are met.
+- Easy to be implemented though the reuse of existing implementation of IETF technologies : e.g. CoAP.
+- (Constrained Application Protocol) for the Transfer Protocol, and DTLS (Datagram, Transport Layer Security) <a href="#_ref_i.3">[i.3]</a> for securing the Server/Client exchanges.
+
+One of typical use cases of using LWM2M technology is the firmware upgrade of streetlights <a href="#_ref_i.4">[i.4]</a>.
+
+- A Streetlights supervisor is responsible for managing the streetlights system. (There are thousands of streetlights in the city and low-cost LWM2M devices embedded in the streetlights.)
+- The supervisor needs to remotely upgrade of the firmware of a specific streetlight or a group of streetlights.
+
+
+
+**Figure A.1-1: Firmware Upgrade of Streetlight of Use Case using LWM2M**
+
+
+## A.2 Architecture
+
+
+
+**Figure A.2-1: LWM2M Architecture**
+
+
+As shown in the Figure A.2-1, the layout is the architecture of LWM2M <a href="#_ref_3">[3]</a>. The Components specified by OMA LWM2M compose the LWM2M enabler which specifies the LWM2M Server / LWM2M Client interface. The LWM2M Server and LWM2M Client are typically instantiated in a M2M Server and a M2M Device.
+
+Based on the deployment scenario, the LWM2M Server has the bootstrapping capability itself, or the LWM2M Bootstrap Server exists separately for security reasons.
+
+
+## A.3 Terminology
+
+LWM2M <a href="#_ref_3">[3]</a> is a RESTful protocol with concepts that are similar to oneM2M, however LWM2M uses different terms for these concepts. The following table provides a comparison of applicable LWM2M and oneM2M terminology.
+
+
+**Table A.3-1: LWM2M/oneM2M Terminology Mapping**<a name="table_A.3-1"></a>
+
+| LWM2M Terminology | oneM2M Terminology |
+|-------------------------|--------------------------------------------------------------------------------|
+| Client Endpoint | <AE> resources that reside on devices and oneM2M nodes. |
+| Object, Object Instance | Resource in general; <contentInstance> resource when used for interworking. |
+| Resource | Attribute for a Resource. |
+
+
+## A.4 Reference Points
+
+### A.4.1 Introduction
+
+This clause introduces the interfaces carried over the reference point consisting of two main components LWM2M Server and the LWM2M Client.
+
+### A.4.2 Functional Components
+
+#### A.4.2.1 LWM2M Server
+
+The LWM2M Server is a logical component which serves as an endpoint of the LWM2M protocol.
+
+
+#### A.4.2.2 LWM2M Client
+
+The LWM2M Client is a logical component. This LWM2M Client serves as an endpoint of the LWM2M protocol and communicates with the LWM2M Server to execute the device management and service enablement operations from the LWM2M Server and reporting results of the operations.
+
+
+### A.4.3 Interfaces
+
+There are four interfaces supported by the reference point between LWM2M server and LWM2M Client. The logical operation of each interface is defined as follows:
+
+- Bootstrap:
+ - This interface is used to provision essential information into the LWM2M Client so that the LWM2M Client can register to the LWM2M Server(s) after bootstrap procedure has completed.
+- Client Registration:
+ - This interface allows the LWM2M Client register to the LWM2M Server. This procedure lets the Server know the existence and information (e.g. address, capabilities) of the LWM2M Client so that LWM2M Server can perform M2M services and device management on the LWM2M Client.
+- Device Management and Service Enablement:
+ - This interface allows the LWM2M Server to perform the device management and M2M service enablement operations. Over this interface, the LWM2M Server can send operations to the LWM2M Client and gets response of the operations from the LWM2M Client.
+- Information Reporting:
+ - This interface allows the LWM2M Client to report resource information to the LWM2M Server. This Information Reporting can be triggered periodically or by events (e.g. resource information is changed and configured conditions are met).
+
+## A.5 Protocols
+
+### A.5.1 Protocol Stack
+
+The LWM2M has the protocol stack defined as below.
+
+
+
+**Figure A.5.1-1: LWM2M Protocol Stack**
+
+
+- LWM2M Objects: LWM2M Objects are designed for the functionality provided by the LWM2M enabler. The LWM2M specification <a href="#_ref_i.4">[i.4]</a> defines a set of Standard Objects. Other Objects may also be added by OMA, external SDOs (e.g. the IPSO alliance) or vendors to enable certain M2M Services.
+- LWM2M Protocol: LWM2M protocol defines the logical operations and mechanisms per each interface.
+- CoAP: The LWM2M utilizes the IETF Constrained Application Protocol <a href="#_ref_i.2">[i.2]</a> as an underlying transfer protocol across UDP and SMS bearers. This protocol defines the message header, request/response codes, message options and retransmission mechanisms. The LWM2M only uses the subset of features defined in CoAP.
+- DTLS: DTLS <a href="#_ref_i.3">[i.3]</a> is used to provide secure UDP/SMS on-device channels between the LWM2M Server and the LWM2M Client for all the messages interchanged.
+- UDP Binding with CoAP (Mandatory): Reliability over the UDP transport is provided by the built-in retransmission mechanisms of CoAP.
+- SMS Binding with CoAP (Optional): CoAP is used over SMS by placing a CoAP message in the SMS payload using 8-bit encoding.
+
+### A.5.2 Data Model
+
+In the LWM2M Enabler technical specification <a href="#_ref_i.4">[i.4]</a>, a simple data model is described. Basically, a resource made available by data model of the LWM2M Client is a Resource, and Resources are logically organized into Objects. Figure A.5.2-1 illustrates this structure, and the relationship between Resources, Objects, and the LWM2M Client. The LWM2M Client may have any number of Resources, each of which belongs to an Object.
+
+
+
+**Figure A.5.2-1: LWM2M Data Model <a href="#_ref_3">[3]</a>**
+
+
+Resources are defined per Object, and each resource is given a unique identifier within that Object. Each Resource is designed to have one or more Operations that it supports. A Resource may be a single or multiple (possibility of several instantiations) one, dependent on the Resource definition in Object specification. An Object defines a grouping of Resources, for example the Firmware Object contains all the Resources used for firmware update purposes. The LWM2M enabler defines standard Objects and Resources and other Objects may be added to enable a certain M2M Services.
+
+Object needs to be instantiated either by the LWM2M Server or the LWM2M Client, which is called Object Instance, before using the functionality of an Object. After Object Instance is created, the LWM2M Server can access that Object Instance and Resources in the Object Instance. Furthermore a Resource can contain a simple value (e.g. sensor measure), or a reference to an Object Instance.
+
+
+### A.5.3 Interface Descriptions
+
+#### A.5.3.1 Bootstrap
+
+The Bootstrap interface is used to provision essential information into the LWM2M Client in order to allow the LWM2M Client to be able to register to a certain LWM2M Server. There are four modes for bootstrapping:
+
+- Factory Bootstrap: the LWM2M Client is already provisioned at the time of the device manufacture. The pre-configured data is stored in the LWM2M Client.
+- Bootstrap from Smartcard: When the Device supports a Smartcard and retrieval of bootstrap message from Smartcard is successful, the LWM2M Client processes the bootstrap message from the Smartcard and applies it to the LWM2M Client.
+- Client initiated Bootstrap: the LWM2M Client requests and retrieves the bootstrap message from a LWM2M Bootstrap Server. In this case the LWM2M Client needs to be pre-provisioned with the LWM2M Bootstrap Server Bootstrap Information.
+- Server initiated Bootstrap: the LWM2M Bootstrap Server provisions the bootstrap message into the LWM2M Client after recognizing the existence of the LWM2M Device. In this case the LWM2M Client needs to be pre-provisioned with the LWM2M Bootstrap Server Bootstrap Information.
+
+
+
+
+**Figure A.5.3.1-1: Bootstrap Modes**
+
+
+#### A.5.3.2 Client Registration
+
+The Client Registration interface is used by the LWM2M Client to register with one or more LWM2M Servers, maintain each registration, and de-register from the LWM2M Server(s). When registering, the LWM2M Client indicates its Endpoint Name, MSISDN, supporting binding modes, lifetime of registration, the list of Objects the Client supports and available Object Instances. The registration is a soft state, with a lifetime indicated by the registration lifetime. The LWM2M Client periodically performs an update of its registration information to the registered Server(s). If the lifetime of a registration expires without receiving an update from the Client, the Server removes the registration information. Finally, when shutting down or discontinuing use of a Server, the Client performs de-registration.
+
+
+
+
+**Figure A.5.3.2-1: Example of Registration Procedure**
+
+
+#### A.5.3.3 Device Management and Service Enablement
+
+This interface is used by the LWM2M Server to access Resources available from a LWM2M Client using Create, Read, Write, Delete, or Execute operations. The operations that a Resource supports are defined in the definition of its Object.
+
+
+
+
+**Figure A.5.3.3-1: Example of Device Management and Service Enablement Interface**
+
+
+#### A.5.3.4 Information Reporting
+
+This interface is used by the LWM2M Server to observe any changes in a Resource on the LWM2M Client, receiving notifications when new values are available. The LWM2M Server needs to configure observation related parameters by sending "Write Attribute" operation before observing Resources in the LWM2M Client. This observation relationship is initiated by sending an "Observe" operation to the L2M2M Client for an Object Instance or Resource. An observation ends when a "Cancel Observation" operation is performed
+
+
+
+
+**Figure A.5.3.4-1: Example of Information Reporting Interface**
+
+
+## A.6 Functions
+
+A first set of standard Objects for the LWM2M 1.0 enabler have been developed:
+
+- Server Security: security data related to the LWM2M server(s) and/or the LWM2M Bootstrap Server.
+- Server: data, configuration, functions related to the LWM2M Server.
+- Access Control: to check whether the LWM2M server has access right for performing an operation on Resources in the LWM2M Client.
+- Device: provision of a range of device related information, device reboot and factory reset function.
+- Connectivity Monitoring: to monitor parameters related to underlying network connectivity.
+- Firmware: provision of firmware management, installing and updating new firmware.
+- Location: provides location information of the LWM2M Devices.
+- Connectivity Statistics: to statistical information of network connection (e.g. SMS counter, UDP data size).
+
+These Standard Objects are intended to support a variety of functionalities to manage LWM2M Devices. OMA has already specified others LWM2M objects (e.g. as Software Management, Device Capability Management,) and may create further objects in future. Furthermore, other organizations and companies may define additional LWM2M Objects for their own M2M services using according to LWM2M Object Template and Guideline Annex in <a href="#_ref_3">[3]</a>: e.g. oneM2M has specified the set of LWM2M Objects around CMDH Policy functionality; IPSO Alliance has developed LWM2M Objects for various sensors.
+
+
+# History
+
+| Publication history | Publication history | Publication history |
+|---------------------|---------------------|-------------------------|
+| V3.1.1 | February 2019 | Release 3 - Publication |
+| V4.0.0 | February 2023 | Release 4 - Publication |
+| | | |
+
+
+
diff --git a/media/BootstrapModes.png b/media/BootstrapModes.png
new file mode 100644
index 0000000000000000000000000000000000000000..7593a0b0f915c78075e81af71be2f4f6322a01aa
Binary files /dev/null and b/media/BootstrapModes.png differ
diff --git a/media/EndToEndLWM2MInterworingProcedure.png b/media/EndToEndLWM2MInterworingProcedure.png
new file mode 100644
index 0000000000000000000000000000000000000000..e3051ce2e250b3673edee3391137ab9da681491d
Binary files /dev/null and b/media/EndToEndLWM2MInterworingProcedure.png differ
diff --git a/media/ExampleOfDeviceManagementAndServiceEnablementInterface.png b/media/ExampleOfDeviceManagementAndServiceEnablementInterface.png
new file mode 100644
index 0000000000000000000000000000000000000000..7bd1c97b48794ec645a9ec8bf75051f0178ae729
Binary files /dev/null and b/media/ExampleOfDeviceManagementAndServiceEnablementInterface.png differ
diff --git a/media/ExampleOfInformationReportingInterface.png b/media/ExampleOfInformationReportingInterface.png
new file mode 100644
index 0000000000000000000000000000000000000000..91413ec0fa3ac78a775f4949a829bf8eb42d3895
Binary files /dev/null and b/media/ExampleOfInformationReportingInterface.png differ
diff --git a/media/ExampleOfRegistrationProcedure.png b/media/ExampleOfRegistrationProcedure.png
new file mode 100644
index 0000000000000000000000000000000000000000..90de12178cba1d910e56620cfd249c3b88a6ef95
Binary files /dev/null and b/media/ExampleOfRegistrationProcedure.png differ
diff --git a/media/FirmwareUpgradeOfStreetlightOfUseCaseUsingLWM2M.png b/media/FirmwareUpgradeOfStreetlightOfUseCaseUsingLWM2M.png
new file mode 100644
index 0000000000000000000000000000000000000000..99742c1beb64524c33fc6fe6e2328fd6553a23f9
Binary files /dev/null and b/media/FirmwareUpgradeOfStreetlightOfUseCaseUsingLWM2M.png differ
diff --git a/media/LWM2MArchitecture.png b/media/LWM2MArchitecture.png
new file mode 100644
index 0000000000000000000000000000000000000000..33243dd8670501156ebbf01bace26cbb39ef24c9
Binary files /dev/null and b/media/LWM2MArchitecture.png differ
diff --git a/media/LWM2MDataModel.png b/media/LWM2MDataModel.png
new file mode 100644
index 0000000000000000000000000000000000000000..372cc6b4f6fd67b9e48d31521d53f4226406d0b8
Binary files /dev/null and b/media/LWM2MDataModel.png differ
diff --git a/media/LWM2MProtocolStack.png b/media/LWM2MProtocolStack.png
new file mode 100644
index 0000000000000000000000000000000000000000..ee3fc02c497003921d9c31bf9b6709598189bde8
Binary files /dev/null and b/media/LWM2MProtocolStack.png differ
diff --git a/media/LWM2M_IPE_Architecture.png b/media/LWM2M_IPE_Architecture.png
new file mode 100644
index 0000000000000000000000000000000000000000..3dc89feaee6ec7430d5bced9d0fdc68cd2ae32da
Binary files /dev/null and b/media/LWM2M_IPE_Architecture.png differ
diff --git a/media/LWM2M_Interworking_Scenarios.png b/media/LWM2M_Interworking_Scenarios.png
new file mode 100644
index 0000000000000000000000000000000000000000..f02d3d97bf72162043da7b8f0b49d3cbcaa5b00a
Binary files /dev/null and b/media/LWM2M_Interworking_Scenarios.png differ
diff --git a/media/LWM2M_Reference_Model.png b/media/LWM2M_Reference_Model.png
new file mode 100644
index 0000000000000000000000000000000000000000..613136f9d8b407fe83358111e38a143d2477e9b4
Binary files /dev/null and b/media/LWM2M_Reference_Model.png differ
diff --git a/media/LWM2M_Semantically_Enabled_Interworking_Function.png b/media/LWM2M_Semantically_Enabled_Interworking_Function.png
new file mode 100644
index 0000000000000000000000000000000000000000..3dfc2baae3fed6942aaef78f484fe5099a6fabbb
Binary files /dev/null and b/media/LWM2M_Semantically_Enabled_Interworking_Function.png differ
diff --git a/media/LWM2M_Translation_Interworking_Function.png b/media/LWM2M_Translation_Interworking_Function.png
new file mode 100644
index 0000000000000000000000000000000000000000..96b99886d81817e524cb2f52237bbaa4d665665f
Binary files /dev/null and b/media/LWM2M_Translation_Interworking_Function.png differ
diff --git a/media/LWM2M_Transparent_Interworking_Function.png b/media/LWM2M_Transparent_Interworking_Function.png
new file mode 100644
index 0000000000000000000000000000000000000000..896a130397cc4b73b5893db2b5c99698b5a7b6a7
Binary files /dev/null and b/media/LWM2M_Transparent_Interworking_Function.png differ
diff --git a/media/ProcedureForCSEToSupportNewSpecializedMgmtObjResources.png b/media/ProcedureForCSEToSupportNewSpecializedMgmtObjResources.png
new file mode 100644
index 0000000000000000000000000000000000000000..49f9ff4601aa658c88206d8d7245388c5256ca9f
Binary files /dev/null and b/media/ProcedureForCSEToSupportNewSpecializedMgmtObjResources.png differ
diff --git a/media/ProcedureForCreatingAResource.png b/media/ProcedureForCreatingAResource.png
new file mode 100644
index 0000000000000000000000000000000000000000..f84d9da035e5a8f88a44322b9880a50a7808ddbc
Binary files /dev/null and b/media/ProcedureForCreatingAResource.png differ
diff --git a/media/ProcedureForDeletingAResource.png b/media/ProcedureForDeletingAResource.png
new file mode 100644
index 0000000000000000000000000000000000000000..db7cc36cf35aa8cf04150770b850171e162ab772
Binary files /dev/null and b/media/ProcedureForDeletingAResource.png differ
diff --git a/media/ProcedureForRetrievingAResource.png b/media/ProcedureForRetrievingAResource.png
new file mode 100644
index 0000000000000000000000000000000000000000..db0672500944480550ab0b743844af651979f711
Binary files /dev/null and b/media/ProcedureForRetrievingAResource.png differ
diff --git a/media/ProcedureForUpdatingAResource.png b/media/ProcedureForUpdatingAResource.png
new file mode 100644
index 0000000000000000000000000000000000000000..f133c4febfc71f4a0f9f741ab03446ff0e1e240a
Binary files /dev/null and b/media/ProcedureForUpdatingAResource.png differ
diff --git a/media/RelationsOfLWM2MSemanticallyEnabledContentSharingResources.png b/media/RelationsOfLWM2MSemanticallyEnabledContentSharingResources.png
new file mode 100644
index 0000000000000000000000000000000000000000..e5b3550b87d6ed0895dd1219e244c0d4a085cbca
Binary files /dev/null and b/media/RelationsOfLWM2MSemanticallyEnabledContentSharingResources.png differ
diff --git a/media/oneM2MAttributeLevelSubscriptionUseCase.png b/media/oneM2MAttributeLevelSubscriptionUseCase.png
new file mode 100644
index 0000000000000000000000000000000000000000..68d2a42c980891c5e0b20ef84759fb4a3c50bb29
Binary files /dev/null and b/media/oneM2MAttributeLevelSubscriptionUseCase.png differ