DECT NR+ HARQ communication and testing

RE: DECT NR+ HARQ communication and testing

schnitzlein — Tue, 06 May 2025 07:34:05 GMT

Thanks!

RE: DECT NR+ HARQ communication and testing

dejans — Tue, 06 May 2025 04:59:15 GMT

Hi,

Flipping initial transmission bits at transmitter side is not a good solution since these bits would be used as redundant information at receiver. Using them would most likely destroy retransmissions.
The best option for testing is to use high MCS (for example MCS 4) with low RSSI/SNR. The range -100dBm to -96dBm is especially suitable for testing with MCS 4 as there is always one retransmission, and in range -96dBm to -93dBm either zero or one retransmissions.

Best regards,
Dejan

RE: DECT NR+ HARQ communication and testing

dejans — Wed, 30 Apr 2025 14:44:54 GMT

Hi,

Thank you for additional information.

I expect to get back to you by the end of next week.

Best regards,
Dejan

RE: DECT NR+ HARQ communication and testing

schnitzlein — Mon, 28 Apr 2025 13:25:14 GMT

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.

RE: DECT NR+ HARQ communication and testing

schnitzlein — Mon, 28 Apr 2025 11:32:02 GMT

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

RE: DECT NR+ HARQ communication and testing

dejans — Mon, 28 Apr 2025 11:26:43 GMT

Hi,

Can you provide more details about your measurement setup?

[quote user=""]

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 )?

[/quote]

What exactly are you trying to achieve/test?

Best regards,
Dejan