• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 57 subscribers
  • Views 630 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/LAUNCHXL-CC1312R1: The resend packets with same sequence number are still passed to application

MarcusCWLiang
Prodigy 160 points
Part Number: LAUNCHXL-CC1312R1

Tool/software: TI-RTOS

Hi all,

I am working on the CC1312 with SDK version simplelink_cc13x2_sdk_2_20_00_71.

I tried both the collector v.s sensor and co-processor v.s. sensor architecture. It shows the same result. 

In my test, the sensor would fetch data from serial and pass to collector/co-processor through sub1G communication.

On the collector/co-processor side, I found some duplicated packets are shown in the application layer. So I use RF sniffer to log the wireless packet, and found the resend packet caused by the delayed ACK are still passed to the application layer.

In the wireshark log, please check the attachment with below packets:

No.108 (00:52:27.212359) MSG from sensor to collector (Seq. #61)

No.111 (00:52:27.311052) ACK from collector to sensor (ACK to No.108 with Seq. #61)

No.112 (00:52:27.315969) MSG from sensor to collector (Seq. #61, resend of No.108)

No.114 (00:52:27.516954) ACK from collector to sensor (ACK to No.112 with Seq. #61)

The No.112 is the resend packet of No.108 because the ACK(No.111) istoo late. However, the application on the collector/co-processor gets both No.108 and No.112 as 2 different packets. 

Is there any way to identify the resend packet in the application and discard it manually? Or TI will fix it in the future?

Thanks!

Sub1G resend issue.zip

  • 0
    TI__Mastermind 23730 points
    This can occur when you have an asymmetric link between both devices, that is A can hear B but B cannot hear A.

    What happens (probably) is that the first packet is transmitted from the sensor to collector, collector receives packet and transmits an ACK to the sensors. However, the sensor is not able to receive the ACK (for whatever reason) and re-transmits the packet. The collector will again receive the same packet. This continues until either the sensor receives the ACK or has reached maximum number of re-transmissions.

    What is the distance between the sensor and collector?
  • 0 in reply to Severin Suveren
    Expert 2235 points
    Just throwing in my opinion. Shouldn't the MAC layer take care of this? After all, the MAC layer is aware that it passed on the frame to the application layer the first time. Any duplicates received by the MAC should be ignored (due to same sequence number) and not sent to the application layer (however, MAC should still send ACK in order to shut up the sensor), I would think?

    I would assume you could use the frame counter (available in application layer i think) to discard identical frames - however this requires security enabled (and at some securityLevel). I am not sure if the sequence number is available to application layer. You can not read the NV memory to retrieve the previous frame counter, as this is only physically written for increments of 25 or so... so you would need to add this field in the associate list or something...
  • 0 in reply to Severin Suveren
    Prodigy 160 points

    Hi Edvard P,

    Thanks for your reply!

    As you can see from the wireshark log, it's not the case you said that A can hear B but B can't hear A. In my test, the distance between the sensor and collector is just around 10 cm and both device got antenna, the RSSI is around -20 dBm.

    I think it happens when the wireless traffic is very busy. From the wireshark log, there were 2 more packets between the first MSG(No.108) and the first ACK(No.111), which makes delay of first ACK(No.111). Besides, the first ACK(No.111) and the resend message(No.112) is very close, less than 5ms. Maybe the sensor put the resend packet to transmit buffer before the first ACK is received.

    In my opinion, the TI 802.15.4 stack should handle this problem, it should discard the duplicated message and should not pass it to application. 

  • 0 in reply to MarcusCWLiang
    TI__Genius 12415 points
    I am looking into this but as far as I know filtering for duplicate frames does not happen when security is disabled. If you want this duplicated frames to be filtered you will need to enable security or filter them at the application layer.
  • 0 in reply to Hector_r
    Prodigy 160 points
    Hi Hector_r,

    Thanks, I will try to enable security and check if it does filter the duplicated frame.
    And could you provide the method to filer the duplicate frames at the application layer?
  • 0 in reply to MarcusCWLiang
    TI__Genius 12415 points
    If you are not using security then you will have to come up with your own way since the stack is not required to keep track of a frame counter according to the IEEE 802.15.4 spec.

    Something that you can do is add your own frame counter into the data packet that you are sending so for example you could append at the end of your data payload a uint32 to keep track of the counter and then when you receive a packet in your device you compare if the incoming counter is higher than your local one. If the incoming counter is not higher then you drop the packet.
  • 0 in reply to Hector_r
    Prodigy 160 points

    Hi Hector,

    Thanks, I know we can add a sequence number into all the transmitted packet and check every incoming packets.

    However, does TI have any plan to fix this in the next revision or in the near future?

  • 0 in reply to MarcusCWLiang
    TI__Genius 12415 points
    I am not sure if we will be able to fix this behavior since it is not a problem according to the IEEE 802.15.4 specification. If security is not used then the frame counter will not be used therefore not keeping track of repeated messages.
    If this was instead happening when security is enabled then that would be something that we would fix.