• State Not Answered
  • Replies 8 replies
  • Subscribers 66 subscribers
  • Views 468 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 327573
Options

How to send a confirmable packet

kaushalyasat

Hi,

I have bunch of SEDs (sensors/clients) and one or more FTDs (hosts) working on CoAP protocol. SEDs send data packets once in a while and mostly sleeping. I have few questions.

1. Does confirmable packets consume more battery power from the SEDs?

2. Can we set a application call back when ACK fails?

3. The 'coap_send_request ()' function in coap_utils.c seems hardwired to send non-confirmable packets. How can we send confirmable packets in this case? (I dont want to modify SDK functions as they can get overwritten if we update the SDK). Do we have to implement our own version of  'coap_send_request ()' function?

4. 'coap_send_request ()' function has a reply call back as a parameter. How does this function in a non-confirmable/confirmable packets?

Cheers,

Kaushalya

Parents
  • 0

    Yes, confirmable packets do consume more battery power from the SEDs because they require the sensors to wait for an acknowledgment (ACK) from the receiver, keeping the radio on for longer periods. You can set an application callback to handle failed ACKs, typically by setting a timeout and managing the event when no ACK is received within that timeframe. If the 'coap_send_request()' function in coap_utils.c is hardwired to send non-confirmable packets and you don’t want to modify the SDK, you will likely need to implement your own version of this function to set the confirmable flag appropriately in the CoAP message. The reply callback in 'coap_send_request()' is invoked when a response is received. For confirmable packets, it is called upon receiving the ACK, while for non-confirmable packets, it is triggered when the response arrives without an acknowledgment mechanism.

  • 0 in reply to Ragnorrak

    Hi  Ragnorrak,

    I have implemented confirmable packets and it seems packets are sent to the intended router. In this instance my SED is connected to a parent router and I am sending confirmable packets to another router (destined router). But when I shutdown the destined router, I still get the confirm callback!!. Is the confirm coming from the parent? 

    When the SED is sending the data packet, I am using 'OT_COAP_CODE_PUT'. I tried OT_COAP_CODE_GET instead but still result is the same. I get a callback in either case. Now I am trying to dig into the parameters passed onto the callback to determine if my intended router is in reachable or not.

    My cb is defined like this.

    int *sensor_data_ack (const struct coap_packet *response, struct coap_reply *reply, const struct sockaddr *from) {
    .
    .
    .
    }
    When I looked into *from, which is a sockaddr, I get the sa_family as 0x5c00, which is incorrect I think. This should be AE_INET6, which should evaluate to 2. What's going wrong here?

    Also, do we need to implement the ACK reply in application layer of the receiver?

    Cheers,

    Kaushalya

  • 0 in reply to kaushalyasat
    kaushalyasat said:
    I have implemented confirmable packets and it seems packets are sent to the intended router. In this instance my SED is connected to a parent router and I am sending confirmable packets to another router (destined router). But when I shutdown the destined router, I still get the confirm callback!!. Is the confirm coming from the parent? 

    This sounds weird. Do you have a setup like following topology from RFC 7252? In theory, even with some routers in between CoAP client and server, the CoAP communication should only visible on application level, since CoAP is an application level protocol running on top of UDP/IP protocol. Keep in mind you CoAP server need to send ACK when a CON message from client is received.

    I suggest you play CoAP client and server with an Ethernet instead of Thread to understand how it works first.

    Best regards,
    Charlie

                            Client              Server
                           |                  |
                           |   CON [0x7d34]   |
                           +----------------->|
                           |                  |
                           |   ACK [0x7d34]   |
                           |<-----------------+
                           |                  |

                  Figure 2: Reliable Message Transmission

  • 0 in reply to Charlie

    Hi Charlie,

    Thanks. 

    Charlie said:
    Keep in mind you CoAP server need to send ACK when a CON message from client is received.

    My understanding was CoAP server sends an ACK for us before passing the CON packet to my application level. May be my understanding is not correct.  

    If I have to send an ACK packet, could you please outline how to structure it?

    Cheers,

    Kaushalya

Reply Children
Related