Using NB-IoT as the underlying LPWA technology

[seanmcilroy29]

• Submitter: Andrew.Forster-Knight@sew.com.au
• Name, version and date of the document, (e.g. OMA-TS-LightweightM2M-V1_0_2-20180209-A):
• OMA Advice In our LWM2M design (for water meters), which we have been extensively testing over the last few months (across multiple LWM2M platforms), we have come across a slight dilemma in the protocol. Basically, as water meters are battery powered, the idea is to conserve as much battery as possible. Therefore, after the initial bootstrap and registration process, the meter will go to deep sleep and only wake once each day to do an Information Report (notification) of its payload, after which it returns to sleep. The dilemma comes about as we are using NB-IoT as the underlying LPWA technology, and one of the optimizations is to have the meter disconnect from the network as soon as these daily packets are ACK by the LWM2M server (which negates the need for the meter to remain connected to the network in RX mode for 20 seconds, which is the NB-IOT default). All of this works well, however by doing this (disconnecting from the network as soon as its packets are delivered), it means that any queued/pending commands on the server will NOT be able to get to the meter. The only way we see around this is to use the Registration Update. Our initial design was for this to occur every ~ 20 days, as again we wanted to avoid the meter unnecessarily doing extra communications. However, under this dilemma, it appears as though our only option is to send the Registration update each day BEFORE each daily payload packet. Once the server sees the Reg Update packets, it will send any queued commands to the meter and then receive the daily notification packets and disconnect from the network. This workaround is fine in theory, but it adds an additional ~ 100 bytes overhead to each and every daily communication session, which is not ideal. Are you able to offer any advice on any options we may have missed to resolve this issue? I'm sure many others that will be using battery-powered devices will also come across this issue.

[mojanm]

By the sound of it you are using Queue Mode of operations, or at least should be. So as per section 8.3 of LwM2M specification client needs to send Registration Update to the server before anything else every time it wakes up and comes online.

[aforster23]

Thanks. I think you are correct, however this behaviour is very inefficient for battery powered devices that are reporting their logged data every day (or even more frequently), as the Registration Update gets sent, then the client waits on the air for ACK_TIMEOUT time (~ 15 seconds in our case) before sending the daily payload. This adds significant overhead to each day, as Reg Update can be ~ 100 bytes, plus extra 15 seconds waiting for any queued server messages, followed finally by daily payload. Hopefully the next release allows notification messages to reset the registration lifetime timer.

[ytava]

Hi,

As mentioned above, when working in Queue Mode every time the client goes back online it should send Registration Update, it is not related to reg lifetime. So resetting reg lifetime upon notification won't help in this case.

Your options for optimize power consumption:

1. Modem should use PSM/EDRX (depending if it should be available for NW request - pageable).
2. Even during LWM2M communication time (pending for ACK timeout, etc), the modem should go to low power mode (still in IDLE DRX)

[hannestschofenig]

The registration update message is very small since it does not have any payload. Using notifications to extend the registration lifetime is not possible with LwM2M.

[aforster23]

Thanks, yes we now have default behaviour to send registration update each and every time the device wakes from PSM mode and connects to our server. Its a small overhead that we were trying to avoid, but given how well NB-IOT works it is negligible in the scheme of things now. thanks