Gateway Selection

Choosing the right gateway (or gateways) is one of the most important decisions for a successful update. The goal is always the same: reach as many devices in the campaign as possible without overlapping radio coverage, which can cause on-air collisions. This guide covers both automatic gateway selection performed by the FUOTA server and how to select gateways manually when you need full control.

Before You Begin

You need:

• A device group and the DevEUIs you plan to update. See Quick Start Guide.
• The NodeID of any gateways you intend to specify manually. A NodeID is a unique gateway identifier printed on the back of any MachineQ gateway (for example 2CC4070000001234).
• $MQ_TOKEN exported from the authentication step. See Quick Start Guide.

Automatic Gateway Selection

Starting with API version v3.0, the FUOTA server automatically selects gateways based on the provided set of DevEUIs. The server chooses the best combination of gateways to cover as many devices as possible without overlapping coverage. If some devices are not reachable by any customer gateway, or coverage is poor, the server still includes them in the campaign. When the campaign restarts, the server automatically updates the gateway list based on the devices that did not update.

How to Use Automatic Selection

To enable automatic gateway selection, skip providing the gateways field when creating the device group.

If you already created a campaign whose device group specifies a list of gateways, you can force automatic selection by setting the gateways property to either null or an empty list when calling the restart API.

curl -sS -X POST "https://fuota.machineq.net/api/v3.2/campaigns/restart" \
  -H "Authorization: Bearer $MQ_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "campaign_id": "<campaign_id>",
    "gateways": null
  }' | jq

Unless explicitly changed, the server continues to respect the original selection on every restart:

• A campaign created or restarted with a device group that has a specific list of gateways will keep using those gateways on automatic restart and on a manual restart without the gateways property.
• A campaign created or restarted with a device group that has an empty gateway list will re-run automatic gateway selection on every restart.

Note: If you manually define the list of gateways using the gateways parameter, the server will not try selecting gateways, even on campaign restart.

Which devices are included in the picking process? Whenever the campaign restarts, the automatic gateway selection algorithm only looks at the failed devices. As the list of devices needing an update changes, the gateway selection might also change.

How Automatic Selection Works

The algorithm is tuned to maximize the number of devices most likely to update while avoiding gateway overlap during the multicast session, which reduces on-air collisions, repetitions, and out-of-order fragments. The process is:

1. Determine the list of gateways that all participating devices reach, regardless of connectivity quality.
2. Group all trivially overlapping gateways. A "trivial" overlap is when one gateway can fully cover another gateway's devices while maintaining good connectivity to all of them.
3. Perform a more complex assessment of overlap by analyzing device-to-gateway connectivity quality, finding the combination of gateways with the most non-overlapping device coverage. A small overlap is allowed only if it increases the non-overlapping device count.

Overlapping vs. non-overlapping devices: An "overlapping device" reaches multiple gateways at the same time; the gateways it connects to have overlapping coverage. A "non-overlapping device" is connected to only one gateway.

Using RSSI and the number of uplinks: The server looks at both the average RSSI and the number of uplinks for each gateway to determine which is more reliable. For example, if a device reached GW1 100 times with an average RSSI of -90 and GW2 only 5 times with RSSI -70, GW1 is the better option because it reliably hears the device even though its RSSI is slightly lower.

Selection Examples

The following scenarios illustrate how the algorithm chooses gateways.

Case 1: Full Overlap

In the first scenario, all four devices have roughly the same connectivity quality for both gateways. In the second, two devices have much better connectivity to GW1 while their connectivity to GW2 is still acceptable, so picking GW2 would still cover all four devices. In both cases the server analyzes the combined connectivity of both gateways and picks the one with better connectivity to all devices combined, scored by RSSI and number of uplinks.

Picked gateways: GW1/GW2 (based on the combined connectivity score).

Case 2: Overlapping and Non-Overlapping Coverage

Some gateways have simple overlapping coverage while others have none. The server picks between GW1 and GW2 based on the combined connectivity quality for the three shared devices, then also includes GW3 because it has no overlap.

Picked gateways: GW1/GW2 (based on the combined connectivity score) and GW3.

Case 3: Small Overlap

GW1 and GW2 each have two devices that do not overlap with other gateways. Device #5 overlaps between all three gateways and has better connectivity to GW3. The server selects GW1 and GW2 because that results in four non-overlapping devices; Device #5 may or may not update, but the other four update fine.

Picked gateways: GW1 and GW2.

Case 4: One Device, Many Gateways

With many gateways and one device, GW3 has better connectivity than GW1 or GW2, so the server picks GW3.

Picked gateways: GW3.

Case 5: Complex Overlap 1

A more complex scenario with more overlapping devices. Although GW2 has the best connectivity to devices 3 through 8, choosing GW2 alone would guarantee that four other devices are never updated. To maximize the number of devices updated in a single campaign, the server selects GW1 and GW2, giving four non-overlapping devices and up to four overlapping devices a chance to update. Two overlapping gateways have, in practice, led to a reasonable success rate.

Picked gateways: GW1 and GW2.

Case 6: Complex Overlap 2

Similar to the previous case, but GW3 now has three non-overlapping devices and one additional overlapping device, while GW1 keeps better connectivity to devices 3 and 4. Picking GW1 and GW3 covers every device — ten non-overlapping and two overlapping.

Picked gateways: GW1 and GW3.

Case 7: Chained Overlap

Multiple gateways form a chain of overlap. The server first resolves the simple overlaps, selecting the gateway with better connectivity for each shared pair of devices, then discards redundant gateways to avoid overlap. This can leave, for example, only GW2 and GW4 selected with no overlapping devices.

Picked gateways: GW2 and GW4.

Case 8: High Overlap Count

GW1 and GW2 have four overlapping devices and one non-overlapping device each. Selecting both would yield only two non-overlapping devices and four overlapping. Because overlapping devices have a lower chance of success, the server maximizes the non-overlapping count and picks only one gateway based on the combined connectivity quality, resulting in five non-overlapping devices.

Picked gateways: GW1/GW2 (based on the combined connectivity score).

Manual Gateway Selection

When selecting a gateway manually, choose one within reach of all the devices. If a device is within reach of two or more gateways at the same time, select the gateway with better coverage for all or most devices. For example, if you have a group of devices at your house, choose the gateway located at your house. If you are updating all the devices at a commercial location such as a store, use the gateway located at the store.

You can run the FUOTA update in multiple locations using multiple gateways. For example, update your home devices with your home gateway and warehouse devices with the warehouse gateway. However, if two gateways are near each other, they could cause an on-air collision because they advertise the update simultaneously.

Warning: Gateways must not overlap in radio coverage. If two gateways within a device group overlap, the resulting radio interference can increase the failure rate of updates. The Network Server applies a short delay (1 second) between each gateway, but this does not guarantee there will be no on-air collision.

Using Multiple Gateways Within the Device Group

The device group can have between two and ten (2 to 10) gateway NodeIDs. During the fragmentation session, each NodeID sends the same FragmentedData packet with roughly a 1-second delay.

Geographically Separated Gateways

If gateways' radio spectrum does not overlap, they can be considered geographically separated. Separating gateways allows running a single campaign for multiple sites simultaneously with no need to change the campaign setup.

Gateways at the Same Location

Because the FUOTA server is unaware of the gateways' geographical location, we recommend increasing the inter-fragment delay. The create campaign API accepts a frag_send_delay parameter. If you have two or more gateways in the device group, set frag_send_delay to 1.5 * {gateway count}. For example, with two gateways the frag_send_delay would be 3 seconds.

Note: Increasing frag_send_delay may decrease battery life. A longer delay means a longer fragmentation session, which keeps the device in class C mode longer. For battery-powered devices, this reduces battery life. Reducing frag_send_delay below 1.5 is not recommended.

What's Next?

• Choosing Multicast Setup Time: Pick the right session setup time for your devices.
• Multicast Session Overlap Avoidance: Understand how the server prevents overlapping sessions on the same gateway.
• Upgrade Delegation: Let another subscriber manage upgrades on your devices and gateways.