SVE-42 Test Event Postponed. For more information click HERE.

Members Meeting Postponed. For more information click HERE.

Logo
HOME   >   LWM2M   >   WHATIS   >   COMPONENTS

LwM2M Components

This section provides a quick overview of LwM2M Architecture and Resource Model.

LwM2M Architecture

1. LwM2M Client

  • This runs on the device and is responsible for managing local resources and communicating with the LwM2M server.

2. LwM2M Server

  • This is the remote entity that manages the LwM2M clients. It handles tasks such as device registration, reading and writing resources, and executing commands.

3. Bootstrap Server

  • This server helps devices to connect to the LwM2M server by providing initial configuration and credentials.
Overal LwM2M Architecture

Overal LwM2M Architecture

LwM2M 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. The figure illustrates this structure, and the relationship between Resources, Objects, and the LWM2M Client.

Resource Model

Resource Model

The OMA Lightweight M2M (LwM2M) protocol uses a hierarchical object and resource model to manage and interact with IoT devices. This model organizes the data and functionalities of a device into well-defined objects and resources, making it easier to monitor, control, and manage various aspects of the device.

  • 1. Object: An object represents a specific type of data or functionality on a device. For example, an object could be a temperature sensor, a firmware update mechanism, or a connectivity monitor.
  • 2. Resource: Each object consists of one or more resources. A resource represents a specific piece of data or a function within the object. For instance, a temperature sensor object might have resources for the current temperature reading, the sensor's unit of measurement, and the sensor's status.
    • 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.
    • 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.

LwM2M Objects:

Object License

  • Software license inside of the Object.
    • Each Object in the OMNA LwM2M Registry MUST have a license. Currently, the tool provides only three different type of licenses:
      • BSD-3 Clause license. This is the only license that is accepted by One Data Model Registry, (ODM). ODM has created a language that can represent any object/model defined by Standards Development Organizations. For more information see One Data Model.
      • OMA BSD-3 license. To be used by OMA Working Groups only.
      • Your own license. Please note that licenses that are not popular, e.g. (MIT, Apache, etc) are strongly discouraged; your Object won't be registered with One Data Model and more than probably won't be used by other members of the community.

Name

  • Name of the Object.
  • The Name value is duplicated in the title of the tool and in the definition of the Object. There is only one single Name value.

Description

  • The object description element should contain a precise and short definition of the purpose of the object.
  • This value is used to populate the description field in the OMNA LwM2M Registry.
  • The length of the description is limited to 134 characters.

1. Object Definition

Operations

Name

  • Name of the Object, is the value that will appear inside the Object file.
  • If the Name has more than one word, first letter of each word should be capitalized.
  • NOTE: The IPSO Working Group, pay special attention to the meaning of the name. The names should be very specific rather than general.

To request support and direction, please contact the IPSO Working Group via GitHub Issues.

Object ID

Note:Object ID is formally allocated by OMA staff.

If you would like to reserve an ID please get in contact via GitHub Issues or via email: helpdesk@omaorg.org.

Object Version

  • This is related to the version of the Object.

Please ensure that the version is aligned with the definition of the URN.

LWM2M Version

  • The value of this element indicates the version of the LwM2M protocol.

Please ensure that this value matches the schema defined in the attribute, e.g.: xsi:noNamespaceSchemaLocation="http://.../LWM2M-v1_1".

NOTE: OMA may introduce new schemas, e.g.: LWM2M.xsd, LWM2M-v1_1.xsd, in the future.

Object URN

  • The composition of this element is: urn:oma:lwm2m:<oma|ext|x>:<ObjectID>:<version>
    • The category: indicates different ranges and stakeholders as described in the Object ID.
      • oma- Objects Produced by OMA. Only OMA can use this element
        • e.g urn:oma:lwm2m:oma:<ObjectID>:<version>
      • ext- Objects registered by 3rd party standards organisations or alliances
        • e.g urn:oma:lwm2m:ext:<ObjectID>:<version>
      • x- Objects registered by companies or individuals
        • e.g urn:oma:lwm2m:x:<ObjectID>:<version>
  • version indicates the ObjectVersion:
    • for 1.0 is omitted from the urn,e.g.: urn:oma:lwm2m:x:10241
    • for version increments the urn is updated, e.g.1.1 must be included: urn:oma:lwm2m:x:10241:1.1

Instances

  • Two possible values:
    • multiple - Indicates that it is possible to have more than one instantiation of the Object.
    • single - Indicates that is only one instantiation of the Object.

Mandatory

  • Optional - It is the default value.
  • Mandatory - Value is restricted to some Objects defined by OMA DMSE Working Group.

2. Resource Definition

Editing Operations

  • These are operations related to the LwM2M Editor:
  • Edit
  • Save
  • Cancel
  • Delete
  • Move (only available under Resources Definitions)

Resource ID

  • There are three types of Resources ID's:
    • Common
      • It doesn't need to be registered with OMNA LwM2M Registry.
      • Range: 0 - 2047
      • The ResourceID must be unique within the Object.

    Please ensure that the range is sorted out in ascending order, e.g.: 0, 1, 2, etc.

    Please note that Reusable Resources are selected by entry the number of the Reusable Resource in the Editor. The tool populates, directly, the values for the Reusable Resource from the OMNA LwM2M Registry. According to the Technical Specifications. The following elements in a Reusable Resource cannot be modified:

    • Name,
    • ResourceID,
    • Operations,
    • Type,
    • Range or Enumeration,
    • Units, and
    • Description

    If you need to customize the Reusable Resource Description, then use Edit Additional Definition button at the end of the table.

    • Private
      • It doesn't need to be registered with OMNA LwM2M Registry.
      • Range: 26241 - 32768.
      • It is open to re-use.

Resource Name

  • If the Resource is composed by more than one name, then please capitalize and separate each word.

Resource Operations

Please note that if you select the option E-Execute then, the Type must be empty.

Resource Instances

  • The LwM2M Editor provides two possible options:
    • Multiple
    • Single

Resource Mandatory

  • This element has two possible values:
    • Mandatory
      • It implies that the Resource must be present as soon as the Object is instantiated.
    • Optional
      • It indicates that this Resource in that particular Objects is optional.

Resource Type

Resource Range or Enumeration

  • Machine-readable definition of valid values for the resource.
  • Ranges of values are expressed with two dots, e.g.: '0..250'. List of valid values can be given as comma separated list. See Appendix D of LwM2M TS 1.1.1 for details.
  • Explanation of values (if not obvious from the context) should be given in the resource description.

Resource Units

  • The Units defined in OMA LwM2M Objects are defined by SenML - Sensor Measurement Lists.
  • In addition to SenML Units two extra values have been added to this list:
    • TBD - To Be Defined
      • This value is used when none of the Unit symbols in the drop-menu list are suitable.
        • This value will trigger the IPSO WG to define a suitable Unit.
    • blank
      • This value can be used when no Unit is necessary.

Please, send your Unit suggestion to the IPSO WG via GitHub Issues.
IPSO WG will evaluate if a new Unit value will be sent to IANA for registration.

The following guidelines should be followed to maximize interoperability across uses of the units:

  • Existing unit identifiers, when available, MUST be used (there must be only one unit identifier for each unit).
  • When selecting a unit, the non-scaled SI units SHOULD be preferred over-scaled units (e.g., "m/s" instead of "km/h" for speed)
    • certain scaled units (e.g., "km/h" and "kWh") are being registered to enable the use of units for legacy models and in scenarios where scaled units are the industry norm; however the number of registered scaled units should be minimal.
  • There needs to be a compelling use case for registering new units; a reference to the use of the new unit in standards specifications is recommended
    • units that are specific to a single use case or user should not be registered; for such use, the unit field can be left empty, and the semantics of the value can be explained in the description of the resource.

Resource Description

  • Be precise and short.

Note: Reusable Resources Description is fixed during initial definition and must not be changed when used in new objects. If a context-specific description of a resource is needed, the object description can be used for this purpose.

SPECIFICATIONS
Key Features