• State Not Answered
  • Replies 18 replies
  • Subscribers 88 subscribers
  • Views 3417 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 277762
Options

how can i send a 100 or 500 bytes Payload from nRF9160 to Leshan server?

ced27

Hello,

i had a look at lwm2m_client_sample and it worked pretty well. Now my next step is to be able to send for example a 100 or 500 Bytes Payload from nRf9160 to Leshan server.

Since i am a new comer, i don't really know how to go about it.

Questions:

1. Is it possible in the first place to be able to send payload data to leshan server?

2. When yes. How can i go about it? 

3. When no. Is there any alternative of sending payload data using lwm2m?

I will be glad, if someone could help me.

best regards

Cedric

  • 0 in reply to ced27
    ced27 said:
    Another option would be to not use LwM2M (at least for these updates), and just send a plain UDP/CoAP message to a listening socket on the server.

    Can you please tell me how i may do that?

    For UDP, you can look at the udp sample, and for CoAP, you can look at the coap_client sample.

  • 0

    I read through the comments an my impression is, that there is a gap in understanding coap/dtls and lwm2m.

    Starts with lwm2m:

    Usually your device registers once and then updates that registration in order to inform the server, that the device is still valid/used.

    On that registration, the server may start the obervations, the application is interested in. Such an observation could simply be considered as continue-read. With that, the device may always send a new response, usually intended when the addressed resource has changed. If such a response requires an ACK of the server depends on the device, it may use NON (no ACK, no retransmission, may be lost) or CON (waits for ACK or retransmitts the response, if the ACK is not received, much more reliable).

    So, you may send the responses as NON, but you must also notice, that it may get lost without further notice.  

    Coap/dtls:

    Though you wrote, your device wakes up from PSM, the first important thing is, if it gets a fresh ip-address or keeps a static one. With the static one, everything is easy as described above. With a fresh ip-address, it depends ...

    (long story years ago in the oma/lwm2m github).

    My personal conclusion:

    Wait until draft-ietf-tls-dtls-connection-id is released and the DTLS libraries supports that (e.g. mbedtls and zephyr).

    Leshan already supports that (at least, once it gets updated to Californium 3.0.0.).

    Without, it will be a DTLS issue in the first place. If the encryption context is bound to th eip-address, but that is changing, encryption will not work.

  • 0 in reply to Achim Kraus
    Achim Kraus said:
    On that registration, the server may start the obervations, the application is interested in. Such an observation could simply be considered as continue-read. With that, the device may always send a new response, usually intended when the addressed resource has changed. If such a response requires an ACK of the server depends on the device, it may use NON (no ACK, no retransmission, may be lost) or CON (waits for ACK or retransmitts the response, if the ACK is not received, much more reliable).

    I really agree. But my case is that i don't want the server to start the observations before i can send a new response.

    Achim Kraus said:
    Though you wrote, your device wakes up from PSM, the first important thing is, if it gets a fresh ip-address or keeps a static one. With the static one, everything is easy as described above. With a fresh ip-address, it depends ...

    By every new registration the device gets a new ip adresse

  • 0

    Unfortunately, my browser doesn't show the reply to other comments ... so.

    "But my case is that i don't want the server to start the observations before i can send a new response"

    That raises the question, why you think, that this is relevant ... or why your want to use lwm2m, if you want it in "your way". lwm2m tries to build a "reusable base" for different applications. A lwm2m device may be used in different applications without adapting the lwm2m devices firmware. At least sometimes this should be possible.

    "By every new registration the device gets a new ip adresse"

    Just to ensure "registration" in terms of the mobile network ... not a lwm2m-registration?

    With that, let me repeat: wait for dtls connection id. That will solve your pain.

    (I use it now for more than 2 years on Nb-IoT. The main left issue is the "mobile network registration time", which is in my experience in good cases 2s in bad up to 60s ... which makes the time for the server's ACK (additional 2s) less important. By the way, if you use NB IoT, the MTU is about 330 bytes, leaving something as 270 for the coap-message and 250 for the coap payload. 500 bytes may result on higher paket loss, but that will be up to you, to test, what works better.) 

  • 0 in reply to Achim Kraus

    Thanks for your contribution.

    so if i understand, it will be good for my own interest to stay with lwm2m as it. Meaning the server starts observations before i can start sending a new response.

    And when the device wakes up from PSM, it should wait for dtls connection id. 

    And leshan server will support it once it gets update to Californium 3.0.0.

    Is that correct?

Related
Terms of service