Latency and scheduling timing in DECT NR+

[nir_g]

Hi,

 

I’m trying to have two nrf9161s exchange data back and forth as quickly as possible. Initially the first radio is transmitting, and the other is receiving (3 sub-slots in my case); and then they switch – the first radio receives while the other transmits (and the cycle then repeats). I’m trying to figure out the correct scheduling/timing given the modem’s latency. I’m using the combined TxRx operation to reduce latency. (Note that my MAC scheme is not conforming to the DECT standard).

 

Modem 0: TX                TxRx latency    RX                     RX->TX latency

         +----+----+----+--- ............. ---+----+----+----+--- ............... ---+ Repeat

 

Modem 1: RX                RX->TX latency      TX                 TxRx latency

         +----+----+----+--- ................. ----+----+----+--- ............... ---+ Repeat

 

Regarding the switch from TX to RX. From a scheduling perspective in a combined TxRx operation, the start_time of the RX part is (from the docs): “The start time of the RX operation is relative to the end of the TX operation and it must include the guard time”. How is that related to the latency? For instance, in my configuration the GI is about 1500 ticks, and the RxTX latency is 20044 for the ntf9161. If I assign the value “0” to the Rx start_time, when will the transmission start? The latency itself is longer than the GI, so can I assume that the transition from TX to RX will start immediately when the TX ends, and the RX will start 20044 ticks later (and the GI is just included in that)?

 

Regarding the switch from TX to RX. There’s no special latency for this transition. Does this mean that the modem must transition through idle, and the latency is rx_to_idle + idle_to_tx? Specifically, if the next transmission is already scheduled.

 

Thanks,

Nir

 

[Øyvind]

Hi Nir, 

Note that my MAC scheme is not conforming to the DECT standard

Could you please provide more details on what this means? What modem FW are you running on the nRF9161? 

Will need more information to discuss this internally. 

Kind regards,
Øyvind

[nir_g]

Hi Øyvind,

Sorry, but I wasn't clear on that.  I'm using the standard PHY firmware supplied by you.

What I meant was that in my application, some transmissions may not start on a sub-slot boundary (as the standard dictates). But that is fine, as long as all the modems are transmitting/receiving in a synchronized way (i.e. this is really about my MAC implementation, not PHY).

I think that the questions should be relevant even I was going exactly by the standard:

1. In a combined TxRx operation, when will RX start after TX - given the TxRx latency and the start_time parameter (e.g. if latency is bigger than start_time - does the start_time even matter?).

2. What is the transition time from RX to TX, and does the modem go through idle when doing that.

I hope that makes more sense :-)

Thanks,

Nir

[Øyvind]

Thanks for clarifying, Nir! I will forward and discuss internally. I hope to have an answer by end of this week. 

Kind regards,
Øyvind

[Øyvind]

Hello Nir, 

Our DECT team provided me with the following answer:

For start TX-RX combined operation is mainly done for fast turnaround for HARQ ACK response after data transmission. For example, in case TX fails due to LBT also RX will fail (not started at all). Of course, one can re-use the operation to other purposes if restrictions does not affect to the use case.

1. TXRX_operation (as it is thought to be used for TX → HARQ monitoring) shall have less than 1 slot turnaround. The time is delivered in nrf_modem_dect_phy_modem_cfg in nrf_modem_phy_init -callback: value is in “txrx_tx_to_rx” member and depends of the software version in use. For release 1.0.0 this is defined as 290 us.

2. From RX to TX modem will go to IDLE in release 1.0.0. This means that expected latency is:

RX to IDLE + APP processing + IDLE to TX and depends if RX is using RSSI measurement in the operation and if TX has LBT used or not (different constants for all of these options). Basic case will have “rx_to_idle” + undefined customer app delay + “idle_to_tx” from same nrf_modem_phy_init -callback resulting to 190 us + ~100 us app + 410 us = 700 us in 1.0.0 firmware. NOTE that RX to IDLE assumes packet reception with single shot or semicontinuous mode having implicit RX stop, so that explicit RX stop is not commanded from application.

Members for latency constants in nrf_modem_phy_init() -callback can be found in the API documentation of our modem library

Kind regards,
Øyvind