DECT NR+ HARQ communication and testing

DECT NR+ HARQ communication and testing

Hello,

we using two nrf9151 development boards with latest modem firmware version DECT-NR+ (1.0.2) and nrf-connect v2.9.0 and v2.9.1

Using HARQ with phy_type2 and handling is somehow clear and understandable. It is just an enabled Flag, I can see the Code in Ping App.

My Question is targetting the sending good packets and sending bad/broken packets.
For example application layer have an image file I want to send, this will be brake down into 100 packets, just an example calculation...
If the Transmission works fine all 100 packets are received, no HARQ mechanism is started, no harq process is running etc.

With injecting broken packets in the 100 packets, say every 10 packet is broken for a test case, how would I do that ?

Assuming a harq process is started etc. etc. Is there some undocumented API call or

can I flip some bits while the data is in the buffer after CRC is calculated of the packet?

Maybe I am thinking to complicated here and there is simple solution: transmit_with_packet_error( buffer, length, every_8_bit_flip )?

kind regards

Parents
  • Hi,

    Can you provide more details about your measurement setup?

    With injecting broken packets in the 100 packets, say every 10 packet is broken for a test case, how would I do that ?

    Assuming a harq process is started etc. etc. Is there some undocumented API call or

    can I flip some bits while the data is in the buffer after CRC is calculated of the packet?

    Maybe I am thinking to complicated here and there is simple solution: transmit_with_packet_error( buffer, length, every_8_bit_flip )?


    What exactly are you trying to achieve/test?

    Best regards,
    Dejan

Reply
  • Hi,

    Can you provide more details about your measurement setup?

    With injecting broken packets in the 100 packets, say every 10 packet is broken for a test case, how would I do that ?

    Assuming a harq process is started etc. etc. Is there some undocumented API call or

    can I flip some bits while the data is in the buffer after CRC is calculated of the packet?

    Maybe I am thinking to complicated here and there is simple solution: transmit_with_packet_error( buffer, length, every_8_bit_flip )?


    What exactly are you trying to achieve/test?

    Best regards,
    Dejan

Children
  • Hi,

    I just want to see the impact of HARQ enabled or not with my transmissions.
    I want to play with the existing setup and use the existing code base to start my own investigating and development based on that.

    The change and difference with using different Feedback fields for example is my goal.

    I am used to use ZTEST suite for example and create a test setup which demonstrate the different use-cases  and trigger definitily ERROR Transmissions which can be used to monitor HARQ in action (over the air) - with sniffer and/or logic analyzer.

    For the product use case I need than to pick a specific solution / result of the research on that topic.
    And maybe create different show-cases based on application scenarios.

    kind regards

  • Something which might be better to visualize is a scenario where I have a continous stream of data coming from application layer.
    It doesnt matter what kind of type it is, it is just bytes coming from peripherial continous.

    Those will be transmitted.
    To setup the Project and application I need to create Options.
    Option 1: No HARQ

    Option 2: With HARQ (...feedback1 or)

    To Test Option 2 within our Test-Setup and with ZTEST basically I want to send a stream of bytes with 1024 Bytes and see if  is like in the dect_shell with result:
    No HARQ feedback count:                  0
      HARQ ACK receive count:                  2581
      HARQ NACK receive count:                 0
      HARQ reset NACK receive count:           0

    To Test Option 2 within our Test-Setup and with ZTEST negativ basically I want to send a stream of bytes with 1024 Bytes and randomize bit flips or drop packets randomized --> see if it works, if the app data is fine.
    See a "brownout" use case --> no retransmission is possible, no fec recaclc is possible for ... packets xyz. Signal to upper layer --> request again packets nbr. 123 and 456 is lost. or just signal.
    See a "blackout" use case --> no retransmission is possible, no fec recacl is possible, packets are broken --> drop bocken fragments --> signalize to upper layer --> dont die, give user interessting information (bad signal strength, to many noise etc. etc. etc.)

    Just to create a concrete scenario for you.

Related