Use CBOR array for object representation.

[snakeru]

Problem description

In current version of the specification (OMA-TS-LightweightM2M_Core-V1_2-20201110-A) the map type is used to represent an object. While this makes sense if we want to update a single resource of a single object, this is not necessarily the most efficient encoding if a whole object has to be transmitted.

For example, in section 7.4.4.4 an example serialization is provided for an object with resources 0,1,2,3,5,6,7 (in fact that section looks at two instances, but I'll only be considering first one here). That means that 7 bytes are spent for explicit listing of resource ids:

      A7             # map(7)
         00          # unsigned(0)
         18 65       # unsigned(101)
         01          # unsigned(1)
         1A 00015180 # unsigned(86400)
         02          # unsigned(2)
         19 012C     # unsigned(300)
         03          # unsigned(3)
         19 1770     # unsigned(6000)
         05          # unsigned(5)
         1A 00015180 # unsigned(86400)
         06          # unsigned(6)
         F5          # primitive(21): true
         07          # unsigned(7)
         61          # text(1)
            55       # "U"

A json representation of that would have been: {0:101,1:86400,2:300,3:6000,5:86400,6:true,7:"U"}

Possible solution

If instead an array were used, then the resource 4 had to be explicitly listed as undefined, but that would have still saved 6 bytes out of 29 on the wire:

      88             # array(8)
         18 65       # unsigned(101)
         1A 00015180 # unsigned(86400)
         19 012C     # unsigned(300)
         19 1770     # unsigned(6000)
         F7          # primitive(23): undefined
         1A 00015180 # unsigned(86400)
         F5          # primitive(21): true
         61          # text(1)
            55       # "U"

A json representation of such array would have been: [101,86400,300,6000,undefined,86400,true,"U"]

This is of course also applicable to multiple objects encoding, though with significantly smaller impact.

Implementation strategy

Would it be reasonable to support both representation formats and let the encoder choose the most efficient? The encoder could select the array representation if highest resource ID doesn't differ much from number of resources to be encoded and fall back to map encoding otherwise.

[hannestschofenig]

Hey Alexey,

thanks for sharing your thoughts about a new encoding scheme. As you know, we have published a CBOR-based encoding format with LwM2M v1.2 and it was developed with the help of group members to define a generic mechanism. In particular, it works also well if you have resources with higher resource ids. There are a large number of objects, which use re-usable resources. These tend to have resource ids starting at resource id 4000 upwards (see https://technical.openmobilealliance.org/OMNA/LwM2M/LwM2MRegistry.html). When applied to your encoding, this would lead to a lot of inefficiency.

Regardless of this issue, you are always welcome to join the OMA to help us make LwM2M better (not just the CBOR encoding).

[snakeru]

Hi Hannes.

I don't think this will lead to inefficiency. There is this line in my proposal:

let the encoder choose the most efficient [encoding]

So for such objects this encoding just won't be used.

What I had in mind is the non-standard, vendor-developed objects where the numbering doesn't have this limitation. If CBOR is used for encoding of messages sent over the air then the difference between 23 and 29 bytes could be, for example, having N and 1.26N collisions per day and correspondingly more battery consumption (for retransmission etc).

Using standard objects for that purpose would make matters only worse because ID 4000+ requires one more byte for encoding so we are speaking already about 23 vs 35 bytes.

[hannestschofenig]

It is, of course, possible to develop an additional encoding as you suggest. Per OMA by-laws you will, however, have to join the OMA to contribute this new encoding.