2. Overview of the functionality

Endpoints working in SubG-FSK mode shall be synchronized with a gateway before an uplink or downlink transmission is performed. The synchronization mechanism uses periodic frames sent by gateways, namely Beacon frames. This process can be divided into three phases, each controlled by the Gateway Discovery and Selection feature.

Table 2.1: Gateway Discovery phases.

The following sections describe the parameters and algorithms that are used in each of the three phases.

2.1 Gateway Discovery parameters

The following table describes the parameters for gateway discovery.

Table 2.2: Parameters for gateway discovery.

2.1.1 Discovery algorithm

The gateway discovery is performed according to the following algorithm:

1. The Scanning timeout in seconds parameter determines the total time of the SubG-FSK discovery process that the Endpoint will perform.
2. During the discovery process, the Endpoint adds to the discovery list all gateways it can connect to.
3. During the discovery process, the Endpoint performs active scanning during the time intervals specified in the Scanning back off parameter. See section 2.1.2 for details.
4. If after the discovery process is completed there are found gateways in the list, then control passes to the Gateway Selection algorithm.
5. If after the discovery process is completed there are no gateways to connect to in the list, the developer is notified of the discovery failure status via the on_control_event_notify callback. See Chapter 4 Gateway discovery control events for details.
6. The decision to scan even after Scanning timeout in seconds has expired and the developer notified of the status of discovery failure is determined by the setting Continue scanning after fail.
7. If the gateway was not selected or the connection to the gateway did not occur, the next discovery iteration will be performed according to the intervals specified in the Scanning back off parameter.

2.1.2 Scanning back off

In the case of an unsuccessful Gateway Discovery, when no gateway was selected, the MCU SDK library uses timeout intervals to resume scanning (back off). The duration of the interval depends on the number of unsuccessful discovery iterations.

The default back-off for Amazon Sidewalk MCU SDK has the following timeout intervals:

Table 2.3: Default back off intervals.

If the gateway is not found, the Endpoint operates as follows:

1. For iteration from 1 to 5, the Endpoint performs an active scanning for 40 seconds and then stops scanning for 60 seconds between every iteration.
2. For iteration from 6 to 15, the Endpoint performs an active scanning for 40 seconds and then stops scanning for 300 seconds between every iteration.
3. For iteration 16 and greater, the Endpoint performs an active scanning for 40 seconds, then stops scanning for 3600 seconds between every iteration.

The iteration counter is reset every time after a successful connection to the gateway or if the SubG-FSK link is restarted.

2.2 Gateway Selection parameters

After the gateway discovery process is complete, the gateway selection algorithm determines the best gateway to be selected based on the list of the gateways discovered during the gateway discovery phase. The selection of the best gateway is based on the information obtained from the beacons.

The following table describes the parameters for gateway selection.

Table 2.4: Parameters for gateway selection.

2.2.1 Gateway Load Indicator

Load Indicator is a complex characteristic that shows the level of gateway load. Load Indicator is transmitted in the corresponding field in the beacon and can be from 0 to 3. Value 0 means low gateway load, value 3 means high load.

Load Indicator is calculated on the gateway side and includes such factors as current throughput, number of connected EPs, CPU utilization, RAM utilization, etc. The calculation mechanism is platform-dependent and is not included in the scope of this document.

The developer can use this parameter to score the gateway when selecting and for Gateway Connection Health Monitoring.

2.2.2 Cloud Connection Health

With Cloud Connection Health, the gateways pass additional information to the Endpoints about the status of the connection to the cloud. By passing this value through a beacon, Endpoints are able to select a more reliable gateway.

There are the following values of the Cloud Connection Health:

Table 2.5: Cloud Connection Health.

During the Discovery process, only gateways with Cloud Connection Health of ‘1’ or ‘3’ are considered.

2.2.3 Transmit Power Rank

The beacon payload has a field that indicates the effective isotropic maximum radiated power of the Gateway used for the current Beacon round. Using this value and the RSSI level of the received beacon, the Endpoint can estimate how close the gateway is and determine how much power is required to transmit a message to one gateway relative to another. Depending on the received EIRP and RSSI values, each gateway is assigned an evaluation characteristic called Transmit Power Rank, which can be used to score the gateway.

The table below shows the possible Transmit Power Rank values and their meaning.

Table 2.6: Transmit Power Rank.

A higher Transmit Power Rank means that the gateway is further from the EP and more energy is needed for transmission.

2.2.4 Gateway Score Calculation

The Gateway scoring is used to determine the best Gateway to select for connection. This scoring is based on the received data from the beacon and the specified Gateway Selection parameters. Depending on the value of the criterion, a Weight (from 0 to 5) is used to calculate score points.

The table below shows the parameters for score calculation and their Weights.

Table 2.7: Parameters for gateway score calculation.

Below is an example of calculating gateway score using the following Gateway Selection parameters:

• Minimum RSSI to connect = -90
• Use Gateway Load Indicator = True
• Use Gateway Connection Health = True
• Use Transmit Power Rank = True

Sample discovered gateway list that has three gateways and their parameters. In the below sample, Gateway #1 with total score 14 will be selected for connection.

Table 2.8: Gateway score calculation example.

2.2.5 Gateway Selection Algorithm

The gateway selection is performed according to the following algorithm:

1. From the list of discovered gateways, those gateways to which a connection is possible are considered.
2. If there is more than one gateway to connect to in the list, the score of each gateway is calculated to determine the best one.
3. The score is calculated by adding the weights of the parameters mentioned in the above table.
4. Depending on policy settings, certain parameters may not be considered when calculating the score.
5. If no gateway is found that satisfies the selection criteria, the developer is notified using the control event notify callback on_control_event_notify.
6. If a gateway is selected for connection, the EP enters beacon synchronization mode with the selected gateway. In this case, the developer will be notified with the corresponding event using on_control_event_notify.
7. After connecting the EP to the gateway, the control moves to the Connection Health Monitoring phase.

2.3 Gateway Connection Health Monitoring

After connecting to a gateway, the Endpoint enters the connection health monitoring phase. During this phase, the Endpoint monitors key gateway parameters to determine if the gateway is still suitable for maintaining the connection.

The following table describes the parameters for Gateway Connection Health Monitoring.

Table 2.9: Parameters for connection health monitoring.

2.3.1 Monitoring Algorithm

The Gateway Connection Health Monitoring is based on information from the connected gateway beacons. For a more detailed description of the beacon format and available fields, see the document Amazon Sidewalk Specification, Section 5.1.3.1 Beacon Frame format.

The Gateway Connection Health Monitoring is performed according to the following algorithm:

1. The Endpoint monitors the beacons of the connected gateway and analyzes the values of its internal fields.
2. If the Endpoint is connected to a WAN gateway, then the roam_opt flag from the Beacon Connection Status field is analyzed. If the roam_opt field is 0, the Endpoint disconnects from the gateway and notifies the developer via the on_control_event_notify callback and starts a new discovery process immediately.
3. If the Cloud Connection Health value is 2 (cloud_conn field), the Endpoint disconnects from the gateway and notifies the developer and starts the discovery process immediately.
4. The number of consecutive beacons from the connected gateway that are missed are tracked to determine whether the EP is still connected to the gateway. If the number is greater than or equal to Maximum missed beacons, the EP switches from the connected state to gateway discovery state. The status of link connection status as disconnected is also notified to the developer’s application through the on_status_changed callback.
5. If the average RSSI level of the received beacons is below the specified Threshold RSSI to disconnect, the Endpoint triggers disconnection from the connected gateway and starts a new discovery process. The number of messages for calculating the average RSSI is specified in the Number of messages for threshold RSSI parameter.

2.4 Gateway Discovery and Selection policies

The Gateway Discovery and Selection feature can be enabled at build time by setting the build flag SID_SDK_INTERNAL_CONFIG_ENABLE_GW_SELECTION.

The Amazon Sidewalk stack is required to be initialized using sid_init before setting the gateway discovery policy using sid_option. The gateway discovery policy can be configured successfully only if the sid_init function was called using the link_mask parameter with the flag SID_LINK_TYPE_2 (FSK).

The Gateway Discovery and Selection policy does not persist within the stack across reboots. The developer is expected to set the preferred gateway discovery policy on every reboot of the device.

There are several predefined discovery policies that are optimized for different scenarios, as well as a custom policy, the parameters of which can be configured by the developer depending on the needs.

The following enumeration shows the policies that are available to the developer to configure the gateway discovery policy.

/**
 * Describes the gateway discovery policy modes for FSK
 */
enum sid_link_type_2_gw_discovery_policy {
    /** Default policy applied. The GW discovery behavior
     *  is same as 1.16 SDK release which is to connect to
     *  the first beacon which has opt-in flag set to true
     */
    SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_DEFAULT = 0,
    /** Policy optimized for latency to establish a connection,
     *  and therefore choose the first-one that is available.
     */
    SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_OPTIMIZED_FOR_FAST_CONNECTION = 1,
    /** Policy optimized for highest reliability to establish a connection,
     *  the gateway with the best RSSI and healthy connection is selected.
     */
    SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_OPTIMIZED_FOR_RELIABLE_CONNECTION = 2,
    /** Policy optimized for minimum power consumption. */
    SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_OPTIMIZED_FOR_POWER_SAVE = 3,
    /** Policy for implementing a custom user scenario */
    SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_CUSTOM = 4,
    /** Delimiter to enum sid_link_type_2_gw_discovery_policy */
    SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_LAST,
};

The developer can change the discovery policy at any time after the Sidewalk stack has been initialized, even if the Endpoint is already connected to the gateway.

If the developer has started the stack by the sid_start function, then changing the policy will cause all timeouts to be reset and the gateway discovery process to be restarted.

If the developer changes the discovery policy for an Endpoint that is connected to the gateway, the EP will remain connected, and only the monitoring parameters will be changed according to the new policy.

There are four discovery policies with predefined parameters and the SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_CUSTOM policy that allows the developer to use their own parameters.

The following sections describe each policy, its parameters, and behavior.

2.4.1 Default Policy

Gateway Discovery and Selection policy: SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_DEFAULT

Description: This policy is the default behavior of the Gateway Discovery algorithm. The first gateway to which the EP can be connected is selected. The connection time will depend on how long it takes for the first beacon to be received by the EP. This algorithm is fully compatible with previous versions of Sidewalk MCU SDK and is used by default.

Gateway discovery parameters

Scanning back off:

Gateway selection parameters: Not applicable to default policy.

Connection health monitoring

Table 2.10: Parameters for default policy.

2.4.2 Optimized for Fast Connection Policy

Gateway Discovery and Selection policy: SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_OPTIMIZED_FOR_FAST_CONNECTION

Description: The policy optimized for latency to establish a connection. The developer is notified on the discovery status faster than other policies. The connection time under this policy is a minimum of 30 seconds as the EP spends 30 seconds scanning before moving to the selection phase.

This policy performs discovery for 30 seconds before proceeding to the selection of the gateway from the discovered list and the developer is notified within 30 seconds if no gateway is found that matches the selection criteria. This policy continues to scan and follow scanning back-off until the developer changes the policy or stops the SubG-FSK link.

Gateway discovery parameters

Scanning back off:

Gateway selection parameters

Connection health monitoring

Table 2.11: Parameters for optimized for fast connection policy.

2.4.3 Optimized for Reliable Connection Policy

Gateway Discovery and Selection policy: SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_OPTIMIZED_FOR_RELIABLE_CONNECTION

Description: This policy prioritizes reliable delivery of messages in both uplink and downlink. It is recommended to configure this policy when there is a requirement for the EP to perform high throughput traffic. The connection time under this policy is at least 90 seconds as the EP spends 90 seconds scanning before moving to the selection phase.

This policy performs discovery for 90 seconds before proceeding to the selection of the gateway from the discovered list and the developer is notified within 90 seconds if no gateway is found that matches the selection criteria. This policy continues to scan and follow scanning back-off until the developer changes the policy or stops the SubG-FSK link.

Gateway discovery parameters

Scanning back off:

Gateway selection parameters

Connection health monitoring

Table 2.12: Parameters for optimized for reliable connection policy.

2.4.4 Optimized for Power Save Policy

Gateway Discovery and Selection policy: SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_OPTIMIZED_FOR_POWER_SAVE

Description: This policy is optimized for power consumption and recommended to be used when there is less or infrequent data to be transferred or received.

The policy performs discovery according to the intervals specified in the scanning back-off parameter, i.e. 30 seconds of active scanning alternates with 120 seconds of sleep. After the total scanning time is 120 seconds, the EP enters the phase of selecting a gateway from the discovered list. Taking into account the scanning time and the sleep time, the connection time under this policy is a minimum of 480 seconds as the EP spends 120 seconds scanning before moving to the selection phase. The developer is notified by the on_control_event_notify() callback if no gateway is found that matches the selection criteria. This policy continues to scan and follow scan back-off until the developer changes the policy or stops the SubG-FSK link.

Gateway discovery parameters

Scanning back off:

Gateway selection parameters

Connection health monitoring

Table 2.13: Parameters for optimized for power save policy.

2.4.5 Custom Policy

Gateway Discovery and Selection policy: SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_CUSTOM

Description: This policy allows the developer to set custom parameters. Using this policy, the developer can set some parameters to control the Gateway Discovery and Selection process. The connection time under this policy depends on the value specified by the developer.

The developer can optimize the parameters of this policy according to the application requirements. If no gateway was discovered with the given parameters, the developer can change the selection criteria before the next discovery cycle.

Gateway discovery parameters

Scanning back off:

Gateway selection parameters

Connection health monitoring

Table 2.14: Parameters for custom policy.

2.4.6 Using the sid_option API to manage policies

The following data structures are used to manage Gateway Discovery and Selection policies and their parameters.

/** Defines the necessary constants for GW discovery */
enum sid_link_type_2_gw_discovery_defines {
    SID_LINK_TYPE_2_GWD_BACKOFF_ARRAY_MAX_SIZE = 4,
};

/** Describes parameters for gateway discovery backoff intervals */
struct sid_link_type_2_gw_discovery_backoff_params {
    /** Number of elements in the backoff table */
    uint8_t retry_arr_size;
    /** Retry threshold for transition to the next intervals */
    uint8_t retry_threshold[SID_LINK_TYPE_2_GWD_BACKOFF_ARRAY_MAX_SIZE];
    /** Scan duration in seconds */
    uint16_t retry_scan_duration_s[SID_LINK_TYPE_2_GWD_BACKOFF_ARRAY_MAX_SIZE];
    /** Sleep time in seconds between scanning */
    uint16_t retry_sleep_time_s[SID_LINK_TYPE_2_GWD_BACKOFF_ARRAY_MAX_SIZE];
};

/**
 * Describes parameters for the custom gateway discovery policy
 */
struct sid_link_type_2_gw_discovery_custom_policy_params {
    /** Gateway discovery scanning timeout in seconds */
    uint16_t scan_timeout_secs;
    /** Continue to scan even after scan_timeout_secs has expired */
    bool continue_scanning_after_fail;
    /** Gateway discovery backoff parameters.
     *  Set this parameter to NULL to use default values.
     */
    struct sid_link_type_2_gw_discovery_backoff_params *backoff_params;
    /** Minimum RSSI level at which connection is allowed.
     *  Zero means the parameter is not used
     */
    int8_t min_rssi_to_connect;
    /** RSSI level at which EP initiates disconnection from
     *  the connected gateway. Should be less than min_rssi_to_connect
     */
    int8_t threshold_rssi_to_disconnect;
    /** Number of beacons to calculate the average RSSI level
     *  for threshold_rssi_to_disconnect.
     *  Zero means the parameter is not used
     */
    int8_t threshold_rssi_msg_num;
    /** The maximum number of consecutive beacons that can be missed
     *  before the EP notifies disconnection.
     */
    uint8_t max_beacon_miss;
    /** The maximum number of beacons the EP can skip listening */
    uint8_t max_beacon_skip;
    /** Use gateway load to calculate gw score */
    bool use_gateway_load_for_selection;
    /** Gateway load at which EP initiates disconnection from the
     *  connected gateway. The range is [0,3].
     *  Zero means the parameter is not used
     */
    uint8_t gateway_load_to_disconnect;
    /** Use gateway connection health to calculate gw score */
    bool use_gateway_connection_health_for_selection;
    /** Use gateway transmit power rank to calculate gw score */
    bool use_gateway_tx_power_rank_for_selection;
};

/**
 * The structure used to configure the gateway discovery policy
 */
struct sid_link_type_2_gw_discovery_policy_config {
    /** Gateway discovery policy */
    enum sid_link_type_2_gw_discovery_policy policy;
    /** Parameters for the custom gateway discovery policy */
    struct sid_link_type_2_gw_discovery_custom_policy_params *policy_params;
    /** True: Set policy config, False: Get policy config */
    bool is_set;
};

The sid_link_type_2_gw_discovery_policy_config structure is used to configure the discovery policy. To set a predefined policy, it is enough to specify the desired policy. The parameters of predefined policies are applied inside the Amazon Sidewalk stack and therefore do not need to be specified. Also, the developer can get the current policy at any time.

Below is an example of code for setting/getting a predefined discovery policy.

// Examples of IOCTL to set/get gateway discovery and selection policy

// Set gateway discovery and selection policy to
// SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_OPTIMIZED_FOR_FAST_CONNECTION
struct sid_link_type_2_gw_discovery_policy_config policy = {
    .is_set = true,
    .policy = SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_OPTIMIZED_FOR_FAST_CONNECTION,
};
sid_error_t ret = sid_option(handle,
                             SID_OPTION_LINK_TYPE_2_GW_DISCOVERY_POLICY,
                             &policy, sizeof(policy));

// Get current gateway discovery and selection policy
struct sid_link_type_2_gw_discovery_policy_config policy = {
    .is_set = false,
};
sid_error_t ret = sid_option(handle,
                             SID_OPTION_LINK_TYPE_2_GW_DISCOVERY_POLICY,
                             &policy, sizeof(policy));

To use the SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_CUSTOM policy, the developer must provide the parameters using the sid_link_type_2_gw_discovery_custom_policy_params structure.

To use the default Scanning back off intervals, the backoff_params parameter must be set to NULL. If the developer wants to override the default Scanning back off interval values, a filled sid_link_type_2_gw_discovery_backoff_params structure must be passed.

The following sections contain several examples of configuring a custom discovery policy using the API.

Custom policy example 1

Custom policy conditions

This example shows the use of a custom policy with default scanning back off intervals and the use of all possible parameters for gateway selection and further monitoring of the connected gateway’s health. The gateway will be selected after 30 seconds of scanning. In case of failure, the developer will be notified via the on_control_event_notify() callback and the scanning process will continue after the appropriate sleep interval.

Gateway discovery parameters:

Scanning back off:

Gateway selection parameters:

Connection health monitoring:

Implementation

// Set parameters for the custom gateway discovery policy
struct sid_link_type_2_gw_discovery_custom_policy_params policy_params = {
    .scan_timeout_secs = 30,
    // set NULL to use default scanning back off intervals
    .backoff_params = NULL,
    .continue_scanning_after_fail = true,
    .min_rssi_to_connect = -90,
    .use_gateway_load_for_selection = true,
    .use_gateway_connection_health_for_selection = true,
    .use_gateway_tx_power_rank_for_selection = true,
    .threshold_rssi_to_disconnect = -100,
    .threshold_rssi_msg_num = 3,
    .max_beacon_miss = 3,
    .max_beacon_skip = 0,
    .gateway_load_to_disconnect = 3,
};

// Preparing the structure to configure the gateway discovery policy
struct sid_link_type_2_gw_discovery_policy_config policy_config = {
    .policy = SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_CUSTOM,
    .policy_params = &policy_params,
    .is_set = true,
};

// IOCTL to set gateway discovery policy
sid_error_t ret = sid_option(*cli_cfg.app_cxt->sidewalk_handle,
                             SID_OPTION_LINK_TYPE_2_GW_DISCOVERY_POLICY,
                             &policy_config, sizeof(policy_config));

Table 2.15: Custom policy example 1.

Custom policy example 2

Custom policy conditions

This example shows the use of a policy with custom scanning back off intervals. The gateway will be selected after 60 seconds of scanning. The gateway is selected only by the signal level without restrictions on the minimum RSSI. Disconnection from the selected gateway will be performed only when the beacon sync is lost.

In case of failure, the developer will be notified via the on_control_event_notify() callback and the scanning process will continue after the appropriate sleep interval.

Gateway discovery parameters:

Scanning back off:

Gateway selection parameters:

Connection health monitoring:

Implementation

// Set parameters for gateway discovery back off intervals
struct sid_link_type_2_gw_discovery_backoff_params backoff_params = {
    .retry_arr_size = 4,
    .retry_threshold = {10, 20, 30, 255},  // the value 255 means infinite
    .retry_scan_duration_s = {60, 60, 60, 60},
    .retry_sleep_time_s = {60, 120, 240, 480},
};

// Set parameters for the custom gateway discovery policy
struct sid_link_type_2_gw_discovery_custom_policy_params policy_params = {
    .scan_timeout_secs = 60,
    .backoff_params = &backoff_params,
    .continue_scanning_after_fail = true,
    // set the value to 0 to disable the parameter
    .min_rssi_to_connect = 0,
    .use_gateway_load_for_selection = false,
    .use_gateway_connection_health_for_selection = false,
    .use_gateway_tx_power_rank_for_selection = true,
    // set the value to 0 to disable the parameter
    .threshold_rssi_to_disconnect = 0,
    .threshold_rssi_msg_num = 0,
    .max_beacon_miss = 3,
    .max_beacon_skip = 0,
    // set the value to 0 to disable the parameter
    .gateway_load_to_disconnect = 0,
};

// Preparing the structure to configure the gateway discovery policy
struct sid_link_type_2_gw_discovery_policy_config policy_config = {
    .policy = SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_CUSTOM,
    .policy_params = &policy_params,
    .is_set = true,
};

// IOCTL to set gateway discovery policy
sid_error_t ret = sid_option(*cli_cfg.app_cxt->sidewalk_handle,
                             SID_OPTION_LINK_TYPE_2_GW_DISCOVERY_POLICY,
                             &policy_config, sizeof(policy_config));

Table 2.16: Custom policy example 2.

Custom policy example 3

Custom policy conditions

This example shows the use of a policy with custom scanning back off intervals. The gateway will be selected after two 20-second scan iterations, with a 20-second sleep interval between them. In total, the first gateway selection will be made after 60 seconds. If the gateway is not selected, the developer will be notified via the on_control_event_notify() callback and the discovery process will be stopped. In this case, to restart the discovery process, the developer must restart the link or select another policy.

Gateway discovery parameters:

Scanning back off:

Gateway selection parameters:

Connection health monitoring:

Implementation

// Set parameters for gateway discovery back off intervals
struct sid_link_type_2_gw_discovery_backoff_params backoff_params = {
    .retry_arr_size = 1,
    .retry_threshold = {255},  // the value 255 means infinite
    .retry_scan_duration_s = {20},
    .retry_sleep_time_s = {60},
};

// Set parameters for the custom gateway discovery policy
struct sid_link_type_2_gw_discovery_custom_policy_params policy_params = {
    .scan_timeout_secs = 20,
    .backoff_params = &backoff_params,
    .continue_scanning_after_fail = false,
    .min_rssi_to_connect = -85,
    .use_gateway_load_for_selection = true,
    .use_gateway_connection_health_for_selection = true,
    .use_gateway_tx_power_rank_for_selection = true,
    .threshold_rssi_to_disconnect = -95,
    .threshold_rssi_msg_num = 5,
    .max_beacon_miss = 4,
    .max_beacon_skip = 0,
    // set the value to 0 to disable the parameter
    .gateway_load_to_disconnect = 0,
};

// Preparing the structure to configure the gateway discovery policy
struct sid_link_type_2_gw_discovery_policy_config policy_config = {
    .policy = SID_LINK_TYPE_2_GW_DISCOVERY_POLICY_CUSTOM,
    .policy_params = &policy_params,
    .is_set = true,
};

// IOCTL to set gateway discovery policy
sid_error_t ret = sid_option(*cli_cfg.app_cxt->sidewalk_handle,
                             SID_OPTION_LINK_TYPE_2_GW_DISCOVERY_POLICY,
                             &policy_config, sizeof(policy_config));

Table 2.17: Custom policy example 3.