-
Notifications
You must be signed in to change notification settings - Fork 11
SMCP vs LwM2M
This page is a work-in-progress elaborating on the differences between Splot/SMCP and IPSO/LwM2M.
The author of this document isn't an expert on LwM2M, so there may be unintentional misrepresentation. Please feel free to comment or suggest edits if you see something wrong.
LwM2M is a CoAP-based client-to-server protocol with well-defined schema-based interfaces to “smart objects”. The resources of these objects may be read, changed, or observed. OMA SpecWorks has published schemas and definitions for dozens of categories of devices ("IPSO Smart Objects"), and these schemas are what are used by LwM2M.
LwM2M is largely defined in terms of a client/server model, where clients register with servers that control and monitor them. Sensors and actuators are LwM2M clients that register with a LwM2M server. That server then manages that sensor or actuator.
This is a fundamentally different approach from SMCP, where there is no strict client/server roles—although applications built on top of SMCP may define such roles if that makes sense.
Much like LwM2M, SMCP uses CoAP and will support DTLS and OSCORE.
The IPSO Smart Objects schemas focus largely on defining the properties exposed by objects and what actions can be performed on them. Features like scenes, groups, and access controls are defined in limited ways.
The Splot Object Model (SOM), upon which SMCP is based, addresses these issues by way of introducing a relatively simple general-purpose object framework upon which advanced features like groups and scenes can be built. For groups in particular, the resulting implementation is capable of using multicast in a way that LwM2M doesn’t seem to be able to easily take advantage of.
Additionally, the flexibility that allows the SOM to efficiently represent groups and scenes can also be used to implement other mechanisms, such as managing irrigation program controls, notification managers, etc. In IPSO, all classes, interfaces, properties, and actions are referenced by number, which increases the burden of initially getting developers up to speed. The Splot Object Model uses short textual identifiers which are somewhat easier to grasp and memorize than integers. This helps make the Splot Object Model somewhat more user friendly to developers.
The SOM equivalent of a object is called a functional endpoint, or FE. FEs can be nested to contain one or more categories of child FEs. These child FEs are first-class citizens in the SOM, and can be controlled, monitored, or added to groups just like any other FE. This mechanism is a fundamental part of the flexibility of the SOM, and there appears to be no equivalent in IPSO.
In IPSO/LwM2M, objects are collections of resources, which are individual attributes. Some level of polymorphism seems to be implemented via the use of reusable resources, which are single attributes with defined characteristics.
In the SOM, Functional Endpoints are composed of one or more traits, which are named collections of related properties and methods. Traits provide FEs with polymorphism. For example, a smart light bulb might implement the base trait, on/off trait, level trait, and power traits to provide for the ability to describe the name/manufacturer of the light, turn the light on and off, adjust the light's brightness, and monitor the light's power usage. Some traits enable features that affect the properties of other traits, such as the transition trait or the scene trait. A named sets of required-to-implement traits and properties is called a trait profile, which an FE can advertise in its metadata.
Transitions between attribute values (such as you might want for lighting) appear to be defined in an ad-hoc basis in LwM2M. This makes it confusing how to best transition different sorts of devices simultaneously with a single action, or as a part of a scene. All SOM FEs that implement the transition trait support smooth transitions between numeric state property values, and is largely transparent in operation.
In the SOM, a scene is a named set of property values that can be stored and recalled. Each individual FE that supports scenes keeps track of the information for the scene. The scene is recalled by setting the current scene property to the id of the scene. This works for both individual FEs and group FEs.
In LwM2M (OpenAIS), scenes are implemented by performing POST/PUT actions on URLs with a given body, and is also contextually limited to lighting (although it seems general enough to use in other situations). This approach is indicative of the heavy client/server nature of LwM2M.
In the SOM, groups provide a way to perform a single action on several functional endpoints. In effect, a group allows you to treat several functional endpoints as a single functional endpoint. Each group with the same name is effectively rooted at the same place on all devices, and also includes a multicast group address associated with the group. This allows a device to perform a single multicast request and have that action be performed by all FEs in the group across multiple physical devices relatively efficiently. Since groups are a top-level mechanism in the SOM, they can be used with all types of functional endpoints. Support for both unreliable and reliable groups in SMCP is forthcoming.
It is somewhat unclear to me how LwM2M/OpenAIS groups are intended work, but it appears to support multicast. It does seem to rely on a device managing the group, which is something that SMCP does not require.
Value Type | SOM | LwM2M |
---|---|---|
Booleans | YES | YES |
Integers | YES | YES |
Floats | YES | YES |
Strings | YES | YES |
Opaque data | YES | YES |
Timestamps | YES, as integers | YES |
Object Link | YES, via URLs | YES |
Big Integers | YES | As Opaque |
Dictionaries | YES | As Opaque? |
Arrays | YES | As Opaque? |
NULL | YES | ? |
Operation | SOM | LwM2M |
---|---|---|
Get/Read | YES | YES |
Set/Write | YES | YES |
Increment/Decrement | YES | NO? |
Toggle | YES | NO? |