Question about MAC/HARQ architecture in LENA 5G(v4.2) bwp/CA and advice for simulating non-ideal backhaul CA(FR1-FR2)

[Yanwei Li]

Hello,

I am using ns-3.47(all-in-one), and I am new to both ns-3 and Lena 5G module(v4.2).

while studying the cttc-nr-cc-bwp-demo.cc, I would like to confirm my understanding of how MAC and HARQ entities are organized when multiple BWPs or CCs are configured.

From what I learned in Lena 5G v4.2:

each bwp has its own MAC entity,

In carrier aggregation, the BWPmanagergnb distributes traffic across BWPs.

even though scheduling is centralized, each MAC entity maintains its ow HARQ process and receives HARQ feedback independently.

Is this interpretation correct? specifically, I want to confirm that HARQ feedback is not aggregated into a single MAC entity, but instead remains per-MAC/per-BWP.

Simulation advice

I would like to simulate a non-ideal backhaul carrier aggregation scenario combining FR1 and FR2, and compare two architectural options

1. one MAC entity share across multiple CC/BWPs(Centralized MAC and centralized HARQ)

2. multiple MAC entities (one per cc/bwp)  (current Lena architecture: distributed MAC and distributed HARQ)

I would appreciate advice on the following point:

1. whether Lena 5G v4.2  supports a single MAC entity across multiple bwps, or if this requires modifying the code.

2. which classes or modules would be the correct starting point for such modification(e.g.nrgnbMac, nrMacscheduler, bwpmanager ? or HARQ-related classes)

3. any recommended approach or existing examples for simulating non-ideal backhual CA between FR1 and FR2

4. Since Lena v5 is released, would you recommend starting this work on Lena 5G v5 instead of v4.2 ?

Thanks.

[Gabriel Ferreira]

Hello,

>From what I learned in Lena 5G v4.2:

>each bwp has its own MAC entity,

That is correct.

>In carrier aggregation, the BWPmanagergnb distributes traffic across BWPs.

Exactly.

>even though scheduling is centralized, each MAC entity maintains its ow HARQ process and receives HARQ feedback independently.

My understanding is that it isn't centralized. Each MAC has its own scheduler. The scheduler then generates a transmission opportunity for the RLC queues atop it.
Mostly because that is what 3GPP mandates and we tend to follow it. But to be honest, I'm never quite sure. I find the design very confusing, and I work with it every day. :x

>Is this interpretation correct? specifically, I want to confirm that HARQ feedback is not aggregated into a single MAC entity, but instead remains per-MAC/per-BWP.

It can be or not right. For example, in case of FDD, UE UL BWP HARQ signaling is routed to the gNB DL BWP, so the gNB can keep track how DL is doing. And vice-versa.

>Simulation advice

>I would like to simulate a non-ideal backhaul carrier aggregation scenario combining FR1 and FR2, and compare two architectural options

>1. one MAC entity share across multiple CC/BWPs(Centralized MAC and centralized HARQ)

Can't do that with current code. And I think it will be quite massive change to handle that. But hey, with these LLMs, maybe not that hard.

>2. multiple MAC entities (one per cc/bwp)  (current Lena architecture: distributed MAC and distributed HARQ)

Yes.

>I would appreciate advice on the following point:

>1. whether Lena 5G v4.2  supports a single MAC entity across multiple bwps, or if this requires modifying the code.

Answered. It doesn't. You will need to modify a lot of stuff.

>2. which classes or modules would be the correct starting point for such modification(e.g.nrgnbMac, nrMacscheduler, bwpmanager ? or HARQ-related classes)

It will need to touch a lot of things in NrGnbMac, NrMacScheduler, BwpManager, NrGnbRrc, NrUeRrc, NrPhy.

>3. any recommended approach or existing examples for simulating non-ideal backhual CA between FR1 and FR2

Well, to be honest, what we support for carrier aggregation is very limited in scope. It is basically routing different 5QI to different BWPs.
Not what you want for backhaul. What you need is to transmit data through both links. Same data for URLLC, interleaved data for eMMC.
We don't support that yet, because it requires significant refactoring of RLC, PDCP, MAC. But it is in our roadmap, targeting early next year.

>4. Since Lena v5 is released, would you recommend starting this work on Lena 5G v5 instead of v4.2 ?

v5.1 should be released this week with important fixes that affect handover scenarios, if you are planning on simulating scenarios with mobility.