Client Registration Interface
The LWM2M Server MUST support all the operations in this interface and the LWM2M Client MUST support “Register” and “Update” and SHOULD support “De-register” operation.
The Client Registration Interface is used by a LWM2M Client to register with one or more LWM2M Servers, maintain each registration and de-register from a LWM2M Server. The registration is based on the Resource Model and Identifiers defined in Section 6 Identifiers and Resources. When registering, the LWM2M Client performs the “Register” operation and provides the properties the LWM2M Server requires to contact the LWM2M Client (e.g., End Point Name); maintain the registration and session (e.g., Lifetime, Queue Mode) between the LWM2M Client and LWM2M Server as well as knowledge of the Objects the LWM2M Client supports and existing Object Instances in the LWM2M Client. The registration is soft state, with a lifetime indicated by the Lifetime Resource of that LWM2M Server Object Instance. The LWM2M Client periodically performs an update of its registration information to the registered LWM2M Server(s) by performing the “Update” operation. If the lifetime of a registration expires without receiving an update from the LWM2M Client, the LWM2M Server removes the registration. Finally, when shutting down or discontinuing use of a LWM2M Server, the LWM2M Client performs a “De-register” operation.
The Binding Resource of the LWM2M Server Object informs the LWM2M Client of the transport protocol preferences of the LWM2M Server for the communication session between the LWM2M Client and LWM2M Server. The LWM2M Client SHOULD perform the operations with the modes indicated by the Binding Resource of the LWM2M Server Object Instance.
Figure 9: Client Registration Interface example flows.
Register
Registration is performed when a LWM2M Client sends a “Register” operation to the LWM2M Server. After the LWM2M Device is turned on and the bootstrap procedure has been completed, the LWM2M Client MUST perform a “Register” operation to each LWM2M Server that the LWM2M Client has a Server Object Instance. Table 3 describes the parameters used for the “Register” operation.
The “Register” operation includes the Endpoint Client Name parameter along with other parameters listed in Table 3. The “Register” operation MUST include a value for the Endpoint Client Name parameter that is unique on that LWM2M Server.
Upon receiving a “Register” operation from the LWM2M Client, the LWM2M Server records the IP address and port from the IP packet of the registration message and uses this information for all future interactions with that LWM2M Client.
If the LWM2M Client sends a “Register” operation to the LWM2M Server even though the LWM2M Server has registration information of the LWM2M Client, the LWM2M Server removes the existing registration information and performs the new “Register” operation. This situation happens when the LWM2M Client forgets the state of the LWM2M Server (e.g., factory reset).
The LWM2M Server MUST support all the parameters listed at Table 3 and the LWM2M Client MUST support Endpoint Client Name, Lifetime, Binding Mode, and Object and Object Instances and MAY support LWM2M Version and SMS Number.
| Parameter | Required | Default Value | Notes |
|---|---|---|---|
| Endpoint Client Name | Yes | See Section 6.2 | |
| Lifetime | No | 86400 | If Lifetime Resource does not exist in a LWM2M Server Object Instance (see Appendix D.1), the Client MUST NOT send this parameter and the Server MUST regard lifetime of the Client as 86400 seconds The registration SHOULD be removed by the Server if a new registration or update is not received within this lifetime. |
| LWM2M Version | No | 1.0 | Indicates the version of the LWM2M Enabler that the LWM2M Client supports. This parameter is required only for LWM2M versions > 1.0. |
| Binding Mode | No | U | Indicates current binding and Queue mode of the LWM2M Client. “U” means UDP binding, and "S" means SMS binding. The "Q" can be appended to represent the binding works in the Queue mode. |
| SMS Number | No | The value of this parameter is the MSISDN where the LWM2M Client can be reached for use with the SMS binding. | |
| Objects and Object Instances | Yes | The list of Objects supported and Object Instances available on the LWM2M Client. |
Table 3: Registration parameters
The list of Objects and Object Instances is included in the payload of the registration message. Each Object is described as a Link in the CoRE Link Format [RFC6690]. The Target component of the link is required, and consists of the Object path. Any other parameters included in the link MUST be silently ignored, unless specified for use by the LWM2M Enabler. The Media Type of this payload is application/link-format.
The payload for a LWM2M Client supporting LWM2M Server, Access Control, Device, Connectivity Monitoring and Firmware Update Objects from Appendix D would simply be:
</1>, </2>, </3>, </4>, </5>
If Objects Instances are already available on the LWM2M Client at the time of registration, then the format would be (for the example client of Appendix E):
</1/101>, </1/102>, </2/0>, </2/1>, </2/2>, </3/0>, </4/0>, </5>
By default, the RFC6690 links of Objects are located under the root path as in the examples above. However, devices might be hosting other Resources on an endpoint, and there may be the need to place Objects under an alternative path. This is achieved by including an OMA LWM2M link in addition to the Object links as follows, e.g. to place Objects under the “/lwm2m” path:
</lwm2m>;rt="oma.lwm2m", </lwm2m/1/101>, </lwm2m/1/102>, </lwm2m/2/0>, </lwm2m/2/1>, </lwm2m/2/2>, </lwm2m/3/0>,</lwm2m/4/0>,</lwm2m/5>
The RFC6690 Resource Type parameter (i.e., rt="oma.lwm2m") MAY be used to provide the information that the path in front of the Resource Type parameter is used for the LWM2M enabler.
The Resource Type value “oma.lwm2m” is registered with the appropriate IANA registry for this purpose.
If the LWM2M Client supports the JSON data format for all the Objects it SHOULD inform the LWM2M Server by including the content type in the root path link using the ct= link attribute. An example is as follows (note that the content type value 100 is an example, the actual value will be assigned by IANA for the LWM2M JSON format).
</>;rt="oma.lwm2m";ct=100, </1/101>, </1/102>, </2/0>, </2/1>, </2/2>, </3/0>, </4/0>, </5>
Behavior with Current Transport Binding and Mode
Behavior of the LWM2M Server and the LWM2M Client is differentiated by Current Transport Binding and Mode. Current Transport Binding and Mode is decided by “Binding” Resource set by the LWM2M Server and whether SMS and/or Queue Mode are supported by the LWM2M Client. Queue Mode is useful when the LWM2M Device is not reachable by the LWM2M Server at all the times and it could help the LWM2M Client sleep longer. Table 4 describes the behaviour of the LWM2M Server and the LWM2M Client for each Current Transport Binding and Mode.
| Current Transport Binding and Mode | Behaviour |
|---|---|
| U (UDP) | The LWM2M Server expects that the LWM2M Client is reachable via the UDP binding at any time. The LWM2M Server MUST send requests to a LWM2M Client using the UDP binding. The LWM2M Client MUST send the response to such a request over the UDP binding. |
| UQ (UDP with Queue Mode) | The Server MUST queue all requests to the LWM2M Client, sending requests via UDP when the LWM2M Client is on-line as described in Section 8.4 Queue Mode Operation.The LWM2M Server MUST send requests to a LWM2M Client using the UDP binding. The LWM2M Client MUST send the response to such a request over the UDP binding. |
| S (SMS) | The LWM2M Server expects that the LWM2M Client is reachable via the SMS binding at any time. |
| SQ (SMS with Queue Mode) | The Server MUST queue all requests to the LWM2M Client, sending requests via SMS when the LWM2M Client is on-line as described in Section 8.4 Queue Mode Operation. Requests MUST be sent to the LWM2M Client using the SMS binding. The LWM2M Client MUST send the response to such a request over the SMS binding. |
| US (UDP and SMS) | The LWM2M Server expects that the LWM2M Client is reachable via the UDP binding at any time. |
| UQS (UDP with Queue Mode and SMS) | The Server MUST queue all requests to the LWM2M Client, sending requests via UDP when the LWM2M Client is on-line as described in Section 8.4 Queue Mode Operation. |
Table 4: Behaviour with Current Transport Binding and Mode
UQSQ and USQ are not supported.
Update
Periodically or based on certain events within the LWM2M Client or initiated by the LWM2M Server, the LWM2M Client updates its registration information with a LWM2M Server by sending an “Update” operation to the LWM2M Server. This “Update” operation MUST contain only the parameters listed in Table 5 which have changed compared to the last registration parameters sent to the LWM2M Server.
If the LWM2M Client is using the UDP binding to communicate with a LWM2M Server and LWM2M Client’s IP address or the port changes, the LWM2M Client MUST send an “Update” operation to the LWM2M Server.
| Parameter | Required |
|---|---|
| Lifetime | No |
| Binding Mode | No |
| SMS Number | No |
| Objects and Object Instances | No |
Table 5: Update parameters
The “Update” operation can be initiated by the LWM2M Server via an “Execute” operation on the “Registration Update Trigger” Resource of the LWM2M Server Object.
De-register
When a LWM2M Client determines that it no longer requires to be available to a LWM2M Server (e.g., LWM2M Device factory reset), the LWM2M Client SHOULD send a “De-register” operation to the LWM2M Server. Upon receiving this message, the LWM2M Server removes the registration information from the LWM2M Server.