Support Generation of router_config for 16/64 Channel Basic Station gateways

KrishnaIyer commented 5 years ago

Summary

Support gateway config for gateways with >8 channels.

Why do we need this?

This is to support configuration of 16 ch gateways Ex: TTOG US Version and potentially higher channels.

What is already there? What do you see now?

pfconfig supports only one SX1301_conf object.
lns generates only one SX1301_conf.

What is missing? What do you want to see?

Support combining channels from frequency plans from different frequency plans and pass that to the Basic Station.

Environment

All

How do you propose to implement this?

[x] API: introduce a repeated string frequency_plan_ids to Gateway. Falls in scope of this issue
[x] ER: handle new field as described in #1353 (comment) (i.e. staying backward compatible with clients who only know frequency_plan_id, potentially having them accidentally reset multiple plans). Falls in scope of this issue GS
[x] Support multiple frequency plans in Basic Station LNS. Falls in scope of this issue
- [x] promote basicstation router_config to pkg/pfconfig
- [x] make sx1301 a slice.
- [x] Generate one SX1301_conf object for each configured frequency plan.
- [x] Update the hwspec field of the router_config for basicstation.
[x] Support multiple frequency plans in the scheduler. This needs a separate issue, scoped to same band frequency plans, referencing #1394 to support mixed bands
[x] GCS: add support to return a UDP packet forwarder global_conf.json with multiple concentrator support. This needs a separate issue: #1837

Can you do this yourself and submit a Pull Request?

Yes.

cc: @htdvisser

htdvisser commented 5 years ago

Blocked on #762

KrishnaIyer commented 5 years ago

Back when I worked on this, I noticed that we extract a single SX1301 field from one Frequency plan. We probably need to edit the frequency plans yaml ( except the band_id field), and add a top level key with n arrays where n=no of concentrators.

band-id: EU_863_870
concentrators:
- uplink-channels:
  - frequency: 868100000
    min-data-rate: 0
    max-data-rate: 5
    radio: 1
  - frequency: 868300000
    min-data-rate: 0
    max-data-rate: 5
    radio: 1
  - frequency: 868500000
    min-data-rate: 0
    max-data-rate: 5
    radio: 1
  - frequency: 867100000
    min-data-rate: 0
    max-data-rate: 5
    radio: 0
  - frequency: 867300000
    min-data-rate: 0
    max-data-rate: 5
    radio: 0
  - frequency: 867500000
    min-data-rate: 0
    max-data-rate: 5
    radio: 0
  - frequency: 867700000
    min-data-rate: 0
    max-data-rate: 5
    radio: 0
  - frequency: 867900000
    min-data-rate: 0
    max-data-rate: 5
    radio: 0
  downlink-channels:
  - frequency: 868100000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 868300000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 868500000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 867100000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 867300000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 867500000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 867700000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 867900000
    min-data-rate: 0
    max-data-rate: 5
  lora-standard-channel:
    frequency: 868300000
    data-rate: 6
    radio: 1
  fsk-channel:
    frequency: 868800000
    data-rate: 7
    radio: 1
  radios:
  - enable: true
    chip-type: SX1257
    frequency: 867500000
    rssi-offset: -166
    tx:
      min-frequency: 863000000
      max-frequency: 870000000
  - enable: true
    chip-type: SX1257
    frequency: 868500000
    rssi-offset: -166
  clock-source: 1
- uplink-channels:
  - frequency: 868100000
    min-data-rate: 0
    max-data-rate: 5
    radio: 1
  - frequency: 868300000
    min-data-rate: 0
    max-data-rate: 5
    radio: 1
  - frequency: 868500000
    min-data-rate: 0
    max-data-rate: 5
    radio: 1
  - frequency: 867100000
    min-data-rate: 0
    max-data-rate: 5
    radio: 0
  - frequency: 867300000
    min-data-rate: 0
    max-data-rate: 5
    radio: 0
  - frequency: 867500000
    min-data-rate: 0
    max-data-rate: 5
    radio: 0
  - frequency: 867700000
    min-data-rate: 0
    max-data-rate: 5
    radio: 0
  - frequency: 867900000
    min-data-rate: 0
    max-data-rate: 5
    radio: 0
  downlink-channels:
  - frequency: 868100000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 868300000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 868500000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 867100000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 867300000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 867500000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 867700000
    min-data-rate: 0
    max-data-rate: 5
  - frequency: 867900000
    min-data-rate: 0
    max-data-rate: 5
  lora-standard-channel:
    frequency: 868300000
    data-rate: 6
    radio: 1
  fsk-channel:
    frequency: 868800000
    data-rate: 7
    radio: 1
  radios:
  - enable: true
    chip-type: SX1257
    frequency: 867500000
    rssi-offset: -166
    tx:
      min-frequency: 863000000
      max-frequency: 870000000
  - enable: true
    chip-type: SX1257
    frequency: 868500000
    rssi-offset: -166
  clock-source: 1

KrishnaIyer commented 5 years ago

I've temporarily added a discussion label on this until we decide how to handle this. cc: @johanstokking @htdvisser

johanstokking commented 5 years ago

Blocking #48 Blocking #1303

htdvisser commented 5 years ago

I don't think it's a good idea to put things under a Concentrators list. Probably better to add a Concentrator uint8 to Channel and Radio structs. That way the current frequency plans don't have to be modified.

htdvisser commented 5 years ago

Another option would be to specify multiple (instead of one) frequency_plan_ids for gateways, and we'd combine all that.

htdvisser commented 5 years ago

The latter would actually be better if we also want to support multi-antenna gateways that listen on the same channels with multiple antennas.

johanstokking commented 5 years ago

So the consideration is to;

be able to set multiple frequency plans to gateways
be able to set multiple frequency plans to end devices

I'll have a look at the GS downlink scheduling and NS-GS transmission request logic.

@rvolosatovs can you indicate the implication for the NS of 2? Note that different frequency plans can refer to different bands. Note also that we should enforce that uplink channels of frequency plans do not overlap. We can in fact compile one FrequencyPlan struct from multiple by combining all uplink and downlink channels; there should be no conflict.

rvolosatovs commented 5 years ago

So a device could be operating in multiple frequency plans(and bands) simultaneously? That's doable, however the underlying bands must be compatible, i.e.:

Same default channels(one may be a superset of the other)
Same TXPower operation
Same Data Rates
Same ChMaskCntl operation
Same Rx1 frequency computation scheme
Same Rx2 frequency
Same CFList types
Same JoinAcceptDelay{1,2} for OTAA
Rx1 delay and Rx2 data rate must be the same of ABP - for OTAA we can send this in Join-Accept

That is for Class A/C operation. Some other requirements may exist for Class B operation.

Theoretically, some of these may be different(e.g. Rx2 frequency and CFList type), since we can work around these during the session via e.g. MAC commands, but IMO we should only do that as last-resort and, preferably, not do it at all.

I think we should start with multiple frequency plans, which all belong to the same PHY band. That should require changes mostly in the resetMACState. Supporting multiple frequency plans belonging to different PHY bands is more tricky and could require a significant amount of changes, however maybe it's possible to abstract it somehow. I would need to give it some more thought.

htdvisser commented 5 years ago

How would this work with dynamic channel bands such as EU868? If you combine multiple channel plans, the channel indexes will be all messed up, right? Isn't it better to treat bands with fixed or dynamic channels differently?

We also need to keep in mind that all of this only makes sense if end device owners know for sure that their end devices are deployed in an area with coverage for additional channels. I think in many cases end device owners will not know. At the same time we see that the environment can be dynamic. New gateways with additional channel coverage may be deployed in an area, and we want to adapt end devices that are (or move into) that area. We may need to help them (owners/end devices) a bit with this. Of course it doesn't have to be the responsibility of The Things Stack, and can be done by an external service as well.

So the complete proposal would be:

In gateway settings, a gateway owner can specify multiple frequency plans; one for each concentrator. Here the underlying band doesn't really matter, so TTN's AS923-925 frequency plan is equivalent to AU915's 6th FSB (ch40-47). It's also possible to assign the same channel plan to multiple concentrators.
In end device settings, an end device owner can configure
1. A single channel plan that contains all mandatory + additional channels for a dynamic channel band (such as EU868).
2. A set of channel plans for different FSBs of (the same) fixed channel band (such as US915).
APIs that allow an external service to monitor the network environment (perhaps by making gateways or specific end devices send pings on different channels, or just by looking at the registered locations on a map) and dynamically (re)configure end devices with different channel plans if more channels are available around those end devices.

johanstokking commented 5 years ago

@KrishnaIyer can you update this issue for the gateway-side, i.e. gateway entity API and potentially uplink message, GS and GCS support? Then we can remove discussion and assignment. Probably push this to Next Up.

@rvolosatovs can you file an issue for the device and network side (device entity API, NS)? Also Next Up

ama9910 commented 5 years ago

In gateway settings, a gateway owner can specify multiple frequency plans; one for each concentrator. Here the underlying band doesn't really matter, so TTN's AS923-925 frequency plan is equivalent to AU915's 6th FSB (ch40-47). It's also possible to assign the same channel plan to multiple concentrators.

Ideally, it would be great to assign different channel plans to the same concentrator. This is important for Australia where we use both AS923 and AU915. As @htdvisser mentions above the channel frequencies are the same for AS923-925 and AU915 FSB6. A single 8-channel gateway could then service could service both bands. I note though that the RX1 frequency calculation and RX2 frequencies are different for those two bands.

johanstokking commented 5 years ago

Ideally, it would be great to assign different channel plans to the same concentrator. This is important for Australia where we use both AS923 and AU915. As @htdvisser mentions above the channel frequencies are the same for AS923-925 and AU915 FSB6. A single 8-channel gateway could then service could service both bands. I note though that the RX1 frequency calculation and RX2 frequencies are different for those two bands.

The channel plan for the gateway is basically only the channels on which to listen. So if AU915/6 and AS923-925 are overlapping, it doesn't matter for the gateway configuration.

Any downlink calculations (RX1/RX2 frequency and data rates) are carried out by the Network Server and are based on the end device's frequency plan(s), channel it used in those plans and the versioned PHY. This is regardless of the gateway channel plan; gateway channel 2 may be end device's channel 6, as long as the frequency is the same. The gateway will respect the NS/GS's chosen downlink settings; gateways transmit on any requested frequency and data rate.

So you can configure a gateway with AU915/6 and have AS923-925 devices work without problem, or vice-versa.

htdvisser commented 5 years ago

@johanstokking how about the scheduler in the GS? That seems to depend on the frequency plan and band.

@KrishnaIyer how about Basic Station gateways? For those we may need to register additional data rate configurations, since the downlink DRs for AU915 and AS923 are different.

KrishnaIyer commented 5 years ago

Basic Station gateways accept n SX1301 objects as part of the the spec. So we can send an AU915 and an AS923 sub-band on the same message under two different objects.

htdvisser commented 5 years ago

I meant DRs in the router_config message.

johanstokking commented 5 years ago

@johanstokking how about the scheduler in the GS? That seems to depend on the frequency plan and band.

Yes, we may need to get this from NS as part of TxRequest indeed.

@ama9910 can you provide the debug log of the failed GS scheduling attempts?

KrishnaIyer commented 5 years ago

IIRC The DR objects are not actually used and only the SX1301_conf objects are needed but I'll confirm this.

johanstokking commented 5 years ago

IIRC The DR objects are not actually used and only the SX1301_conf objects are needed but I'll confirm this.

They should be used for translating the uplink and downlink data rates to what has been communicated to the gateway through the router config. So if the gateway is set to AU915/6, the DRs follow that of the AU915 band (and they vary by version). On uplink, we only get DR (not SF and BW), so regardless of the end device's frequency plan, we need to figure out the SF and BW from the gateway's frequency plan and NS figures out which actual end device's DR that is based on the end device's frequency plan by looking at SF and BW only. Other way around for downlink.

ktsolakas commented 5 years ago

@ama9910 can you provide the debug log of the failed GS scheduling attempts?

Attaching debug_log_failed_GS.txt

johanstokking commented 5 years ago

Thanks. This is a bit more complicated than I thought.

The logs indicate that GS can't find the data rate index in the gateway's band. This is because of the mismatch between end device and gateway band. That's normal.

The reason why my suggestion to let NS pass the frequency plan as part of the transmission request does not work, is that the GS scheduler enforces duty-cycle by (sub-)band. The band is referred to by the frequency plan. Mixing bands AS926 and AU915 is no problem for duty-cycle, but this is not a general rule. For this issue not to go off-topic, please open a separate issue to see what can be done.

johanstokking commented 5 years ago

With multiple frequency plans with different bands described in #1394, this issue focuses on supporting multiple frequency plans for gateways. My proposal is;

API: introduce a repeated string frequency_plan_ids to Gateway. Falls in scope of this issue
ER: handle new field as described in https://github.com/TheThingsNetwork/lorawan-stack/issues/1353#issuecomment-531156037 (i.e. staying backward compatible with clients who only know frequency_plan_id, potentially having them accidentally reset multiple plans). Falls in scope of this issue
GS
- Support multiple frequency plans in Basic Station LNS. Falls in scope of this issue
- Support multiple frequency plans in the scheduler. This needs a separate issue, scoped to same band frequency plans, referencing #1394 to support mixed bands
GCS: add support to return a UDP packet forwarder global_conf.json with multiple concentrator support. This needs a separate issue

johanstokking commented 5 years ago

@KrishnaIyer @htdvisser ack?

If so, let's remove discussion and plan work in a milestone

htdvisser commented 5 years ago

I quickly did 1 and 2 in https://github.com/TheThingsNetwork/lorawan-stack/compare/feature/761-multi-fplan-gtw.

KrishnaIyer commented 5 years ago

@htdvisser: I already have a branch for this. I didn't have the time to write tests. I'll adapt your changes into it.

johanstokking commented 5 years ago

@KrishnaIyer great, please file additional issues with assignments as needed. I can do the GS scheduler part

htdvisser commented 5 years ago

@KrishnaIyer please delete the branch when you've incorporated my changes.

KrishnaIyer commented 4 years ago

I've updated the description with the TODO. I've created a feature branch feature/multi-fplan-gateway where we can target the individual PRs from the items.

TheThingsNetwork / lorawan-stack