WiFi PHY Buffers

[George Frangulea]

Hello,

I am working on some sort of buffer that would be aware of the Time Division Duplex (TDD) pattern (e.g., DL|DL|DL|DL|UL|DL|DL|DL| UL | DL | DL|UL) (issue detailed here: https://gitlab.com/cttc-lena/nr-u/-/issues/12). 

However, I cannot find any specifications of how packets should be handled at the PHY layer in cases where the channel is not Granted in NR-U. 

• How does WiFi handle these situations (what happens with packets when channel is not granted) at the PHY layer? Can someone point me to the right code to look at? I am sure it is not directly applicable to the NR-U system, but maybe there is something to learn there. Thank you!

[Tommaso Pecorella]

I don't know about the specific code point (the codebase is huge), but I think there's a queue at the MAC level, and the PHY uses a back pressure to pick them when the channel is granted.

If I'd have to do it from scratch without other code I'd do something like:

• Queue at MAC level (small and finite)
• Request an access depending on the queue size and - maybe - a forecast of the queue size when the grant will arrive (*)
• When the grant is there, pick from the queue

Where the forecast is based on the statistics of the arrival process at the queue, and the granted slots (they might be less or more than what one asked).

And here you can add the problem of traffic forecasting, and also game theory if you want.

[George Frangulea]

I know. I wish there was a map for all the ns-3 codes that I could print and hang on the wall. I will think about your solution, but I am not sure if it is feasible in the current implementation of LBT (the equivalent of DCF) in NR-U. 

I know that in Wi-Fi, DCF procedure is at the MAC layer, so it can directly interact with the MAC queue and handle whether to allow TxoP, which is great. 

In the ns-3 NR-U module, LBT has been implemented at the PHY layer. The PHY-MAC processing delay is also 2 ms, so the MAC will schedule 1-2 slots in advance. At the PHY layer, StartSlot is called for the already scheduled slots (if any). If the channel is not already Granted (for TxOp duration), then LBT is requested, and the current scheduled slots are buffered. 

So you see, this LBT after MAC is great (low latency) when the channel is Granted straight away, while if channel acquisitions is repeatedly failed, it becomes a headache. If the channel is not clear within the duration of the PHY processing, then the MAC Packet Data Unit (PDU) needs to be rescheduled, which will incur an access delay of more than 3 ms to reschedule at Radio Link Control (RLC) and then reprocess at MAC and PHY. 

[Tom Henderson]

In my experience, specifications are intentionally vague on how to
implement internals such as buffering, and implementations could vary
widely. Therefore, I think you need to make assumptions and document them.

There is quite a difference in how latency is handled in NR and Wi-Fi
models. NR contains significant MAC-to-PHY delay (as you mention, 2
ms), but has a simplification that it does not model propagation delay
in the channel. Wi-Fi is the opposite (the internal device delay is
just the buffering and channel access delays, but no processing delay,
and propagation delay is modeled).

I think you should first try to modify the Wi-Fi channel access and
frame exchange manager to adjust the timing and TXOP length according to
the constraints from NR-U, without changes to the PHY.

[George Frangulea]

NR-U delay for a TxOp of 3ms (which i test with Wi-Fi AC_VI) can be from 3 seconds (at scs 15 kHz -> 1 ms slot),  to  14 ms (at scs 120 kHz -> 0.123 ms slot).  Most of this delay comes from gNB having the LBT blocked by the UL UCI from its UEs during the sensing before the slot boundary (which then has to wait for next slot boundary to try and transmit just to find another UL UCI). That's why I was thinking of implementing TDD, which would allow me to not have a UL symbol at the end of each slot. 

I saw papers that assume same TxOp in Wi-Fi as in NR-U. But is that realistic to test since it will never happen in reality? 

Thank you.

[George Frangulea]

For my current simulations, Wi-Fi always achieves perfect performance even with a smaller TxOp. I cannot even test data rates that would push Wi-Fi closer to saturations because I get above 1-second latencies in NR-U.  That's why I am looking for things to improve NR-U.