MAC settings profile Console UI

[halimi]

Summary

We implemented the MAC settings profile API in https://github.com/TheThingsNetwork/lorawan-stack/issues/7380 for batch of devices it is useful but for a couple of devices it would be easier to use the Console UI.

Current Situation

Currently we can manage MAC settings profiles via the API.

Why do we need this? Who uses it, and when?

To have an easy way to manage MAC settings profiles and to associate/disassociate it to devices.

Proposed Implementation

A MAC settings profile is bind to an application. You can create/update/list/delete MAC settings profiles. We need to create a new section under the application where you can manage the MAC settings profiles.

We need to make sure that you can assign a MAC settings profile to an individual end device. For this probably the best place to put it under the end devices -> general settings -> network layer. Currently you can find here the Advanced MAC settings. When you assign a MAC settings profile then we are removing the Advanced MAC settings, they are mutually exclusive so it should reflect on the UI as well. We need to either show the MAC setting profile ID or the Advanced MAC settings. When unassigning the MAC settings profile from the device (setting the profile ID to null) then we need to show the Advanced MAC settings again.

There is also a possibility to assign MAC settings profile to batch of end devices. Probably a good place to put this under the Application -> MAC settings profile (the newly created page). Here you need to choose a MAC settings profile and you need to add a list of end-device IDs. You can also unassign the MAC setting profile from this list of end devices.

Contributing

• [x] I can help by doing more research.
• [ ] I can help by implementing the feature after the proposal above is approved.
• [x] I can help by testing the feature before it's released.

Validation

• [ ] The feature is tested in a staging environment.
• [ ] The feature is documented in The Things Stack Documentation

Code of Conduct

• [x] I agree to follow TTN's Community Code of Conduct.

[KrishnaIyer]

@pierrephz: Please sync with @halimi for the views. Once done, we can implement the screens for v3.35.0 maybe.

[halimi]

There is also a possibility to assign MAC settings profile to batch of end devices. Probably a good place to put this under the Application -> MAC settings profile (the newly created page). Here you need to choose a MAC settings profile and you need to add a list of end-device IDs. You can also unassign the MAC setting profile from this list of end devices.

During the design session, it turned out that currently doesn't make sense to use this on the UI, because we don't have a possibility to get a list of end devices that are using the profile. So we cannot show here and makes it hard to change or modify the list of end devices that are using the profile.

We decided that you can assign/unassign a profile on a particular end device page only.

[pierrephz]

Here are mockups for the MAC settings profile settings (list of profiles + creation of profile)

Adding a new menu item in the Application sidebar where you can see existing profiles and create new ones:

When clicking on the button Create MAC settings profile, you go to the creation process:

These mockup are a first version and open to feedback

Here are mockup of the MAC settings profile usage form the End device settings page:

These mockups are a first version and open to feedback cc @halimi @KrishnaIyer

[halimi]

Nice job @pierrephz ! Only one remark, you renamed the Advanced MAC settings to MAC settings profile, I think it should be called just MAC settings to not confused with the MAC settings profile.

[KrishnaIyer]

@ryaplots: I think this is good to do to complete this feature.

[ryaplots]

I have some questions about this. 2. Our current modals do not allow for adding forms inside. To allow for this we would either have to refactor the whole modal system or create a new one specifically for this case. This is a lot of work, when we can simply redirect the user to the create form, just like we do with wifi profiles. 3. The advanced mac settings that we currently have in the frontend is a rather complex form, with over 30 fields, we show fields conditionally depending on ACTIVATION MODE, LoRaWAN version and the class of the device. If these profiles are created at the level of the application, then we do not have access to these values per device. So I assume that the mac settings profile form has to have all the 36 mac settings fields:

message MACSettings {
  option (thethings.flags.message) = {
    select: true,
    set: true
  };
  // Maximum delay for the device to answer a MAC request or a confirmed downlink frame.
  // If unset, the default value from Network Server configuration will be used.
  google.protobuf.Duration class_b_timeout = 1;
  // Periodicity of the class B ping slot.
  // If unset, the default value from Network Server configuration will be used.
  PingSlotPeriodValue ping_slot_periodicity = 2;
  // Data rate index of the class B ping slot.
  // If unset, the default value from Network Server configuration will be used.
  DataRateIndexValue ping_slot_data_rate_index = 3;
  // Frequency of the class B ping slot (Hz).
  // If unset, the default value from Network Server configuration will be used.
  ZeroableFrequencyValue ping_slot_frequency = 4;
  // Frequency of the class B beacon (Hz).
  // If unset, the default value from Network Server configuration will be used.
  ZeroableFrequencyValue beacon_frequency = 25;

  // Maximum delay for the device to answer a MAC request or a confirmed downlink frame.
  // If unset, the default value from Network Server configuration will be used.
  google.protobuf.Duration class_c_timeout = 5;

  // Class A Rx1 delay.
  // If unset, the default value from Network Server configuration or regional parameters specification will be used.
  RxDelayValue rx1_delay = 6;
  // Rx1 data rate offset.
  // If unset, the default value from Network Server configuration will be used.
  DataRateOffsetValue rx1_data_rate_offset = 7;
  // Data rate index for Rx2.
  // If unset, the default value from Network Server configuration or regional parameters specification will be used.
  DataRateIndexValue rx2_data_rate_index = 8;
  // Frequency for Rx2 (Hz).
  // If unset, the default value from Network Server configuration or regional parameters specification will be used.
  FrequencyValue rx2_frequency = 9;
  // List of factory-preset frequencies.
  // If unset, the default value from Network Server configuration or regional parameters specification will be used.
  repeated uint64 factory_preset_frequencies = 10 [(validate.rules).repeated.max_items = 96];

  // Maximum uplink duty cycle (of all channels).
  AggregatedDutyCycleValue max_duty_cycle = 11;

  // Whether the device supports 32-bit frame counters.
  // If unset, the default value from Network Server configuration will be used.
  BoolValue supports_32_bit_f_cnt = 12;

  // Whether the Network Server should use ADR for the device.
  // This field is deprecated, use adr_settings instead.
  BoolValue use_adr = 13 [deprecated = true];
  // The ADR margin (dB) tells the network server how much margin it should add in ADR requests.
  // A bigger margin is less efficient, but gives a better chance of successful reception.
  // This field is deprecated, use adr_settings.dynamic.margin instead.
  google.protobuf.FloatValue adr_margin = 14 [deprecated = true];
  // Whether the device resets the frame counters (not LoRaWAN compliant).
  // If unset, the default value from Network Server configuration will be used.
  BoolValue resets_f_cnt = 15;
  // The interval after which a DevStatusReq MACCommand shall be sent.
  // If unset, the default value from Network Server configuration will be used.
  google.protobuf.Duration status_time_periodicity = 16;
  // Number of uplink messages after which a DevStatusReq MACCommand shall be sent.
  // If unset, the default value from Network Server configuration will be used.
  google.protobuf.UInt32Value status_count_periodicity = 17;

  // The Rx1 delay Network Server should configure device to use via MAC commands or Join-Accept.
  // If unset, the default value from Network Server configuration or regional parameters specification will be used.
  RxDelayValue desired_rx1_delay = 18;
  // The Rx1 data rate offset Network Server should configure device to use via MAC commands or Join-Accept.
  // If unset, the default value from Network Server configuration will be used.
  DataRateOffsetValue desired_rx1_data_rate_offset = 19;
  // The Rx2 data rate index Network Server should configure device to use via MAC commands or Join-Accept.
  // If unset, the default value from frequency plan, Network Server configuration or regional parameters specification will be used.
  DataRateIndexValue desired_rx2_data_rate_index = 20;
  // The Rx2 frequency index Network Server should configure device to use via MAC commands.
  // If unset, the default value from frequency plan, Network Server configuration or regional parameters specification will be used.
  FrequencyValue desired_rx2_frequency = 21;

  // The maximum uplink duty cycle (of all channels) Network Server should configure device to use via MAC commands.
  // If unset, the default value from Network Server configuration will be used.
  AggregatedDutyCycleValue desired_max_duty_cycle = 22;

  // The ADR ACK limit Network Server should configure device to use via MAC commands.
  // If unset, the default value from Network Server configuration or regional parameters specification will be used.
  ADRAckLimitExponentValue desired_adr_ack_limit_exponent = 23;
  // The ADR ACK delay Network Server should configure device to use via MAC commands.
  // If unset, the default value from Network Server configuration or regional parameters specification will be used.
  ADRAckDelayExponentValue desired_adr_ack_delay_exponent = 24;

  // The data rate index of the class B ping slot Network Server should configure device to use via MAC commands.
  // If unset, the default value from Network Server configuration will be used.
  DataRateIndexValue desired_ping_slot_data_rate_index = 27;
  // The frequency of the class B ping slot (Hz) Network Server should configure device to use via MAC commands.
  // If unset, the default value from Network Server configuration or regional parameters specification will be used.
  ZeroableFrequencyValue desired_ping_slot_frequency = 28;
  // The frequency of the class B beacon (Hz) Network Server should configure device to use via MAC commands.
  // If unset, the default value from Network Server configuration will be used.
  ZeroableFrequencyValue desired_beacon_frequency = 29;
  // Maximum EIRP (dBm).
  // If unset, the default value from regional parameters specification will be used.
  DeviceEIRPValue desired_max_eirp = 30;
  // The minimum duration passed before a network-initiated(e.g. Class B or C) downlink following an arbitrary downlink.
  google.protobuf.Duration class_b_c_downlink_interval = 31;

  // Whether uplink dwell time is set (400ms).
  // If unset, the default value from Network Server configuration or regional parameters specification will be used.
  BoolValue uplink_dwell_time = 32;
  // Whether downlink dwell time is set (400ms).
  // If unset, the default value from Network Server configuration or regional parameters specification will be used.
  BoolValue downlink_dwell_time = 33;

  // Adaptive Data Rate settings.
  // If unset, the default value from Network Server configuration or regional parameters specification will be used.
  ADRSettings adr = 34;

  // Whether or not downlink messages should be scheduled.
  // This option can be used in order to disable any downlink interaction with the end device. It will affect all types
  // of downlink messages: data and MAC downlinks, and join accepts.
  BoolValue schedule_downlinks = 35;

  // The relay settings the end device is using.
  // If unset, the default value from Network Server configuration or regional parameters specification will be used.
  RelaySettings relay = 36;

  // The relay settings the Network Server should configure device to use via MAC commands.
  // If unset, the default value from Network Server configuration or regional parameters specification will be used.
  RelaySettings desired_relay = 37;
}

And the user fills in the ones they need? If so then this is a very long form, which is not accounted for in the designs. Is there validation on the backend to prevent some fields from being accepted under some conditions, for example, beacon_frequency is the frequency of the class B beacon, if the mac settings profile has a value for this field but the profile is being set to a class C device, will it be possible to set this profile anyway? I think I need more context on how this would work @KrishnaIyer @halimi

[halimi]

@ryaplots The idea is that when you create a MAC settings profile at that moment is not attached to any device so it is a general profile and should be able to set all the settings. Because it is not attached to a device therefore there is no backend and frontend validation for the set of settings.

The validation happens when you assign it to a device because that is the point when we know the device activation mode, lorawan version, class, etc. The backend will validate the set of settings and reject it if not fits for the device. In this case the user needs to change the settings in the profile to able to apply it.

[ryaplots]

I see, that's clear! Thanks!

[ryaplots]

I tested on staging and seems to be working well.