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 [4] 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 [4] provides mapping LWM2M Objects, Object Instances and Resources into <mgmtObj> resource types.
- Clause 6.2.1 of TS-0005 [4] 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 [4] provides mapping of the LWM2M Object and Instance Identifiers to the <mgmtObj> resource's objectId and objectPath attributes.
- Clause 6.7 of TS-0005 [4] 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 [4] 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[4] 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 [4] 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 [2] 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
| 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: - The resource is a <CSEBase> resource or a <remoteCSE> resource. - The resource is hosted on the same CSE as the present <node> resource. 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. 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
| 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. 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: /5/0 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
| Attributes of <subscription> | Description |
|---|---|
| accessControlPolicyIDs | Link a <accessControlPolicy> resource with the privileges: accessControlOriginator originatorID set to the LWM2M IPE AE's AE-ID 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 [4], 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:
- Check if the Originator has the appropriate privileges for performing the request.
- 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.
- Assign a Resource-ID to the resource to be created.
- 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.
-
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. -
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.
- On successful validation of the Create Request, the Receiver shall create the requested resource.
- 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:
Editor's note: Is the following numbering correct? Does it refer to the previous steps?
- The Originator does not have the privileges to create a resource on the Receiver. The Receiver responds with an error.
-
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
| 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.