Support downlink to multiple antennas

[johanstokking]

Summary:

Support multiple antennas for downlink.

Why do we need this?

To have more downlink paths.

What is already there? What do you see now?

The Gateway Server currently only provides uplink tokens for antennas with index 0 and sets the downlink path constraint "never" on other antennas.

What is missing? What do you want to see?

Treat all antennas equal; provide uplink token and inherit the gateway's downlink path constraint.

How do you propose to implement this?

We need answers to the following questions;

1. Should duty-cycle be enforced per antenna or per physical gateway?
2. How to specify the antenna index in the UDP protocol?

---

Original issue: https://github.com/TheThingsIndustries/lorawan-stack/issues/1406 by @johanstokking

[johanstokking]

1. My expectation is that this is still per physical gateway
2. Basic Station has a rctx field which refers to the antenna. So that's gonna work. We probably need to differentiate in the frontend to check support for multiple antennas on the downlink path

[johanstokking]

From @Oliv4945 input;

• Duty-cycle is per sub-band per gateway
• In UDP, for txpk, the antenna is simply the ant field. It comes from the multiple rsig entries, where it's also ant

This means concretely for the implementation;

• pkg/gatewayserver/scheduling.SubBand should have an emissions array per antenna as conflicts are per antenna, not per gateway. The duty-cycle is still the compound of these arrays, as that is per gateway
• I'd propose to change the uplink token to contain an array of antenna indices and their timestamp. We can freely change the uplink token proto as it's not part of the API and opaque to NS
• On downlink, GS tries each antenna in the given uplink token for availability for conflict and duty-cycle

[KrishnaIyer]

blocked on #761.

[virtualguy]

:+1: would be great to see this implemented as we are downlink heavy and this would increase our capacity

[KrishnaIyer]

Note to self:

• At the moment wrt multiple antennas, we allow setting multiple but use only the first one.
• When we implement multi-antenna support, we need to match the frequency plan with the antenna index, since each concentrator gets an FP and one antenna(?). This is important for LBS since the Antenna Gain is part of the RFConfig which is specific to a concentrator.
• Currently, we just read this based on index in the code antenna[i] and gateway.FrequencyPlanIds[i] and assume that these indices match (ex: antenna[2] corresponding to concentrator 2 with a FrequencyPlanIds[2]).
• We'll have to make sure that these items match, i.e., add a check in the IS when someone updates the FPs and/or antennas.

We could also introduce a new repeated Concentrator field on the gateway that collects these for internal use. This will remove any ambiguity while matching.

message Concentrator{
  string frequency_plan = 1;
  GatewayAntenna antenna = 2;
}

[johanstokking]

One antenna is indeed tied to one concentrator, but they can use the same frequency plan. This is used for geolocation with two omnidirectional antennas (Semtech V2 reference design). It can also be for noise reduction using two directional antennas, again using the same frequency plan.

BTW, what does the frequency plan matter for scheduling downlink? It's only the band that matters, right? And we require the band to match.

[KrishnaIyer]

Indeed FP is not related to the gain. But in LBS, the LNS sends n SX1301_conf objects, each object meant for one concentrator (and hence antenna). Each object contains info from one FP (converted to IFConf) and one antenna gain. So these two must be in sync. It's ok for both concentrators to use the same FP but the user must indicate this. Ex: Below is how currently users indicate that there are two concentrators.

ttn-lw-cli gateways set test-gtw  --frequency-plan-ids EU_863_870, EU_863_870

My proposal above is to explicitly have the concentrator configuration separately. These can just be pointers to existing FP and Antenna fields but everything meant for a particular concentrator is collected somewhere. Otherwise we need to use array indices (gateway.FrequencyPlans[x] and gateway.Antennas[x]) to match these which might get ugly.

BTW, what does the frequency plan matter for scheduling downlink? It's only the band that matters, right? And we require the band to match.

That's right indeed for downlinks. But afaik users can override certain parameters for a sub-band which is controlled by the FP right?

[johanstokking]

My proposal above is to explicitly have the concentrator configuration separately. These can just be pointers to existing FP and Antenna fields but everything meant for a particular concentrator is collected somewhere. Otherwise we need to use array indices (gateway.FrequencyPlans[x] and gateway.Antennas[x]) to match these which might get ugly.

Sounds good

BTW, what does the frequency plan matter for scheduling downlink? It's only the band that matters, right? And we require the band to match.

That's right indeed for downlinks. But afaik users can override certain parameters for a sub-band which is controlled by the FP right?

Yes indeed, some bands are applicable to multiple regions (like AS923) and then the regional constraints are defined (overridden) in the FP. So you're right, we need the associated FP on downlink.