Skip to main content

Editing the base station's radio configuration

Editing the RF Region​

The LoRaWAN® Regional Parameters document defines several RF profiles depending on the regional RF regulatory context. For each ISM Band, these regional parameters are grouped into RF Regions which determine the radio frequency allocation plan for devices and base stations, together with a set of radio parameters used by the LoRaWAN® MAC layer.

For more information about the RF Regions supported by ThingPark's catalog, see RF Regions.

To edit the RF region of an existing base station, it must be connected to the network. If your base station is currently disconnected from the network, you must wait for it to come online.

  1. Select the base station you want to edit. You may search it by its name or ID.

  2. In the Basic View tab, under the Information widget, go to RF Region.

  3. Click the drop-down menu and select your target RF Region, you may quickly search it by typing in the text area. Only RF Regions matching the ISM Bands associated with your deployment are proposed by the user interface.

    caution

    Do not assign an RF Region exceeding the maximum number of channels supported by your base station. For instance, if your base station supports 8 channels, do not allocate an RF Region with 16 or 64 channels.

  4. To confirm your choice, click , otherwise click to cancel.

Activating beacon transmission​

LoRaWAN® beacons are mandatory for class B operations. Class B is achieved by having the base station send beacon signals on a regular basis (every 128 seconds by default) to synchronize all end-devices in the network so that the end-device can open a short additional reception window (called a ping slot) at a predictable time during a periodic time slot. To learn more about LoRaWAN beacons and class B, see LoRaWAN specifications.

If you have devices operating in class B mode, you must ensure that the base stations serving these devices activate the beacon transmission.

In the current release, sending beacon signals is only allowed on base stations equipped with a GPS receiver. Therefore, activating beacon transmission is proposed in the user interface only if the base station has an embedded GPS receiver.

  1. Select the base station you want to edit. You may search it by its name or ID.

  2. In the Advanced tab, under the Advanced settings widget, switch on the Beacon transmission switch to activate beacons on your base station.

This action will immediately trigger the scheduling of beacon signals according to the timing protocol defined by LoRaWAN specifications, provided that the base station is GPS-synchronized.

tip

To monitor the status of beacon transmission by the base station, go to RF Statistics tab, then check the beacon statistics in the Counters widget.

Changing the BS coverage mode​

To deploy base stations providing temporary RF coverage without jeopardizing the longer-term radio operation of surrounding devices, BS administrators can determine the RF coverage type of each base station.

Base stations providing temporary RF coverage may be useful in the following use cases:

  • For drive-by or walk-by use cases to retrieve sensor measurements in hard-to-cover locations such as water meters located in basements.

  • In special deployment scenarios where LoRaWAN® coverage is missing or very poor, temporary coverage would be established by lifting a base station up in the air with a drone.

  • Mobile gateways could be used to rescue the RF coverage of devices that initially use aggressive ADR settings (for instance, SF7 with power reduction) while the actual radio design requires those devices to use higher SF/TxPower. Example The best serving gateway of some devices goes in outage while those devices currently use SF7. To allow surrounding base stations to serve those devices, the network administrator may deploy a temporary BS to capture the SF7 traffic of those devices while switching them to higher SF/TxPower/NbTrans through the RF recovery mode.

This RF Coverage Type attribute specifies if the BS provides permanent RF coverage or it only offers temporary coverage for recovery purposes.

  • Permanent (default setting): the BS provides permanent RF coverage to surrounding devices. Accordingly, the uplink packets received through this BS are counted in ADR decisions. Additionally, this BS may be used to route downlink packets for all device classes A/B/C.

  • Temporary and mobile: the base station does not have a fixed location, it provides temporary RF coverage to surrounding devices. This is typically used for the walk-by or drive-by use cases.

    Accordingly, if the same uplink packet is received through both permanent and temporary base stations, the reception through the temporary BS does not impact ADR decisions and this temporary BS is not eligible for routing of DL traffic.

    Otherwise, if the uplink packet is received only through the temporary BS, the device is assumed to be out-of-coverage of the permanent base stations; hence, the network triggers the RF recovery mode for this device, to boost its SF/TxPower and number of repetitions. This BS may be used to route downlink packets for class A devices only, since there is no guarantee that this moving BS will remain within the device's vicinity in class B/C modes.

  • Temporary and stationary: the base station has a static location for a period of several days, up to a few weeks, but it does not provide permanent RF coverage. This is typically the case of seasonal gateways deployed to temporarily boost the RF coverage/capacity during specific events. The same UL/DL processing described in "temporary and mobile" mode applies for this "temporary and stationary" mode, with the only difference that this BS may be used to route downlink packets for class B/C devices besides class A. Note that this BS must be switched to "temporary and moving" once it leaves its temporary location, to avoid losing DL class B/C packets.

  1. Select the base station you want to edit. You may search it by its name or ID.

  2. In the Advanced tab, under the Advanced settings widget, select the right setting for the RF Coverage Type field according to your use case.

Activating RX2 Optimization mechanism​

LoRaWAN® devices implement two downlink receive windows identified as RX1 and RX2. As per LoRaWAN specifications, when listening to RX1 slot, the end-device expects to receive a downlink signal using the same channel and Spreading Factor (if RX1DRoffset = 0) as the last uplink transmission. On RX2 slot, the end-device expects to receive a signal using a fixed configurable data rate on a preset channel frequency. The end-device will listen to RX2 slot if it has not received any downlink transmission on RX1, therefore the choice of using RX1 or RX2 is made by the network server.

ThingPark's RX2 Optimization mechanism optimizes the selection of the downlink reception slot.

When RX2 Optimization is not activated: DL transmission systematically uses RX1 slot, except in one of the following two cases:

  1. If, due to unexpected backhaul network latency, the downlink packet reached the LRR too late for RX1 slot but still in time for RX2, the LRR shall use RX2 slot.
  2. If the LRC network server forces the use of RX2 to comply with the downlink maximum payload size defined in LoRaWAN® Regional Parameters.

When RX2 Optimization algorithm is activated (default setting): The network server optimizes the choice of the RX slot according to the following criteria:

  • Link Budget criterion: Since RX2 channel can use higher TX Power than RX1 in EU868 ISM band, end-devices with limited link budget use RX2 slot in priority to secure reliable DL transmissions in bad coverage spots.

  • Data Rate criterion: When the device's performance is not limited by its link budget (that is to say, radio conditions are “fair enough” for RX1 use), the network server selects the RX slot that maximizes the downlink data rate (that is to say, lower SF) to reduce air-time and boost the DL capacity.

  • Maximum downlink MAC payload size: To comply with the maximum payload size imposed by LoRaWAN® Regional Parameters for each ISM band, the network server may force the use of RX2 slot if the applicative payload can only be sent over RX2, but not RX1.

    Example:

    • The applicative payload has 80 bytes and the regional profile is EU868.
    • The RX1 data rate is DR2 (SF10), the maximum allowed payload size for RX1 is 59 Bytes.
    • The RX2 data rate is DR3 (SF9), the maximum allowed payload size for RX2 is 123 Bytes.

    ==> RX2 is forced by the network server to send this downlink frame.

  • Backhaul latency: When the round-trip delay between the BS and the network server is high, the network server forces the use of RX2 channel to maximize the chances of sending the downlink frame within the device’s timing constraints.

    note

    In all cases, even if the network server requested RX1, the LRR packet forwarder shall switch to RX2 slot if the downlink transmission request arrives too late to the BS.

  1. Select the base station you want to edit. You may search it by its name or ID.

  2. In the Advanced tab, under the Advanced settings widget, switch on the RX2 Optimization switch to activate this mechanism on your base station.

Configuring the AES decryption key for TDoA geolocation​

To use Time Difference of Arrival (TDoA) techniques to geolocate LoRaWAN end-devices, you must fill the AES decryption key related to your base station. This key allows decrypting the fine timestamps generated by the BS so that they can be used by ThingPark's network geolocation solver.

This option is currently available only for base stations using Semtech's V2 reference design.

  1. Select the base station you want to edit. You may search it by its name or ID.

  2. In the Advanced tab, under the Advanced settings widget, set the Fine timestamp decryption key provided to you by Actility or Semtech.

  3. To confirm your choice, click , otherwise click to cancel.

Last updated on
Copyright © 2024 Actility
On this page