OMA_LwM2M_for_Developers
OMA_LwM2M_for_Developers copied to clipboard
OpenMobileAlliance
LightweightM2M-1.0-int-104 Test Case: Receiving SMS capability
In LightweightM2M-1.0-int-104 test case the binfing mode is 'U' which means that the device does not support SMS. However according to the test procedure the Register Update should be trigger by SMS. It is more make sense to trigger the update using UDP
On my view, the test case also seems to be unclear.
/1/0/8
"If this Resource is executed the LWM2M Client MUST perform an “Update” operation with this LWM2M Server using the Current Transport Binding and Mode."
But why should "update" then be "reregister"!
So my initial understanding of the use case was: The device uses mainly UDP, but unaware of a IP change (or half sleeping) it's not reachable by UDP from the server side. Therefore the server uses the SMS to trigger an update, so that the server can reach the device afterwards again with UDP.
With the testcase in mind, I would now describe the scenario more like: The device uses mainly UDP. If it's not used for longer time, it get's deregistered and so the server doesn't try to send data to the device. If the server want to reanimate the device, it sends a SMS.
May be someone can clarify, what is wanted / covered.
There is an inconsistency between the ETS and the current TS. This will be fixed.
Regarding resource /1/n/8, it triggers a registration update. If the device was deregistered by the Server, the Server should not send commands to it. This resource is useful to be sure the device is still up or in a multi-server set-up.
SMS is typically used when the server needs to send downlink data or a command to a cellular device and does not wish/cannot wait till the device is next due to update its registration.
This is for cellular devices which may have lost their packet data connection e.g. for power saving purposes. The "update" trigger via SMS is to make the device setting up again a packet data connection. When the server receives the "update" via UDP it knows the device is online again.
Test case needs to be fixed :
- Binding is set to US
In the ETS we would also have to replace the "device de-registration" step by "terminate device PDN context", or, something similar.
