Resource Model

The LWM2M Enabler defines a simple resource model where each piece of information made available by the LWM2M Client is a Resource. Resources are logically organized into Objects. Figure 9 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. Resources and Objects have the capability to have multiple instances of the Resource or Object.

Figure 13: Relationship between LWM2M Client, Object, and Resources

Resources are defined per Object, and each Resource is given a unique identifier within that Object. Each Object and Resource is defined to have one or more operations that it supports. A Resource MAY consist of multiple instances called a Resource Instance as defined in the Object specification. The LWM2M Server can send “Write” operation with JSON or TLV format to Resource to instantiate a Resource Instance. The LWM2M Client also has the capability to instantiate a Resource Instance.

An Object defines a grouping of Resources, for example the Firmware Update Object contains all the Resources used for firmware update purposes. Each Object is assigned a unique OMA Management Object identifier and corresponding index which identifies an Object defined for the LWM2M Enabler. The LWM2M Enabler defines standard Objects and Resources. Further Objects may be added by OMA or other organizations to enable additional M2M Services.

An Object MUST be instantiated either by the LWM2M Server or the LWM2M Client, which is called Object Instance before using the functionality of an Object. After an Object Instance is created, the LWM2M Server can access that Object Instance and Resources which belong to that Object Instance.

The LWM2M Server performs operations on an Object, Object Instance and Resources as described in Section 5 Interfaces. These operations are conveyed as described in Section 8 Transport Layer Binding and Encoding and how to convey the Operation data is defined in 6.3.

The LWM2M Enabler defines an access control mechanism per Object Instance. Object Instances SHOULD have an associated Access Control Object Instance. An Access Control Object Instances contains Access Control Lists (ACLs) that define which operations on a given Oject Instance are allowed for which LWM2M Server(s).

Figure 14 shows an example of the operations the Resources support and how Object Instances and Resources are associated with Access Control Object Instance. In the example, Object Instance 0 for Object 0 has 2 Resources. Resource 1 supports the ”Read”, “Write” and ”Execute” operations, while Resource 2 supports only the “Read” operation. The associated Access Control Object Instance has ACL of Object Instance 0 for Object 0. Server1 is authorized to perform “Read” and “Write” operations to the Object Instance 0 for Object 0 and Resources of the Object Instance. However, due to the supported operations of each Resource, Server1 can perform the “Read” operation on Resource 1 and 2, and also can perform the “Write” and “Execute” operations on Resource 1, but Server1 cannot perform the “Write” operation on Resource 2 and cannot perform the “Execute” operation on both Resources. The detail access control mechanism is defined in Section 7.3 Access Control.

Figure 14: Example of Supported operations and Associated Access Control Object Instance