{"0": { "doc": "Qualified development kits", "title": "Nordic Semiconductor", "content": ". | Navigate to the Nordic Sidewalk Landing Page for everything you need to get started | Buy the Nordic nRF54L15 DK or Nordic nRF52840 DK development kit | Buy the Semtech SX1262MB2CAS or the Semtech LR1110MB1LCKS evaluation board | Download the Nordic Connect Software Development Kit for Sidewalk | For the LR111x family, refer to the driver plugin from Semtech | . ", "url": "/getting-started/Qualified-Development-Kits.html", "relUrl": "/getting-started/Qualified-Development-Kits.html" },"1": { "doc": "Qualified development kits", "title": "Semtech", "content": ". | Navigate to the Semtech Sidewalk Landing Page the full IC selection guide, development kits, and SDK integration resources | Purchase links for the Semtech SX1262MB2CAS or the Semtech LR1110MB1LCKS shields | Semtech shields pair with the Nordic nRF54L15 DK, Silicon Labs KG100S Pro Kit, and STM32WBA55CG — see the full kit compatibility matrix here | . ", "url": "/getting-started/Qualified-Development-Kits.html", "relUrl": "/getting-started/Qualified-Development-Kits.html" },"2": { "doc": "Qualified development kits", "title": "Silicon Laboratories", "content": ". | Navigate to the Silicon Labs Sidewalk Landing Page for everything you need to get started | Buy the Silabs Pro Kit For Sidewalk development kit | Download the Silicon Labs Gecko Software Development Kit plugin for Sidewalk | Start your Developer Journey | Review the Developer Documentation | . ", "url": "/getting-started/Qualified-Development-Kits.html", "relUrl": "/getting-started/Qualified-Development-Kits.html" },"3": { "doc": "Qualified development kits", "title": "ST Micro", "content": ". | Navigate to the ST Micro Sidewalk Landing Page for everything you need to get started | Download the STM32-Sidewalk-SDK software | . ", "url": "/getting-started/Qualified-Development-Kits.html", "relUrl": "/getting-started/Qualified-Development-Kits.html" },"4": { "doc": "Qualified development kits", "title": "Telink Semiconductor", "content": ". | Navigate to the Telink Sidewalk Landing Page for everything you need to get started | Download the Telink Sidewalk SDK | . ", "url": "/getting-started/Qualified-Development-Kits.html", "relUrl": "/getting-started/Qualified-Development-Kits.html" },"5": { "doc": "Qualified development kits", "title": "Texas Instruments", "content": ". | Navigate to the TI Sidewalk Landing Page for everything you need to get started | Buy the TI LaunchXL CC1352P7-1 Launchpad development kit | Download the Texas Instruments SimpleLink Software | . ", "url": "/getting-started/Qualified-Development-Kits.html", "relUrl": "/getting-started/Qualified-Development-Kits.html" },"6": { "doc": "Qualified development kits", "title": "Quectel", "content": ". | Buy the Pro Kit for Sidewalk that incorporates the Quectel KG100S module | Download the Software Development Kit | . ", "url": "/getting-started/Qualified-Development-Kits.html", "relUrl": "/getting-started/Qualified-Development-Kits.html" },"7": { "doc": "Qualified development kits", "title": "Qualified development kits", "content": "Getting Started With Silicon Partners . Choose from one or more silicon partners below. ", "url": "/getting-started/Qualified-Development-Kits.html", "relUrl": "/getting-started/Qualified-Development-Kits.html" },"8": { "doc": "3. Amazon Sidewalk APIs", "title": "3. Amazon Sidewalk APIs", "content": "Amazon Sidewalk provides APIs for the developer’s application to configure, control and use the services of the Amazon Sidewalk stack on an Endpoint. For the list of error codes and their values see 5. API Reference . | sid_platform_init() | sid_platform_deinit() | sid_init() | sid_deinit() | sid_start() | sid_stop() | sid_process() | sid_put_msg() | sid_get_error() | sid_get_mtu() | sid_option() | sid_set_factory_reset() | sid_ble_connection_request() | sid_set_msg_dest_id() | sid_get_status() | sid_get_time() | sid_set_time() | sid_bulk_data_transfer_init() | sid_bulk_data_transfer_deinit() | sid_bulk_data_transfer_release_buffer() | sid_bulk_data_transfer_finalize() | sid_bulk_data_transfer_cancel() | sid_bulk_data_transfer_get_stats() | sid_location_init() | sid_location_deinit() | sid_location_run() | sid_location_set_max_mode() | sid_location_get_effort_mode() | sid_location_update_almanac() | sid_serial_registration_init() | sid_serial_registration_start() | sid_serial_registration_process() | sid_serial_registration_deinit() | sid_device_information_init() | sid_device_information_deinit() | sid_device_information_is_region_registerable() | . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html" },"9": { "doc": "3. Amazon Sidewalk APIs", "title": "3.1 sid_platform_init", "content": "sid_platform_init initializes the platform specific components. These are platform abstraction Layer(PAL) routines that are required by the Sidewalk stack . The sid_platform_init is the first API that is required to be invoked before invoking any other Sidewalk API. The sid_platform_init invocation can be avoided if the each PAL component’s initialization routine is explicitly invoked in the developer’s application prior to calling the sid_init API. The sid_platform_init API accepts a pointer to the platform specific data. Invoking sid_platform_init API multiple times without invocation of sid_platform_deinit would not re-initialize the PALs but would return SID_ERROR_NONE . SID_ERROR_INCOMPATIBLE_PARAMS is returned if the argument passed is invalid for a specific PAL initialization’s implementation. SID_ERROR_NO_SUPPORT is returned if a specific PAL is not supported by the platform. SID_ERROR_GENERIC is returned if the error code is specific to a PAL implementation. SID_ERROR_NONE is returned if the PALs are initialized successfully when sid_platform_init is invoked or PALs are already initialized before the invocation of sid_platform_init. On a platform built with a sub-GHz link (SID_SDK_CONFIG_ENABLE_LINK_TYPE_2 or SID_SDK_CONFIG_ENABLE_LINK_TYPE_3), platform_init_parameters also selects the region the sub-GHz radio operates in. This sets the band, spreading factor, transmit power and channel-access rules: . | region (sid_reg_region_code_t): SID_PAL_RADIO_RC_NA (1), SID_PAL_RADIO_RC_EU (2), SID_PAL_RADIO_RC_JP (3) or SID_PAL_RADIO_RC_ANZ (4). These values are numerically equal to the corresponding enum sid_device_region values, see 2.16.1. | iso_country (const char *): the ISO 3166-1 alpha-2 code of the country the Endpoint operates in, for example \"US\". The string is copied during the call and may be NULL. | . On a REGION_LITE build, SID_ERROR_UNINITIALIZED is returned if region is SID_PAL_RADIO_RC_NONE (0) or a region the build does not include. A single-region build (REGION_US915 or REGION_EU868) ignores both fields and operates on its fixed region. Calling sid_platform_init again without sid_platform_deinit does not apply a new region. For how the radio region relates to the region the Endpoint reports, see 2.16.3. /** * Initializes the Sidewalk stack platform specific parameters. * * sid_platform_init() shall only be called once before other Sidewalk * stack functions e.g. sid_init(). * * @param[in] platform_init_parameters The required configuration in order * to properly initialize platform specific * parameters * * @returns #SID_ERROR_NONE in case of success. */ sid_error_t sid_platform_init(const void *platform_init_parameters); platform_parameters_t platform_parameters = { .mfg_store_region.addr_start = 0x71000, .mfg_store_region.addr_end = 0x72000, .platform_init_parameters.radio_cfg = (radio_sx126x_device_config_t *)get_radio_cfg(), .platform_init_parameters.region = SID_PAL_RADIO_RC_NA, .platform_init_parameters.iso_country = \"US\", }; sid_error_t ret_code = sid_platform_init(&platform_parameters); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#31-sid_platform_init", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#31-sid_platform_init" },"10": { "doc": "3. Amazon Sidewalk APIs", "title": "3.2 sid_platform_deinit", "content": "sid_platform_deinit deinitializes the platform specific components. The sid_platform_deinit shall not be called before calling sid_deinit. The sid_platform_deinit invocation can be avoided if each PAL component’s deinitialization routine is explicitly invoked in the developer’s application after calling the sid_deinit API. Invoking sid_platform_deinit API multiple times without invocation of sid_platform_init would not deinitialize the PALs multiple times but returns SID_ERROR_NONE . SID_ERROR_GENERIC is returned if the error code is specific to a PAL implementation. SID_ERROR_NONE is returned if the PALs are deinitialized successfully when sid_platform_deinit is invoked or PALs are already deinitialized before the invocation of sid_platform_deinit. /** * Deinitializes the Sidewalk stack platform specific parameters. * * sid_platform_deinit() shall only be called once after * using of Sidewalk stack, i.e. after sid_deinit(). * * @returns #SID_ERROR_NONE in case of success. */ sid_error_t sid_platform_deinit(void); sid_error_t ret_code = sid_platform_deinit(); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#32-sid_platform_deinit", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#32-sid_platform_deinit" },"11": { "doc": "3. Amazon Sidewalk APIs", "title": "3.3 sid_init", "content": "The Amazon Sidewalk stack can be initialized using the sid_init API. The sid_init API accepts a pointer to the Amazon Sidewalk configuration see 2.11. The sid_init API returns a pointer to its internal handle. This handle needs to be passed to all other APIs. On initialization, the Amazon Sidewalk stack and the link specific initialization sequences are executed. On initialization, message buffers and other control structures are allocated however no radio activity occurs in this state. The config structure contains device capability information that is required to be populated for the Amazon Sidewalk stack to report the device capability to the Sidewalk cloud All features supported by the Amazon Sidewalk stack (such as FFS, Time Synchronization, Security, etc.) are available without requiring further feature-specific initialization. sid_init should not be called in the context of any sid_event_callbacks to avoid re-entrancy and recursion issues. sid_init does not trigger any notifications to the callbacks that the developer has registered with the Amazon Sidewalk stack. Re-initializing the Amazon Sidewalk stack without de-initializing causes the sid_init to fail with the API return error code SID_ERROR_ALREADY_INITIALIZED. The sid_init API returns error code SID_ERROR_INVALID_ARGS if any of the following conditions are met: . | Pointers to config and handle are NULL. | The FFS over FSK periodicity is configured with a value which is not in the valid range. | The keep-alive payload length in sub_ghz_link_config->ka_payload.len exceeds SID_KA_PAYLOAD_MAX_SIZE (19). See 2.9.10. | . Note that sub_ghz_link_config is optional. If link_mask includes SID_LINK_TYPE_2 (FSK) or SID_LINK_TYPE_3 (LoRa) and sub_ghz_link_config is NULL, sid_init does not return SID_ERROR_INVALID_ARGS: the Amazon Sidewalk stack applies its own default sub-GHz configuration, in which the LoRa link runs at the default data rate. sid_init does not validate the LoRa data rate requested through that structure, so a value the Amazon Sidewalk stack does not recognize, and a request the regulatory region does not permit, both select the default data rate without a return code and without a callback. See 2.11. Passing NULL is not identical to passing a structure. The SID_ERROR_NOSUPPORT conditions below apply in either case, with one exception: the Amazon Sidewalk stack evaluates the condition on FFS registration over FSK only when sub_ghz_link_config is supplied. On a build that is not one of the lite build variants of 2.15 and that disables FFS registration over FSK with a compilation flag, an unregistered Endpoint whose link_mask is SID_LINK_TYPE_2 therefore does not receive SID_ERROR_NOSUPPORT when sub_ghz_link_config is NULL. Supply a sub_ghz_link_config when the developer’s application needs that condition to be evaluated. The sid_init API returns error code SID_ERROR_NOSUPPORT if any of the following conditions are met: . | link_mask in the config structure has an unsupported combination of link types. The following list are unsupported combinations. Note for FSK and LoRa a device may have the capability to support both link types, but FSK and LoRa cannot be active at the same time. | SID_LINK_TYPE_3(LoRa) only, if the Endpoint is not registered yet with Amazon Sidewalk cloud and is not a factory-registered Endpoint on a build with SID_SDK_INTERNAL_CONFIG_IS_FACTORY_REGISTERED, see 2.15 | . | link_mask is configured to SID_LINK_TYPE_2 (FSK) only, and FFS registration over FSK is disabled either through run time config or through a compilation flag. Please note that FFS registration over FSK can be disabled if link_mask includes BLE. For instance link_mask configured to SID_LINK_TYPE_1 (BLE) and SID_LINK_TYPE_2 (FSK) can have FFS registration over FSK disabled. | link_mask is configured to SID_LINK_TYPE_2 (FSK) and SID_LINK_TYPE_2 (LoRa), the Sidewalk stack switches between the two links for every one minute until either one of the link is able to connect to Amazon Sidewalk cloud | link_mask is configured to SID_LINK_TYPE_3 (LoRa) only when the Endpoint is registered. In an unregistered state, the developer’s application should configure link_mask with atleast one link that supports registration, unless the Endpoint is factory-registered (2.3.4). | The Endpoint is neither registered nor factory-registered and the Amazon Sidewalk stack is a lite build variant (2.15). The lite variants have no over-the-air registration path, so sid_init fails instead of the Endpoint failing later. | . The sid_init API returns error code SID_ERROR_NONE when the Amazon Sidewalk stack initialization with the requested configuration is successful. /** * Initializes the Sidewalk library for the chosen link type. * * sid_init() can only be called once for the given sid_config.link_type * unless sid_deinit() is called first. * * @see sid_deinit * * @param[in] config The required configuration in order to properly * initialize Sidewalk for the chosen link type. * @param[out] handle A pointer where the opaque handle type will be * stored. `handle` is set to NULL on error. * * @returns #SID_ERROR_NONE on success. * @returns #SID_ERROR_ALREADY_INITIALIZED if Sidewalk was already initialized * for the given link type. */ sid_error_t sid_init(const struct sid_config *config, struct sid_handle **handle); // Initialize BLE and LoRa links struct sid_end_device_characteristics dev_ch = { .type = SID_END_DEVICE_TYPE_STATIC, .power_type = SID_END_DEVICE_POWERED_BY_BATTERY_AND_LINE_POWER, .qualification_id = 0x0001, }; // Initialize adaptive gcs sync intervals array, values are in hours static uint16_t sync_intervals_h[MAX_TIME_SYNC_INTERVALS] = {2, 4, 8, 12}; static struct sid_time_sync_config time_sync_config = { .adaptive_sync_intervals_h = sync_intervals_h, .num_intervals = sizeof(default_sync_intervals_h) / sizeof(default_sync_intervals_h[0]) }; struct sid_config config = { .link_mask = (SID_LINK_TYPE_1 | SID_LINK_TYPE_3), .dev_ch = dev_ch, .callbacks = &event_callbacks, .link_config = app_get_ble_config(), // update the BLE config .sub_ghz_link_config = app_get_sub_ghz_config(), // update sub GHz config .time_sync_config = &time_sync_config, }; static struct sid_handle *sidewalk_handle; sid_error_t ret = sid_init(config, &sid_handle); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#33-sid_init", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#33-sid_init" },"12": { "doc": "3. Amazon Sidewalk APIs", "title": "3.4 sid_deinit", "content": "The Amazon Sidewalk stack can be de-initialized using the sid_deinit API. The sid_deinit API requires the pointer to the internal handle that was provided to the developer’s application during initialization. The sid_deinit API stops the links that are initialized during sid_init by calling sid_stop. The time is reset to zero which means that when the Amazon Sidewalk stack is initialized with the sid_init again, the Amazon Sidewalk stack is required to acquire time synchronization again. There is no separate API required to de-initialize any features, calling the sid_deinit API causes all the routines that de-initialize features to be called. sid_deinit does not trigger any notifications to the callbacks that the developer has registered with the Amazon Sidewalk stack. sid_init can be called with a different or the same config after sid_deinit is called. sid_deinit should not be called in the context of any sid_deinit to avoid re-entrancy and recursion issues. The pointer to the internal handle that the developer’s application receives is set to NULL. | The sid_deinit API call returns SID_ERROR_INVALID_ARGS, if the handle passed is NULL. | The sid_deinit API call returns SID_ERROR_INVALID_STATE, if the Amazon Sidewalk stack is already de-initialized. | The sid_deinit API call return SID_ERROR_NONE, if the Amazon Sidewalk stack is successfully de-initialized. | . /** * De-initialize the portions of the Sidewalk library associated with the * given handle. * * @see sid_init * * @param[in] handle A pointer to the handle returned by sid_init() * * @returns #SID_ERROR_NONE in case of success */ sid_error_t sid_deinit(struct sid_handle *handle); sid_error_t ret = sid_deinit(handle); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#34-sid_deinit", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#34-sid_deinit" },"13": { "doc": "3. Amazon Sidewalk APIs", "title": "3.5 sid_start", "content": "The Amazon Sidewalk stack can be started using the sid_start API. The Sidewalk handle provided to the developer’s application during initialization is required to be passed to the sid_start API. The link_mask passed to sid_start can be the same as the link_mask passed to the sid_init API or a subset of the links passed to the sid_init API. The links that are not initialized cannot be started. For example, if SID_LINK_TYPE_1 and SID_LINK_TYPE_2 are initialized, the developer’s application can start only one link or both the links as follows: . | Setting the link_mask to SID_LINK_TYPE_1 or SID_LINK_TYPE_2 starts one link. | Setting the link_mask to SID_LINK_TYPE_1 and SID_LINK_TYPE_2 starts both the links. | . A call to sid_start triggers the following behavior: . | If the Amazon Sidewalk stack is not registered, the Amazon Sidewalk stack starts registration based on the links that have started. If both SID_LINK_TYPE_1 and SID_LINK_TYPE_2 have started, and if FFS over FSK is enabled, the registration procedure starts in SID_LINK_TYPE_2 (FSK), and the registration procedure also starts on SID_LINK_TYPE_1 (BLE). The registration procedure is completed based on whichever Gateway is in range: if an Amazon Sidewalk BLE Gateway is in range, the registration procedure is started and completed on BLE link and if an Amazon Sidewalk FSK Gateway is in range, registration procedure is started and completed on the FSK link. The developer’s application can force the Amazon Sidewalk stack to perform registration on the desired link by starting only that link. The developer’s application can initialize BLE and FSK links, but may then start just the BLE link if the developer requires registration to complete on the BLE link or the developer’s application may start just the FSK link if the developer requires registration to complete on the FSK link. Note that registration is not supported on the LoRa link. | If the Amazon Sidewalk stack does not have time synhcronization, the Amazon Sidewalk stack acquires time based on the links that are started. If more than one link has started, the time acquisition procedure is started simultaneously on all links that have started. | On the BLE link, the Amazon Sidewalk stack updates the beacon’s payload requesting the GPS time. | On the FSK link, the Amazon Sidewalk stack synchronizes to an FSK Gateway in range and sends a time request message to Amazon Sidewalk cloud services. | on the LoRa link, the Amazon Sidewalk stack immediately sends the time request message to Amazon Sidewalk cloud services. | . | After sid_start is called the link behaves as follows . | on BLE, the Endpoint is always beaconing. If the device has an uplink message to send, the beacon’s payload is updated with the intent to connect with a BLE Gateway to send the uplink message. If there is no uplink message to send, the Endpoint advertises its presence to the Amazon Sidewalk BLE Gateways to receive downlink messages from the Amazon Sidewalk cloud services. | on FSK, the Endpoint synchronizes with the Amazon Sidewalk FSK Gateway and, based on the device profile configured, performs a join procedure through the Amazon Sidewalk FSK Gateway with the Amazon Sidewalk cloud services. For more details on the join procedure and device profiles see the device profile document. | on LoRa, the device performs the join procedure with the Amazon Sidewalk cloud services. For more details on join procedure and device profile, see the device profile document. | . | sid_start should not be called in the context of any sid_event_callbacks to avoid re-entrancy and recursion issues. | sid_start uses the on_status_changed callback to notify the developer of the Amazon Sidewalk stack status. The on_status_changed callback notifies the developer’s application of the Sidewalk state on the Endpoint, whether it is registered, whether it has acquired GPS time and the connection status of the links that are being started. | If a link that has already started, is started again, SID_ERROR_NONE is returned. | The Amazon Sidewalk stack returns SID_ERROR_INVALID_ARGS if any of the following is true: . | sid_start is called with a handle that is NULL. | sid_start is called before sid_init has been called at least once | link_mask contains links that are not initialized but are being requested to start. | . | The Amazon Sidewalk stack returns SID_ERROR_NONE, if the requested links can be started successfully. | . /** * Makes the Sidewalk library start operating. * * The notifications registered during sid_init() are invoked once sid_start() * is called. * * On an unregistered Sidewalk Endpoint sid_start() will put the Sidewalk * library into a state ready for device registration, typically the device is * registered with a separate mobile application or MCU SDK tool. * * After registration the Sidewalk Endpoint will receive a time sync message * from an accessible Sidewalk gateway. This is a prerequisite to establish * up-link or down-link data connectivity. This is visible to the developer by * #SID_STATE_READY and #SID_STATUS_TIME_SYNCED. * * If sid_stop() is called after receiving #SID_STATE_READY the Sidewalk * library will cache the time sync for a minimum of SID_TIME_SYNC_MIN_PERIOD * seconds. This value should not be modified by the developer using the API. * * sid_start() can be used to start one or more links at once. * To start a single link, eg #SID_LINK_TYPE_1, link_mask = SID_LINK_TYPE_1, * To start more than one link, eg #SID_LINK_TYPE_1 and #SID_LINK_TYPE_3, * link_mask = SID_LINK_TYPE_1 | SID_LINK_TYPE_3 * * @note Developer can only start a link_type that was initialized in * sid_init() * * @see sid_stop * * @param[in] handle A pointer to the handle returned by sid_init() * @param[in] link_mask The links that need to started. * * @returns #SID_ERROR_NONE in case of success. */ sid_error_t sid_start(struct sid_handle *handle, uint32_t link_mask); // To start BLE and FSK links and initializing both BLE and FSK links uint32_t link_mask = (SID_LINK_TYPE_1 | SID_LINK_TYPE_2); // To start BLE link only after initializing BLE and FSK links uint32_t link_mask = SID_LINK_TYPE_1; // To start FSK link only after initializing BLE and FSK links uint32_t link_mask = SID_LINK_TYPE_2; sid_error_t ret = sid_start(handle, link_mask); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#35-sid_start", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#35-sid_start" },"14": { "doc": "3. Amazon Sidewalk APIs", "title": "3.6 sid_stop", "content": "The Amazon Sidewalk stack can be stopped by calling the sid_stop API. The Sidewalk handle provided to the developer’s application during initialization is required to be passed to the sid_stop API. The link_mask passed to sid_stop can be the same as the link_mask passed to the sid_init API or a subset of the links passed to the sid_init API. The links that are not initialized cannot be stopped. For example, if SID_LINK_TYPE_1 and SID_LINK_TYPE_2 are initialized, the developer’s application can stop one link or both links as follows: . | To stop one link, set the link_mask to SID_LINK_TYPE_1 or SID_LINK_TYPE_2. | To stop both links, set the link_mask to SID_LINK_TYPE_1 and SID_LINK_TYPE_2. | . A call to sid_stop triggers the following behavior: . | The links that are requested to be stopped are handled as follows: . | on the BLE link . | If the Endpoint was in connected state, calling sid_stop causes the Amazon Sidewalk stack to disconnect | If the Endpoint was in advertisement state, calling sid_stop causes the Endpoint to stop beaconing. | . | . | . Note that the BLE radio is not set to sleep on called sid_stop. | on the FSK link, calling sid_stop causes the Amazon Sidewalk stack to disconnect from the Amazon Sidewalk FSK Gateway and sets the radio to sleep. | on the LoRa link, calling sid_stop causes the Amazon Sidewalk stack to set the radio to sleep. | sid_stop notifies the Amazon Sidewalk stack status to the developer through the on_status_changed callback. The on_status_changed callback notifies the developer’s application of the Sidewalk state on the Endpoint, whether it is registered, whether it has time synchronization and the connection status of the links that are started. | sid_stop should not be called in the context of any sid_event_callbacks to avoid re-entrancy and recursion issues. | If a link that is already stopped is stopped again, SID_ERROR_NONE is returned. | The Amazon Sidewalk stack returns SID_ERROR_INVALID_ARGS if any of the following is true: . | sid_stop is called with a handle that is NULL. | sid_stop is called before sid_init has been called at least one time. | link_mask is set to request links to stop that are not initialized. | . | The Amazon Sidewalk stack returns SID_ERROR_NONE, if the requested links can be stopped successfully. | . /** * Makes the Sidewalk library stop operating. * * No messages will be sent or received and no notifications will occur after * sid_stop() is called. * Link status will be changed to disconnected and time sync status is cached * after sid_stop() is called. * * sid_stop() can be used to stop one or more links at once. * To stop a single link, eg #SID_LINK_TYPE_1, link_mask = SID_LINK_TYPE_1, * To stop more than one link, eg #SID_LINK_TYPE_1 and #SID_LINK_TYPE_3, * link_mask = SID_LINK_TYPE_1 | SID_LINK_TYPE_3 * * @note Developer can only stop a link_type that was initialized in * sid_init() * * @see sid_start * * @warning sid_stop() should be called in the same caller context as * sid_process(). * * @warning sid_stop() must not be called from within the caller context of * any of the sid_event_callbacks registered during sid_init() to avoid * re-entrancy and recursion problems. * * @warning RTC should not be stopped after sid_stop() is called. * * @param[in] handle A pointer to the handle returned by sid_init() * @param[in] link_mask The links that need to be stopped. * * @returns #SID_ERROR_NONE in case of success. */ sid_error_t sid_stop(struct sid_handle *handle, uint32_t link_mask); /** To stop BLE and FSK links and initializing and starting both BLE * and FSK links */ uint32_t link_mask = (SID_LINK_TYPE_1 | SID_LINK_TYPE_2); // To stop BLE link only after initializing BLE and FSK links uint32_t link_mask = SID_LINK_TYPE_1; // To start FSK link only after initializing BLE and FSK links uint32_t link_mask = SID_LINK_TYPE_2; sid_error_t ret = sid_stop(handle, link_mask); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#36-sid_stop", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#36-sid_stop" },"15": { "doc": "3. Amazon Sidewalk APIs", "title": "3.7 sid_process", "content": "When the Amazon Sidewalk stack calls the developer’s registered callback of on_event, the developer’s application is required to call sid_process. The event sources for the Amazon Sidewalk stack are timers and the radio. The timer events are generated when the Amazon Sidewalk stack schedules events to occur in the future to maintain its states. The radio events are generated by the radio when a particular low level radio process is complete, for example transmitting a message over the air, receiving a message, radio transmit and receive errors etc. The timer and radio events are generated in the Interrupt Service Routine (ISR) context. sid_process should not be called in the same context in which on_event is notified to the developer’s application. This is because on_event notifies internal events that run and maintain Sidewalk states to the developer’s application. This notification process is a slow operation that must not be performed in ISR context. Note that these internal events are not meaningful to the developer. SID_ERROR_STOPPED is returned if all the links are stopped. SID_ERROR_INVALID_ARGS is returned if the Amazon Sidewalk stack is not initialized. SID_ERROR_NONE is returned if the Amazon Sidewalk stack can successfully process its internal events. Failure to call sid_process after being notified of an event by on_event causes events of the Amazon Sidewalk stack to remain in an unprocessed state. sid_process should be called before calling sid_stop or sid_deinit. /** * Process Sidewalk events. * * When there are no events to process, the function returns immediately. * When events are present, sid_process() invokes the sid_event_callbacks * registered during sid_init() within its calling context. You may not * receive any callbacks for internal events. * * You are required to schedule sid_process() to run within your main-loop or * running context when the sid_event_callbacks.on_event callback is received. * * Although not recommended for efficiency and power usage reasons, * sid_process() can also be called even if sid_event_callbacks.on_event has * not been received, to support main loops that operate in a polling manner. * * @warning sid_process() must not be called from within the caller context of * any of the sid_event_callbacks registered during sid_init() to avoid * re-entrancy and recursion problems. * * @see sid_init * @see sid_start * @see sid_event_callbacks * * @param[in] handle A pointer to the handle returned by sid_init() * * @returns #SID_ERROR_NONE in case of success. * @returns #SID_ERROR_STOPPED if sid_start() has not been called. */ sid_error_t sid_process(struct sid_handle *handle); sid_error_t ret = sid_process(handle); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#37-sid_process", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#37-sid_process" },"16": { "doc": "3. Amazon Sidewalk APIs", "title": "3.8 sid_put_msg", "content": "Messages can be sent over Amazon Sidewalk from an Endpoint by calling the sid_put_msg API. For more details on message’s metadata, attributes to configure message’s metadata, and MTU, see 2.8. The Amazon Sidewalk stack generates a unique ID for a every message that it accepts to send. The message ID starts from the value zero at the time of reset and incremented by one on every message sent including Amazon Sidewalk internal messages. The maximum value that this unique ID is incremented to is 16383, after which it resets to zero. The message ID is used as follows: . | For the LoRa link, the Amazon Sidewalk stack uses the message ID to notify the developer’s application of the sent status of the message over the air. | For BLE and FSK links, the message ID is used for Gateway acknowledgements. | if the call to sid_put_msg configures the message to request an acknowledgement from AWS IoT Core for Amazon Sidewalk. AWS IoT Core for Amazon Sidewalk uses the message ID to notify the message’s acknowledgement status. The notification is as follows: . | If the message is sent successfully over the air. This is notified to the developer’s application using the on_msg_sent callback. The on_msg_sent callback has a pointer to the message descriptor that has the same message ID that was provided to it at the call made to sid_put_msg. The on_msg_sent callback does not guarantee that the message has been received successfully by AWS IoT Core for Amazon Sidewalk. For messages sent by BLE and FSK, the on_msg_sent callback only notifies the developer’s application that the message has been sent over the air, and that the mesage was acknowledged by a Gateway. For messages sent by LoRa, the on_msg_sent only indicates that the message has been sent over the air successfully. | If the message can not be sent successfully over the air, the developer’s application is notified using the on_send_error callback. The on_send_error callback has a pointer to the message descriptor that has the same message ID that was provided to it at the call made to sid_put_msg. Note that on_msg_sent and on_send_error notifications are mutually exclusive. For a given message ID, both callbacks will not be notified, only one of them is notified to the developer. on_msg_sent is called for successful transmission and on_send_error is called for failure to transmit. | If the message has been acknowledged by AWS IoT Core for Amazon Sidewalk, if it was configured to receive an acknowledgement in the message’s transmit attributes. A message which has the acknowledgement field set to true in its transmit attributes gets the first notification that the message has been successfully sent using the on_msg_sent callback and also another notification that the message has been successfully acknowledged by AWS IoT Core for Amazon Sidewalk through on_msg_received callback. | . | . The message attributes passed define the behavior the Amazon Sidewalk stack applies to the message. The messages’ transmit attributes play a role only in this API. The developer’s application uses this API to inform the Amazon Sidewalk stack of the following attributes: . | The message is fire and forget, this message has acknowledgement set to false. | The Amazon Sidewalk stack is required to retry the message. The number of retries field governs this setting. | The period that the Amazon Sidewalk stack is required to hold the message before reporting error code SID_ERROR_TIMEOUT using the on_msg_sent_error callback. | The retry periodicity is linear and is derived from time to live and number of retries. For example: for a message configured with time to live as 60 seconds and number of retries as 3, the Amazon Sidewalk stack attempts to retry the message once every 20 seconds until an acknowledgement is received from the AWS IoT Core for Amazon Sidewalk. Once the acknowledgement is received, the developer’s application is notified using on_msg_received that an acknowledgement has been received for the message. Acknowledgements can be differentiated from regular messages notified through the on_msg_received callback by using the is_msg_ack field in the receive attributes in the message descriptor. | . When a call to sid_put_msg is made, the receive message attributes of the message descriptor are disregarded by the Amazon Sidewalk stack. This is because sid_put_msg is used to send messages and receive attributes in the message descriptor are only valid for the downlink messages or for Acknowledgements sent by AWS IoT and notified using the on_msg_received callback. For fire and forget messages, if the time to live field in the transmit attributes is set to zero, the Amazon Sidewalk stack holds the message in its transmit queue for a maximum period of two minutes. In this period, the Amazon Sidewalk stack tries to send the message over the air. If the message cannot be sent over the air within two minutes, the developer’s application is notified with the error code SID_ERROR_TIMEOUT. A message can be configured to be sent on a specific link or a combination of the links. This setting is in the link_mask field of the message descriptor. The rules are as follows: . | If only one link is specified in the link_mask: . | If the link is not connected, the Amazon Sidewalk stack will fail to send messages with the error SID_ERROR_INVALID_STATE. | If the link is connected the Amazon Sidewalk stack will accept the message. | . | If more than one link is specified in the link_mask the following rules apply: . | If only one link is in the connected state, the Amazon Sidewalk stack will send the message over the link which is in connected state. | If all the links in the link_mask are in disconnected state, sid_put_msg fails with the error code SID_ERROR_INVALID_STATE. | If more than one link specified in the link_mask is in the connected state, then the Amazon Sidewalk stack follows a pre-defined order: BLE has the highest priority, followed by FSK and then LoRa has the lowest priority. | . | . sid_put_msg returns SID_ERROR_OOM when the Amazon Sidewalk stack does not have enough buffers to send the message. Whenever the sid_put_msg is called, the stack allocates a buffer from its pre-allocated memory pool and queues the message for transmission. If the developer’s application requests transmissions of messages at a rate higher than the Amazon Sidewalk stack can transmit messages, the Amazon Sidewalk stack runs out of buffers and messages start to fail with the SID_ERROR_OOM error code. It is recommended that the developer’s application should control the rate at which the messages are requested to be transmitted. When sid_put_msg starts to fail messages with SID_ERROR_OOM, callbacks indicate whether the message was transmitted as follows: . | For messages that do not require retries the on_msg_sent or on_msg_sent_error callbacks indicate whether the message was transmitted. | For messages that are configured to expect an acknowledgement from AWS IoT Core for Amazon Sidewalk the on_msg_received callback gives an additional indication of whether the message was received by AWS IoT Core for Amazon Sidewalk. | . sid_put_msg returns SID_ERROR_INVALID_ARGS when one or more of the following conditions occurs: . | The pointer to the msg structure or the pointer to the Sidewalk handle, or the pointer to the message descriptor is NULL. | The message size is zero or the message size is greater than 255 bytes. | An acknowledgement was requested from AWS IoT Core for Amazon Sidewalk, but either the number of retries is zero or the time to live is zero. | The message type is RESP, and the message id is greater than 16383. | . sid_put_msg returns SID_ERROR_INVALID_STATE if any of the following conditions occur: . | The Sidewalk state is not ready. The Amazon Sidewalk stack can send and receive messages only when it’s state is ready. State ready requires, the Endpoint to be registered, acquired GPS time and at least one link is connected. | The link_mask specifies a link that is in disconnected state. For example, when the Amazon Sidewalk stack’s BLE and FSK links are started. and only the FSK link is in connected state, and the BLE link is in disconnected state, if the developer’s application sets the link_mask field in the message descriptor to BLE only, sid_put_msg fails with the SID_ERROR_INVALID_STATE error code. | . sid_put_msg returns SID_ERROR_NOSUPPORT if a link mode is not supported on the link the message is being requested to be sent on. sid_put_msg returns SID_ERROR_NONE when the Amazon Sidewalk stack has successfully accepted the message for transmission. When sid_put_msg returns SID_ERROR_NONE this does not imply that the Endpoint’s Amazon Sidewalk stack has already successfully transferred the message to AWS IoT Core for Amazon Sidewalk, instead it implies that the message has been successfully queued in the Endpoint’s internal transmit queue. The sent status of the message is notified to the developer through on_msg_sent and on_msg_sent_error for fire and forget messages and for messages requiring acknowledgement from AWS IoT Core for Amazon Sidewalk. /** * Queues a message. * * @note msg_desc can be used to correlate this message with the * sid_event_callbacks.on_msg_sent and sid_event_callbacks.on_send_error * callbacks. * * @note When sending #SID_MSG_TYPE_RESPONSE in response to #SID_MSG_TYPE_GET, * the developer is expected to fill the id field of message descriptor with * the id from the corresponding #SID_MSG_TYPE_GET message descriptor. * This allows the sid_api to match each unique #SID_MSG_TYPE_RESPONSE with * #SID_MSG_TYPE_GET. * * @param[in] handle A pointer to the handle returned by sid_init() * @param[in] msg The message data to send * @param[out] msg_desc The message descriptor this function fills which * identifies this message. * Only valid when #SID_ERROR_NONE is returned. * * @returns #SID_ERROR_NONE when the message is successfully placed in the * transmit queue. * @returns #SID_ERROR_TRY_AGAIN when there is no space in the transmit queue. */ sid_error_t sid_put_msg(struct sid_handle *handle, const struct sid_msg *msg, struct sid_msg_desc *msg_desc); /* send a fire and forget message of length 10 bytes and type notify to * AWS IoT, over BLE link with time to live as 60 seconds */ #define MAX_MSG_PAYLOAD_SIZE 255 static uint8_t payload[MAX_MSG_PAYLOAD_SIZE]; struct sid_msg_desc msg_desc = { .link_type = SID_LINK_TYPE_1, .type = SID_MSG_TYPE_NOTIFY, .mode = SID_LINK_MODE_CLOUD, .msg_desc_attr = { .tx_attr = { .request_ack = false, .num_retires = 0, .ttl_in_seconds = 60, }, }, }; struct sid_msg msg = { .data = payload, .size = 10, }; sid_error_t ret; ret = sid_put_msg(handle, &msg, &msg_desc); /* send message of length 100 bytes and type set to AWS IoT, over BLE or FSK * link with request_ack set to true, number of retries to 3 and time to live * as 120 seconds */ #define MAX_MSG_PAYLOAD_SIZE 255 static uint8_t payload[MAX_MSG_PAYLOAD_SIZE]; struct sid_msg_desc msg_desc = { .link_type = (SID_LINK_TYPE_1 | SID_LINK_TYPE_2), .type = SID_MSG_TYPE_SET, .mode = SID_LINK_MODE_CLOUD, .msg_desc_attr = { .tx_attr = { .request_ack = true, .num_retires = 3, .ttl_in_seconds = 120, }, }, }; struct sid_msg msg = { .data = payload, .size = 100, }; sid_error_t ret; ret = sid_put_msg(handle, &msg, &msg_desc); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#38-sid_put_msg", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#38-sid_put_msg" },"17": { "doc": "3. Amazon Sidewalk APIs", "title": "3.9 sid_get_error", "content": "sid_get_error returns the error code, and is used after the on_status_changed callback has returned with SID_STATE_ERROR. The sid_get_error API call returns the detail error code. The sid_get_error API call is only valid in the context in which the on_status_changed callback was called . SID_ERROR_INVALID_ARGS is returned if the Amazon Sidewalk stack is not initialized. /** * Get the current error code. * * When the sid_event_callbacks on_status_changed callback is called * with a #SID_STATE_ERROR you can use this function to retrieve the * detailed error code. The error code will only be valid in the * calling context of the sid_event_callbacks.on_status_changed callback. * * @param[in] handle A pointer to the handle returned by sid_init() * * @returns The current error code */ sid_error_t sid_get_error(struct sid_handle *handle); sid_error_t ret = sid_get_error(handle); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#39-sid_get_error", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#39-sid_get_error" },"18": { "doc": "3. Amazon Sidewalk APIs", "title": "3.10 sid_get_mtu", "content": "The sid_get_mtu API call gets the MTU of the requested link. SID_ERROR_INVALID_ARGS is returned if the Amazon Sidewalk stack is not initialized. Note that a specific link type has to be requested to get the MTU and not a combination of link types . SID_ERROR_NOSUPPORT is returned if the link type requested is not initialized. For example: if the BLE link is the only link that is initialized but the MTU of the FSK link is requested, SID_ERROR_NOSUPPORT is returned . SID_ERROR_NONE is returned if the link MTU can be successfully retrieved. The MTU of a link does not depend on the data rate at which the Amazon Sidewalk stack operates that link, nor on whether a Gateway Session Key is in use; see 2.11.1 and 2.11.2. The developer’s application does not need to query the MTU again, or resize its buffers, when either changes. /** * Gets the MTU associated with the given link_type. * * @param[in] handle A pointer to the handle returned by sid_init() * @param[in] link_type The link type to query * @param[out] mtu A pointer to store the MTU size for the given * link_type * * @returns #SID_ERROR_NONE on success. */ sid_error_t sid_get_mtu(struct sid_handle *handle, enum SID_LINK_TYPE link_type, size_t *mtu); size_t mtu = 0; sid_error_t ret = sid_get_mtu(handle, SID_LINK_TYPE_1, &mtu); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#310-sid_get_mtu", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#310-sid_get_mtu" },"19": { "doc": "3. Amazon Sidewalk APIs", "title": "3.11 sid_option", "content": "The sid_option API call is used to configure settings of the Amazon Sidewalk stack. For details of configuration see 2.9. For SID_OPTION_900MHZ_SET_DEVICE_PROFILE and SID_OPTION_900MHZ_GET_DEVICE_PROFILE, len shall be sizeof(struct sid_device_profile); any other length returns SID_ERROR_INVALID_ARGS. For SID_OPTION_900MHZ_SET_DEVICE_PROFILE, the developer’s application shall initialize every member of struct sid_device_profile, not only the members it intends to change: the Amazon Sidewalk stack compares the whole structure against the profile currently in effect, and a stale value in a member the developer’s application did not intend to set is validated like any other and can cause the call to be rejected with SID_ERROR_INCOMPATIBLE_PARAMS or SID_ERROR_INVALID_ARGS. Zero-initialize the structure and set the members required, or start from the profile returned by SID_OPTION_900MHZ_GET_DEVICE_PROFILE. For the members that may be set, their accepted values, the preconditions of each operation and the error conditions, see 2.9. /** * Set an option * * @see sid_option * @param[in] handle A pointer to the handle returned by sid_init * @param[in] option The option to set * @param[in/out] data A pointer to the memory for input/output data * associated with the option * @param[in] len The size of the data array * * @returns #SID_ERROR_NONE on success. */ sid_error_t sid_option(struct sid_handle *handle, enum sid_option option, void *data, size_t len); // Set FSK device profile to Sync profile with the following settings struct sid_device_profile target_dev_cfg = { .unicast_params = { .device_profile_id = SID_LINK2_PROFILE_2, .rx_window_count = SID_RX_WINDOW_CNT_INFINITE, .unicast_window_interval = { .sync_rx_interval_ms = SID_LINK2_RX_WINDOW_SEPARATION_1, }, .wakeup_type = SID_TX_AND_RX_WAKEUP, }, }; // Set device profile for FSK sid_error_t ret = sid_option(sid_handle, SID_OPTION_900MHZ_SET_DEVICE_PROFILE, &target_dev_cfg, sizeof(target_dev_cfg)); // Set LoRa device profile to Profile C (continuous RX mode) struct sid_device_profile lora_profile_c_cfg = { .unicast_params = { .device_profile_id = SID_LINK3_PROFILE_C, // rx_window_count and async_rx_interval_ms are automatically // set by the stack for Profile C: // rx_window_count = SID_RX_WINDOW_CONTINUOUS (0xFF) // async_rx_interval_ms = SID_LINK3_RX_WINDOW_SEPARATION_CONTINUOUS (0) .wakeup_type = SID_TX_AND_RX_WAKEUP, }, }; sid_error_t ret = sid_option(sid_handle, SID_OPTION_900MHZ_SET_DEVICE_PROFILE, &lora_profile_c_cfg, sizeof(lora_profile_c_cfg)); // Set LoRa device profile to Profile B, and express a preferred RX window // interval for use while the stack operates the link at the higher data rate struct sid_device_profile lora_profile_b_cfg = { .unicast_params = { .device_profile_id = SID_LINK3_PROFILE_B, .rx_window_count = SID_RX_WINDOW_CNT_INFINITE, .unicast_window_interval = { // At the default data rate, Profile A and Profile B accept only 5000 ms or 0 .async_rx_interval_ms = SID_LINK3_RX_WINDOW_SEPARATION_3, }, .wakeup_type = SID_TX_AND_RX_WAKEUP, // Preference, applied by the stack only while it operates the link // at the higher data rate, see section 2.9 .l3_mdr_rx_window_interval_ms = SID_LINK3_RX_WINDOW_SEPARATION_5, }, }; sid_error_t ret = sid_option(sid_handle, SID_OPTION_900MHZ_SET_DEVICE_PROFILE, &lora_profile_b_cfg, sizeof(lora_profile_b_cfg)); // Get current configured device profile struct sid_device_profile curr_dev_cfg = { .unicast_params = { .device_profile_id = SID_LINK2_PROFILE_2, }, }; sid_error_t ret = sid_option(sid_handle, SID_OPTION_900MHZ_GET_DEVICE_PROFILE, &curr_dev_cfg, sizeof(curr_dev_cfg)); // Set filter duplicates settings to allow all duplicates bool filter_duplicates = true; sid_error_t ret = sid_option(sid_handle, SID_OPTION_SET_MSG_POLICY_FILTER_DUPLICATES, &filter_duplicates, sizeof(filter_duplicates)); // Get current configured duplicate setting bool filter_duplicates; sid_error_t ret = sid_option(sid_handle, SID_OPTION_GET_MSG_POLICY_FILTER_DUPLICATES, &filter_duplicates, sizeof(filter_duplicates)); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#311-sid_option", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#311-sid_option" },"20": { "doc": "3. Amazon Sidewalk APIs", "title": "3.12 sid_set_factory_reset", "content": "The sid_set_factory_reset API shall be called when the application decides to clear the Amazon Sidewalk stack’s configuration and keys that were established during registration from non-volatile storage. The sid_set_factory_reset API places the Amazon Sidewalk stack in pre-registration state. On the lite build variants it returns the Endpoint to the factory-registered state instead, see 2.3.5. Application usage of this API shall be tied to a button press or other event to trigger a de-registration process. When this API is invoked, if a link is available, the SDK attempts to send notification to the Amazon Sidewalk cloud before clearing the Amazon Sidewalk stack’s configuration and keys. On completion of clearing the Amazon Sidewalk stack’s configuration and keys, on_factory_reset callback shall be triggered from the SDK. SID_ERROR_INVALID_ARGS is returned by the API if the Amazon Sidewalk stack is not initialized or if the Sidewalk handle is NULL. SID_ERROR_STOPPED is returned by the API if the Amazon Sidewalk stack is not started. /** * set factory reset * * Inform the sidewalk stack the factory reset event. * The sidewalk library clears its configuration from the non volatile storage * and resets its state accordingly. * The device needs to successfully complete device registration with the * cloud services for the sidewalk library to sned and receive messages * * @param[in] handle A pointer to the handle returned by sid_init * * @returns #SID_ERROR_NONE on success. */ sid_error_t sid_set_factory_reset(struct sid_handle *handle); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#312-sid_set_factory_reset", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#312-sid_set_factory_reset" },"21": { "doc": "3. Amazon Sidewalk APIs", "title": "3.13 sid_ble_connection_request", "content": "The sid_ble_connection_request API can only be used on the BLE link. The sid_ble_connection_request API is called by the developer’s application to request connection from a BLE Gateway, or to cancel a request for a connection. When the sid_ble_connection_request API is called by the developer’s application to request connection, the Endpoint requests an uplink connection on BLE through a BLE Gateway by updating its beacon’s advertisement payload, requesting a BLE Gateway to connect. The sid_ble_connection_request API must be called again to stop the request to connect. This is because when the sid_ble_connection_request has requested a connection, the beacons have connect request set to TRUE. The value of connect request then remains set to TRUE until set to FALSE by another call to sid_ble_connection_request. SID_ERROR_NOSUPPORT is returned by the API if the BLE link is not compiled into the image. SID_ERROR_INVALID_ARGS is returned if one or more of the following conditions is True: . | BLE is not initialized. | BLE is not started. | The Sidewalk handle is NULL. | . SID_ERROR_INVALID_STATE is returned if one of the following conditions occurs: . | The Sidewalk state is un-registered | The Sidewalk time sync state is FALSE (indicating that the Endpoint does not have time synchronization) | . SID_ERROR_ALREADY_EXISTS is returned if the BLE is already beaconing with the request to connect. SID_ERROR_NONE is returned if the Amazon Sidewalk stack can successfully handle the request. /** * Using this API, the device can request that the Sidewalk gateway initiates * a connection to the device while the device is advertising via BLE * (Sidewalk beaconing). After a connection is dropped the developer's * application has to set this beacon state again. A Gateway may not always be * able to honor this request depending on the number of devices connected to * it. * * @param[in] handle A pointer to the handle returned by sid_init(). * @param[in] set Set or clear the connection request in BLE * advertising packet. * * @returns #SID_ERROR_NONE on success. * @returns #SID_ERROR_ALREADY_EXISTS when device is already connected to a * Sidewalk gateway and connection request * is set. */ sid_error_t sid_ble_bcn_connection_request(struct sid_handle *handle, bool set); // Enable connection request sid_error_t ret = sid_ble_bcn_connection_request(struct sid_handle *handle, true); // Disable connection request sid_error_t ret = sid_ble_bcn_connection_request(struct sid_handle *handle, false); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#313-sid_ble_connection_request", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#313-sid_ble_connection_request" },"22": { "doc": "3. Amazon Sidewalk APIs", "title": "3.14 sid_set_msg_dest_id", "content": "Amazon Sidewalk currently supports only one destination ID: AWS IoT Core for Amazon Sidewalk When the developer’s application sends a message using the Amazon Sidewalk stack, using link mode cloud, the destination ID is set to 32 (the ID of AWS IoT Core for Amazon Sidewalk). The sid_set_msg_dest_id API configures the destination IDs, for future use when Amazon Sidewalk supports destination IDs other than AWS IoT Core for Amazon Sidewalk. SID_ERROR_INVALID_ARGS is returned if handle is NULL. SID_ERROR_NONE is returned if the destination ID can be set successfully. /** * Set destination ID for messages. * * By default, the destination ID is set to #SID_MSG_DESTINATION_AWS_IOT_CORE * unless changed by sid_set_msg_dest_id(). The destination ID is retained * until the device resets or its changed by another invocation of * sid_set_msg_dest_id(). * * @see sid_put_msg(). * * @param[in] handle A pointer to the handle returned by sid_init(). * @param[in] id The new destination ID. * * @returns #SID_ERROR_NONE on success. */ sid_error_t sid_set_msg_dest_id(struct sid_handle *handle, uint32_t id); sid_error_t ret = sid_set_msg_dest_id(handle, 32); // only AWS IoT destination // is currently supported . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#314-sid_set_msg_dest_id", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#314-sid_set_msg_dest_id" },"23": { "doc": "3. Amazon Sidewalk APIs", "title": "3.15 sid_get_status", "content": "The status of the Amazon Sidewalk stack can be polled by calling the sid_get_status API. For details of the sid_status structure, see 2.6. SID_ERROR_INVALID_ARGS is returned if the Sidewalk handle passed is NULL or if the Amazon Sidewalk stack is not initialized. SID_ERROR_NONE is returned when the current status can be successfully returned to the developer’s application. /** * Get current status from Sidewalk library. * * @warning sid_get_status() should be called in the same caller context as * sid_process(). * * @warning sid_get_status() must not be called from within the caller context * of any of the sid_event_callbacks registered during sid_init() to avoid * re-entrancy and recursion problems. * * @param[in] handle A pointer to the handle returned by sid_init() * @param[out] current_status A pointer to store the sdk current status * * @returns #SID_ERROR_NONE in case of success. * @returns #SID_ERROR_INVALID_ARGS when Sidewalk library is not initialized. */ sid_error_t sid_get_status(struct sid_handle *handle, struct sid_status *current_status); struct sid_status current_status; sid_error_t ret = sid_get_status(handle, &current_status); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#315-sid_get_status", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#315-sid_get_status" },"24": { "doc": "3. Amazon Sidewalk APIs", "title": "3.16 sid_get_time", "content": "sid_get_time provides the caller with the GPS time. UTC and local time are not supported. SID_ERROR_NOSUPPORT is returned when the sid_get_time call requests time other than GPS time. SID_ERROR_INVALID_ARGS is returned if one or more of the following conditions occurs: . | The handle is NULL. | The pointer to hold the time is NULL | The Amazon Sidewalk stack is not initialized | . SID_ERROR_NONE is returned if the API can successfully provide GPS time. /** * Get time from the Sidewalk library with the requested format. * * @warning sid_get_time() should be called in the same caller context as * sid_process(). * * @warning sid_get_time() must not be called from within the caller context * of any of the sid_event_callbacks registered during sid_init() to avoid * re-entrancy and recursion problems. * * @param[in] handle A pointer to the handle returned by sid_init(). * @param[in] format The time format to query * @param[out] curr_time A pointer to store the current time in * sid_timespec format. * * @returns #SID_ERROR_NONE in case of success. * @returns #SID_ERROR_INVALID_ARGS when sidewalk is not initialized or not * registered or invalid format is supplied. * @returns #SID_ERROR_UNINITIALIZED when time is not available. */ sid_error_t sid_get_time(struct sid_handle *handle, enum sid_time_format format, struct sid_timespec *curr_time); struct sid_timespec curr_time; sid_error_t ret = sid_get_time(handle, SID_GET_GPS_TIME, &curr_time); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#316-sid_get_time", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#316-sid_get_time" },"25": { "doc": "3. Amazon Sidewalk APIs", "title": "3.17 sid_set_time", "content": "sid_set_time allows the application to set the time in the Sidewalk stack. This API can be used to provide time synchronization from external sources. SID_ERROR_INVALID_ARGS is returned if one or more of the following conditions occurs: . | The handle is NULL. | The pointer to the time is NULL | The pointer to the drift is NULL | The Amazon Sidewalk stack is not initialized | . SID_ERROR_INVALID_STATE is returned if the device is not registered. SID_ERROR_NONE is returned if the API can successfully set the time. /** * Set time in the Sidewalk stack. * * @warning sid_set_time() should be called in the same caller context as * sid_process(). * * @warning sid_set_time() must not be called from within the caller context * of any of the sid_event_callbacks registered during sid_init() to avoid * re-entrancy and recursion problems. * * @param[in] handle A pointer to the handle returned by sid_init(). * @param[in] time A pointer to the time to set in sid_timespec format. * @param[in] drift A pointer to the time drift in sid_timespec format. * * @returns #SID_ERROR_NONE in case of success. * @returns #SID_ERROR_INVALID_ARGS when Sidewalk is not initialized or not * registered or invalid parameters are supplied. * @returns #SID_ERROR_INVALID_STATE when device is not registered. */ sid_error_t sid_set_time(struct sid_handle *handle, const struct sid_timespec *time, const struct sid_timespec *drift); struct sid_timespec time = {.tv_sec = 1640995200, .tv_nsec = 0}; // Example time struct sid_timespec drift = {.tv_sec = 0, .tv_nsec = 100000000}; // 100 ms drift sid_error_t ret = sid_set_time(handle, &time, &drift); . 3.17.1 Local Time Synchronization Example . Applications can implement local time synchronization to reduce power consumption and network traffic by avoiding frequent cloud time sync requests: . // Note: Users must implement get_application_timestamp(), flash_write_time_data(), // and flash_read_time_data() functions based on their platform requirements // Save current time to flash storage for later use void save_time_to_flash(void) { struct sid_timespec current_time, save_timestamp; sid_error_t ret = sid_get_time(handle, SID_GET_GPS_TIME, &current_time); if (ret == SID_ERROR_NONE) { // Save GPS time and current app timestamp get_application_timestamp(&save_timestamp); flash_write_time_data(&current_time, &save_timestamp); } } // Restore time from flash and apply drift compensation void restore_time_from_flash(void) { struct sid_timespec saved_time, save_timestamp, restore_timestamp, app_uptime; struct sid_timespec adjusted_time; // Read saved data from flash if (flash_read_time_data(&saved_time, &save_timestamp) == SUCCESS) { // Get current application timestamp get_application_timestamp(&restore_timestamp); // Calculate app uptime = timestamp at restore - timestamp at saving app_uptime.tv_sec = restore_timestamp.tv_sec - save_timestamp.tv_sec; app_uptime.tv_nsec = restore_timestamp.tv_nsec - save_timestamp.tv_nsec; // Calculate adjusted time: saved_time + app_uptime adjusted_time.tv_sec = saved_time.tv_sec + app_uptime.tv_sec; adjusted_time.tv_nsec = saved_time.tv_nsec + app_uptime.tv_nsec; sid_error_t ret = sid_set_time(handle, &adjusted_time, &app_uptime); if (ret == SID_ERROR_NONE) { // Time sync successful - no cloud request needed } } } . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#317-sid_set_time", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#317-sid_set_time" },"26": { "doc": "3. Amazon Sidewalk APIs", "title": "3.18 sid_bulk_data_transfer_init", "content": "SBDT can be initialized using sid_bulk_data_transfer_init API. The sid_bulk_data_transfer_init API accepts a pointer to the SBDT configuration and sid_handle. On initialization, SBDT registers for SBDT messages from the cloud, and loads any existing ongoing transfers. If there was an ongoing transfer, the memory is requested from the developer’s application to handle said transfers see 2.13.4. sid_bulk_data_transfer_init should not be called in the context of SBDT Callbacks to avoid re-entrancy and recursion issues. If there was an ongoing transfer sid_bulk_data_transfer_init API will trigger on_transfer_request API call to request memory and to allow developer’s application to either reject or accept the ongoing transfer. If the developer’s application chooses to reject the ongoing transfer then ongoing transfer information is wiped away from the KV store API. Re-initializing SBDT without de-initializing causes the sid_bulk_data_transfer_init to fail with the API return error code SID_ERROR_ALREADY_INITIALIZED. The sid_bulk_data_transfer_init API returns error code SID_ERROR_INVALID_ARGS if any of the following conditions are met: . | Pointers to config and handle are NULL. | Any of the SBDT Callbacks functions are set to NULL. | Amazon Sidewalk stack is not initialized via the sid_init API. | . The sid_bulk_data_transfer_init API will return error code SID_ERROR_STORAGE_READ_FAIL if it is not able to read the status of any ongoing transfer’s from the KV store API. /** * Initializes Sidewalk bulk transfer * * @see sid_bulk_data_transfer_init * @see sid_init * * @param[in] config Required configuration needed to initialize Sidewalk * bulk transfer * @param[in] handle A pointer to the handle returned by sid_init() * * @returns #SID_ERROR_NONE in case of success */ sid_error_t sid_bulk_data_transfer_init (const struct sid_bulk_data_transfer_config *config, struct sid_handle *handle); // Initialize BLE link struct sid_config config = { .link_mask = SID_LINK_TYPE_1, .callbacks = &event_callbacks, .link_config = app_get_ble_config(), // update the BLE config }; static struct sid_handle *sidewalk_handle; sid_error_t ret = sid_init(config, &sid_handle); struct sid_bulk_data_transfer_config sbdt_config = { .callbacks = &sbdt_event_callbacks, }; ret = sid_bulk_data_transfer_init(&sbdt_config, sidewalk_handle); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#318-sid_bulk_data_transfer_init", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#318-sid_bulk_data_transfer_init" },"27": { "doc": "3. Amazon Sidewalk APIs", "title": "3.19 sid_bulk_data_transfer_deinit", "content": "SBDT can be de-initialized using sid_bulk_data_transfer_deinit API. The sid_bulk_data_transfer_deinit API requires the pointer to the internal handle that was provided to the developer’s application during initialization. The sid_bulk_data_transfer_deinit API deregisters SBDT from handling any incoming SBDT commands and releases the memory that was acquired via on_transfer_request callback using the on_release_scratch callback. Calling sid_deinit API will not de initialize SBDT and it needs to be done separately as well. | The sid_bulk_data_transfer_deinit return’s SID_ERROR_INVALID_ARGS if the handle passed is NULL or is not initialized. | . /** * De-initialize Sidewalk bulk transfer * * @see sid_bulk_data_transfer_init * * @param[in] handle A pointer to the handle returned by sid_init() * * @returns #SID_ERROR_NONE in case of success */ sid_error_t sid_bulk_data_transfer_deinit(struct sid_handle *handle); sid_error_t ret = sid_bulk_data_transfer_deinit(sidewalk_handle); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#319-sid_bulk_data_transfer_deinit", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#319-sid_bulk_data_transfer_deinit" },"28": { "doc": "3. Amazon Sidewalk APIs", "title": "3.20 sid_bulk_data_transfer_release_buffer", "content": "The sid_bulk_data_transfer_release_buffer API is called to indicate to SBDT that the developer’s application is done processing the data buffer containing the fragment it received in on_data_recieved callback, and it’s ready to receive the next one. The sid_bulk_data_transfer_release_buffer API in conjunction with on_data_recieved callback can handle the below cases in respect to flash write. The developer’s application can write the data received in on_data_recieved to flash and release the buffer via sid_bulk_data_transfer_release_buffer within the on_data_recieved callback itself. If the write takes too long that it impacts the performance of the system, the write can be scheduled to a later time and sid_bulk_data_transfer_release_buffer can be called once the write is done. This approach gives the developer enough flexibility to handle both cases with respect to writes. | sid_bulk_data_transfer_release_buffer returns SID_ERROR_INVALID_ARGS if . | sid_handle is NULL | If Sidewalk stack is not initialized | . | sid_bulk_data_transfer_release_buffer returns SID_ERROR_NOT_FOUND if . | file_id is incorrect or it does not find an ongoing transfer corresponding to the given file_id | The given buffer does not match the one received in the on_recieved_callback | . | sid_bulk_data_transfer_release_buffer returns SID_ERROR_INVALID_STATE if . | SBDT was not initialized via the sid_bulk_data_transfer_init API call | If developer’s application is trying to release a buffer that was never given or already released | . | . /** * Release data buffer * * This API is called to release ownership of the data buffer back to bulk * transfer * * @param[in] handle A pointer to the handle returned by sid_init() * @param[in] file_id Identifier of the file transfer whose buffer is being * released * @param[in] buffer A pointer to the buffer that needs to be released, which * is never NULL * * @returns #SID_ERROR_NONE in case of success */ sid_error_t sid_bulk_data_transfer_release_buffer(struct sid_handle *handle, uint32_t file_id, const struct sid_bulk_data_transfer_buffer *const buffer); void sbdt_on_data_recieved (const struct sid_bulk_data_transfer_desc *const desc, const struct sid_bulk_data_transfer_buffer *const buffer, void *context) { // Illustrative API indicating write to flash write_to_flash(buffer->data, buffer->size); sid_error_t ret = sid_bulk_data_transfer_release_buffer(sidewalk_handle, desc->file_id, buffer); } . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#320-sid_bulk_data_transfer_release_buffer", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#320-sid_bulk_data_transfer_release_buffer" },"29": { "doc": "3. Amazon Sidewalk APIs", "title": "3.21 sid_bulk_data_transfer_finalize", "content": "The developer’s application calls sid_bulk_data_transfer_finalize to indicate weather the file was fully transferred and it passed any of user’s validation checks, such as CRC32 check or signature verification checks. This API is used in conjunction with on_finalize_request, where once the developer’s application receives the on_finalize_request callback the developer’s application verifies the received file and calls sid_bulk_data_transfer_finalize with the appropriate success or failure response. The sid_bulk_data_transfer_finalize API can be called within any context. | sid_bulk_data_transfer_finalize returns SID_ERROR_INVALID_ARGS if . | sid_handle is NULL | If Sidewalk stack is not initialized | . | sid_bulk_data_transfer_finalize returns SID_ERROR_NOT_FOUND if . | file_id is incorrect or it does not find an ongoing transfer corresponding to the given file_id | . | sid_bulk_data_transfer_finalize returns SID_ERROR_INVALID_STATE if . | SBDT was not initialized via the sid_bulk_data_transfer_init API call | If developer’s application is trying to finalize a transfer before all of the file is received | . | . /** * Complete an ongoing Sidewalk bulk transfer * * This function is called when on_finalize_request callback is invoked. The * purpose of the API is to inform bulk transfer if the transfer was * successful (CRC checks/signature is verified), or it was a failure. * * @see sid_bulk_data_transfer_event_callbacks.on_finalize_request * * @param[in] handle A pointer to the handle returned by sid_init() * @param[in] file_id Identifier of the file being transferred * @param[in] status Indicates if the transfer was completed successfully from * the user end * * @returns #SID_ERROR_NONE in case of success */ sid_error_t sid_bulk_data_transfer_finalize (struct sid_handle *handle, uint32_t file_id, enum sid_bulk_data_transfer_final_status status); void sbdt_on_finalize_request(uint32_t file_id, void *context) { // Illustrative API indicating verification of file bool success = validate_recieved_file(file_id); sid_error_t ret = sid_bulk_data_transfer_finalize (sidewalk_handle, file_id, success ? SID_BULK_DATA_TRANSFER_FINAL_STATUS_SUCCESS : SID_BULK_DATA_TRANSFER_FINAL_STATUS_FAILURE); } . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#321-sid_bulk_data_transfer_finalize", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#321-sid_bulk_data_transfer_finalize" },"30": { "doc": "3. Amazon Sidewalk APIs", "title": "3.22 sid_bulk_data_transfer_cancel", "content": "The developer’s application can use sid_bulk_data_transfer_cancel API to cancel an ongoing transfer. When the developer’s application calls the sid_bulk_data_transfer_cancel, SBDT informs AWS of the cancellation request and calls on_cancel_request callback and on_release_scratch. | sid_bulk_data_transfer_cancel returns SID_ERROR_INVALID_ARGS if . | sid_handle is NULL | If Sidewalk stack is not initialized | . | sid_bulk_data_transfer_cancel returns SID_ERROR_NOT_FOUND if . | file_id is incorrect or it does not find an ongoing transfer corresponding to the given file_id | . | sid_bulk_data_transfer_cancel returns SID_ERROR_INVALID_STATE if . | SBDT was not initialized via the sid_bulk_data_transfer_init API call | . | sid_bulk_data_transfer_cancel returns SID_ERROR_NO_ROUTE_AVAILABLE if the transfer link is not connected. The developer’s application will then need to re-establish the link again before calling the sid_bulk_data_transfer_cancel again. | . /** * Cancels any ongoing bulk transfer * * @param[in] handle A pointer to the handle returned by sid_init() * @param[in] file_id Identifier of the file transfer that needs to be * cancelled * @param[in] reason Reason for cancelling the transfer * * @return #SID_ERROR_NONE in case of success */ sid_error_t sid_bulk_data_transfer_cancel (struct sid_handle *handle, uint32_t file_id, enum sid_bulk_data_transfer_reject_reason reason); sid_error_t ret = sid_bulk_data_transfer_cancel (sidewalk_handle, file_id, SID_BULK_DATA_TRANSFER_REJECT_REASON_NONE); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#322-sid_bulk_data_transfer_cancel", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#322-sid_bulk_data_transfer_cancel" },"31": { "doc": "3. Amazon Sidewalk APIs", "title": "3.23 sid_bulk_data_transfer_get_stats", "content": "The developer’s application can use sid_bulk_data_transfer_get_stats API to get the current progress of the file transfer. It returns the fragment size, size of the file transferred and total size of the file. The developer’s application can call this API anytime during the duration of the transfer. | sid_bulk_data_transfer_get_stats returns SID_ERROR_INVALID_ARGS if . | sid_handle is NULL | If Sidewalk stack is not initialized | If the stats argument is NULL | . | sid_bulk_data_transfer_get_stats returns SID_ERROR_NOT_FOUND if . | file_id is incorrect or it does not find an ongoing transfer corresponding to the given file_id | . | sid_bulk_data_transfer_get_stats returns SID_ERROR_INVALID_STATE if . | SBDT was not initialized via the sid_bulk_data_transfer_init API call | . | . /** * Get the stats of an ongoing Sidewalk bulk transfer * * This function is called to get the current stats/progress of an ongoing * file transfer * * @param[in] handle A pointer to the handle returned by sid_init() * @param[in] file_id Identifier of the file being transferred * @param[in] stats A pointer to the structure that holds the stats * information * * @returns #SID_ERROR_NONE in case of success */ sid_error_t sid_bulk_data_transfer_get_stats (struct sid_handle *handle, uint32_t file_id, struct sid_bulk_data_transfer_stats *const stats); struct sid_bulk_data_transfer_stats stats = {}; sid_error_t ret = sid_bulk_data_transfer_get_stats(sidewalk_handle, file_id, &stats); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#323-sid_bulk_data_transfer_get_stats", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#323-sid_bulk_data_transfer_get_stats" },"32": { "doc": "3. Amazon Sidewalk APIs", "title": "3.24 sid_location_init", "content": "The Sidewalk Location Library can be initialized using the sid_location_init API. The sid_location_init API accepts a pointer to the location configuration and the Sidewalk handle returned by sid_init. The location library can be initialized after sid_init() and provides a unified interface for multiple location resolution methods including Sidewalk Network Location over BLE, WiFi scanning, and GNSS scanning. On initialization, the location library configures the supported location methods based on the hardware capabilities and initializes the corresponding Platform Abstraction Layers (PALs) if WiFi and GNSS are enabled. The library automatically manages location effort levels and provides fallback mechanisms to ensure the most power-efficient location method is used first. sid_location_init should not be called in the context of any location event callbacks to avoid re-entrancy and recursion issues. Re-initializing the location library without de-initializing returns SID_ERROR_NONE (the existing context is reused). The sid_location_init API returns error code SID_ERROR_INVALID_ARGS if any of the following conditions are met: . | Pointer to handle is NULL or the Sidewalk stack is not initialized. | Pointer to config is NULL. | The max_effort in config is greater than the available hardware capabilities. | . The callbacks.on_update function pointer must not be NULL as it is called throughout the location library operations. Passing a NULL callback will result in undefined behavior. The sid_location_init API returns error code SID_ERROR_NOSUPPORT if any of the following conditions are met: . | The requested location method types are not supported by the platform. | WiFi or GNSS PALs are not available when SID_LOCATION_METHOD_WIFI or SID_LOCATION_METHOD_GNSS are specified. | . The sid_location_init API may also return errors from the underlying WiFi or GNSS PAL initialization. The sid_location_init API returns error code SID_ERROR_NONE when the location library initialization is successful. The sid_location_init API returns error code SID_ERROR_OOM if memory allocation fails. The struct sid_location_config contains the following fields: . | sid_location_type_mask - Bitmask of location methods to enable (SID_LOCATION_METHOD_BLE_GATEWAY, SID_LOCATION_METHOD_WIFI, SID_LOCATION_METHOD_GNSS, or SID_LOCATION_METHOD_ALL) | callbacks - Event callback structure containing on_update function pointer and optional context | max_effort - Maximum effort mode allowed for location operations | manage_effort - When true, the library automatically manages effort levels and steps down through different location methods | stepdowns - Timeout configuration (in milliseconds) for stepping down location levels: . | l4_to_l3 - Timeout after GNSS scan completes before stepping down to WiFi | l3_to_l2 - Timeout after WiFi scan completes before stepping down to L2 | l2_to_l1 - Timeout before stepping down to BLE | . | fragmentation - Configuration for fragmented uplink over LoRa: . | timeout_ms - Total timeout for fragmentation retries | max_retries - Maximum number of retry attempts | . | auto_link_pause_resume - When true, automatically pauses Sub-1GHz links (Link Type 2 and 3) during GNSS scans to avoid hardware conflicts, and resumes them after scan completion | . /** * Initialize sid location library * * This API will configure and initialize one or more of the supported * location libraries available on device. * * @param[in] handle A pointer to the handle returned by sid_init() * @param[in] config Location configuration structure * * @returns #SID_ERROR_NONE in case of success **/ sid_error_t sid_location_init(struct sid_handle *handle, struct sid_location_config *config); // Initialize location library with BLE-only support void location_callback(const struct sid_location_result *const result, void *context) { // Handle location result } static struct sid_location_config cfg = { .sid_location_type_mask = SID_LOCATION_METHOD_BLE_GATEWAY, .manage_effort = true, .max_effort = SID_LOCATION_EFFORT_L1, .callbacks = { .on_update = location_callback, .context = NULL, }, .stepdowns = { .l2_to_l1 = 0, .l3_to_l2 = 0, .l4_to_l3 = 0, }, .fragmentation = { .timeout_ms = 60000, .max_retries = 1, }, .auto_link_pause_resume = false, }; sid_error_t ret = sid_location_init(sidewalk_handle, &cfg); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#324-sid_location_init", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#324-sid_location_init" },"33": { "doc": "3. Amazon Sidewalk APIs", "title": "3.25 sid_location_deinit", "content": "The Sidewalk Location Library can be de-initialized using the sid_location_deinit API. The sid_location_deinit API requires the pointer to the Sidewalk handle that was provided during initialization. The sid_location_deinit API deinitializes the enabled location libraries and releases any allocated resources. sid_location_deinit should not be called in the context of any location event callbacks to avoid re-entrancy and recursion issues. The sid_location_deinit API call returns SID_ERROR_UNINITIALIZED, if the handle passed is NULL, if the Sidewalk stack is not initialized, or if the location library is not initialized. The sid_location_deinit API call returns SID_ERROR_BUSY, if there is an ongoing GNSS or WiFi scan operation. The sid_location_deinit API may also return errors from the underlying GNSS or WiFi PAL deinitialization. The sid_location_deinit API call returns SID_ERROR_NONE, if the location library is successfully de-initialized. /** * Deinitialize sid location library * * This API will deinitialize the enabled location libraries. * * @param[in] handle A pointer to the handle returned by sid_init() * * @returns #SID_ERROR_NONE in case of success **/ sid_error_t sid_location_deinit(struct sid_handle *handle); sid_error_t ret = sid_location_deinit(sidewalk_handle); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#325-sid_location_deinit", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#325-sid_location_deinit" },"34": { "doc": "3. Amazon Sidewalk APIs", "title": "3.26 sid_location_run", "content": "The sid_location_run API is used to scan and send available location information to the cloud to resolve coordinates. The API accepts a configuration structure that specifies the location effort mode and run type (scan only, send only, or scan and send). The location library will prioritize the most power and time efficient mechanism based on the configured effort mode. When manage_effort is enabled in the location configuration, the library automatically manages effort levels and steps down through different location methods based on availability and timeout configurations. If manage_effort is disabled, SID_LOCATION_EFFORT_DEFAULT cannot be used and a specific effort mode must be specified. The location effort levels are ordered by power consumption: . | Level 1 (SID_LOCATION_EFFORT_L1): Sidewalk Network Location over BLE - No additional power consumption | Level 2 (SID_LOCATION_EFFORT_L2): LoRa location trigger (requires Link Type 3 network sync) | Level 3 (SID_LOCATION_EFFORT_L3): WiFi Scan - Low power consumption | Level 4 (SID_LOCATION_EFFORT_L4): GNSS Scan - Higher power consumption | . The sid_location_run API returns error code SID_ERROR_UNINITIALIZED if the handle is NULL, the Sidewalk stack is not initialized, or the location library is not initialized. The sid_location_run API returns error code SID_ERROR_INVALID_STATE if the Sidewalk stack is not started. The sid_location_run API returns error code SID_ERROR_INVALID_ARGS if any of the following conditions are met: . | For SID_LOCATION_SEND_ONLY operations: the buffer is NULL, size is zero, or mode is not SID_LOCATION_EFFORT_L3 or SID_LOCATION_EFFORT_L4. | . The sid_location_run API returns error code SID_ERROR_NO_ROUTE_AVAILABLE if SID_LOCATION_SEND_ONLY is requested but no link is connected. The sid_location_run API returns error code SID_ERROR_NOSUPPORT if the requested effort mode requires a location method that is not available or not initialized. The sid_location_run API returns error code SID_ERROR_INSUFFICIENT_RESULTS if the scan completes but does not find sufficient data for location resolution (e.g., insufficient WiFi access points or GNSS satellites). The sid_location_run API returns error code SID_ERROR_NONE when the location request is successfully queued for processing. The struct sid_location_run_config contains the following fields: . | mode - The location effort mode to use (SID_LOCATION_EFFORT_L1 through SID_LOCATION_EFFORT_L4, or SID_LOCATION_EFFORT_DEFAULT when manage_effort is enabled) | type - The run type: . | SID_LOCATION_SEND_ONLY - Send pre-scanned location data without performing a new scan | SID_LOCATION_SCAN_ONLY - Perform a scan but do not send the data to the cloud | SID_LOCATION_SCAN_AND_SEND - Perform a scan and send the data to the cloud | . | buffer - Pointer to pre-scanned location data (required for SID_LOCATION_SEND_ONLY, NULL otherwise) | size - Size of the buffer in bytes (required for SID_LOCATION_SEND_ONLY, 0 otherwise) | . The maximum payload size for location data is defined by SID_LOCATION_MAX_PAYLOAD_SIZE (106 bytes). /** * API to scan and send available location information to the cloud to resolve * coordinates. If effort mode is NOT managed, SID_LOCATION_EFFORT_DEFAULT * cannot be used. * * @param[in] handle A pointer to the handle returned by sid_init() * @param[in] config struct containing the configuration for the location request * @param[in] delay_s delay to start scan (if applicable) and uplink data * * @returns #SID_ERROR_NONE in case of success **/ sid_error_t sid_location_run(struct sid_handle *handle, struct sid_location_run_config *config, uint32_t delay_s); // WiFi scan and send uplink struct sid_location_run_config config = { .type = SID_LOCATION_SCAN_AND_SEND, .mode = SID_LOCATION_EFFORT_L3, .buffer = NULL, .size = 0, }; sid_error_t ret = sid_location_run(sidewalk_handle, &config, 0); // GNSS scan only (no uplink) struct sid_location_run_config config = { .type = SID_LOCATION_SCAN_ONLY, .mode = SID_LOCATION_EFFORT_L4, .buffer = NULL, .size = 0, }; sid_error_t ret = sid_location_run(sidewalk_handle, &config, 0); // Send pre-scanned location data (SEND_ONLY) uint8_t location_buffer[SID_LOCATION_MAX_PAYLOAD_SIZE]; // ... populate location_buffer with scan data ... struct sid_location_run_config config = { .type = SID_LOCATION_SEND_ONLY, .mode = SID_LOCATION_EFFORT_L3, // or SID_LOCATION_EFFORT_L4 for GNSS .buffer = location_buffer, .size = sizeof(location_buffer), }; sid_error_t ret = sid_location_run(sidewalk_handle, &config, 0); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#326-sid_location_run", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#326-sid_location_run" },"35": { "doc": "3. Amazon Sidewalk APIs", "title": "3.27 sid_location_set_max_mode", "content": "The sid_location_set_max_mode API is used to set the maximum effort mode allowed for location operations. This is useful when the device is in a low power mode and the developer wants to limit location operations to less power-intensive methods. For example, setting the maximum mode to SID_LOCATION_EFFORT_L1 will restrict location operations to BLE-only methods. The sid_location_set_max_mode API returns error code SID_ERROR_UNINITIALIZED if the handle is NULL, if the Sidewalk stack is not initialized, or if the location library is not initialized. The sid_location_set_max_mode API returns error code SID_ERROR_PARAM_OUT_OF_RANGE if the mode is invalid (negative or greater than or equal to SID_LOCATION_EFFORT_INVALID). The sid_location_set_max_mode API returns error code SID_ERROR_NONE when the maximum effort mode is successfully set. /** * API to set the maximum effort mode allowed (ex. if the device is in a low * power mode, send messages via mode 1) * * @param[in] handle A pointer to the handle returned by sid_init() * @param[in] mode maximum effort mode allowed. * **/ sid_error_t sid_location_set_max_mode(struct sid_handle *handle, enum sid_location_effort_mode mode); // Limit to BLE-only location methods sid_error_t ret = sid_location_set_max_mode(sidewalk_handle, SID_LOCATION_EFFORT_L1); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#327-sid_location_set_max_mode", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#327-sid_location_set_max_mode" },"36": { "doc": "3. Amazon Sidewalk APIs", "title": "3.28 sid_location_get_effort_mode", "content": "The sid_location_get_effort_mode API retrieves the current location effort mode maintained by the location library. This can be used by the developer’s application to query the current location level and make decisions about when to request location updates. The sid_location_get_effort_mode API returns SID_LOCATION_EFFORT_INVALID if the handle is NULL or the location library is not initialized. /** * API to retrieve the location mode maintained by the location library * * @param[in] handle A pointer to the handle returned by sid_init() * * @returns the current sid location effort mode. **/ enum sid_location_effort_mode sid_location_get_effort_mode(struct sid_handle *handle); enum sid_location_effort_mode current_mode = sid_location_get_effort_mode(sidewalk_handle); if (current_mode != SID_LOCATION_EFFORT_INVALID) { // Use current_mode for decision making } . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#328-sid_location_get_effort_mode", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#328-sid_location_get_effort_mode" },"37": { "doc": "3. Amazon Sidewalk APIs", "title": "3.29 sid_location_update_almanac", "content": "The sid_location_update_almanac API is used to sideload GNSS almanac data to the location library. The almanac contains orbital information for GNSS satellites and is used to improve the time to first fix (TTFF) and accuracy of GNSS location resolution. This API provides a mechanism to manually update almanac data from external sources such as the cloud. Note that some GNSS chips may have a built-in almanac demodulation service that can automatically update almanac data over satellite signals. The sid_location_update_almanac API provides an alternative sideload method for almanac updates. This API is currently not implemented and always returns SID_ERROR_NOSUPPORT. /** * API to update the GNSS almanac * * @param[in] handle A pointer to the handle returned by sid_init(). * @param[in] almanac_buffer a pointer to a buffer containing the almanac. * @param[in] almanac_size size of the almanac buffer. * * @returns #SID_ERROR_NONE in case of success **/ sid_error_t sid_location_update_almanac(struct sid_handle *handle, uint8_t *almanac_buffer, size_t almanac_size); uint8_t almanac_data[ALMANAC_SIZE]; // ... populate almanac_data from cloud or other source ... sid_error_t ret = sid_location_update_almanac(sidewalk_handle, almanac_data, sizeof(almanac_data)); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#329-sid_location_update_almanac", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#329-sid_location_update_almanac" },"38": { "doc": "3. Amazon Sidewalk APIs", "title": "3.30 sid_serial_registration_init", "content": "sid_serial_registration_init builds the factory registration stack and the wired link (SID_LINK_TYPE_8) and registers the completion callback, see 2.3.4. It does not start the registration exchange. The Amazon Sidewalk stack does not have to be initialized with sid_init; the serial registration stack is independent of it. The developer’s application initializes the serial transport before calling this API; the transport is not re-initialized by the Amazon Sidewalk stack. The completion callback is called from within the receive path of the registration exchange; it shall only record the completion, for example by setting a flag, and shall not call sid_serial_registration_process or sid_serial_registration_deinit. SID_ERROR_NULL_POINTER is returned if the configuration pointer or the transport pointer is NULL. SID_ERROR_ALREADY_INITIALIZED is returned if the serial registration stack is already initialized. If a component of the serial registration stack fails to initialize, its error code is returned. SID_ERROR_NONE is returned if the serial registration stack is initialized successfully. struct sid_serial_registration_config { /* Application-provided serial/UART transport. The application must bring the transport up * (ifc->serial_init) before calling sid_serial_registration_init(); it is not re-initialized here. */ const struct serial_ifc_context *ifc; /* * Invoked when the device becomes factory-registered. PRECONDITION: runs deep inside the RX / * handshake dispatch stack while the message manager still owns a live app_cmd (freed on unwind). * It MUST only set a flag. It MUST NOT call sid_serial_registration_process(), free resources, or * otherwise re-enter the manager or event queue. */ void (*on_registration_done)(void *ctx); void *ctx; }; /* Build the registration stack + wired PHY and register the completion callback. Does not trigger. */ sid_error_t sid_serial_registration_init(const struct sid_serial_registration_config *cfg); static volatile bool registration_done; static void on_registration_done(void *ctx) { registration_done = true; } // The serial transport is provided by the developer's application, see the reference application struct sid_serial_registration_config cfg = { .ifc = app_serial_registration_uart_get_context(), .on_registration_done = on_registration_done, .ctx = NULL, }; sid_error_t ret = sid_serial_registration_init(&cfg); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#330-sid_serial_registration_init", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#330-sid_serial_registration_init" },"39": { "doc": "3. Amazon Sidewalk APIs", "title": "3.31 sid_serial_registration_start", "content": "sid_serial_registration_start triggers the factory registration exchange: it sends the first frame to the host and returns immediately. The exchange is driven to completion by sid_serial_registration_process, and completion is reported through the callback registered with sid_serial_registration_init. SID_ERROR_UNINITIALIZED is returned if sid_serial_registration_init has not been called. SID_ERROR_NONE is returned if the first frame was sent; other error codes are those of the registration exchange. /* Trigger the factory-registration exchange; sends the first frame and returns immediately. */ sid_error_t sid_serial_registration_start(void); sid_error_t ret = sid_serial_registration_start(); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#331-sid_serial_registration_start", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#331-sid_serial_registration_start" },"40": { "doc": "3. Amazon Sidewalk APIs", "title": "3.32 sid_serial_registration_process", "content": "sid_serial_registration_process drives one non-blocking pass of the registration exchange: it receives and decodes the frames from the host, dispatches them, transmits the responses and runs the event queue. The developer’s application calls it from its main loop, from the moment the host may start registration until the completion callback has been called. It is a no-op before sid_serial_registration_init. /* Drive one non-blocking pass of the registration exchange. Call from the app main loop. */ void sid_serial_registration_process(void); while (!registration_done) { sid_serial_registration_process(); } . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#332-sid_serial_registration_process", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#332-sid_serial_registration_process" },"41": { "doc": "3. Amazon Sidewalk APIs", "title": "3.33 sid_serial_registration_deinit", "content": "sid_serial_registration_deinit tears down the serial registration stack and the wired link brought up by sid_serial_registration_init, in the reverse order of initialization. After it returns, sid_serial_registration_start and sid_serial_registration_process are safe no-ops until sid_serial_registration_init is called again. It shall be called from the main loop and never from the completion callback. SID_ERROR_UNINITIALIZED is returned if the serial registration stack is not initialized. SID_ERROR_NONE is returned if the serial registration stack is de-initialized successfully. sid_error_t sid_serial_registration_deinit(void); sid_error_t ret = sid_serial_registration_deinit(); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#333-sid_serial_registration_deinit", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#333-sid_serial_registration_deinit" },"42": { "doc": "3. Amazon Sidewalk APIs", "title": "3.34 sid_device_information_init", "content": "The Device Information module, including region reporting for Sidewalk internationalization (2.16), is initialized using the sid_device_information_init API. The API accepts a pointer to struct sid_device_info_config and the Sidewalk handle returned by sid_init. On initialization, the module stores the configuration and registers the GET_DEVICE_INFORMATION and DEVICE_CONFIGURATION command handlers. The configuration passed in config is not copied; the developer’s application shall keep it, and the callback structure and static device information it points to, in static storage for as long as the module is initialized. sid_device_information_init does not validate handle — it is accepted even if NULL, since it is neither dereferenced nor stored. sid_device_information_init also does not detect or reject being called a second time without an intervening sid_device_information_deinit; a second call simply overwrites the stored configuration and re-registers the command handler table. The sid_device_information_init API returns error code SID_ERROR_INVALID_ARGS if config is NULL. The sid_device_information_init API returns error code SID_ERROR_NONE when the module is initialized successfully. /** * Initializes the Device Information module, including region reporting, * and registers the GET_DEVICE_INFORMATION / DEVICE_CONFIGURATION command * handlers. * * @param[in] config The device information configuration. Must remain * valid for as long as the module is initialized. * @param[in] handle A pointer to the handle returned by sid_init() * * @returns #SID_ERROR_NONE in case of success. * @returns #SID_ERROR_INVALID_ARGS if config is NULL. */ sid_error_t sid_device_information_init(const struct sid_device_info_config *config, struct sid_handle *handle); static struct sid_device_info_callbacks device_info_callbacks = { .context = &g_app_context, .get_info = on_device_get_info, .set_info = on_device_set_info, }; static const struct sid_device_info_config device_info_cfg = { .info = &device_static_info, .callbacks = &device_info_callbacks, }; /* After sid_init() returns a handle. The config must stay valid for the app lifetime. */ sid_error_t ret = sid_device_information_init(&device_info_cfg, sidewalk_handle); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#334-sid_device_information_init", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#334-sid_device_information_init" },"43": { "doc": "3. Amazon Sidewalk APIs", "title": "3.35 sid_device_information_deinit", "content": "The Device Information module can be de-initialized using the sid_device_information_deinit API. The API takes no arguments. It clears the stored configuration and deregisters the GET_DEVICE_INFORMATION and DEVICE_CONFIGURATION command handlers. The sid_device_information_deinit API always returns SID_ERROR_NONE. /** * Deinitializes the Device Information module and deregisters its * command handlers. * * @returns #SID_ERROR_NONE always. */ sid_error_t sid_device_information_deinit(void); sid_error_t ret = sid_device_information_deinit(); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#335-sid_device_information_deinit", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#335-sid_device_information_deinit" },"44": { "doc": "3. Amazon Sidewalk APIs", "title": "3.36 sid_device_information_is_region_registerable", "content": "sid_device_information_is_region_registerable reports whether the configured region permits registration and radio bring-up on the sub-GHz links. It takes no arguments: it reads the region through the get_info callback of the configuration most recently passed to sid_device_information_init, rather than through a Sidewalk handle. The Amazon Sidewalk stack calls this function internally from sid_start() (3.5), which masks link_mask down to SID_LINK_TYPE_1 (BLE) when this function returns false, rather than refusing to start outright. Integrators do not normally call it directly. See 2.16.4 for the full effect on sid_start(), including the case where masking leaves no link to start. If the Device Information module was never initialized, sid_device_information_is_region_registerable returns true, matching the legacy, pre-i18n behavior described in 2.16.5. /** * Returns whether the configured region permits registration and radio * bring-up on the sub-GHz links. Called internally by the Sidewalk stack * from sid_start(). * * @returns true if the region is NA, EU, or ANZ, or if the Device * Information module is not initialized. * @returns false if the region is unset or unsupported (e.g. Japan). */ bool sid_device_information_is_region_registerable(void); . ", "url": "/sid-api-dg/amazon-sidewalk-apis.html#336-sid_device_information_is_region_registerable", "relUrl": "/sid-api-dg/amazon-sidewalk-apis.html#336-sid_device_information_is_region_registerable" },"45": { "doc": "6.4 Amazon Sidewalk BLE features", "title": "6.4 Amazon Sidewalk BLE features", "content": "6.4.1 Endpoint-initiated Encrypted Connection . It is assumed that an Endpoint is registered and time synchronized. Process flow is presented in 6.16. Obfuscated TXID and Amazon Sidewalk internal server ID are used in the advertisement packet. Details of frames content are presented in 6.2. fig 6.16 BLE Endpoint initiated encrypted connection . The connection request advertisement is an on-demand procedure when an application needs to send an uplink packet but no active connection to the Amazon Sidewalk Cloud is available. A connection request from an Endpoint application API is handled by an Endpoint SDK to translate into a connection request advertisement. The Amazon Sidewalk BLE Gateway forwards the connection request advertisement to the Amazon Sidewalk internal server as a Report Beacon message. The Amazon Sidewalk internal server, based on decoded content, builds a challenge request and sends it back to a BLE Gateway which then forwards the challenge request to the Endpoint over RF. After successful reception and authentication, the Endpoint SDK notifies the application of confirmation of link existence after which the application can send uplink data traffic over the Amazon Sidewalk network. The encrypted link is disconnected due to timeouts and message decryption errors. 6.4.2 Device-to-Device Communication (D2D) . Device to device (D2D) functionality describes encrypted connection of the Amazon Sidewalk Mobile SDK hosted on a mobile phone and an Endpoint. D2D functionality encompasses Amazon Sidewalk Mobile SDK authentication to the Amazon Sidewalk Cloud and encrypted channel establishment between the Mobile Application and an Endpoint. The core of D2D functionality is the Mobile Application to Endpoint device key (D2D_PRIMARY_KEY) that is established on the Endpoint and on the Mobile Application. The customer owning an Endpoint can have more than one instance of the Mobile Application in the Amazon Sidewalk environment. Two basic cases are possible: . | 1x1 configuration - one Mobile Application handles the Endpoint. | Nx1 configuration - multiple Mobile Applications instances with the Endpoint belonging to the customer. All instances of the Mobile Application have the same D2D_PRIMARY_KEY. | . D2D_PRIMARY_KEY is generated independently on the Mobile Application and the Endpoint in case of 1x1 configuration. When an additional instance of the Mobile Application is created (Nx1 configuration) then this additional instance of the Mobile Application gets the D2D_PRIMARY_KEY from the Endpoint using a session key. D2D_PRIMARY_KEY is the input parameter for derivation of the D2D_GCM_KEY, and for derivation of the D2D_GCM_CTRREF_KEY that are used in encrypted communication between the Mobile Application and the Endpoint with either time-based reference or counter-based reference (see Chapter 6.3 for the derivation formula). D2D connection establishment is the base for data exchange between the Mobile Application and the Endpoint. D2D session establishment, Custom class, Challenge request/response and Metrics commands are supported on D2D communication. 6.4.2.1 D2D communication scenarios . D2D communications between the Mobile Application, the Amazon Sidewalk Cloud and the Endpoint include the following: . | The Endpoint is not registered . | Mobile activity . | Detects Endpoint proximity based on Beacon data. | Starts establishing the encrypted channel with the cloud and the Endpoint. | At the end of establishing the encrypted channel: . | Mobile Application instance will have the D2D_PRIMARY_KEY and the frequency of D2D_GCM_KEY key rotation. | . | If channel establishment fails or the BLE link disconnects, and a D2D_PRIMARY_KEY was generated, that key is discarded. | . | Cloud activity . Supports mobile to establish the encrypted channel establishment by validating the Endpoint with signature verification from the Endpoint. | Endpoint activity . | Performs signature verification from the cloud via a Mobile Application to verify it is communicating with a trusted source. | At the end of the procedure of establishing the channel: . | The Endpoint will have the D2D_PRIMARY_KEY and the frequency of D2D_GCM_KEY key rotation. | . | In case of failure or disconnection of BLE link, D2D_PRIMARY_KEY is discarded if generated. | . | . | The Endpoint is registered and Mobile Application has Mobile to device key . | Mobile activity . | Checks if the Endpoint is registered with the Beacon data and: . | if authentication material is present, authenticates the obfuscated TXID with the authentication material for the Amazon Sidewalk ID. | if authentication material is not present, requests that the cloud to identify the device and receives the authentication material. | if Endpoint is requesting time sync, Mobile Application shall request that the Amazon Sidewalk Cloud provide time to the Endpoint | . | Establishes direct BLE connection to exchange data using time-based encryption (D2D_GCM_KEY key). | . | Cloud activity . Performs the Endpoint authentication on the mobile request and provides authentication material to the Mobile Application. | Endpoint activity . Decrypts the packet (using D2D_GCM_KEY key) and provide the payload to application. | . | The Endpoint is registered and mobile does not have Mobile to device key . | Mobile activity . | Checks if the Endpoint is registered with the Beacon data and: . | if authenticated material is present, authenticates the obfuscated TXID with the authentication material for the Amazon Sidewalk ID. | if authenticated material is not present, requests that the cloud identify the device and receives the authentication material. | if Endpoint is requesting time sync, Mobile Application shall request that the Amazon Sidewalk Cloud provide time to the Endpoint | . | Requests the cloud to send a challenge request to the Endpoint. The Endpoint shall respond with its challenge response to the cloud for authentication and the Endpoint shall open up the encrypted session channel. | Starts the procedure of establishing the encrypted channel and derives the session key. A derived key from the session key shall be used to get the D2D_PRIMARY_KEY from the Endpoint. | . | Cloud activity . | Performs the Endpoint authentication on the mobile request and provides authentication material to the Mobile Application. | Sends the challenge request to the Endpoint via the Mobile Application. | Validates the challenge response from the Endpoint. | . | Endpoint activity . | Validates the challenge request. When the validation is successful then sends the challenge response to the cloud. | Opens up the gate to honor commands required for establishing an encrypted session and derivation of session key. | Derived key from session key shall be used to share the D2D_PRIMARY_KEY to the Mobile Application. | . | . | The Endpoint is registered and both the Endpoint and Mobile Application do not have primary key . | Mobile activity . | Checks if the Endpoint is registered with the Beacon data and: . | if authenticated material is present, authenticates the obfuscated TXID with the authentication material for the Amazon Sidewalk ID. | if authenticate material is not present, requests that the cloud identify the device and receives the authentication material. | if the Endpoint is requesting time sync, the Mobile Application shall request that the Amazon Sidewalk Cloud provide time to the Endpoint. | . | Requests that the cloud send a challenge request to the Endpoint. The Endpoint shall respond with its challenge response to the cloud for verification. | Starts the procedure of establishing the encrypted channel and derives the session key. Since the Endpoint does not have the D2D_PRIMARY_KEY, the Endpoint shall store the session key as D2D_PRIMARY_KEY. D2D_PRIMARY_KEY is shared using a derived key from session key. | . | Cloud activity . | Performs the Endpoint authentication on the mobile request and provides authentication material to the Mobile Application. | Sends the challenge request to the Endpoint via the Mobile Application. | Validates the challenge response from the Endpoint. | . | Endpoint activity . | Validates the challenge request. When the validation is successful then sends the challenge response to the cloud. | Opens up the gate to honor commands required for establishing an encrypted session and derivation of session key. | Derived key from session key shall be used to share the D2D_PRIMARY_KEY to the Mobile Application. | . | . | The Endpoint is registered to another user . The Amazon Sidewalk Cloud shall prevent D2D communication from the Mobile Application to the Endpoint by not providing the authentication material to the Mobile Application. | . 6.4.3 Touchless Registration (Frustration-Free Network) . Frustration-Free Network (FFN) is a procedure where an Endpoint is registered onto the Amazon Sidewalk network without user interaction (Touchless). Simplified architecture diagram is presented in 6.17. fig 6.17 BLE FFN architecture . There are three types of user accounts possible to provide FFN setup: . | User account type | Registration type | . | Amazon account | Type A registration | . | Enterprise/Partner account | Type B registration | . | No account (WAN use cases) | Type C registration | . Setup options are presented in 6.18. fig 6.18 BLE FFN touchless registration flow . The FFN process consists of two preliminary steps: Amazon Sidewalk registration and initialization session and actual registration in the Amazon Sidewalk system. During the FFN procedure the Endpoint is verified and authenticated by the Amazon Sidewalk Cloud and the credentials, and the key and configuration are stored in the Endpoint and in the cloud registry. Following completion of the FFN procedure, the BLE link is disconnected. The Endpoint is then ready to establish a link with its updated key and configuration. Using the link, the Endpoint can obtain time information and perform any required Amazon Sidewalk functionality. For detailed flow diagrams see: 6.19, and 6.20. fig 6.19 BLE Endpoint registration 1of2 . fig 6.20 BLE Endpoint registration 2of2 . 6.4.4 Time Sync trigger over Amazon Sidewalk BLE Beacon . Time Synchronization with a common time source is a prerequisite for the operation of time-based authentication materials and encryption of messages in normal operation mode. During the boot-up process, the internal clock in the Endpoint is not synchronized with the NTP source, therefore counter-based synchronization is carried out in the first stage of establishing the connection. The counter is represented by 4 B length TimeSync. The synchronization process is as follows: An Endpoint sends the TimeSync Beacon to the Gateway and the Gateway forwards the TimeSync Beacon once every 30 s to the Amazon Sidewalk TimeSync Server. The Amazon Sidewalk TimeSync server, based on the received Beacon, authenticates the counter-based TXID and sends back to the Gateway a notify Response Time with one time authentication key. Gateway provides the reference time to the Endpoint. After authenticating the response time, the Endpoint disconnects the BLE link and changes its state to obfuscated time-based TXID. During normal operation mode, the Endpoint will move to periodic TimeSync mode once every 2 h for 60 s to correct time drift. If the time cannot be synced, then the Endpoint shall remain time synced and Beacon with obfuscated time-based TXID for normal operation. When the Endpoint detects the drift to be more than 60 s, then the Endpoint will reset the network time and more into TimeSync request mode till the Endpoint receives a time from the Amazon Sidewalk Cloud. fig 6.21 BLE TimeSync flow . For details of the events used for time synchronization, and the periodicity of events, see Table 6.6. Table 6.6 Periodicity of TimeSync events . | TimeSync events | Periodicity | Comments | . | Beaconing Interval | 160ms for the first 30s after boot and 1s afterward |   | . | Time sync beacons Upload from gateway | 30 sec |   | . | Periodic time sync request (counter-based) | Every 2 hours | For 60 seconds | . 6.4.5 Network Key Refresh . 6.4.5.1 Introduction . Sufficiently frequent key exchange is essential to avoid system compromise. Based on estimation of traffic and keys’ complexity, the key refresh procedure is to be triggered periodically for the Endpoint. This periodicity is configurable by the Amazon Sidewalk Cloud. The network key refresh process is similar to the registration procedure. The network key refresh process is triggered by the cloud service in the Amazon Sidewalk system. Due to available bandwidth in the BLE channel, the impact for the system performance during executing network key refreshing procedure can be neglected. Due to lack of a direct TCP link between Endpoint and Network Server an intermediate state of the state machine maintaining both established (previous) keys and current (new) keys is necessary. 6.4.5.2 Key Refresh Flow . | Key refreshing scheduler initiates Key Refresh process using a time-based policy for cloud-initiated Key Refresh request. | Keep track of Key Refresh state and update flag Key Refresh pending if the Endpoint is not in a pending reset state. | Perform the Key Refresh if the Endpoint is time-synchronized. | Check Key Refresh Initiated flag for device refresh state | Provisioning Service will send a cloud-authenticated message to start Key Refresh process on the Endpoint | . | Upon handshake verification, Amazon Sidewalk Provisioning Service shall indicate to the Network Server to delete the old authentication material and calculate the new authentication material. | On completion of the Key Refresh procedure, the Endpoint shall Beacon with the TXID generated with the new key. | . 6.4.5.3 Sequence Diagram . The process follows the diagram shown in 6.22 . fig 6.22 BLE Network key refresh . Details about state machine flags are presented below. 6.4.5.4 States for Key Refresh . | KEY_REFRESH_TRIGGERED: When the scheduler trigger event is received for an Endpoint in the provisioning service and GET_ENCRYPTION_CAPABILITIES is sent to the Endpoint from the cloud. | KEY_REFRESH_INITIATED: When the Initial commands are received for authentication with Key Refresh flag. | KEY_REFRESH_UNSUCCESSFUL: If any error occurs during the Key Refresh flows and the current state of the device is one of the above, set retry count accordingly. | KEY_REFRESH_PROCESSED: When Endpoint signature is verified and processed successfully (cloud has old and new keys stored for the device). | KEY_REFRESH_COMPLETED: When the Perform Handshake is successful, the device entry will have this state (old key will be cleared and only new key will be maintained). | . For intermediate step failure, the Endpoint resets back to initialization state for the Key Refresh procedure to be restarted. 6.4.6 Deregistration . Deregistration of the Endpoint and Endpoint reset work together in BLE mode. When the Amazon account user or AWS API user initiates the deregistration process, its authorization is validated first with its Amazon LWA or AWS account credentials respectively. The next step is to update the Endpoint state in AWS IoT wireless from “registered” to “provisioned” and cancel Endpoint associations. The Amazon Sidewalk Cloud will mark the internal state of the Endpoint to be in Pending Reset state. The Amazon Sidewalk Cloud continues to hold device keys and authentication material until an Endpoint becomes reachable by the network and successfully resets. A cloud-authenticated RESET message is sent from the cloud to the Amazon Sidewalk Mobile SDK. After the Mobile SDK determines that the Endpoint is not in initialization mode, the Mobile SDK forwards the RESET command to an Endpoint. An Endpoint answers with a cloud-authenticated RESET_RESPONSE message and removes all the credentials and transitions to a provisioned state. The Endpoint starts sending initialization Beacon message, awaiting reregistration. During this time, the Amazon Sidewalk Mobile SDK is scanning for registration Beacon from the Endpoint. After successful registration and Beacon reception, the Amazon Sidewalk Mobile SDK sends Deregister Device message to the cloud proxy service to finalize the deregistration process in the cloud. The Endpoint status is published, credentials are removed, session information is removed and confirmation response is sent back to the Amazon Sidewalk Mobile SDK. The Endpoint state machine is presented in 6.23. fig 6.23 BLE Endpoint state machine . A detailed process flow is presented in 6.26. fig 6.24 BLE deregistration . If a Mobile is not in the proximity of the Endpoint, then the cloud marks the device state as pending reset and attempts to send a deregistration command via an available Gateway to reach the Endpoint when the Endpoint tries communicating with the Amazon Sidewalk Cloud. A similar deregistration procedure is followed using a Gateway. When the user deregisters the Endpoint on the Amazon Sidewalk Cloud, the Amazon Sidewalk Cloud marks the Endpoint in Reset Pending state and waits for any uplink message from the Endpoint. When an uplink message is received and the Endpoint is in Reset Pending state, the authenticated RESET message is sent to the Endpoint via a reachable Gateway. The Endpoint authenticates the RESET command and then sends the RESET_RESPONSE as best effort. The Endpoint shall then remove credentials and shall move to a deregistration state awaiting reregistration. A detailed process flow is presented in 6.25. fig 6.25 Deregistration by Sidewalk Gateway when Endpoint is not in proximity of mobile application . 6.26 shows the reset message sent might or might not reach the Endpoint. Even if the reset message does not reach the Endpoint, it will be resent upon receiving the first uplink from the Endpoint. fig 6.26 BLE GW deregistration . An Endpoint can trigger deregistration using sid_set_factory_reset API provided to the application. Amazon Sidewalk SDK as best effort shall attempt to send Factory Reset Notify using an available link to the Amazon Sidewalk Cloud via a Gateway and then clear the credentials. The Endpoint shall move to waiting for reregistration state. A detailed process flow is presented in 6.27 . fig 6.27 BLE Endpoint Triggered deregistration . ", "url": "/specifications/sidewalk-protocol-spec/ble-protocol-stack/amazon-sidewalk-ble-features.html", "relUrl": "/specifications/sidewalk-protocol-spec/ble-protocol-stack/amazon-sidewalk-ble-features.html" },"46": { "doc": "6.2 Amazon Sidewalk BLE protocol stack", "title": "6.2 Amazon Sidewalk BLE protocol stack", "content": "Amazon Sidewalk BLE supports two types of messages that play the main role in the BLE communication between Endpoints in the Amazon Sidewalk environment. The first message type is the Beacon that is used for communication initiation, e.g. data transfer, registration, time synchronization. The protocol stack for the Beacon is shown in figure 6.1 . fig 6.1 BLE Beacon stack . The Beacon frame format and a detailed description of the different advertisement payloads is included in section 6.2.1. The second message type is the data message that is used for data transmission and reception by the user application (custom commands) and Amazon Sidewalk management and security class commands used for registration, time synchronization, factory reset, and challenge request. The protocol stack of the data message is shown in figure 6.2. The Application Layer frame format and application commands are described in Chapter 3. The Presentation Layer frame format is described in section 5.1.1.1. The Flex Layer is described in section 6.2.1.6. fig 6.2 BLE Data stack . The AMA (Alexa Mobile Accessory) Layer is common to the Beacon and Data formats. Details of the AMA frame and AMA frame types may be found in section 6.2.1.9. The BLE Link Layer and BLE PHY are described in the BLE Specification v 4.2. 6.2.1 Beacon frame format . The BLE Beacon is used for communication initiation. The following types of Beacons are defined based on the communication purpose: . | Beacon for initiating registration of a new Endpoint to the Amazon Sidewalk network. | Beacon for initiating counter-based time synchronization procedure from the Amazon Sidewalk Cloud. | Beacon for initiating Endpoint-encrypted connection. | Beacon for presence detection and determining device state (ONLINE/OFFLINE). | . The Beacon frame format is common to all Beacons, and selected fields in the Beacon frame define the purpose of the Beacon. The Beacon frame format contains two main blocks: Header and Manufacturing Data. The Header includes information related to the BLE Ad Type and BLE UUID of the service. Manufacturing Data contains information about the Amazon Sidewalk application, network service, device state and Application-Specific Data. fig 6.3 BLE Beacon - Blocks . Every time the SDK starts advertising, the device advertises every 160 ms for the first 30 s after boot and 1 s afterwards, independently of the advertisement type. These values are user-configurable in the SDK. The Sidewalk BLE Gateways does not scan for advertisements all the time. Increasing the frequency of advertisements will reduce the latency to establish a BLE connection. However, configuring a longer interval for advertisement periodicity may result in high connection latency or an inability to connect altogether, if the Endpoint’s advertising window does not overlap with the Sidewalk BLE Gateway’s scanning window. An Endpoint shall move to perform periodic time synchronization advertising mode for 60 s once every two (default) hours. Beacons advertised by the Endpoint shall be forwarded by a Gateway to the cloud using three types of policies: . | Upload - Beacons are forwarded to the cloud without a delay. | Accumulate - the Gateways maintain the latest Beacon information for each type of Beacon received and forward the first Beacon received of a particular type. The accumulated Beacon is sent after the defined accumulation period. | Drop - unknown or unsupported Beacon formats are dropped by the Gateway. | . | Beacon type | Policy name | Accumulation period | . | Registration/Provisioning | Upload | N/A | . | Counter-based time synchronization | Accumulate | 30 s | . | Time-based connection request | Accumulate | 30 s | . | Presence detection and determining device state | Accumulate | 10 min | . | Unknown | Drop | N/A | . 6.2.1.1 Beacon Header . The Beacon header block is coded in Tag, Length, Value format. All fields of the Beacon header are mandatory. Each field has only one value that is defined and supported by the specification. The header fields are presented in figure 6.4. fig 6.4 BLE Beacon - Header . The header field values are constant and not configurable. The following values shall be applied in each header field: . | Field name | Field size | Field value | Description | . | Flags Ad Type Length | 1B | 0x02 |   | . | Flags Ad Type Identifier | 1B | 0x01 |   | . | Flags Ad Type Value | 1B | 0x06 | BLE only accessory | . | List of 16-bit Service Class UID Ad Type Length | 1B | 0x03 |   | . | List of 16-bit Service Class UUID Ad Type Identifier | 1B | 0x03 |   | . | List of 16-bit Service Class UUID Ad Type Value | 2B | 0x03FE | AMA Service UUID | . 6.2.1.2 Beacon Manufacturing Data . Manufacturing Data fields are presented in figure 6.5. fig 6.5 BLE Beacon - Manufacturing Data . The length of the Manufacturing Data is mainly determined by application-specific data that contain information used for Beacon sender identification and authorization. The Manufacturing Data Tag and Vendor ID are constant and not configurable. | Field name | Field size | Field value | Description | . | Manufacturing Data Length | 1B | 0xB - 0x17 | Size of subsequent fields of the Manufacturing Data Block | . | Manufacturing Data Tag | 1B | 0xFF |   | . | Vendor ID | 2B | 0x0171 | Amazon.com Services LLC (value assigned by Bluetooth SIG) | . | Service Type | Service value | Service Description | . | Sidewalk Services | 0x00 - 0x06 | Sidewalk Cloud Services | . |   | 0x07 - 0x1F | reserved | . |   | 0x20 | Amazon Device Application | . |   | 0x21 | IoT Wireless Application | . |   | 0x22 - 0x25 | Amazon Device Application | . |   | 0x26 - 0xFF | reserved | . 6.2.1.3 Manufacturing data - Application ID . The Application ID field contains the identification of the Beacon receiver. 6.2.1.4 Manufacturing data - Device State . Device State includes information related to the device of the Beacon sender. fig 6.6 BLE Beacon - Device State . | Mnemonic | Length | Value | Description | . | dev_prot | 1b | 0x0 | reserved | . |   |   | 0x1 | BLE | . | dev_mod | 2b | 0x0 | Normal mode | . |   |   | 0x1 | Registration Mode | . |   |   | 0x2 | Connection Request | . |   |   | 0x3 | reserved | . | bat_lvl | 2b | 0x0 | Critical level | . |   |   | 0x1 | Low level | . |   |   | 0x2 | Normal level | . |   |   | 0x3 | reserved | . | adv_frmt | 3b | 0x0 - 0x1 | Sidewalk Beacon version | . |   |   | 0x2 - 0x7 | reserved | . 6.2.1.5 Manufacturing data - Application Specific Data . fig 6.7 BLE Beacon - Application Specific Data . Application-Specific Data format may differ for different Beacon types. Frame Indicator contains information related to the type of device identification that is included in the TXID field (see frmt_ind description). It contains information about the Beacon/frame format version that is supported by the sender of the Beacon (see section 5.1.1 and uasl_ver description). | Field name | Field value | Field meaning | . | frmt_ind | 0x0 | TXID time based frame | . |   | 0x1 | TXID counter based frame | . |   | 0x2 | Sidewalk ID / SMSN based frame | . |   | 0x3 | reserved | . | uasl_ver | 0x0 | ASL version | . |   | 0x1 - 0x3 | reserved | . | pld_ind | 0x0 | No Data | . |   | 0x1 - 0xF | reserved | . The Frame Indicator has the following values defined for the different types of Beacon: . | Application ID | Device State | Frame indicator Value | Beacon type | . | 0x04 | 0x23, 0x2B, 0x33 | 0x80 | Registration/Provisioning | . | 0x03 | 0x21, 0x29, 0x31 | 0x40 | Counter-based time synchronization | . | 0x06 | 0x35, 0x2D, 0x25 | 0x00 | Time-based connection request | . | 0x21 | 0x21, 0x29, 0x31 | 0x00 | Presence detection and determining device state | . The Application-Specific Data format for different Beacon types is presented in figures 6.8, 6.9, and 6.10. | Beacon for initiating registration of a new device to the Amazon Sidewalk network. | . fig 6.8 BLE Beacon - Application Specific Data - Registration and Provisioning . | Beacon for initiating counter-based time synchronization. | . fig 6.9 BLE Beacon - Application Specific Data - Counter based time synchronization . | Beacon for initiating Endpoint connection and presence detection. | . fig 6.10 BLE Beacon - Application Specific Data - Time based connection request and presence detection . 6.2.1.6 Flex frame format . Amazon Sidewalk data transmission over BLE uses the single flex frame format. The frame format is presented in figure 6.11. The frame contains two main blocks: . | Flex Header Length that indicates the length of subsequent fields. | Flex Header that contains the sequence of several flex keys that include flex key tags, length and their associated values. Flex key tags, values and description of each flex key are described in section 6.2.1.8. Flex key shall be coded in either Standard format or Optimized format (see section 6.2.1.7). | . fig 6.11 BLE Data - Flex layer frame format . 6.2.1.7 Flex key coding format . Flex keys are encoded in either Standard or Optimized format. The most significant 2 bits of the first octet in the flex key, define the encoding format used. | Bits 8 and 7 value | Coding format | Comment | . | 0x3 | standard | The flex key value size is indicated in the Flex Key Value Length field (see fig 6.12). | . | 0x2 | 4B optimized format | The flex component value is coded on 4 B. (see fig 6.13) | . | 0x1 | 2B optimized format | The flex component value is coded on 2 B. (see fig 6.14) | . | 0x0 | 1B optimized format | The flex component value is coded on 1 B. (see fig 6.15) | . fig 6.12 Flex key coding - Standard format . fig 6.13 Flex key coding - 4 B optimized format . fig 6.14 Flex key coding - 2 B optimized format . fig 6.15 Flex key coding - 1 B optimized format . 6.2.1.8 Flex keys . The flex keys supported by Amazon Sidewalk data transmission over BLE are shown in Table 6.1 . Table 6.1 Flex keys . | Flex Key Name | Flex Key Tag | Flex Key Value Length | Presence M/O/C | Description | . | FLEX_KEY_DST | 0x01 | 1 - 5B | M | Destination address. The coding is the same as dst field in Link Layer - Message frame format (see section 5.1.3.2). | . | FLEX_KEY_DST_FRMT | 0x02 | 1B | M | Destination address format (see FLEX_KEY_DST). The coding is the same as dst_frmt field in Link Layer - Message frame format (see section 5.1.3.2). | . | FLEX_KEY_ENCR_ENA | 0x04 | 1B | M | Network level encryption flag. Value 0x00 and absence of the flex components means that encryption is disabled. Value 0x01 means that encryption is enabled. The Flex Payload is encrypted. | . | FLEX_KEY_SRC | 0x10 | 1 - 5B | M | Source address. The coding is the same as src field in Link Layer - Message frame format (see section 5.1.3.2). | . | FLEX_KEY_SRC_FRMT | 0x11 | 1B | M | Source address format (see FLEX_KEY_SRC). The coding is the same as src_frmt field in Link Layer - Message frame format (see section 5.1.3.2). | . | FLEX_KEY_PROTOCOL_VER | 0x12 | 1B | M | Flex Protocol Version Number. Value 0x01 is the only value supported by the specification. | . | FLEX_KEY_SEC_REF | 0x1B | 1B | M | Security reference configuration. The coding is the same as sec_ref field in Network Layer frame format (see section 5.1.2.2). Absence of this flex component means that security reference is GCS. | . | FLEX_KEY_SEC_REF_COUNTER_VAL | 0x1C | 4B | C | Counter value to be used as security reference. The field is mandatory when FLEX_KEY_SEC_REF indicates security reference COUNTER. | . | FLEX_KEY_SEC_TOPOLOGY | 0x1E | 1B | M | Network security topology. The coding is the same as sec_top field in Network Layer frame format (see section 5.1.2.2). | . | FLEX_KEY_LL_SEQ_NUM | 0x21 | 1 - 3B | M | BLE Link Layer sequence number. 2MSbs specify size of field in bytes. | . | FLEX_KEY_AUTH_TAG | 0x23 | 4B | M | Authentication tag. | . | FLEX_KEY_IS_DATA_ASL_FORMATTED | 0x2B | 1B | M | Flex Payload formatting flag. Value 0x00 or absence of this flex component means that Presentation Layer is not included (not supported, used for backward compatibility only). Value 0x01 means the ASL frame format. | . 6.2.1.9 AMA frame format . The Amazon Sidewalk frame format is encapsulated within an Amazon proprietary (AMA - Alexa Mobile Accessory) format for which the specification will be publicly available in the near future. ", "url": "/specifications/sidewalk-protocol-spec/ble-protocol-stack/amazon-sidewalk-ble-protocol-stack.html", "relUrl": "/specifications/sidewalk-protocol-spec/ble-protocol-stack/amazon-sidewalk-ble-protocol-stack.html" },"47": { "doc": "6.1 Amazon Sidewalk BLE requirements", "title": "6.1 Amazon Sidewalk BLE requirements", "content": "An Endpoint hosting an Amazon Sidewalk mobile application or working as a Gateway shall support the following functionalities: . | Functionality | A device hosting mobile application or a Gateway requirement | . | BLE spec support | Minimum: BLE 4.2 (Not leveraging security features) | . | Number of concurrent connections | Minimum: 4Preferred: 6 | . | Supported PHY layers | 1.0 Mbps (minimum)2.0 Mbps | . 6.1.1 Endpoint software requirements . | Functionality | Endpoint requirement | . | BLE spec support | Minimum: BLE 4.2 (Not leveraging security features) | . | Profile | ATT (GATT) and GAP | . | Support for peripheral role (and advertiser) | Yes | . | Support for central role (and scanner) | No | . | Number of concurrent connections | N/A - only one connection support | . | Supported PHY layers | 1.0 Mbps (minimum)2.0 Mbps | . | Support for configurable ATT MTU size | Minimum: 185BRecommended: 512B | . | Support for extended advertising | No | . | Support for data length extension | Yes - 251B | . | Support for L2CAP with LE credit-based flow control mode | No | . | Support for LL privacy | Yes | . | Advertisement Interval | Alternating 160 ms and 30 s and 1 s [+/- 10 ms] for the rest of the time | . | Advertisement delay/window | 0-10 ms | . | Connection Interval | 30 ms - 4 s (based for use case) - enforced by central | . | Peripheral latency | Default 0 | . 6.1.2 BLE KPIs . | KPIs | Type | Target | Definition | Notes | . | Concurrent connection |   | Minimum: 4Preferred: 6 | Minimum simultaneous connection | KPIs for the Gateway or cellular phone with end user mobile application | . | Packet latency |   | Less than 2 s | Latency for beacon detection | Based on scanning interval KPIs for the Gateway or cellular phone with end user mobile application | . | Latency to connection |   | Less than 1s | Latency to get connected via central after beacon detection |   | . 6.1.3 Traffic patterns . | Pattern | Occurrence | Description | Size | Comments | . | Advertisement | 160 ms for 30 s, 1 s afterwards | Standard Advertisement packet | 31B |   | . | Connection management | Upon each connection establishment | AMA stack handshake messages | Less than 32 Bytes each | The procedure contains two TX and two RX transmissions | . | Authentication |   | Beacon packet message on BLE connection | Fragmentation dependent. AMA fragmentation size depends on negotiated BLE MTU between central and peripheral |   | . | Time synchronization message |   |   | Up to 255 Bytes of BLE payload |   | . ", "url": "/specifications/sidewalk-protocol-spec/ble-protocol-stack/amazon-sidewalk-ble-requirements.html", "relUrl": "/specifications/sidewalk-protocol-spec/ble-protocol-stack/amazon-sidewalk-ble-requirements.html" },"48": { "doc": "6.3 Amazon Sidewalk BLE security", "title": "6.3 Amazon Sidewalk BLE security", "content": "The Amazon Sidewalk security model, architecture and certificate chain are described in Chapter 4, section 4.1, section 4.1.1, section 4.1.2. The frame structure is described in section 4.8. The key structure and names, key exchange and authentication procedure are the same as those described for sub-GHz technology in section 4.5. The following sections of the document focus on the differences in implementation for the specificity of the BLE medium (high bandwidth and available frame length 255 B). The procedures for synchronization, registration and authentication of an Endpoint in the Amazon Sidewalk system are described in Chapter 4, and in section 4.2 and section 4.4.2.2. 6.3.1 Amazon Sidewalk Application Layer credentials . Detailed specification for the Amazon Sidewalk Application Layer credentials for Network Server and Application Server are presented in the following subsections. 6.3.1.1 Network Server Encryption/Decryption . Counter-based credentials are used only after a factory reset when an Endpoint has not yet synchronized time. Time-based credentials are used for regular data traffic. Symmetric keys with 128 bit length are used for coding the Network Server link. Authentication tag is 4 B size. Initialization vector is 12 B length. Additional Authentication Data are a concatenation of Flex parameters listed in Table 6.2 below. Table 6.2 Encryption and Decryption parameters . | Credentials | Time-based Commands | Counter-based Commands | Registration (Touchless FFN / Mobile) | . | Key type | GCM_KEY | GCM_CTRREF_KEY | GCM_CTRREF_KEY | . | Authentication tag | 4B | 4B | 4B | . | AAD | 1B Flex Header lengthFLEX_KEY_LL_SEQ_NUMFLEX_KEY_SRC_FRMT | FLEX_KEY_SRCFLEX_KEY_DST_FRMT | FLEX_KEY_DSTFLEX_KEY_ENCR_ENAFLEX_KEY_PROTOCOL_VERFLEX_KEY_SEC_REF_COUNTER_VALFLEX_KEY_SEC_TOPOLOGYFLEX_KEY_SEC_REFFLEX_KEY_IS_DATA_ASL_FORMATTED | 1B Flex Header lengthFLEX_KEY_LL_SEQ_NUMFLEX_KEY_SRC_FRMT | FLEX_KEY_SRCFLEX_KEY_DST_FRMT | FLEX_KEY_DSTFLEX_KEY_ENCR_ENAFLEX_KEY_PROTOCOL_VERFLEX_KEY_SEC_REF_COUNTER_VALFLEX_KEY_SEC_TOPOLOGYFLEX_KEY_SEC_REFFLEX_KEY_IS_DATA_ASL_FORMATTED | 1B Flex Header lengthFLEX_KEY_LL_SEQ_NUMFLEX_KEY_SRC_FRMT | FLEX_KEY_SRCFLEX_KEY_DST_FRMT | FLEX_KEY_DSTFLEX_KEY_ENCR_ENAFLEX_KEY_PROTOCOL_VERFLEX_KEY_SEC_REF_COUNTER_VALFLEX_KEY_SEC_TOPOLOGYFLEX_KEY_SEC_REFFLEX_KEY_IS_DATA_ASL_FORMATTED | . | IV | 5B Source ID | 2b Link type22b Sequence number | 4B Reference time | 5B Source ID | 2b Link type22b Sequence number | 4B counter reference | 5B Source ID | 2b Link type22b Sequence number | 4B counter reference | . Link type: 0x0 = Radio, 0x1 = BLE . 6.3.1.2 Counter-based network server security . Counter-based network security is used in the registration procedure and the deregistration procedure when an Endpoint has not yet synchronized time. Payload is processed according to the formula: . AES-GCM (Encrypted Payload, AAD, IV, Authentication TAG, GCM_CTRREF_KEY) . where . GCM_CTRREF_KEY = CMAC(NETWORK_PRIMARY_KEY, \"Network KDF Dev Ntw GCM COUNTER\" | Counter Reference) . and Counter Reference = Counter value supplied in the flex header. 6.3.1.3 Network Server Authentication parameters (Only TIME_SYNC command) . Counter-based time synchronization (TIME_SYNC command) is used when an Endpoint reboots and/or over the periodic time sync. The only difference between the time-based and counter-based time sync commands is the key type used. Details are presented in Table 6.3. Table 6.3 BLE key types . | Credentials | Time-based | Counter-based | . | Key type | TSYNC_RESP_KEY (Not Supported) | TSYNC_RESP_CTRREF_KEY | . | Authentication Tag (MAC) size | 4B | 4B | . | IV (Initialization Vector) | None | None | . | AAD (Additional Authentication Data) | 1B Flex Header lengthFLEX_KEY_LL_SEQ_NUM | FLEX_KEY_SRC_FRMTFLEX_KEY_SRC | FLEX_KEY_DST_FRMTFLEX_KEY_DST | FLEX_KEY_ENCR_ENAFLEX_KEY_PROTOCOL_VERFLEX_KEY_SEC_REF_COUNTER_VALFLEX_KEY_SEC_TOPOLOGY | FLEX_KEY_SEC_REFFLEX_KEY_IS_DATA_ASL_FORMATTED | 1B Flex Header lengthFLEX_KEY_LL_SEQ_NUM | FLEX_KEY_SRC_FRMTFLEX_KEY_SRC | FLEX_KEY_DST_FRMTFLEX_KEY_DST | FLEX_KEY_ENCR_ENAFLEX_KEY_PROTOCOL_VERFLEX_KEY_SEC_REF_COUNTER_VALFLEX_KEY_SEC_TOPOLOGY | FLEX_KEY_SEC_REFFLEX_KEY_IS_DATA_ASL_FORMATTED | . 6.3.2 Application Server Encryption/Decryption . AES-CTR cryptography is used for Application Server data processing. Details are presented in Table 6.4. Table 6.4 Encryption/Decryption parameters . | Credentials | Time based | Registration | . | Key type | APP_CTR_KEY | APP_GCM_CTRREF_KEY | . | AAD (Additional Authentication Data) | NONE | 1B Flex Header length | FLEX_KEY_LL_SEQ_NUMFLEX_KEY_SRC_FRMT | FLEX_KEY_SRC | FLEX_KEY_DST_FRMTFLEX_KEY_DST | FLEX_KEY_ENCR_ENAFLEX_KEY_PROTOCOL_VER | FLEX_KEY_SEC_REF_COUNTER_VALFLEX_KEY_SEC_TOPOLOGY | FLEX_KEY_SEC_REFFLEX_KEY_IS_DATA_ASL_FORMATTED | 2B - 4B of plain text ASL header | . | Authentication Tag (MAC) size | NONE | 4B | . | IV (Initialization Vector) | 5B Source ID | 1b uplink/downlink | 7b Zeros2B app layer seqn | 4B time reference | 4B ZerosSource ID: Component generating the packetUL: Sidewalk IDDL: Cloud component generating the packet1b uplink/downlink: 1 = uplink, 0 = downlink4B Zeros: Padding to align 16Bytes IV | 5B Source ID | 1b Link type | 7b null2B app layer seqn | 4B counter referenceSource ID: Component generating the packetUL: Sidewalk IDDL: Cloud component generating the packet (Provisioning Service)link type: 1 = uplink, 0 = downlink | . 6.3.3 D2D-related parameters . D2D feature uses a security procedure similar to that used for registration. D2D_PRIMARY_KEY is used for mobile to Endpoint communication. Derived keys with their credentials and derivation method are in Table 6.5. Table 6.5 Device to device keys . | Credentials | D2D_GCM_KEY | D2D_GCM_CTRREF_KEY | . | Key type | time based | counter based | . | Authentication tag | 4B | 4B | . | AAD | 1B Flex Header length | FLEX_KEY_LL_SEQ_NUMFLEX_KEY_SRC_FRMT | FLEX_KEY_SRCFLEX_KEY_DST_FRMT | FLEX_KEY_DSTFLEX_KEY_ENCR_ENA | FLEX_KEY_PROTOCOL_VERFLEX_KEY_SEC_REF_COUNTER_VALFLEX_KEY_SEC_TOPOLOGY | FLEX_KEY_SEC_REFFLEX_KEY_IS_DATA_ASL_FORMATTED | 1B Flex Header length | FLEX_KEY_LL_SEQ_NUMFLEX_KEY_SRC_FRMT | FLEX_KEY_SRCFLEX_KEY_DST_FRMT | FLEX_KEY_DSTFLEX_KEY_ENCR_ENA | FLEX_KEY_PROTOCOL_VERFLEX_KEY_SEC_REF_COUNTER_VALFLEX_KEY_SEC_TOPOLOGY | FLEX_KEY_SEC_REFFLEX_KEY_IS_DATA_ASL_FORMATTED | . | IV | 5B Source ID | 2b Link type22b Sequence number | 4B counter reference | 5B Source ID | 2b Link type22b Sequence number | 4B counter reference | . | Key derivation | CMAC(D2D_PRIMARY_KEY, \"Mobile KDF Device Mobile GCM\" | time reference for this key) | CMAC(D2D_PRIMARY_KEY, \"Mobile KDF Device Mobile GCM COUNTER\" | [0x00, 0x00, 0x00, 0x00]) | . ", "url": "/specifications/sidewalk-protocol-spec/ble-protocol-stack/amazon-sidewalk-ble-security.html", "relUrl": "/specifications/sidewalk-protocol-spec/ble-protocol-stack/amazon-sidewalk-ble-security.html" },"49": { "doc": "5.5 Amazon Sidewalk Endpoint connection modes", "title": "5.5 Amazon Sidewalk Endpoint connection modes", "content": "The Amazon Sidewalk MCU SDK is configurable to the needs of applications using it through different connection profiles it offers over both Synchronous and Asynchronous link types. Each link type has various connection profiles that further expose a set of configurable parameters. The combination of link types, profiles and parameters allow configuring the MCU-SDK to adopt the needs of the application by trading off between KPIs such as power consumption and latency. The following sections describe the connection profiles for each of the SubG-FSK and SubG-CSS link types. 5.5.1 SubG-FSK connection profiles . For SubG-FSK connection mode, the Amazon Sidewalk SDK defines two connection profiles, Connection profile 1 and Connection profile 2. These connection profiles differ in terms of the properties of the 900 MHz link that the Endpoint forms with the Gateway, through which Amazon Sidewalk connectivity is achieved. As defined in section 5.2.3, Endpoints operate over a certain subset of ul_dl_nb_opp transmission opportunities. This subset differs between Connection profile 1 and Connection profile 2. More explicitly, while all Connection profile 1 Endpoints operate over a common subset of transmission slots defined by the Gateways, each Connection profile 2 Endpoint defines its own subset based on its profile parameters. This configuration directly influences the trade-off between link layer latency and energy consumption. The following sections present the details of Amazon Sidewalk Cloud connection establishment and maintenance of each profile. Dynamic switching between the profiles is not supported. However, parameter switching within profiles is supported. 5.5.1.1 Connection Profile 1 . SubG-FSK connection mode of transmission defines ul_dl_nb_opp transmission opportunities in the interval between two consecutive Beacons numbered as presented in section 5.2.3. The channel and timing of these opportunities are derived based on the Beacons transmitted by the Gateways. The Gateway further selects two subsets of these opportunities, namely CS-UL and CS-DL, together forming Common Slots. These two subsets of transmission opportunities are announced by the Gateway via Beacon packets and are shared by all Connection profile 1 Endpoints connecting to this Gateway. When transmitting uplink data, all Connection profile 1 Endpoints contend and transmit packets only over CS-UL slots. Similarly, the Gateway transmits the downlink data towards Connection profile 1 Endpoints only on CS-DL slots, thereby letting the Endpoint sleep for the rest of the transmission opportunities and save energy. The transmission opportunities in the CS-UL and CS-DL slots are periodic and defined by a pair of integers, namely offset and periodicity as shown in section 5.1.3.1.8. The period can be as small as one transmission opportunity and no maximum is defined either for CS-UL or for CS-DL. Each Gateway selects CS-UL and CS-DL slots to prevent sustained link quality degradation on negotiated links, i.e. Connection Profile 2. The Gateways can announce disabling of Connection profile 1 connectivity in the corresponding direction by choosing an empty subset. The default values used by the Gateways are available in Appendix B.1. The operation of MCU-SDK of Connection profile 1 devices can be divided into three phases: . | Link Connection Establishment Phase, which establishes the connection with a chosen Amazon Sidewalk Gateway; | Amazon Sidewalk Connection Establishment Phase, which establishes the connection with the Amazon Sidewalk Cloud; and | Connection Maintenance Phase, which maintains and periodically checks for connectivity with the Amazon Sidewalk Cloud. | . The application is notified with a connected status after completing the first phase. As long as the protocol is kept on after the connection establishment, Amazon Sidewalk SDK operation maintains both cloud and link connectivity through its Connection Maintenance Phase. During any of these phases, if a connection failure is detected, the MCU SDK notifies the application that it is disconnected from Amazon Sidewalk, and attempts to reestablish an alternative connection starting from the link connection establishment phase. These phases are depicted in figure 5.75. fig 5.75 SubG-FSK connection phases . 5.5.1.1.1 Link Connection Establishment Phase . The link layer connection is initiated by the Endpoints. The Endpoints discover nearby Amazon Sidewalk Gateways through the Beacon Discovery operation as described in section 5.2.1. The contents of each discovered Beacon is evaluated for eligibility of the Gateway sending it to serve as Sidewalk Relay to/from the Amazon Sidewalk Cloud by investigating the fields of the Beacon payload detailed in section 5.1.3.1.4. In order for the Gateway to be chosen as Sidewalk Relay: . | roam_opt must indicate roaming allowed, | CS-UL must define at least one CS-UL slot, and | CS-DL must define at least one CS-DL slot. | . Discovered Beacons not satisfying all three criteria are dropped and the Beacon Discovery procedure continues as described in section 5.2.1. With the first discovered Beacon satisfying all three requirements, each Endpoint chooses the Gateway sending the Beacon as its Sidewalk Relay, stops the Beacon Discovery operation, and starts following the timing and hopping pattern indicated in the Beacon, establishing 900 MHz connectivity with the chosen Sidewalk Relay. Any subsequent communication to/from the Sidewalk Relay follows the uplink and downlink packet transmission as described in section 5.2.3 over the subsets of slots defined by CS-UL and CS-DL. Link layer connectivity is maintained through tracking and receiving the Beacons as described in section 5.2.2. Each subsequent Beacon reception also updates the transmission opportunities available for uplink and downlink for the Endpoints with the new CS-UL and CS-DL, respectively. On the third consecutive failure on Beacon reception, the MCU-SDK triggers disconnect operation, i.e. returning to the beginning of the Link Connection Establishment Phase in which the SDK auto triggers the Beacon Discovery operation to find a new Sidewalk Relay. 5.5.1.1.2 Amazon Sidewalk Connection Establishment Phase . Following link connectivity, the next phase is to establish connectivity with Amazon Sidewalk. This phase involves encrypted packet exchange with the Amazon Sidewalk Cloud following Network Security Level with Sidewalk TX-ID addressing for the Endpoint. Both of these security features require Global Network Time as described in section 4.5. If the network time is not previously available or is not within acceptable bounds, prior to the Connection Establishment Phase, the Endpoint first goes through Global Clock Synchronization procedure to acquire/refresh network time. This time sync operation requires another pair of uplink and downlink messages and the process is covered in section 4.2. If Global Network Time is already available, the Endpoint skips the Global Clock Synchronization and directly proceeds to the Amazon Sidewalk Connection Establishment Phase. Figure 5.76 depicts the message pair used in this phase, namely Join-Req Message and Join-Resp Message. The messages are opaque to the Sidewalk Relay due to the Network Security Level encryption. The purpose of encrypted message exchange in the Amazon Sidewalk Connection Establishment Phase is to validate connectivity with the Amazon Sidewalk Cloud and to establish the routing of the downlink packets from the application server through the Amazon Sidewalk Gateway chosen as Sidewalk Relay. This process is repeated after each completion of the Link Connection Establishment Phase as well as periodically thereafter as long as the SubG-FSK link connection with the Sidewalk Relay is maintained. This initial packet exchange is called Network Join, while the periodic checks are referred to as Network Synchronization and are described in section 5.6. The contents of Join-Req Message and Join-Resp Message are listed in Table 3.1 and Table 3.2, and detailed in section 3.2.2.2.3. Following Join-Req Message, the MCU-SDK waits for a Join-Resp Message for a random duration uniformly chosen in the range [20 s, 30 s]. In a case where no response is received within this interval, MCU-SDK sends another Join-Req Message followed by a new random interval chosen from the same range. After a maximum of three retries, the Endpoint triggers the disconnect operation, i.e returning to the beginning of the Link Connection Establishment Phase in which the SDK auto triggers Beacon Discovery to find a new Sidewalk Relay. Upon the successful reception of the Join-Resp Message the status field inside the command payload is investigated. A negative status acts as a disconnect trigger returning the Endpoint to the beginning of the Link Connection Establishment Phase. fig 5.76 Profile 1 join msg exchange diagram . Finally, the reception of Join-Resp Message with a positive status indicator completes the Amazon Sidewalk Connection Establishment Phase, after which the Amazon Sidewalk Connection Maintenance Phase starts. The Amazon Sidewalk SDK notifies the application that Amazon Sidewalk connectivity is established. In this state, the data generated by the application are served in an FIFO manner following the link characteristics described in section 5.5.1.1.1. All further data communications use network layer encryption between the Amazon Sidewalk Cloud and the Endpoint in addition to any application level encryption over ASL frames as described in section 4.7. In the Amazon Sidewalk Connection Maintenance Phase, alongside the serving of application data, the SDK maintains Amazon Sidewalk Connectivity as described in section 5.5.1.3. 5.5.1.2 Connection Profile 2 . The choice of wake-up frequency of the Endpoint is a trade-off between the expected downlink delay and the power draw on the Endpoint. A frequent wake-up interval drives up the energy consumption of the Endpoint while reducing the latency that the packet waits before being transmitted over the SubG-FSK link. Conversely, an infrequent wake-up interval allows energy savings via longer sleep durations while increasing the Link Layer delay in the downlink. Amazon Sidewalk SDK exposes a configurable parameter, namely link_rx_int for Connection profile 2 that allows arbitration of this trade-off based on the application requirements. Applications selecting this profile additionally configure link_rx_int parameter that defines the desired time interval between consecutive wake-up instances. The range of values defined for this parameter is listed in Table 5.1. Table 5.1 Synchronous Connection Mode Link Profile Parameters . | Profile | Parameter Name | Parameter Description | Value Range | . | Profile 1 | - | - | - | . | Profile 2 | link_rx_int | The requested period of downlink opportunities | 1 Slot (63 ms), 5 Slots (315 ms), 10 Slots (630 ms), 15 Slots (945 ms), 40 Slots (2520 ms), 50 Slots (3150 ms), 80 Slots (5040 ms) | . The operation of MCU-SDK of Connection profile 2 devices can be investigated in three phases: . | initial Link Connection Establishment Phase, which establishes the initial connection to be used for the control of traffic with a chosen Amazon Sidewalk Gateway; | Amazon Sidewalk Connection Establishment Phase and Link Connection Update Phase, which establish the connection with the Amazon Sidewalk Cloud and update the SubG-FSK link properties based on link_rx_int configuration; and | Connection Maintenance Phase, which maintains and periodically checks for connectivity with the Amazon Sidewalk Cloud. | . The flow diagram of these phases is depicted in figure 5.75. 5.5.1.2.1 Link Connection Establishment Phase . The Endpoint operation starts at a point identical to that of Connection profile 1, going through the Link Connection Establishment Phase to discover and select the first Gateway as the Sidewalk Relay matching the criteria described in section 5.5.1.1.1. During this phase, the SubG-FSK link characteristics follow “Common Slots” rather than the configuration of the Endpoint. More explicitly, during this phase, uplink messages are sent over the CS-UL slots and the Endpoint wakes up on the CS-DL slots to receive the responses regardless of the link_rx_int setting configured. 5.5.1.2.2 Amazon Sidewalk Connection and Link Connection Update . The initial link formed with the Gateway has characteristics identical with those of Connection profile 1 Endpoints. The Endpoint uses this initial link during the Amazon Sidewalk Connection Establishment Phase. However, unlike Connection profile 1 nodes, Connection profile 2 update the link characteristics to match their configuration with the completion of the Amazon Sidewalk Connection Establishment Phase. Amazon Sidewalk Connection Establishment involves an ECDHE Key Exchange with the Amazon Sidewalk Cloud following the Network Security level that requires the Global Network Time as described in section 4.5. If the network time is not available or is not within acceptable bounds prior to the Connection Establishment Phase, the Endpoint first goes through the Global Clock Synchronization procedure to acquire/refresh network time. This time sync operation requires another pair of uplink and downlink messages as described in section 4.2. If the Global Network Time is already available, the Endpoint skips the time sync process and directly proceeds to the Amazon Sidewalk Connection Establishment Phase. The Amazon Sidewalk Connection Establishment Phase is depicted in figure 5.77 and involves three message exchanges, namely Join-Req Message, Auth Response Message, Join-Resp Message. The message contents and encryption levels of these messages are tabulated in Appendix A.1. The Amazon Sidewalk Connection Establishment Phase is initiated by the Endpoint by sending a Join-Req Message that includes Connection profile 2 setting configured by the Endpoint. The contents of the Join-Req Message is not visible to the Sidewalk Relay and is forwarded to the Amazon Sidewalk Cloud. The Amazon Sidewalk Cloud decrypts the message and in response sends an Auth Response Message back to the Sidewalk Relay. Semantically, Auth Response Message notifies the Gateway that the Endpoint identified with the Sidewalk TX-ID requests a Connection profile 2 connection with the Gateway has a downlink period of link_rx_int. Auth Response Message encapsulates the contents of the Join-Resp Message as well as a limited duration key Join Response Key that is derived from the Endpoint’s credentials registered in the cloud. Based on the encapsulated contents of the Join-Resp Message, the Gateway runs an algorithm described in section 5.5.1.2.2.1 to make a local decision to accept or reject the incoming request. If the request is accepted, a downlink schedule, namely the schedule indicating the set of slots the Endpoint should wake up to expect downlink packets, is assigned for this Endpoint. The details of the algorithm for selecting the downlink schedule at the Gateway side are described in section 5.5.1.2.2.1. The resulting decision of the Gateway is conveyed to the Endpoint via a Join-Resp Message sent over the SubG-FSK link following the CS-DL slots. This message is encrypted with the key received in the Auth Response Message. As described in section 4.5, this key has limited usage duration and is only used by the Endpoint to receive Join-Req Message. Any other message type using this key type is rejected by the Endpoint. All other communications on the uplink and downlink follow the Network Security model providing encryption between the Amazon Sidewalk Cloud and the Endpoint, hiding the message contents and types from the Sidewalk Relay. Similarly, if the Join Request is rejected by the Gateway, a Join-Resp Message with status code content indicating this rejection is sent to the Endpoint with the same encryption and link schedule. Upon reception of a Join-Resp Message indicating that the connection is accepted, the SubG-FSK link characteristics between the Gateway and the Endpoint are updated with the schedules in its contents. The Join-Resp Message contents indicate two schedules: (i) a schedule indicating the set of slots the Endpoint is allowed to use on its uplink, and (ii) a schedule indicating the set of slots the Endpoint should wake up to expect downlink packets. While the assigned schedules are dependent on the policy implemented in the Gateways, as of the GW-SDK 1.13, the chosen policy is: . | On uplink allows all ul_dl_nb_opp slots between beacons; | On downlink allows a schedule with a period equal to link_rx_int configured by the Endpoint and a random offset as detailed in section 5.5.1.2.2.1. | . Hence, after successful joining, the application layer connection status is updated to “connected” state, and the Endpoint starts using all ul_dl_nb_opp slots between Beacons for its uplink transmissions, and starts following the wake-up schedule matching the desired link_rx_int assigned by the Gateway. The Gateway stores the previously assigned downlink schedule for the Endpoint and routes the downlink packets received from the cloud considering the slots matching the wake-up schedule of the Endpoint. The Gateway preserves allocation through Sidewalk TX-ID rotations by the Endpoint. The downlink messages from the Amazon Sidewalk Cloud are forwarded to the Endpoint following the assigned DL schedule even after a Sidewalk TX-ID rotation and even if no prior message from the Endpoint with the given TXID is received. The saved allocation is removed from the Gateway database if no uplink message is received from the Endpoint for longer than 1 h. fig 5.77 Profile 2 join msg exchange diagram . 5.5.1.2.2.1 Schedule Assignment and Maintenance at Gateways . The incoming Auth Response Message trigger SLOT-ASSIGN-REQ input of the algorithm depicted in figure 5.78. The Gateway first checks if the incoming TXID already has an existing assignment with the same value of the link_rx_int parameter. In the case of a match, the previously assigned schedule is reassigned to the Endpoint. If there is no existing assignment or if the new request parameter is different from the previous one, then an incoming request is classified as a new request. For the request classified as new, the Gateway next checks if the assignment request is made for an Endpoint registered in the same account with the Gateway. Both of these checks are done via querying the Amazon Sidewalk Cloud with the incoming TXID. The Endpoints registered on the same account have privileges and are assigned a schedule without further checks. If the request is made for an Endpoint registered on an account different than the account the Gateway is registered on, the Gateway further checks the total number of allocations actively maintained. If the total is below the threshold, K, a Gateway configured for the incoming request is accepted and a schedule is generated. Otherwise, the incoming request is rejected. To accept the new request, the Gateway creates a periodic downlink schedule for the incoming Endpoint. The period of the schedule is set as link_rx_int configuration of the Endpoint that is sent with Join-Req Message and relayed in Auth Response Message. The offset is selected randomly. The random selection creates a subset of opportunities numbered in the range: [last_ul_dl_nb_opp_index, first_ul_dl_nb_opp_index] as defined in section 5.2.3. The random offset is selected to create a subset with the largest number of elements possible. The offset is selected randomly in the range: [last_ul_dl_nb_opp_index, (last_ul_dl_nb_opp_index + (first_ul_dl_nb_opp_index - last_ul_dl_nb_opp_index) % link_rx_int)]. The assignments are preserved by the Gateway and matched with the upcoming R-TXID. The Gateway preserves the reservation unless no uplink packet from the device is received for a period of 1 h. fig 5.78 SubG-FSK-WAN Connection Profile 2 Schedule Assignment . 5.5.1.3 Link Connection Maintenance Phase . For both Connection profile 1 and Connection profile 2, MCU SDK maintains both the 900MHz connectivity and the Amazon Sidewalk Cloud connectivity through two mechanisms, (i) link connection loss detection mechanism and (ii) Amazon Sidewalk connection loss detection mechanism. Connection loss detection through either mechanism triggers switching to the disconnected state, in which case the Amazon Sidewalk SDK automatically attempts to reestablish Amazon Sidewalk connectivity starting from the Initial Link Connection Establishment phase as presented in section 5.5.1.1.1 and section 5.5.1.2.1. 5.5.1.3.1 Link Connection Loss Detection . The first connection loss detection mechanism depends on periodically received beacons from the Gateway as described in section 5.2.2. Three consecutive failures on Beacon reception indicate a connectivity loss. 5.5.1.3.2 Amazon Sidewalk Connection Loss Detection . The behavior of the network sync, including the frequency of message exchanges and piggybacking, is identical for both profiles and is described in section 5.6. Similar to application layer-generated data packets, the network synchronization messages, whether piggybacked to the data or sent as stand-alone packets, are sent following the updated link properties achieved at the end of the Amazon Sidewalk Connection Establishment Phase. In other words, Connection profile 1 Endpoints use “Common Slots” link characteristics. Connection profile 2 Endpoints use the link characteristics updated in the Amazon Sidewalk Connection Establishment Phase. The updated link characteristics on uplink allow the use of any slots among ul_dl_nb_opp slots for reduced link layer latency, and on the downlink limit the alternatives to the assigned schedule, whose period is chosen by the Endpoint’s configuration arbitrating the energy consumption latency trade-off. Details of network synchronization are presented in section 5.6. 5.5.2 Asynchronous access mode profiles . Asynchronous Connection profiles’ focus is on downlink transmission configuration. This impacts Endpoint availability in the network and amount of downlink data that may be sent from the Amazon Sidewalk Cloud. Uplink transmission is not regulated by Connection Profiles A and B, and both have the same behavior. The following connection profiles are defined for asynchronous connection mode: . | Profile A: This profile maximizes the device radio interface inactivity time, making it the most power-efficient profile in this connection mode. The downlink latency may be significant as downlink may only happen after uplink. The number of downlink opportunities is limited by dl_opp_nb (see Connection Profiles Parameters below). This value indicates the Endpoint availability period in the network for the Amazon Sidewalk Cloud. When the last downlink opportunity is reached, the reception operation on an Endpoint shall be suspended till the next uplink transmission. The profile is suitable for uplink-oriented use cases, where the device application can tolerate relatively longer delay in downlink and tolerate some degree of uncertainty on the Endpoint’s downlink availability. | Profile B: This profile has greater power consumption than Connection Profile A. The DL latency is reduced compared to Profile A and may be estimated. The Profile may handle larger amounts of data in the downlink direction. | Profile C: This profile operates in continuous RX mode, providing the lowest downlink latency among all asynchronous profiles. The device stays in receive mode continuously without intervals between RX windows. This profile has the highest power consumption and is suitable for line-powered devices requiring minimal downlink latency. | Profile D: Reserved for future use. | . Connection profiles in SubG-CSS mode are defined by two parameters: . | Number of downlink opportunities - dl_opp_nb - the parameter indicates how many downlink opportunities are available after the last uplink transmission. | Downlink opportunities separation - dl_separation - the parameter indicates the time between two consecutive downlink opportunities. | . 5.5.2.1 Profile A Configuration . Profile A parameters: . | Number of downlink opportunities - dl_opp_nb - the profile has limited downlink opportunities. The number of downlink opportunities shall be counted after each uplink transmission. The counter shall be reset after each uplink. | Downlink opportunities separation - dl_separation - the value is constant and is not configurable. | . Table 5.2 Profile A parameters . | Parameter | Value | Note | . | dl_opp_nb | 5, 10, 15, 20 |   | . | dl_separation | 5s | constant not configurable | . fig 5.79 Profile A - UL of synchronization packet and DL schedule . 5.5.2.2 Profile B Configuration . The Profile B parameters: . Table 5.3 Profile B parameters . | Parameter | Value | Note | . | dl_opp_nb | infinite |   | . | dl_separation | 5s | constant not configurable | . | Number of downlink opportunities - dl_opp_nb - the profile has infinite downlink opportunities which are scheduled continuously with downlink opportunity separation. | Downlink opportunities separation - dl_separation - the value is constant and is not configurable. | . This profile has infinite downlink opportunities. The downlink transmission shall be synchronized based on uplink synchronization packets. Only selected uplink packets shall be used for downlink synchronization. These are sent in the uplink direction no later than around ul_sync_interval since the last uplink packet used for downlink synchronization but no earlier than ul_sync_guard_interval. The procedure for selecting an uplink packet used for synchronization defines two cases: . | when a user application data packet is being sent within ul_sync_guard_interval then this packet shall have Epoch bit set (see figure 5.80) | when a user application data packet is not planned to be sent within ul_sync_guard_interval then Join Request message with Epoch bit set shall be sent after ul_sync_interval time (see figure 5.81) | . fig 5.80 Profile B - DL synchronization - user data in UL . fig 5.81 Profile B - DL synchronization - no user data in UL . 5.5.2.3 Profile C Configuration . The Profile C parameters: . | RX window count - rx_window_count - the profile operates in continuous RX mode with value 0xFF (SID_RX_WINDOW_CONTINUOUS). | Downlink opportunities separation - dl_separation - the value is 0 (SID_LINK3_RX_WINDOW_SEPARATION_CONTINUOUS), meaning continuous reception. | . Table 5.4 Profile C parameters . | Parameter | Value | Note | . | rx_window_count | 0xFF | continuous RX mode | . | dl_separation | 0 | continuous, no interval | . This profile operates in continuous RX mode, providing the lowest downlink latency. The device stays in receive mode continuously without intervals between RX windows. Profile C does not perform periodic network synchronization (same as Profile A). This profile is suitable for line-powered devices that require minimal downlink latency and are not constrained by power consumption. ", "url": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/amazon-sidewalk-endpoint-connection-modes.html", "relUrl": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/amazon-sidewalk-endpoint-connection-modes.html" },"50": { "doc": "17. Appendix", "title": "17. Appendix", "content": " ", "url": "/specifications/sidewalk-test-spec/appendix.html", "relUrl": "/specifications/sidewalk-test-spec/appendix.html" },"51": { "doc": "17. Appendix", "title": "17.1 PICS", "content": "A Protocol Implementation Conformance Statement (PICS) is required for every Sidewalk-enabled device, where the developer must confirm that their device implementation meets all requirements outlined in the Amazon Sidewalk protocol specification. The PICS serves as the developer’s attestation that is submitted along with a request for their Sidewalk product qualification review and approval. ", "url": "/specifications/sidewalk-test-spec/appendix.html#171-pics", "relUrl": "/specifications/sidewalk-test-spec/appendix.html#171-pics" },"52": { "doc": "17. Appendix", "title": "17.2 Reference Table", "content": "Table 17.1 PICS Reference Table . | ID | Group | Implementation Name | Implementation Case | Test Required (Y)=YES / (C)=Conditional | . |   | Basic Conformance |   | Basic conformance is mandatory. The items shall be implemented for the selected operation band(s). | Mandatory | . | 1 | SID_VERSION | Amazon Sidewalk Compatible MCU | DUT is flashed with a valid MCU build for Amazon Sidewalk. | (Y) | . | 2 | BAND | Operation Band | DUT with BLE compatibility operates in the 2.4GHz ISM band in US, compliant with FCC ITU Region 2. | (Y) | . | 2.1 | BAND | Operation Band | DUT with Sub-1GHz compatibility operates in the sub-1GHz ISM band in US, compliant with FCC ITU Region 2. | (Y) | . |   | Protocol Implementation Conformance |   | Protocol conformance is mandatory. DUT can have selectable implementations for BLE, SubG-FSK, and SubG-CSS. The items shall be implemented for each chosen protocol. | Mandatory | . | 3 | BLE Protocol | BLE Link Type | DUT with BLE compatibility connects to the Amazon Sidewalk network using BLE version 4.2 (minimum), 1Mbps data rate. | (Y) | . | 3.1 | BLE Protocol | Device Connection - REG | DUT successfully completes Sidewalk device registration over BLE. | (Y) | . | 3.2 | BLE Protocol | Device Connection - REG | DUT successfully completes Sidewalk device registration with use of FFN. | (Y) | . | 3.3 | BLE Protocol | Device Connection - REG | DUT can be deregistered from Sidewalk network. | (Y) | . | 3.4 | BLE Protocol | Device Data - DL | DUT receives downlink packets with various sizes of Command data. | (Y) | . | 3.5 | BLE Protocol | Device Data - UL | Gateway receives uplink packets with various sizes of Command data from DUT. | (Y) | . | 3.6 | BLE Protocol | Device Connection - EST | Gateway establishes BLE connection on DUT’s request. | (Y) | . | 3.7 | BLE Protocol | Device Connection - EST | DUT can connect with Gateway via BLE, after reinitializing Sidewalk library. | (Y) | . | 3.8 | BLE Protocol | Device Connection - EST | DUT can connect with Gateway via BLE, after restarting Sidewalk library. | (Y) | . | 3.9 | BLE Protocol | Device Connection - DSC | BLE connection between Gateway and DUT is dropped after 30 seconds of being idle. | (Y) | . | 3.10 | BLE Protocol | Device Connection - DSC | BLE connection between Gateway and DUT is extended by uplink packet and dropped after additional 30 seconds. | (Y) | . | 3.11 | BLE Protocol | Device Connection - DSC | BLE connection between Gateway and DUT is extended by downlink packet and dropped after additional 30 seconds. | (Y) | . | 3.12 | BLE Protocol | Device Connection - DSC | DUT drops BLE connection in case of received downlink packet with duplicated SEQ. | (Y) | . | 3.13 | BLE Protocol | Device Connection - DSC | DUT drops BLE connection in case of received downlink packets with duplicated SEQ range. | (Y) | . | 3.14 | BLE Protocol | Device Connection - DSC | DUT drops BLE connection after stopping Sidewalk library. | (Y) | . | 3.15 | BLE Protocol | Device Connection - DSC | DUT drops BLE connection after de-initializing Sidewalk library. | (Y) | . | 3.16 | BLE Protocol | Device Connection - BCN | DUT transmits beacons only when BLE connection is not established. | (Y) | . | 3.17 | BLE Protocol | Device Connection - BCN | DUT transmits beacons that contain Identifier (TX-ID), which changes every 15 minutes. | (Y) | . | 3.18 | BLE Protocol | Device Connection - BCN | DUT transmits beacons with 160ms interval for the first 30 seconds after starting BLE protocol. | (Y) | . | 3.19 | BLE Protocol | Device Connection - BCN | DUT transmits beacons with 1s interval, 30 seconds after starting BLE protocol. | (Y) | . | 3.20 | BLE Protocol | Device Connection - BCN | DUT transmits beacons with valid header. | (Y) | . | 3.21 | BLE Protocol | Device Connection - DUP | BLE connection is closed after DUT receives 10 packets with duplicate SEQ number within one minute (filter duplicates enabled). | (Y) | . | 3.22 | BLE Protocol | Device Connection - DUP | BLE connection is closed after DUT receives 10 packets with various duplicate SEQ numbers within one minute (filter duplicates enabled). | (Y) | . | 3.23 | BLE Protocol | Device Connection - DUP | BLE connection is not closed after DUT receives 10 packets with duplicate SEQ number within one minute (filter duplicates disabled). | (Y) | . | 3.24 | BLE Protocol | Device Connection - DUP | BLE connection is not closed after DUT receives 10 packets with various duplicate SEQ numbers within one minute (filter duplicates disabled). | (Y) | . | 3.25 | BLE Protocol | Device Connection - DUP | BLE connection is not closed after 10 packets with duplicate SEQ number reach DUT, if not all of those packets are sent within one minute. | (Y) | . | 3.26 | BLE Protocol | Network Sync - Time | DUT completes the initial time sync procedure. | (Y) | . | 4 | SubG-FSK Protocol | SubG-FSK Link Type | DUT with SubG-FSK compatibility connects to the Amazon Sidewalk network using Sidewalk GFSK 50 kbps raw data rate. | (Y) | . | 4.1 | SubG-FSK Protocol | Beacon Discovery | FSK-WAN DUT discovers neighbor Gateway and synchronizes with it if roaming is allowed. | (Y) | . | 4.2 | SubG-FSK Protocol | Beacon Discovery | FSK-WAN DUT discovers home Gateway and synchronizes with it even if roaming is forbidden. | (Y) | . | 4.3 | SubG-FSK Protocol | Beacon Discovery | FSK-WAN DUT detects a neighbor Gateway Beacon but continues with the Gateway discovery process if roaming is forbidden. | (Y) | . | 4.4 | SubG-FSK Protocol | Device Connection - REG | DUT successfully completes Sidewalk device registration over BLE. | (Y) | . | 4.5 | SubG-FSK Protocol | Device Connection - REG | DUT can be deregistered from Sidewalk network. | (Y) | . | 4.6 | SubG-FSK Protocol | Device Connection - REG | DUT successfully completes Sidewalk device registration with the use of FFN. | (Y) | . | 4.7 | SubG-FSK Protocol | Device Connection - SEQ | Uplink packets contain SEQ number. | (Y) | . | 4.8 | SubG-FSK Protocol | Device Connection - SEQ | DUT increments uplink SEQ number until UUID changes. | (Y) | . | 4.9 | SubG-FSK Protocol | Device Connection - SEQ | DUT accepts and decodes downlink packets with increased and decreased SEQ. | (Y) | . | 4.10 | SubG-FSK Protocol | Device Connection - SEQ | DUT rejects downlink packet with duplicated SEQ. | (Y) | . | 4.11 | SubG-FSK Protocol | Device Connection - SEQ | DUT rejects downlink packet with duplicated SEQ range. | (Y) | . | 4.12 | SubG-FSK Protocol | Device Connection - SEQ | SEQ number can be accepted again after getting 10 other messages. | (Y) | . | 4.13 | SubG-FSK Protocol | Device Connection - SEQ | SEQ number can be accepted again after Sidewalk stack reinitialization. | (Y) | . | 4.14 | SubG-FSK Protocol | Device Connection - SEQ | DUT drops the packet with SEQ which is out of range. | (Y) | . | 4.15 | SubG-FSK Protocol | Device Data - DL | DUT receives downlink packets with various sizes of Command data. | (Y) | . | 4.16 | SubG-FSK Protocol | Device Data - UL | Gateway receives uplink packets with various sizes of Command data from DUT. | (Y) | . | 4.17 | SubG-FSK Protocol | Network Sync - Time | DUT completes the initial time sync procedure. | (Y) | . | 4.18 | SubG-FSK Protocol | Network Sync - JOIN | DUT completes the initial Join procedure. | (Y) | . | 4.19 | SubG-FSK Protocol | Network Sync - JOIN | DUT keeps synchronization with the network by periodic transmission of Join request. | (Y) | . | 4.20 | SubG-FSK Protocol | Network Sync - JOIN | DUT keeps synchronization with the network by embedded sync request. | (Y) | . | 4.21 | SubG-FSK Protocol | Device Security - UUID | DUT rotates UUID immediately after time sync. | (Y) | . | 4.22 | SubG-FSK Protocol | Device Security - UUID | UUID rotates every 15 minutes after time sync. | (Y) | . | 4.23 | SubG-FSK Protocol | Device Security - UUID | DUT can exchange UL/DL during UUID rotation. | (Y) | . | 5 | SubG-CSS Protocol | SubG-CSS Link Type | DUT with SubG-CSS compatibility connects to the Amazon Sidewalk network using LoRa CSS raw bit rate 2 kbps @ BW 500 kHz, SF11. SubG-CSS must exist with either BLE or SubG-FSK implementation. | (Y) | . | 5.1 | SubG-CSS Protocol | Device Data - DL | DUT receives downlink packets with various sizes of Command data. | (Y) | . | 5.2 | SubG-CSS Protocol | Device Data - UL | Gateway receives uplink packets with various Command data sizes from DUT. | (Y) | . | 5.3 | SubG-CSS Protocol | Device Security - UUID | DUT rotates UUID immediately after time sync. | (Y) | . | 5.4 | SubG-CSS Protocol | Device Security - UUID | UUID rotates every 15 minutes after time sync. | (Y) | . | 5.5 | SubG-CSS Protocol | Device Security - UUID | DUT can exchange UL/DL during UUID rotation. | (Y) | . | 5.6 | SubG-CSS Protocol | Device Connection - REG | DUT successfully completes Sidewalk device registration over BLE. | (Y) | . | 5.7 | SubG-CSS Protocol | Device Connection - REG | DUT can be deregistered from Sidewalk network. | (Y) | . | 5.8 | SubG-CSS Protocol | Device Connection - LP | DUT can select Profile A and complete the Join procedure. | (Y) | . | 5.9 | SubG-CSS Protocol | Device Connection - LP | DUT can select Profile B and complete the Join procedure. | (Y) | . | 5.10 | SubG-CSS Protocol | Device Connection - SEQ | Uplink packets contain SEQ number. | (Y) | . | 5.11 | SubG-CSS Protocol | Device Connection - SEQ | DUT increments uplink SEQ number until UUID changes. | (Y) | . | 5.12 | SubG-CSS Protocol | Device Connection - SEQ | DUT accepts and decodes downlink packets with increased and decreased SEQ. | (Y) | . | 5.13 | SubG-CSS Protocol | Device Connection - SEQ | DUT rejects downlink packet with duplicated SEQ. | (Y) | . | 5.14 | SubG-CSS Protocol | Device Connection - SEQ | DUT rejects downlink packet with duplicated SEQ range. | (Y) | . | 5.15 | SubG-CSS Protocol | Device Connection - SEQ | SEQ number can be accepted again after getting 10 other messages. | (Y) | . | 5.16 | SubG-CSS Protocol | Device Connection - SEQ | SEQ number can be accepted again after Sidewalk stack reinitialization. | (Y) | . | 5.17 | SubG-CSS Protocol | Device Connection - SEQ | DUT drops the packet with SEQ which is out of range. | (Y) | . | 5.18 | SubG-CSS Protocol | Network Sync - JOIN | DUT keeps synchronization with the network by periodic transmission of Join request. | (Y) | . | 5.19 | SubG-CSS Protocol | Network Sync - JOIN | DUT keeps synchronization with the network by embedded sync request. | (Y) | . | 5.20 | SubG-CSS Protocol | Network Sync - TIME | DUT completes the initial time sync procedure. | (Y) | . | 6 | SubG-CSS Protocol | Multi-Radio | DUT’s SubG-CSS exists with BLE implementation. | Y (conditional) | . | 6.1 | SubG-CSS Protocol | Multi-Radio - API INIT | DUT switches between 900MHz and BLE stack multiple times. | Y | . | 6.2 | SubG-CSS Protocol | Multi-Radio Connection - DL | DUT is able to receive a downlink packet using BLE. | Y | . | 6.3 | SubG-CSS Protocol | Multi-Radio Connection - DL | DUT is able to receive a downlink packet using LoRa. | Y | . | 6.4 | SubG-CSS Protocol | Multi-Radio Connection - DL | DUT is able to receive a downlink packet using LoRa, while BLE connection with Gateway is established. | Y | . | 6.5 | SubG-CSS Protocol | Multi-Radio Connection - Send LINK | Uplink performed through BLE, when send link 0 and active BT connection. | Y | . | 6.6 | SubG-CSS Protocol | Multi-Radio Connection - Send LINK | Uplink performed through BLE, when send link 1 and active BT connection. | Y | . | 6.7 | SubG-CSS Protocol | Multi-Radio Connection - Send LINK | Uplink performed through LoRa, when send link 3 and active BT connection. | Y | . | 6.8 | SubG-CSS Protocol | Multi-Radio Connection - Send LINK | Uplink performed through LoRa, when send link 0 and terminated BT connection. | Y | . | 6.9 | SubG-CSS Protocol | Multi-Radio Connection - Send LINK | Uplink not performed, when send link 1 and terminated BT connection. | Y | . |   | Functionality Implementation Conformance |   | Functionality conformance is optional. The implementation may choose to implement the items. | Optional | . | 7 | MLM | Multi-Link Connection | DUT enables any combination of BLE, and/or SubG-FSK, and/or SubG-CSS link type for Amazon Sidewalk network connection. | Y (conditional) | . | 8 | SBDT | File Transfer | DUT receives a file transfer via Sidewalk BLE. | Y (conditional) | . | 9 | EPMETRICS | Endpoint Metrics | DUT has the capability to collect and upload endpoint metrics. | Y (conditional) | . | 10 | CAPABILITY | Endpoint Capability | Capability of DUT can be uploaded and configured. | Y (conditional) | . | 11 | BLE BEACON | MAC Address | DUT MAC address rotation under specific conditions | Y (conditional) | . | 12 | Location Service | Location Service Uplink | DUT sends location data (GNSS, Wi-Fi, Gateway) to Cloud for device positioning. | Y (conditional) | . | 13 | Location Service | Location Service MCU | DUT location can be resolved and sent | Y (conditional) | . | 14 | POWER | Power Optimization | DUT can adjust RX window opening time | Y (conditional) | . | 15 | CONNECTION POLICY | BLE connection policy | BLE connection policy and parameters can be configured on DUT | Y (conditional) | . | 7.1 | MLM | Multi-Link Auto Connection - BLE | DUT sends UL without auto-connect, DUT is BLE disconnected (Link Mask 0) | C | . | 7.2 | MLM | Multi-Link Auto Connection - BLE | DUT sends UL with auto-connect, ack is true, retry is 3, TTL is 60 | C | . | 7.3 | MLM | Multi-Link Auto Connection - SubG-FSK | DUT sends UL without auto-connect, DUT is FSK disconnected (Link Mask 0) | C | . | 7.4 | MLM | Multi-Link Auto Connection - SubG-FSK | DUT sends UL with auto-connect, ack is true, retry is 3, TTL is 60 | C | . | 7.5 | MLM | Multi-Link Auto Connection - SubG-CSS | DUT sends UL without auto-connect, DUT is LoRa disconnected (Link Mask 0) | C | . | 7.6 | MLM | Multi-Link Auto Connection - SubG-CSS | DUT sends UL with auto-connect, ack is true, retry is 3, TTL is 60 | C | . | 7.7 | MLM | Multi-Link Auto Connection - BLE SubG-CSS | DUT sends UL with auto-connect when BLE link priority is higher than LoRa, EN Link Mask is 0, Specify BLE+LoRa link | C | . | 7.8 | MLM | Multi-Link Auto Connection - BLE SubG-CSS | DUT sends UL with auto-connect when BLE link priority is higher than LoRa, EN Link Mask is 0, Specify BLE+LoRa link, disable BLE on GW | C | . | 7.9 | MLM | Multi-Link Auto Connection - BLE SubG-CSS | DUT sends UL with auto-connect when BLE link priority is higher than LoRa, EN Link Mask is 0, disables BLE & LoRa on GW | C | . | 7.10 | MLM | Multi-Link Auto Connection - BLE SubG-CSS | DUT sends UL with auto-connect when BLE link priority is higher than LoRa, EN Link Mask is 0, Specify FSK link | C | . | 7.11 | MLM | Multi-Link Auto Connection - BLE SubG-FSK CSS | DUT sends UL through BLE when no connection | C | . | 7.12 | MLM | Multi-Link Auto Connection - BLE SubG-FSK CSS | DUT sends UL through FSK when no connection | C | . | 7.13 | MLM | Multi-Link Auto Connection - BLE SubG-FSK CSS | DUT sends UL through LoRa when no connection | C | . | 7.14 | MLM | Multi-Link Auto Connection - BLE SubG-FSK CSS | DUT doesn’t send UL when no connection and BLE/FSK/LoRa unavailable | C | . | 7.15 | MLM | Multi-Link Auto Connection - BLE SubG-FSK CSS | DUT sends UL through BLE when Link Mask is 1 | C | . | 7.16 | MLM | Multi-Link Active | DUT sends UL through BLE when no connection | C | . | 7.17 | MLM | Multi-Link Active | DUT sends UL through FSK when no connection | C | . | 7.18 | MLM | Multi-Link Active | DUT sends UL through LoRa when no connection | C | . | 7.19 | MLM | Multi-Link Active | DUT doesn’t send UL when no connection and BLE/FSK/LoRa unavailable | C | . | 7.20 | MLM | Multi-Link Active | DUT sends UL through BLE when Link Mask is 1 | C | . | 7.21 | MLM | Multi-Link Power | DUT sends UL through BLE when no connection | C | . | 7.22 | MLM | Multi-Link Power | DUT sends UL through FSK when no connection | C | . | 7.23 | MLM | Multi-Link Power | DUT sends UL through LoRa when no connection | C | . | 7.24 | MLM | Multi-Link Power | DUT doesn’t send UL when no connection and BLE/FSK/LoRa unavailable | C | . | 7.25 | MLM | Multi-Link Power | DUT sends UL through BLE when Link Mask is 1 | C | . | 7.26 | MLM | Multi-Link Performance | DUT sends UL through BLE when no connection | C | . | 7.27 | MLM | Multi-Link Performance | DUT sends UL through FSK when no connection | C | . | 7.28 | MLM | Multi-Link Performance | DUT sends UL through LoRa when no connection | C | . | 7.29 | MLM | Multi-Link Performance | DUT doesn’t send UL when no connection and BLE/FSK/LoRa unavailable | C | . | 7.30 | MLM | Multi-Link Performance | DUT sends UL through BLE when Link Mask is 1 | C | . | 7.31 | MLM | Multi-Link Latency | DUT sends UL through BLE when no connection | C | . | 7.32 | MLM | Multi-Link Latency | DUT sends UL through FSK when no connection | C | . | 7.33 | MLM | Multi-Link Latency | DUT sends UL through LoRa when no connection | C | . | 7.34 | MLM | Multi-Link Latency | DUT doesn’t send UL when no connection and BLE/FSK/LoRa unavailable | C | . | 7.35 | MLM | Multi-Link Latency | DUT sends UL through BLE when Link Mask is 1 | C | . | 7.36 | MLM | Multi-Link Reliability | DUT sends UL through BLE when no connection | C | . | 7.37 | MLM | Multi-Link Reliability | DUT sends UL through FSK when no connection | C | . | 7.38 | MLM | Multi-Link Reliability | DUT sends UL through LoRa when no connection | C | . | 7.39 | MLM | Multi-Link Reliability | DUT doesn’t send UL when no connection and BLE/FSK/LoRa unavailable | C | . | 7.40 | MLM | Multi-Link Reliability | DUT sends UL through BLE when Link Mask is 1 | C | . | 8.1 | SBDT | File Transfer | DUT initializes the feature and starts receiving a file | Y | . | 8.2 | SBDT | File Transfer | DUT cancels ongoing transfer | Y | . | 8.3 | SBDT | File Transfer | DUT prints the progress of the transfer and current file offset | Y | . | 8.4 | SBDT | File Transfer | DUT prints various parameters of the transfer | Y | . | 8.5 | SBDT | File Transfer Recovery | DUT recovers transfer after powered off and back on | Y | . | 8.6 | SBDT | File Transfer Recovery | DUT recovers transfer after being out of range from GW | Y | . | 8.7 | SBDT | File Transfer Recovery | DUT recovers transfer after GW that was using to send packets switched to another GW | Y | . | 8.8 | SBDT | File Transfer Recovery | DUT recovers transfer after GW that was using to send packets being opt-out | Y | . | 8.9 | SBDT | File Transfer Recovery | DUT recovers transfer after GW that was using to send packets powered off for a while and back on | Y | . | 9.1 | EPMETRICS | Endpoint Metrics - Common | DUT has corresponding metrics but not invalid metrics enabled | Y | . | 9.2 | EPMETRICS | Endpoint Metrics - BLE Report | DUT sends endpoint metrics to Cloud over BLE in a specific time interval | Y | . | 9.3 | EPMETRICS | Endpoint Metrics - BLE Report | DUT sends remaining endpoint metrics to Cloud over BLE via piggybacking on a periodic reporting | Y | . | 9.4 | EPMETRICS | Endpoint Metrics - BLE Report | DUT sends endpoint metrics via piggybacking over BLE if the explicit reporting is disabled | Y | . | 9.5 | EPMETRICS | Endpoint Metrics - BLE Uplink | DUT collects BLE uplink messages metrics | Y | . | 9.6 | EPMETRICS | Endpoint Metrics - BLE Downlink | DUT collects BLE downlink messages metrics | Y | . | 9.7 | EPMETRICS | Endpoint Metrics - BLE Connection | DUT collects BLE connection attempts metrics | Y | . | 9.8 | EPMETRICS | Endpoint Metrics - FSK Report | DUT sends endpoint metrics to Cloud over FSK in a specific time interval | Y | . | 9.9 | EPMETRICS | Endpoint Metrics - FSK Report | DUT sends remaining endpoint metrics to Cloud over FSK via piggybacking on a periodic reporting | Y | . | 9.10 | EPMETRICS | Endpoint Metrics - FSK Report | DUT sends endpoint metrics via piggybacking over FSK if the explicit reporting is disabled | Y | . | 9.11 | EPMETRICS | Endpoint Metrics - FSK Uplink | DUT collects FSK uplink messages metrics and total number of tx unique packets Metrics | Y | . | 9.12 | EPMETRICS | Endpoint Metrics - FSK Downlink | DUT collects FSK downlink messages metrics and total number of rx packets metrics | Y | . | 9.13 | EPMETRICS | Endpoint Metrics - LoRa Report | DUT sends endpoint metrics to Cloud over LoRa in a specific time interval | Y | . | 9.14 | EPMETRICS | Endpoint Metrics - LoRa Report | DUT sends remaining endpoint metrics to Cloud over LoRa via piggybacking on a periodic reporting | Y | . | 9.15 | EPMETRICS | Endpoint Metrics - LoRa Report | DUT sends endpoint metrics via piggybacking over LoRa if the explicit reporting is disabled | Y | . | 9.16 | EPMETRICS | Endpoint Metrics - LoRa Uplink | DUT collects LoRa uplink messages metrics and total number of tx normal packets metrics | Y | . | 9.17 | EPMETRICS | Endpoint Metrics - LoRa Downlink | DUT collects LoRa downlink messages metrics and total number of rx packets metrics | Y | . | 10.1 | CAPABILITY | Endpoint Capability - Common Report | DUT does not have the capability report saved, schedule an event to report the capability | Y | . | 10.2 | CAPABILITY | Endpoint Capability - Common Report | DUT have the capability report saved and match, should not schedule an event to report | Y | . | 10.3 | CAPABILITY | Endpoint Capability - Common Report | DUT default capability report | Y | . | 10.4 | CAPABILITY | Endpoint Capability - Common Uplink | DUT schedule an event, before EP capability report ACK receive, can send messages | Y | . | 10.5 | CAPABILITY | Endpoint Capability - Common Request | Send request to get DUT capabilities | Y | . | 10.6 | CAPABILITY | Endpoint Capability - Common Configure | DUT configure should be updated after setting | Y | . | 10.7 | CAPABILITY | Endpoint Capability - Common Register | DUT capability return to default after re-register | Y | . | 10.8 | CAPABILITY | Endpoint Capability - Common Threshold | DUT traffic threshold renew mechanism | Y | . | 10.9 | CAPABILITY | Endpoint Capability - Common Periodicity | DUT set metrics periodicity | Y | . | 10.10 | CAPABILITY | Endpoint Capability - Common Periodicity | DUT set metrics periodicity when link metrics is disabled | Y | . | 10.11 | CAPABILITY | Endpoint Capability - BLE Threshold | Traffic threshold for BLE stack | Y | . | 10.12 | CAPABILITY | Endpoint Capability - FSK Threshold | Traffic threshold for FSK stack | Y | . | 10.13 | CAPABILITY | Endpoint Capability - LoRa Threshold | Traffic threshold for LoRa stack | Y | . | 11.1 | BLE BEACON | MAC Address | DUT BLE MAC address should rotate after registration | Y | . | 11.2 | BLE BEACON | MAC Address | DUT BLE MAC address should rotate after time sync | Y | . | 11.3 | BLE BEACON | MAC Address | DUT BLE MAC address should rotate after time sync every 15 minutes together with UUID | Y | . | 11.4 | BLE BEACON | MAC Address | DUT BLE MAC address should rotate after connection request sent from EN to cloud | Y | . | 11.5 | BLE BEACON | MAC Address | DUT BLE MAC address should rotate after connection released | Y | . | 11.6 | BLE BEACON | MAC Address | DUT BLE MAC address should rotate after receiving a DL | Y | . | 11.7 | BLE BEACON | MAC Address | DUT BLE MAC address should rotate after key refresh | Y | . | 11.8 | BLE BEACON | MAC Address | DUT BLE MAC address should rotate every 15 minutes even during long live connection | Y | . | 12.1 | Location Service | Location Service Uplink - BLE | Resolve EN location for BLE uplink message containing GNSS scan information | Y | . | 12.2 | Location Service | Location Service Uplink - BLE | Resolve EN location for BLE uplink message containing Wi-Fi scan information | Y | . | 12.3 | Location Service | Location Service Uplink - BLE | Resolve EN location for BLE uplink message with connected GW location | Y | . | 12.4 | Location Service | Location Service Uplink - LoRa | Resolve EN location for LoRa uplink message containing GNSS scan information | Y | . | 12.5 | Location Service | Location Service Uplink - LoRa | Resolve EN location for LoRa uplink message containing Wi-Fi scan information | Y | . | 13.1 | Location Service | Location Service MCU | DUT send a location uplink at level 1 | Y | . | 13.2 | Location Service | Location Service MCU | DUT send a location uplink at level 1 via piggybacking | Y | . | 13.3 | Location Service | Location Service MCU | DUT send a location uplink at level 3 | Y | . | 13.4 | Location Service | Location Service MCU | DUT scan location at level 3 | Y | . | 13.5 | Location Service | Location Service MCU | DUT send a location uplink at level 4 | Y | . | 13.6 | Location Service | Location Service MCU | DUT scan location at level 4 | Y | . | 13.7 | Location Service | Location Service MCU | DUT re-transmit all missed fragments for Wi-Fi on LoRa | Y | . | 13.8 | Location Service | Location Service MCU | DUT re-transmit all missed fragments for GNSS on LoRa | Y | . | 13.9 | Location Service | Location Service MCU | DUT switch location resolution from level 1 to level 3 automatically | Y | . | 13.10 | Location Service | Location Service MCU | DUT switch location resolution from level 1 to level 4 automatically | Y | . | 14.1 | POWER | Power Optimization | DUT FSK RX duration can be adjusted | Y | . | 14.2 | POWER | Power Optimization | DUT FSK RX windows after control message sent should not be closed | Y | . | 14.3 | POWER | Power Optimization | DUT FSK RX window termination request stop RX window opened at profile 2 | Y | . | 14.4 | POWER | Power Optimization | DUT FSK RX window termination request should not stop RX window opened at profile 1 | Y | . | 14.5 | POWER | Power Optimization | DUT FSK beacon interval can be adjusted | Y | . | 14.6 | POWER | Power Optimization | DUT FSK beacon interval revert to default after 2nd beacon misses | Y | . | 14.7 | POWER | Power Optimization | DUT FSK can still perform uplinks and downlinks normally after a beacon skipped | Y | . | 14.8 | POWER | Power Optimization | DUT LORA number of RX windows is limited and can be changed | Y | . | 14.9 | POWER | Power Optimization | DUT LORA number of RX windows is reset after sending an additional uplink | Y | . | 14.10 | POWER | Power Optimization | DUT LORA RX window termination request stop RX window opened at profile A | Y | . | 14.11 | POWER | Power Optimization | DUT LORA RX window termination request should not stop RX window opened at profile B | Y | . | 14.1 | Connection Policy | BLE Connection Policy | Advertisement parameters and advertising intervals on default connection policy | Y | . | 14.2 | Connection Policy | BLE Connection Policy | Connection parameters on default connection policy | Y | . | 14.3 | Connection Policy | BLE Connection Policy | Both advertisement and connection parameters, advertising interval of BLE beacons on default connection policy | Y | . | 14.4 | Connection Policy | BLE Connection Policy | Both default advertisement and connection parameters, advertising interval of BLE beacons | Y | . | 14.5 | Connection Policy | BLE Connection Policy | DUT disconnects after inactivity timeout on default connection policy | Y | . | 14.6 | Connection Policy | BLE Connection Policy | Advertisement parameters and advertising intervals on long lived connection policy | Y | . | 14.7 | Connection Policy | BLE Connection Policy | DUT connection parameters on long lived connection policy | Y | . | 14.8 | Connection Policy | BLE Connection Policy | Both advertisement and connection parameters, advertising interval of BLE beacons on long lived connection policy | Y | . | 14.9 | Connection Policy | BLE Connection Policy | DUT disconnects after inactivity timeout on long lived connection policy | Y | . | 14.10 | Connection Policy | BLE Connection Policy | Advertisement parameters and advertising intervals on optimal advertising connection policy | Y | . | 14.11 | Connection Policy | BLE Connection Policy | Connection parameters on optimal advertising connection policy | Y | . | 14.12 | Connection Policy | BLE Connection Policy | Both advertisement and connection parameters, advertising interval of BLE beacons on optimal advertising connection policy | Y | . | 14.13 | Connection Policy | BLE Connection Policy | DUT disconnects after inactivity timeout on optimal advertising connection policy | Y | . ", "url": "/specifications/sidewalk-test-spec/appendix.html#172-reference-table", "relUrl": "/specifications/sidewalk-test-spec/appendix.html#172-reference-table" },"53": { "doc": "3.2 Application Commands", "title": "3.2 Application commands", "content": "Application commands are divided into four types that are coded in the Presentation layer in the opc field. The type and the main purpose of each one are as follows: . | Get/Read - the sender requests data to be returned from the receiver | Set/Write - the sender requests an action to be performed by the receiver | Notify - the sender provides an information to the receiver | Response - the receiver uses it to respond to Get/Read, Set/Write or Notify command types | . The sender shall always provide information whether the response from the receiver is required (see resp_req field in the Presentation layer frame format, shown in figure 5.3). The response type command may be requested in the following cases: . | It shall be always requested in case of Get/Read command. The response command shall include requested data. | It may be requested for Set/Write command type. The response may not include the command payload but it shall include the status of the performed operation (see status_hdr_inc, status_code_inc and status_code fields in the Presentation layer frame format, shown in figure 5.3). | It may be requested for Notify command type. | . Each command is uniquely identified by: Command class, Command ID and sequence number (see seq_num field in the Presentation layer frame format, shown in figure 5.3). A new sequence number shall be generated for each Get/Read, Set/Write and Notify command. The response command type shall have a copy of the sequence number that was included in the related Get/Read, Set/Write or Notify command. Commands are sent in an asynchronous manner. The sender may not wait for a response before another command is sent to the recipient - e.g. it may send a few commands subsequently that are uniquely identified and wait for responses that are related to the sent commands (see Figure 3.8). Fig. 3.8 Commands and responses . 3.2.1 Custom commands . Custom commands are used to exchange data between a user application running on an Endpoint and an application service that is in the cloud. The user application data is included in the command data field. Fig. 3.9 Custom command - Command data format . | Command class . | Mnemonic | Length | Value | Description | . | cmd_class | 3b | 0x01 | The value is common for all custom commands. | . | Command ID . | Mnemonic | Length | Value | Type | Command name | Command direction | . | cmd_id | 3b | 0x00 | Read | CUSTOM_GET_CMD | UL, DL | . | cmd_id | 3b | 0x00 | Write | CUSTOM_SET_CMD | UL, DL | . | cmd_id | 3b | 0x00 | Notify | CUSTOM_NOTIFY_CMD | UL, DL | . | cmd_id | 3b | 0x00 | Response | CUSTOM_RESP_CMD | UL, DL | . | Command data - User application data . | Mnemonic | Length | Value | Description | . | user_data | X B | data bytes | A user application data. | . The field contains user application data. The included data length shall not exceed: . | 200 B for SubG-FSK Endpoints | 19 B for SubG-CSS Endpoints | . | . 3.2.2 Management commands . 3.2.2.1 Time management commands . The set of time management commands contains the following ones: GET_TIME and RESP_TIME. Commands are used by an Endpoint for time synchronization with the Amazon Sidewalk Cloud. For a detailed description of Global Clock Synchronization [GCS], see section 4.2. Fig. 3.10 Time commands - Command data format . | Command class . | Mnemonic | Length | Value | Description | . | cmd_class | 12b | 0x00 | The value is common for all management commands. | . | Command ID . | Mnemonic | Length | Value | Type | Command name | Command direction | . | cmd_id | 12b | 0x108 | Read | GET_TIME | UL | . | cmd_id | 12b | 0x108 | Response | RESP_TIME | DL | . | Command data - Time in seconds . | Mnemonic | Length | Value | Description | . | time_in_sec | 4B | time | The value is presented in seconds. | . The field indicates the time since the GPS epoch (00:00:00 Jan 6, 1980). | Command data - Fractional time . | Mnemonic | Length | Value | Description | . | fract_units | 2B | fractional time | The value is expressed in units of 1/32768 s (30.5 us). | . The field indicates the remaining fractional time. | Command data - Uncertainty units . | Mnemonic | Length | Value | Description | . | uncert_units | 2b | 0x0 | 1/32768 s (30.5us) | . | uncert_units | 2b | 0x1 | 32/32768 s (0.97 ms) | . | uncert_units | 2b | 0x2 | 1024/32768 s (31.25 ms) | . | uncert_units | 2b | 0x3 | 8192/32768 s (250 ms) | . The field indicates the error/uncertainty units of a single bit of uncertainty in time that is presented by two fields: uncert_part_1 and uncert_part_2. The maximum value of error/uncertainty in time based on units is as follows: . | for 0x0 maximum is 0.5 s | for 0x1 maximum is 16 s | for 0x2 maximum is 8.5 min | for 0x3 maximum is 1.13 h | . | Command data - Uncertainty . | Mnemonic | Length | Value | Description | . | uncert_part_1 | 1B | Less significant part of current error/uncertainty. | This part presents bits 0 - 7 of uncertainty | . | uncert_part_2 | 6b | Most significant part of current error/uncertainty. | This part presents bits 8 - 13 of uncertainty | . The field indicates the current error/uncertainty. The total of the error/uncertainty is 14b. The value is split into two fields uncert_part_1 and uncert_part_2 in the frame. The value is expressed in units specified by uncert_units. | Command data - Random key . | Mnemonic | Length | Value | Description | . | rand_key | 4B | random value | The value is generated by the sender device. | . RESP_TIME command shall include the copy of random key received in GET_TIME command. | . 3.2.2.2 Join commands . Join command Join-Req Message uses Amazon Sidewalk CMD ID ‘SET JOIN REQ’. Join command Join-Resp Message uses Amazon Sidewalk CMD ID ‘SET JOIN RESP’. They are used for initial connection establishment, namely Network Join procedure as well as periodic connection refreshes, namely Network Sync procedures as detailed in section 8.3. The information content carried with these commands vary depending on use case, i.e. whether used for Network Join or Network Sync processes, as well as the communication mode and profile configuration of the Endpoint. The contents of and are listed in Table 3.1 and Table 3.2, and detailed in section 3.2.2.2.3. Table 3.1 Information content carried in the JOIN-REQ CMD Payload . | `*Profile** | Use Case | Tag and Length Identifier (TL) | Profile Attributes | . | Async Connection Mode Profiles A, B, D | Network Join | 0xC407 | 1. Device Profile ID (1B)2. Window validity period in seconds (2B)3. Window count (1B)4. Receive window interval (2B)5. Periodic uplink interval (Provable reachability interval) (1B) | . | Async Connection Mode Profiles A, B, D | Network Sync | 0xC407 | 1. Device Profile ID (1B)2. Window validity period in seconds (2B)3. Window count (1B)4. Receive window interval (2B)5. Periodic uplink interval (Provable reachability interval) (1B) | . | Sync Connection Mode Profile 1 | Network Join | 0xC305 | ID of the selected GW (5B) | . | Sync Connection Mode Profile 1 | Network Sync | 0xC305 | ID of the selected GW (5B) | . | Sync Connection Mode Profile 2 | Network Join | 0x4D | UL Link Latency (1B) and Load (1B) | . | Sync Connection Mode Profile 2 | Network Join | 0x4C | DL Link Latency (1B) and Load (1B) | . | Sync Connection Mode Profile 2 | Network Join | 0xC305 | ID of the selected GW (5B) | . | Sync Connection Mode Profile 2 | Network Join | 0x09 | Link Duration (1B) | . | Sync Connection Mode Profile 2 | Network Sync | 0xC305 | ID of the selected GW (5B) | . Table 3.2 Information content carried in the JOIN-RESP CMD Payload . | Profile | Use Case | Tag and Length Identifier (TL) | Profile Attributes | . | Async Connection Mode Profiles A, B, D | Network Join | 0x00 | Success or Failure (1B) | . | Async Connection Mode Profiles A, B, D | Network Sync | 0x00 | Success or Failure (1B) | . | Sync Connection Mode Profile 1 | Network Join | 0x00 | Success or Failure (1B) | . | Sync Connection Mode Profile 1 | Network Sync | 0x00 | Success or Failure (1B) | . | Sync Connection Mode Profile 2 | Network Join | 0x08 | Request Accept Reject (1B) | . | Sync Connection Mode Profile 2 | Network Join | 0x46 | UL Schedule (2B) | . | Sync Connection Mode Profile 2 | Network Join | 0x41 | DL Schedule (2B) | . | Sync Connection Mode Profile 2 | Network Join | 0x47 | Contention Param (2B) | . | Sync Connection Mode Profile 2 | Network Join | 0x09 | Link Duration (1B) | . | Sync Connection Mode Profile 2 | Network Sync | 0x00 | Success or Failure (1B) | . 3.2.2.2.1 Command class . | Mnemonic | Length | Value | Description | . | cmd_class | 12b | 0x00 | The value is common for all management commands. | . 3.2.2.2.2 Command ID . | Mnemonic | Length | Value | Type | Command name | Command direction | . | cmd_id | 12b | 0x22F | Write | SET_JOIN_REQ | UL | . | cmd_id | 12b | 0x22F | Response | RESP_JOIN_REQ | DL | . 3.2.2.2.3 Command Payload . The command payloads of the ‘Join Commands’ carry several different fields of information content as listed in table 3.1 and table 3.2. Each payload can carry several different information fields, each of which encoded following a TLV format (type-length-value) differentiating information from one another. The type and length fields indicate the type and size of the information content in the field followed by a value field carrying the information. In the case of asynchronous connection mode profiles, ‘SET JOIN REQ’ payload contains a single TLV field, namely ‘Async profile attributes’. In the case of synchronous connection mode profile 2’s ‘Join Process’ usage, ‘SET JOIN REQ’ CMD payload contains four different individually encoded TLV fields. All other usages include only a single TLV encoded field. ` Async profile attributes (0x04) This information field has 7 B of information payload requiring 2 B TL field with a value of ‘0xC407’ making the total CMD payload size of 9 B. The information content is listed in order as follows: . | Device Profile id . | Mnemonic | Length | Value | Description | . | profile_id | 1B | 0x80 | Profile A | . | profile_id | 1B | 0x81 | Profile B | . The field indicates the Power Profile ID used by an Endpoint. | Window Validity Period . | Mnemonic | Length | Value | Description | . | val_period | 2B | 0x0 | Unlimited validity period. | . | val_period | 2B | 0x0001 - 0xFFFF | Validity period in seconds. | . The field indicates the time period when an Endpoint is accessible by the cloud. The time counter starts after the last transmission received by the cloud. Downlink transmission shall not be performed after the validity period is expired by the cloud. The cloud shall wait until the next uplink frame to transmit its data in the downlink direction. | Number of downlink opportunities . | Mnemonic | Length | Value | Description | . | nb_dl_slot | 1B | 0, 5, 10, 15, 20 | The number of downlink opportunities. | . The field indicates the number of downlink opportunities that are available after uplink transmission. Value 0 means infinite downlink opportunities. For more information about nb_dl_slot see section 5.3.1. | Downlink opportunities separation . | Mnemonic | Length | Value | Description | . | dl_separation | 2B | 5000 | DL opportunities separation in ms. | . The field indicates the time period between two consecutive downlink opportunities. For detailed information about dl_separation parameter, see section 5.3.1, section 5.5.2.1, section and 5.5.2.2. | Uplink frequency of synchronization packets . | Mnemonic | Length | Value | Description | . | ul_sync_interval | 1B | 0x00 | Profile A | . | ul_sync_interval | 1B | 0x05 | Profile B | . The field indicates the time interval of between subsequent uplink synchronization packets in minutes. Uplink frequency of synchronization packets may be considered also as Provable Reachable Interval (PRI) that identifies the longest interval since last uplink when the cloud may expect uplink data. It does not limit the ability of an Endpoint to send more uplink packets. The value may differ for selected Endpoints’ Connection Profiles. For detailed information about ul_sync_interval parameter, see section 5.5.2.1, and section 5.5.2.2. Value 0 means that the time interval is undefined. It means that the cloud does not know when an uplink packet may come. * Synchronous Connection Mode Profile 2 UL Link Characteristics (0xD) . | . This information field has 2 B of payload requiring 1 B TL field with a value of ‘0x4C’. The first byte of the value contains indicates the desired interval between UL opportunities in increments of 63 ms. The second byte of the information contains an enum indicating the expected load of the node. | Synchronous Connection Mode Profile 2 DL Link Characteristics (0xD) . This information field has 2 B of payload requiring 1 B TL field with a value of ‘0x4C’. The first byte of the value contains indicates the desired interval between DL opportunities in increments of 63 ms. The second byte of the information contains an enum indicating the expected load of the node. | Synchronous Connection Mode - Node ID (0x3) . This information field has 5 B of value, i.e. requiring an extra byte of explicit length field, making the TL field give a value of ‘0xC305’. The information contains the ID of the Gateway selected as the Sidewalk Relay, as discovered by its ‘Beacon’ packet contents. | Synchronous Connection Mode Link Duration (0x9) . This information field has 1 B of payload requiring 1 B TL field with a value of ‘0x09’. The information contains link reservation duration at the Sidewalk Relay without requiring any transmissions activity. Prior to expiration of the reservation, the Endpoints can extend this reservation via an uplink packet for another full reservation period. In ‘SET JOIN REQ’, the information field indicates the desired wake-up characteristics of the Endpoint. In ‘SET JOIN RESP’, the information field indicates the requirement set by the Gateway keeping the reservation. The Endpoint adopts to the value in the ‘SET JOIN RESP’. | Status response (0x0) The field indicates whether SET_JOIN_REQ command is either accepted or rejected. The field is commonly used in Synchronous and Asynchronous connection modes. | Mnemonic | Length | Value | Description | . | status_resp | 1B | 0x00 | accepted | . | status_resp | 1B | 0x01 | rejected | . | . 3.2.2.3 Device profile commands . Device profile commands are applicable to SubG-CSS devices only. Commands purpose is: . | To get information related to the current configuration of the Connection Profiles used by the Endpoint (GET_DEVICE_PROFILE, RESP_DEVICE_PROFILE) | To request the Endpoint to set the selected Connection Profile using the configuration provided (SET_DEVICE_PROFILE ) | . Fig. 3.11 SET-DEVICE-PROFILE and RESP-DEVICE-PROFILE commands - Command data format . Fig. 3.12 GET-DEVICE-PROFILE command - Command data format . | Command class . | Mnemonic | Length | Value | Description | . | cmd_class | 12b | 0x00 | The value is common for all management commands. | . | Command ID . | Mnemonic | Length | Value | Type | Command name | Command direction | . | cmd_id | 12b | 0x230 | Read | GET_DEVICE_PROFILE | DL | . | cmd_id | 12b | 0x230 | Write | SET_DEVICE_PROFILE | DL | . | cmd_id | 12b | 0x230 | Response | RESP_DEVICE_PROFILE | UL | . | Command data - Format ID . | Mnemonic | Length | Value | Description | . | format_id | 1B | 0x01 | SubG-CSS device Connection Profile settings. | . | Commands data - Profile ID . | Mnemonic | Length | Value | Description | . | profile_id | 1B | 0x80 | Profile A | . | profile_id | 1B | 0x81 | Profile B | . The field indicates the Connection Profile ID used by an Endpoint. | Command data - Number of downlink opportunities . | Mnemonic | Length | Value | Description | . | nb_dl_slot | 1B | 0, 5, 10, 15, 20 | The number of downlink opportunities. | . The field indicates the number of downlink opportunities that are available after uplink transmission. Value 0 means infinite downlink opportunities. For detailed information about nb_dl_slot parameter, see Section 5.3.1. | Command data - Downlink opportunities separation . | Mnemonic | Length | Value | Description | . | dl_separation | 2B | 5000 | DL opportunities separation in ms. | . The field indicates the time period between two consecutive downlink opportunities. | . 3.2.2.4 Reset commands . The reset command is used by the Amazon Sidewalk Cloud to request a reset type to be performed by the Endpoint. The SET_RESET command is used for this purpose. The Endpoint confirms reset execution using NOTIFY_RESET command. Fig. 3.13 SET-RESET command - Command data format . Fig. 3.14 NOTIFY-RESET command - Command data format . | Command class . | Mnemonic | Length | Value | Description | . | cmd_class | 12b | 0x00 | The value is common for all management commands. | . | Command ID . | Mnemonic | Length | Value | Type | Command name | Command direction | . | cmd_id | 12b | 0x112 | Write | SET_RESET | DL | . | cmd_id | 12b | 0x112 | Notification | NOTIFY_RESET | UL | . | Command data - Reset type . | Mnemonic | Length | Value | Description | . | reset_type | 1B | 0x00 | Soft reset clears the persistent configuration.Requires factory reset to be performed. | . | reset_type | 1B | 0x01 | Hard reset is the same as Soft reset. | . | reset_type | 1B | 0x02 | Reboots the device. | . | Command data - Reset target . | Mnemonic | Length | Value | Description | . | reset_target | 1B | 0x00 | RESET_TARGET_ALL | . | reset_target | 1B | 0x01 | RESET_TARGET_MCU | . | reset_target | 1B | 0x02 | RESET_TARGET_HOST | . | Command data - Reboot delay . | Mnemonic | Length | Value | Description | . | reboot_delay | 1B | 0x00 - 0xFF | Reboot delay in seconds. | . | . 3.2.3 Capability and Configuration commands . The capabilities of the Endpoint shall be notified to the Sidewalk cloud upon successful registration and time acquisition. In the case of FSK and LoRa links, the notification of capabilities of the Endpoint shall be completed upon successful completion of join procedure. The Endpoint can receive a configuration update from Sidewalk cloud that might require it to change its behavior to adhere to the new configuration downloaded. For instance, Sidewalk cloud could download a configuration to an Endpoint to enforce traffic rate throttling. Upon receiving such a configuration, the Endpoint would limit the number of messages that it sends out. | Command class . | Mnemonic | Length | Value | Description | . | cmd_class | 4b | 0x00 | The value is common for all metrics commands. | . | Command IDs . | Mnemonic | Length | Value | Type | Command name | Command direction | . | cmd_id | 4b | 0x02 | Read | EP_CAP_CFG_READ | DL | . | cmd_id | 4b | 0x02 | Notify | EP_CAP_CFG_NOTIFY | UL | . | cmd_id | 4b | 0x02 | Write | EP_CAP_CFG_WRITE | DL | . | cmd_id | 4b | 0x02 | Response | EP_CAP_CFG_RESP | UL | . | . 3.2.3.1 Capability Parameters . The Endpoint shall notify to the Sidewalk cloud service the following listed capability parameters. | Parameter | Description | . | sdk_version | The version of Sidewalk SDK that the device incorporates. | . | links_supported | The Sidewalk network links that the device supports. | . | features_supported | The Sidewalk Endpoint SDK features that the device supports. | . | qualificaiton_id | The qualification id that is provided to the device by Sidewalk qualification. | . | max_tx_power | The maximum transmit power configured for all the supported links. | . | power_source | The device is battery powered or line powered. | . 3.2.3.2 Configuration Parameters . The Endpoint shall support the configuration of the following parameters through a downlink message sent from the Sidewalk cloud services. | Parameter | Description | . | enable_metrics | The configuration to turn on and off reporting of Sidewalk metrics. | . | metrics_periodicity | The periodicity of the metrics the Sidewalk EP reports to Sidewalk Cloud. | . | traffic_throttling | The configuration to turn on and off traffic rate throttling. | . 3.2.4 Metrics commands . Metrics Commands report Endpoint metrics for synchronous and asynchronous connections. Values are determined by the Endpoint, and sent to the cloud periodically. Metrics data shall be reported by Endpoint asynchronously. The Endpoint shall support synchronous retrieval of its metrics data through a downlink message from the Sidewalk cloud services. Metrics data shall be classified into categories and each category shall contain one or more metrics. Metrics data shall be reported once in a day through an explicit message to Sidewalk cloud service. This periodicity can be changed by the Sidewalk cloud service. Metrics data shall be immediately flushed if the Sidewalk connectivity is not present at the time of reporting. The Sidewalk cloud service can download configuration to the Endpoint to enable or disable reporting metrics of one or all categories. Metrics data shall be reported to Sidewalk cloud using one explicit message with configured retry parameters. When all the data cannot be accommodated in one explicit message, the remaining metric data is sent as part of subsequent messages from the Endpoint. | Command class . | Mnemonic | Length | Value | Description | . | cmd_class | 4b | 0x0B | The value is common for all metrics commands. | . | Command IDs . | Mnemonic | Length | Value | Type | Command name | Command direction | . | cmd_id | 4b | 0x0E | Read | REQ_READ_METRICS_FWK | DL | . | cmd_id | 4b | 0x0E | Response | RESP_REQ_METRICS_FWK | UL | . | cmd_id | 4b | 0x0E | Notify | NOTIFY_REQ_METRICS_FWK | UL | . | cmd_id | 4b | 0x0F | Read | SET_CONFIG_METRICS_FWK | DL | . | cmd_id | 4b | 0x0F | Response | RESP_CONFIG_METRICS_FWK | UL | . | Category - BLE Link . | Mnemonic | Length | Value | Description | . | num_ul | 4B | 0x00 - 0xFFFFFFFF | Number of ULs. | . | num_dl | 4B | 0x00 - 0xFFFFFFFF | Number of DLs. | . | num_ul_fail | 4B | 0x00 - 0xFFFFFFFF | Number of UL failures. | . | num_dl_decode_fail | 4B | 0x00 - 0xFFFFFFFF | Number of DL decode failures. | . | num_dl_buffer_underrun | 1B | 0x00 - 0xFF | buffers. | . | num_msg_bursts | 2B | 0x00 - 0xFFFF | Message burst is defined as more than 30 messages in a minute. | . | avg_ul_msg_size | 1B | 0x00 - 0xFF | Average size of UL messages. | . | avg_dl_msg_size | 1B | 0x00 - 0xFF | Average size of DL messages. | . | num_conn_success | 2B | 0x00 - 0xFFFF | Number of successful connections. | . | num_conn_attempts | 2B | 0x00 - 0xFFFF | Number of connection attempts. | . | num_conn_attempts_error | 2B | 0x00 - 0xFFFF | with critical errors. | . | avg_rssi | 1B | -127 - +127 | Average RSSI of messages received. | . | min_rssi | 1B | -127 - +127 | with. | . | Category - FSK Link . | Mnemonic | Length | Value | Description | . | num_ul | 4B | 0x00 - 0xFFFFFFFF | Number of ULs. | . | num_dl | 4B | 0x00 - 0xFFFFFFFF | Number of DLs. | . | num_ul_fail | 2B | 0x00 - 0xFFFF | Number of UL failures. | . | num_dl_decode_fail | 2B | 0x00 - 0xFFFF | Number of DL decode failures. | . | num_dl_buffer_underrun | 1B | 0x00 - 0xFF | buffers. | . | num_msg_bursts | 1B | 0x00 - 0xFF | Message burst is defined as more than 20 messages per minute. | . | avg_ul_msg_size | 1B | 0x00 - 0xFF | Average size of UL messages. | . | avg_dl_msg_size | 1B | 0x00 - 0xFF | Average size of DL messages. | . | num_sidewalk_network_ul | 2B | 0x00 - 0xFFFF | Sidewalk cloud. | . | Category - FSK MAC Layer . | Mnemonic | Length | Value | Description | . | num_radio_errors | 2B | 0x00 - 0xFFFF | Number of radio errors encountered. | . | num_radio_critical_errors | 1B | 0x00 - 0xFF | encountered. | . | num_tx | 4B | 0x00 - 0xFFFFFFFF | link layer acknowledgments. | . | num_tx_fail | 4B | 0x00 - 0xFFFFFFFF | Number of messages failed to transmit. | . | num_tx_fail_no_ack | 1B | 0x00 - 0xFF | due to lack of link layer acknowledgment. | . | num_rx | 4B | 0x00 - 0xFFFFFFFF | link layer acknowledgments. | . | num_tx_ack | 4B | 0x00 - 0xFFFFFFFF | Number of acknowledgments transmitted. | . | num_crc_errors | 4B | 0x00 - 0xFFFFFFFF | Number of CRC errors. | . | avg_rssi | 1B | -127 - +127 | Average RSSI of messages received. | . | min_rssi | 1B | -127 - +127 | with. | . | Category - LoRa Link . | Mnemonic | Length | Value | Description | . | num_ul | 2B | 0x00 - 0xFFFF | Number of ULs. | . | num_dl | 2B | 0x00 - 0xFFFF | Number of DLs. | . | num_ul_fail | 2B | 0x00 - 0xFFFF | Number of UL failures. | . | num_dl_decode_fail | 2B | 0x00 - 0xFFFF | Number of DL decode failures. | . | num_dl_buffer_underrun | 1B | 0x00 - 0xFF | Number of DL failures due to lack of buffers. | . | num_msg_bursts | 1B | 0x00 - 0xFF | Number of message bursts. Message burst is defined as more than 12 messages per hour for a mobile device and 4 messages per hour for a static device. | . | avg_ul_msg_size | 1B | 0x00 - 0xFF | Average size of UL messages. | . | avg_dl_msg_size | 1B | 0x00 - 0xFF | Average size of DL messages. | . | num_sidewalk_network_ul | 2B | 0x00 - 0xFFFF | cloud. | . | Category - LoRa MAC Layer . | Mnemonic | Length | Value | Description | . | num_radio_errors | 2B | 0x00 - 0xFFFF | Number of radio errors encountered. | . | num_radio_critical_errors | 1B | 0x00 - 0xFF | Number of critical radio errors encountered. | . | num_tx | 2B | 0x00 - 0xFFFF | Number of messages transmitted. | . | num_rx | 2B | 0x00 - 0xFFFF | Number of messages received. | . | num_crc_errors | 1B | 0x00 - 0xFF | Number of CRC errors. | . | avg_rssi | 1B | -127 - +127 | Average RSSI of messages received. | . | min_rssi | 1B | -127 - +127 | The lowest RSSI a message is received with. | . | Category - Retries and Duplicates . | Mnemonic | Length | Value | Description | . | num_retries_ble | 4B | 0x00 - 0xFFFFFFFF | Number of retries performed on BLE link. | . | num_retries_fsk | 2B | 0x00 - 0xFFFF | Number of retries performed on FSK link. | . | num_retries_lora | 2B | 0x00 - 0xFFFF | Number of retries performed on LoRa link. | . | num_duplicates_ble | 4B | 0x00 - 0xFFFFFFFF | Number of duplicates received on BLE link. | . | num_duplicates_fsk | 2B | 0x00 - 0xFFFF | Number of duplicates received on FSK link. | . | num_duplicates_lora | 2B | 0x00 - 0xFFFF | Number of duplicates received on LoRa link. | . | avg_rtt | 1B | 0x00 - 0xFF | Average round trip time for all messages. | . | Category - Registration . | Mnemonic | Length | Value | Description | . | num_reg_attempts | 1B | 0x00 - 0xFF | Number of registration attempts performed. | . | num_reg_errors | 1B | 0x00 - 0xFF | Number of registration attempts failed. | . | num_key_refresh_attempts | 1B | 0x00 - 0xFF | Number of key refresh performed. | . | num_key_refresh_errors | 1B | 0x00 - 0xFF | Number of key refresh attempts failed. | . | Category - Time Synchronization . | Mnemonic | Length | Value | Description | . | num_time_sync_requests | 2B | 0x00 - 0xFFFF | Number of time sync requests performed. | . | num_time_sync_responses | 2B | 0x00 - 0xFFFF | Number of time sync responses received. | . | time_sync_periodicity | 2B | 0x00 - 0xFFFF | The periodicity of time sync requests. | . | drift_ms | 1B | 0x00 - 0xFF | Endpoint GCS time and GCS time received in time sync response. | . | Category - Network Synchronization . | Mnemonic | Length | Value | Description | . | num_nw_join_requests_fsk | 2B | 0x00 - 0xFFFF | performed. | . | num_nw_join_responses_fsk | 2B | 0x00 - 0xFFFF | Number of join responses received. | . | num_nw_join_requests_lora | 2B | 0x00 - 0xFFFF | performed. | . | num_nw_join_responses_lora | 2B | 0x00 - 0xFFFF | performed. | . | Category - Security . | Mnemonic | Length | Value | Description | . | num_decrypt_errors | 2B | 0x00 - 0xFFFF | Number of decryption errors. | . | num_auth_errors | 2B | 0x00 - 0xFFFF | Number of authentication errors. | . | Category - FFN . | Mnemonic | Length | Value | Description | . | num_ffn_retries | 2B | 0x00 - 0xFFFF | Number of FFN retry attempts. | . | Category - Sidewalk Bulk Transfer . | Mnemonic | Length | Value | Description | . | num_file_xfer | 1B | 0x00 - 0xFF | Number of File transfer attempts. | . | num_file_xfer_errors | 1B | 0x00 - 0xFF | Number of File transfer errors. | . | Category - Multi Link Management . | Mnemonic | Length | Value | Description | . | num_conn_attempts_ble | 2B | 0x00 - 0xFFFF | Number of connection attempts over BLE. | . | num_conn_attempts_fsk | 2B | 0x00 - 0xFFFF | Number of connection attempts over FSK. | . | num_conn_attempts_lora | 2B | 0x00 - 0xFFFF | Number of connection attempts over LoRa. | . | num_conn_timeouts_ble | 2B | 0x00 - 0xFFFF | Number of connection timeouts over BLE. | . | num_conn_timeouts_fsk | 2B | 0x00 - 0xFFFF | Number of connection timeouts over FSK. | . | num_conn_timeouts_lora | 2B | 0x00 - 0xFFFF | Number of connection timeouts over LoRa. | . | min_time_successful_conn | 2B | 0x00 - 0xFFFF | connection. | . | max_time_successful_conn | 2B | 0x00 - 0xFFFF | connection. | . | num_links_traversed | 1B | 0x00 - 0xFF | connection. | . | last_policy_selected | 1B | 0x00 - 0xFF | The last MLM policy selected. | . | Category - Automatic Connection Management . | Mnemonic | Length | Value | Description | . | num_conn_attempts_ble | 2B | 0x00 - 0xFFFF | Number of connection attempts over BLE. | . | num_conn_attempts_fsk | 2B | 0x00 - 0xFFFF | Number of connection attempts over FSK. | . | num_conn_attempts_lora | 2B | 0x00 - 0xFFFF | Number of connection attempts over LoRa. | . | num_conn_timeouts_ble | 2B | 0x00 - 0xFFFF | Number of connection timeouts over BLE. | . | num_conn_timeouts_fsk | 2B | 0x00 - 0xFFFF | Number of connection timeouts over FSK. | . | num_conn_timeouts_lora | 2B | 0x00 - 0xFFFF | Number of connection timeouts over LoRa. | . | links_priority_config | 1B | 0x00 - 0xFF | Order of priority of links to connect. | . | timeout_config_ble | 2B | 0x00 - 0xFFFF | Timeout configured for BLE link. | . | timeout_config_fsk | 2B | 0x00 - 0xFFFF | Timeout configured for FSK link. | . | timeout_config_lora | 2B | 0x00 - 0xFFFF | Timeout configured for LoRa link. | . | min_time_successful_conn | 2B | 0x00 - 0xFFFF | connection. | . | max_time_successful_conn | 2B | 0x00 - 0xFFFF | connection. | . | . ", "url": "/specifications/sidewalk-protocol-spec/application/application-commands.html#32-application-commands", "relUrl": "/specifications/sidewalk-protocol-spec/application/application-commands.html#32-application-commands" },"54": { "doc": "3.2 Application Commands", "title": "3.2 Application Commands", "content": " ", "url": "/specifications/sidewalk-protocol-spec/application/application-commands.html", "relUrl": "/specifications/sidewalk-protocol-spec/application/application-commands.html" },"55": { "doc": "3.1 Application layer", "title": "3.1 Application layer", "content": "Application layer is the top layer of the Amazon Sidewalk protocol. This layer supports realization of procedures defined for different activities of an Endpoint. These activities may be Endpoint registration, time synchronization, and data exchange with the cloud. Procedures are executed by sending and receiving a sequence of messages between Endpoint and the other side of communication link. One message shall contain one application command only. The layer takes care of the right order of messages flow, handling exceptions and others that require proper finalization of a procedure. A user application placed on an Endpoint provides a service to a user. This level application does not have direct access to commands defined and described in this and following sections. A user application interacts with the Amazon Sidewalk protocol stack application layer through the SDK interface. SDK interface description is outside the scope of this technical specification. Fig. 3.1 Application layer - SDK interface . 3.1.1 Application layer frame format . Application layer provides a simple frame format for coding of application commands. This frame contains three fields: Command class, Command ID and Command data. Fig. 3.2 Application layer - Frame format . A Command class field identifies a high level functionality area. Each Command class contains set of commands that perform a task in the corresponding area. The following Command classes are defined in the Amazon Sidewalk protocol: . | management - group of commands that are dedicated for managing Endpoints in the Amazon Sidewalk network | custom - group of commands that provide data exchange service for a user application | metrics - group of commands that are related to various statistics and measurements of communication link | security - group of commands that implement Amazon Sidewalk security and registration | . The Command ID field identifies a command in a Command class. It also indicates an interpretation of Command data bytes. The Command data field contains data associated with a Command. The size of the field is Command-dependent. The Command class and Command ID fields may have different lengths. This specification defines five base cases where different sizes and range of values of these fields are determined. Both the Command class and Command ID shall be coded on the same field size and the higher value of either Command class or Command ID specifies the correct case. For example, when Command class is equal to 0x0 and Command ID is equal to 0x108 then both shall be encoded on 12b field size (Case 4). | Case | Command class range of values | Command ID range of values | Command class and command ID fields size | Comment | . | 1 | 0x0 - 0x7 | 0x0 - 0x3 | 3b | see Figure 3.3 | . | 2 | 0x8 - 0xF | 0x4 - 0xF | 4b | see Figure 3.4 | . | 3 | 0x10 - 0xFF | 0x10 - 0xFF | 8b | see Figure 3.5 | . | 4 | 0x100 - 0xFFF | 0x100 - 0xFFF | 12b | see Figure 3.6 | . | 5 | 0x1000 - 0xFFFF | 0x1000 - 0xFFFF | 16b | see Figure 3.7 | . Fig. 3.3 Application layer - Command format - Case 1 . Fig. 3.4 Application layer - Command format - Case 2 . Fig. 3.5 Application layer - Command format - Case 3 . Fig. 3.6 Application layer - Command format - Case 4 . Fig. 3.7 Application layer - Command format - Case 5 . ", "url": "/specifications/sidewalk-protocol-spec/application/application-layer.html", "relUrl": "/specifications/sidewalk-protocol-spec/application/application-layer.html" },"56": { "doc": "4.1 Architecture", "title": "4.1 Architecture", "content": "Amazon Sidewalk is a shared network developed by Amazon to allow developers outside Amazon to create and bring to market all types of consumer, enterprise, and public sector smart and connected devices and services. Amazon Sidewalk security features include: device authentication, data encryption, and more. These features encrypt and protect the network, maintain customer privacy and protect customer data. The following key components are referenced throughout this chapter: Amazon Sidewalk Gateways, Amazon Sidewalk Endpoints, Amazon Sidewalk Network Server, and Application Servers. These key components are defined as follows: . | An Endpoint is a source and termination point of data for the RF protocol. As a hardware entity, an Endpoint contains safe storage for keys (including device and application keys and credentials) and a memory area for security procedures. The Endpoint security software is responsible for the ID obfuscation process. | The Endpoint Application Firmware is a dedicated external application that is loaded onto an Endpoint for handling application business logic tasks. Software is signed using the device manufacturer’s firmware signing key during the manufacturing process. | The Gateway is a hardware entity in the Amazon Sidewalk network. A Gateway provides storage for keys and credentials and a memory area for security procedures. | The Amazon Sidewalk Gateway Software is an Amazon Sidewalk-dedicated internal software module for routing Amazon Sidewalk protocol messages and configuring local resources. Endpoint to Application Server traffic (payload) passes through the Gateway software. For SubG-CSS and SubG-FSK, the Flex Layer has a third layer of encryption to encrypt the communication between the Gateway MCU and the Amazon Sidewalk Cloud. | The Amazon Sidewalk Network Server is a dedicated cloud service responsible for time-based ID obfuscation, rotation and network key management. The service is also responsible for managing device primary keys and the certificate chain, and for terminating the Flex Layer and the Network Layer. The Amazon Sidewalk Network Server is the source of the time in GCS functionality that is part of each ciphering procedure used within the Amazon Sidewalk system. The routing table for Endpoint devices is stored in the Network Server. | The Application Server is a dedicated cloud service. The Application Server is responsible for routing application traffic between external applications and applications in the Endpoint. AWS IoT Wireless is responsible for maintaining Endpoint application credentials for the Application Server. | . Encrypted links in the Amazon Sidewalk system are listed below: . | Endpoint to Gateway content is handled by Amazon Sidewalk protocol. Security aspects are described in section 4.6.1 | Gateway to Amazon Sidewalk Network Server link is managed by the Flex Layer, see section 4.8.1. An encrypted link is established during the Gateway provisioning process, see section 4.4.1.1. Transmission is encrypted by the Gateway network security key. Keys are derived and rotated on an hourly basis, see section 4.5.2. The Gateway primary key is refreshed on each Gateway device reboot. | Endpoint to Amazon Sidewalk Network Server security content is handled by the Network Layer protocol, command messages are provided in the Presentation Layer protocol. See section 5.1.1; for security aspects see section 5.1.2.2.2, and for multirate see section 5.4.3. Encrypted Third Party Application traffic is encapsulated in flex frames. The Gateway uses the Amazon Sidewalk protocol to route flex frames to the Endpoint. | Endpoint to Application Server communication is handled by the Application Layer protocol. Application key encryption is used to encrypt traffic between the Endpoint and the AWS IoT Wireless managed service. See section 3.1; for key exchange procedures see section 4.5; for encoding, decoding and related security aspects, see section 4.7. | Communication between AWS IoT Wireless service and Third Party Application is handled by AWS Cloud Services. The operation of AWS Cloud Services is outside the scope of this document. | . The end-to-end system has an Amazon Sidewalk system and a Third party (Web-based) application. The Amazon Sidewalk system has two hardware modules (Endpoint and Gateway) and five software modules (Endpoint Application, Gateway application, Mobile application, Network, and Application Servers in the cloud).Figure 4.1 shows a simplified view of the system components. AWS IoT asset services support Application Server with auxiliary data (device and user-related). fig 4.1 Security Spec architecture diagram . 4.1.1 Security model . The Amazon Sidewalk protocol ensures the security of transmitted data by encrypting the data. The Amazon Sidewalk protocol also supports device registration, authentication and authorization when connecting to the Amazon Sidewalk network. Authorization in Amazon Sidewalk is based on Amazon Sidewalk’s Public Key Infrastructure Certificate Authority system. A multilevel certificate chain is maintained, based on a self-signed root certificate authority (CA). Certificate issuing and signing and exchange of cryptographic keys is carried out using the asymmetric algorithm ECDH (elliptic curve Diffie-Hellman). Two sets of elliptic cryptographic curves (Ed25519 and p256r1) are used for keys and certificate generation. The Ed25519 certificate is used to define the identity of the device. The p256r1 is used to define the signature of the device. Both are needed to register a device with the certificates and to show proof of possession. Network data confidentiality and integrity are provided by the AES-GCM algorithm. Application data confidentiality is achieved using the symmetric key AES-CTR algorithm. Endpoint pseudo-anonymity is achieved by Device ID obfuscation, and by address translation in the Network server. Each of the entities (device, service) has a set of credentials associated with it. Credentials consist of asymmetric keys, certificates and their signatures - see section 4.1.3. Security aspects are implemented across the whole of the system’s lifetime starting with device production, then FW management, connection to the user’s network, maintaining transmission confidentiality, and ensuring pseudo-anonymity of devices in the network. End user identification and authentication are outside the scope of this document. 4.1.2 Certificate chain . The terms used to describe the certificate chain are described in 4.1. Certificate chain . | Term | Definition | . | Certificate | An electronic document used to prove the validity of a public key. In Sidewalk, a certificate consists of three parts: the public key, the certificate serial number, and the certificate signature. | . | Certificate Chain | The certificate chain is a list of certificates used to authenticate an entity. The chain, begins with the certificate of that entity, and each certificate in the chain is signed by the entity identified by the next certificate in the chain. | . | Certificate Authority | A Certificate Authority (CA) is a certificate that issues (validates and signs) other certificates in the certificate chain. | . | Root Certificate Authority | A Root Certificate Authority (CA) forms the basis for the certificate chain. The root CA has the property that it is self-signed, issuing its own certificate, thus generating its own signature. | . | Intermediate Certificate Authority | An Intermediate Certificate Authority (CA) is a certificate in the chain that was issued (validated and signed) by another CA, and has the authority to issue other certificates (in contrast to the root CA which issues itself). | . | Device Attestation Key | The Device Attestation Key (DAK) is a private key issued by a Certificate Authority (CA) used to sign and issue device certificates during device provisioning and manufacturing. | . | Hardware Security Module | The Hardware Security Module (HSM) is a physical computing device that safeguards and manages digital keys. The HSM is used for computing device certificate signatures. | . Amazon Sidewalk maintains two multilevel certificate chains using Ed25519 and p256r1 elliptic curves. Each Certificate Authority (CA) issues a certificate to the next level in a certificate chain. The certificate chain begins with the Amazon Root CA. The Device Attestation Key (DAK) is hosted on a Hardware Security Module (HSM). The HSM issues device certificates during the manufacturing provisioning process, see section 4.4.1.1. Cloud certificates (Network Server certificate) are derived from the Amazon Root CA. Application server certificates are derived from the Manufacturer’s certificate.Figure 4.2 shows a simplified certification chain. fig 4.2 Certification path . 4.1.3 Certificates and device serial numbers . Amazon Sidewalk Certificates contain three fields - Serial, Public Key, and Signature. Amazon Sidewalk Certificates use the following layout: . Device certificates use the Amazon Sidewalk Manufacturing Serial Number (SMSN) as their serial number in the Serial field. Intermediate and root CAs use the following table to generate a 4 B serial number for the Serial field. A detailed fields description is in Table 4.2. For more information on device serial number content see Section 4.3, for more information on the process of assigning numbers, see Section 4.4.1.1. fig 4.3 Sidewalk certificate formats . Table 4.2 Certificate serial number . | Bit # | Content | Description | Notes | . | 31..30 | Type of certificate | 0 -root, 1- intermediate, 2 - cloud |   | . | 29..28 | Chain size | 1-3 - depth of the full cert chain |   | . | 27..26 | Depth in chain | 0 -root (or cloud) 1 -3 - intermediate certificate |   | . | 25..23 | Signing rights | 0 - intermediate only 1 - intermediate and Endpoint 2 - intermediate and cloud 3 - intermediate, Endpoint and cloud cert 4 - Endpoint cert only 5 - cloud cert only 6 - Gateway 7 - All | Note: cloud can only sign messages | . | 22 : 0 | Subset of device serial number |   | Allows assignment of around 8.3M serial numbers | . 4.1.4 Key types . There are two types of keys in the Amazon Sidewalk system: Asymmetric keys and Symmetric keys. Asymmetric keys are used to sign and verify the message. Symmetric keys are used to encrypt and decrypt the message. Asymmetric keys are built during the factory provisioning process, for more information, see section 4.4.1.1. Symmetric keys are periodically derived from the primary symmetric key. Primary symmetric keys are derived during the device registration process, for more information, see section 4.4.2. Each symmetric key is presented in two versions: counter-based (CTRREF) and global clock-based. Table 4.3 Ephemeral key types: Symmetric security keys are derived in network nodes from a primary symmetric key and rotated periodically . | Key Type | Key name | **Usage | description** | Notes | . | Asymmetric Key | DEVICE_ED25519_PRIVATE | Generate message signature using EDDSA | Ed25519 private key | Built during factory provisioning process | . | Asymmetric Key | DEVICE_ED25519_PUBLIC | Verify message signature EDDSA | Ed25519 public key | Built during factory provisioning process | . | Asymmetric Key | DEVICE_SECP256R1_PRIVATE | Generate message signature using ECDSA | secp256r1 private key | Built during factory provisioning process | . | Asymmetric Key | DEVICE_SECP256R1_PUBLIC | Verify message signature ECDSA | secp256r1 public key | Built during factory provisioning process | . | Symmetric Key | NETWORK_PRIMARY | Generate network symmetric security keys | Primary network key | Shared during device registration or key refresh process by ECDH | . | Symmetric Key | APPLICATION_PRIMARY | Generate application symmetric security keys | Primary application key | Shared during device registration by ECDH-E | . Table 4.4 Keys specification . | Link | Key name | Usage | Derivation | Rotation interval | . | Network Server | TX_ID_KEY | Generate TX_ID for WAN data packet | CMAC(WAN_Primary key, “Network_KDF_TX_UUID” | GCS time reference) | 1 hour | . | Network Server | GCM_KEY | Encrypt/Decrypt data WAN packet with time reference | CMAC(Primary key, “Network_KDF_Device_Network_GCM” | GCS time reference) | 1 hour | . | Network Server | GCM_CTRREF_KEY | Encrypt/Decrypt data WAN packet with counter-based reference | CMAC(Primary key, “Network_KDF_Dev_Ntw_GCM_COUNTER” | counter) | Whenever counter is updated | . | Network Server | TX_ID_CTRREF_KEY | Generate TX ID for WAN time sync packet based on counter | CMAC(Primary key, “Network_KDF_Time_Sync_TX_UUID” | Time_Sync_Counter) | Whenever Time Sync Counter is increased | . | Network Server | CMAC_KEY | Generate authentication tag for time sync packets | CMAC(Primary key, “Network_KDF_Device_Network_CMAC” | GCS time reference) | 1 hour | . | Network Server | CMAC_CTRREF_KEY | Generate authentication tag with counter-based reference | CMAC(Primary key, “Network_KDF_Dev_Ntw_CMAC_COUNTER” | counter) | Whenever counter is updated | . | Network Server | TSYNC_RESP_KEY | Generate time-based CMAC tag for WAN mode RESP_TIME command | CMAC(Primary key, “Network_KDF_Dev_Ntw_Tsync_Resp” | GCS time reference) | 10 min | . | Application Server | TSYNC_RESP_CTRREF_KEY | Generate counter-based CMAC tag for WAN mode RESP_TIME command | CMAC(Primary key, “Network_KDF_Dev_Ntw_Tsync_Resp_Counter” | Time_Sync_Counter) | Whenever counter is updated | . | Application Server | JOIN_RESP_GCM_KEY | Encrypt/Decrypt WAN JOIN RESPONSE packet | CMAC(Primary key, “Network_KDF_Join_Resp_Dev_Ntw” | GCS time reference) | 5 min | . | Application Server | APP_CTR_KEY | Encrypt/Decrypt (AES-CTR) application payload | CMAC(Application Primary key, “Application_KDF_Device_Application_CTR” | GCS time reference) | 1 hour | . | Application Server | APP_GCM_CTRREF_KEY | Encrypt/Decrypt (AES-GCM) application payload with counter-based reference | CMAC(Application Primary key, “Application_KDF_Registration_GCM_COUNTER” | counter) | Whenever counter is updated | . 4.1.5 The procedure of generating device private keys during MFG process . Each device requires two unique key pairs corresponding to the Ed25519 and p256r1 elliptic curves that are generated at the time of device manufacturing. The private keys are then stored in the device’s persistent memory area. The device public key and the Amazon Sidewalk Manufacturing Serial Number (SMSN) are signed using the DAK private key. The device public key and the Amazon Sidewalk Manufacturing Serial Number form the device certificate signature. Note the signing operation takes place in the HSM device, avoiding exposure of the DAK. | ECDSA Signature = ECDSA(DAK p256r1 private key, Device p256r1 Public Key ‖ SMSN) | EdDSA Signature = EdDSA(DAK Ed25519 private key, Device Ed25519 Public Key ‖ SMSN) | . ", "url": "/specifications/sidewalk-protocol-spec/security/architecture.html", "relUrl": "/specifications/sidewalk-protocol-spec/security/architecture.html" },"57": { "doc": "5. Bluetooth Low Energy and the Certification Boundary", "title": "5 Bluetooth Low Energy and the certification boundary", "content": "Bluetooth Low Energy is not region-gated in the way the sub-GHz radio is. The region mechanism described in this note governs sub-GHz behaviour; do not assume it changes Bluetooth Low Energy operation. Operating in a region is necessary but not sufficient for compliance. The stack applying a region’s radio parameters does not, by itself, make your device certified for that market. You remain responsible for obtaining the regulatory certification required for each market in which you sell or operate the device. Configuring the correct region is a precondition for compliant operation, not a substitute for certification. ", "url": "/app-notes/internationalization/ble-and-certification-boundary.html#5-bluetooth-low-energy-and-the-certification-boundary", "relUrl": "/app-notes/internationalization/ble-and-certification-boundary.html#5-bluetooth-low-energy-and-the-certification-boundary" },"58": { "doc": "5. Bluetooth Low Energy and the Certification Boundary", "title": "5. Bluetooth Low Energy and the Certification Boundary", "content": " ", "url": "/app-notes/internationalization/ble-and-certification-boundary.html", "relUrl": "/app-notes/internationalization/ble-and-certification-boundary.html" },"59": { "doc": "15. BLE Connection Policy Test Cases", "title": "15. BLE Connection Policy Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html" },"60": { "doc": "15. BLE Connection Policy Test Cases", "title": "15.1 BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-01: Default connection policy with advertisement interval configured.", "content": "15.1.1 Test Purpose . Verify advertisement parameters and advertising interval of BLE beacons on default connection policy. 15.1.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 15.1.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid option -ble_con 1 0 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Default_connection_policy\" Upper_Tester->>DUT: sid option -ble_cfg 1 0 32 0 1600 0 Upper_Tester->>DUT: sid option -ble_cfg 0 0 DUT->>Upper_Tester: Print Advertisement Parameters \"advertisement_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 20ms+-2ms Upper_Tester->>DUT: sid option -ble_cfg 1 0 8192 65535 8192 65535 Upper_Tester->>DUT: sid option -ble_cfg 0 0 DUT->>Upper_Tester: Print Advertisement Parameters \"advertisement_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 5120ms+-512ms . 15.1.4 Expected Results . 15.1.4.1 Pass Verdict . Both the advertisement parameters and advertising interval on DUT are updated according to the configuration. ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#151-ble-ep-connectionpolicy-default-bv-01-default-connection-policy-with-advertisement-interval-configured", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#151-ble-ep-connectionpolicy-default-bv-01-default-connection-policy-with-advertisement-interval-configured" },"61": { "doc": "15. BLE Connection Policy Test Cases", "title": "15.2 BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-02: Default connection policy with connection parameters configured.", "content": "15.2.1 Test Purpose . Verify DUT connection parameters on default connection policy. 15.2.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 15.2.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid option -ble_con 1 0 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Default_connection_policy\" Upper_Tester->>DUT: sid option -ble_cfg 1 1 12 12 0 10 Upper_Tester->>DUT: sid option -ble_cfg 0 1 DUT->>Upper_Tester: Print Connection Parameters \"connection_parameters_are_updated\" Upper_Tester->>DUT: sid option -ble_cfg 1 1 3200 3200 2 3200 Upper_Tester->>DUT: sid option -ble_cfg 0 1 DUT->>Upper_Tester: Print Connection Parameters \"connection_parameters_are_updated\" Upper_Tester->>DUT: sid option -ble_cfg 1 1 25 25 499 3200 Upper_Tester->>DUT: sid option -ble_cfg 0 1 DUT->>Upper_Tester: Print Connection Parameters \"connection_parameters_are_updated\" . 15.2.4 Expected Results . 15.2.4.1 Pass Verdict . The connection parameters on DUT are updated according to the configuration. ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#152-ble-ep-connectionpolicy-default-bv-02-default-connection-policy-with-connection-parameters-configured", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#152-ble-ep-connectionpolicy-default-bv-02-default-connection-policy-with-connection-parameters-configured" },"62": { "doc": "15. BLE Connection Policy Test Cases", "title": "15.3 BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-03: Default connection policy with both advertisement interval and connection parameters configured.", "content": "15.3.1 Test Purpose . Verify advertisement parameters, connection parameters, and advertising interval of BLE beacons on default connection policy. 15.3.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 15.3.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid option -ble_con 1 0 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Default_connection_policy\" Upper_Tester->>DUT: sid option -ble_cfg 1 2 32 0 1600 0 12 12 0 10 Upper_Tester->>DUT: sid option -ble_cfg 0 2 DUT->>Upper_Tester: Print Advertisement and Connection Parameters \"advertisement_and_connection_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 20ms+-2ms Upper_Tester->>DUT: sid option -ble_cfg 1 2 8192 65535 8192 65535 3200 3200 2 3200 Upper_Tester->>DUT: sid option -ble_cfg 0 2 DUT->>Upper_Tester: Print Advertisement and Connection Parameters \"advertisement_and_connection_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 5120ms+-512ms Upper_Tester->>DUT: sid option -ble_cfg 1 2 8192 65535 8192 65535 25 25 499 3200 Upper_Tester->>DUT: sid option -ble_cfg 0 2 DUT->>Upper_Tester: Print Advertisement and Connection Parameters \"advertisement_and_connection_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 5120ms+-512ms . 15.3.4 Expected Results . 15.3.4.1 Pass Verdict . The advertisement parameters, connection parameters, and advertising interval on DUT are updated according to the configuration. ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#153-ble-ep-connectionpolicy-default-bv-03-default-connection-policy-with-both-advertisement-interval-and-connection-parameters-configured", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#153-ble-ep-connectionpolicy-default-bv-03-default-connection-policy-with-both-advertisement-interval-and-connection-parameters-configured" },"63": { "doc": "15. BLE Connection Policy Test Cases", "title": "15.4 BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-04: Default connection policy.", "content": "15.4.1 Test Purpose . Verify both default advertisement and connection parameters and advertising interval of BLE beacons. 15.4.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 15.4.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid option -ble_con 1 0 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Default_connection_policy\" Upper_Tester->>DUT: sid option -ble_cfg 0 2 DUT->>Upper_Tester: Print Advertisement and Connection Parameters \"Default_advertisement_and_connection_parameters\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 30 seconds, the average BLE beacon interval is 160ms+-16ms . 15.4.4 Expected Results . 15.4.4.1 Pass Verdict . Both the advertisement parameters and advertising interval on DUT are updated according to the configuration. ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#154-ble-ep-connectionpolicy-default-bv-04-default-connection-policy", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#154-ble-ep-connectionpolicy-default-bv-04-default-connection-policy" },"64": { "doc": "15. BLE Connection Policy Test Cases", "title": "15.5 BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-05: Default connection policy with inactivity timeout.", "content": "15.5.1 Test Purpose . Verify that BLE would be disconnected after inactivity timeout on default connection policy. 15.5.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 15.5.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid option -ble_con 1 0 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Default_connection_policy\" Upper_Tester->>DUT: sid option -ble_cfg 1 3 1 Upper_Tester->>DUT: sid option -ble_cfg 0 3 DUT->>Upper_Tester: Print Inactivity Timeout \"1_second_inactivity_timeout\" Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Note over Lower_Tester,Upper_Tester: Wait for 1s DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid option -ble_cfg 1 3 3600 Upper_Tester->>DUT: sid option -ble_cfg 0 3 DUT->>Upper_Tester: Print Inactivity Timeout \"3600_seconds_inactivity_timeout\" Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Note over Lower_Tester,Upper_Tester: Wait for 3600s DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" . 15.5.4 Expected Results . 15.5.4.1 Pass Verdict . BLE connection can be established and will be dropped after inactivity timeout. ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#155-ble-ep-connectionpolicy-default-bv-05-default-connection-policy-with-inactivity-timeout", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#155-ble-ep-connectionpolicy-default-bv-05-default-connection-policy-with-inactivity-timeout" },"65": { "doc": "15. BLE Connection Policy Test Cases", "title": "15.6 BLE-EP-CONNECTIONPOLICY-LONGLIVED-BV-01: Long lived connection policy with advertisement interval configured.", "content": "15.6.1 Test Purpose . Verify advertisement parameters and advertising interval of BLE beacons on long lived connection policy. 15.6.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 15.6.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid option -ble_con 1 1 0 or sid option -ble_con 1 1 1 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Long_lived_connection_policy\" Upper_Tester->>DUT: sid option -ble_cfg 1 0 32 0 1600 0 Upper_Tester->>DUT: sid option -ble_cfg 0 0 DUT->>Upper_Tester: Print Advertisement Parameters \"advertisement_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 20ms+-2ms Upper_Tester->>DUT: sid option -ble_cfg 1 0 8192 65535 8192 65535 Upper_Tester->>DUT: sid option -ble_cfg 0 0 DUT->>Upper_Tester: Print Advertisement Parameters \"advertisement_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 5120ms+-512ms . 15.6.4 Expected Results . 15.6.4.1 Pass Verdict . Both the advertisement parameters and advertising interval on DUT are updated according to the configuration. ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#156-ble-ep-connectionpolicy-longlived-bv-01-long-lived-connection-policy-with-advertisement-interval-configured", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#156-ble-ep-connectionpolicy-longlived-bv-01-long-lived-connection-policy-with-advertisement-interval-configured" },"66": { "doc": "15. BLE Connection Policy Test Cases", "title": "15.7 BLE-EP-CONNECTIONPOLICY-LONGLIVED-BV-02: Long lived connection policy with connection parameters configured.", "content": "15.7.1 Test Purpose . Verify DUT connection parameters on long lived connection policy. 15.7.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 15.7.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid option -ble_con 1 1 0 or sid option -ble_con 1 1 1 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Long_lived_connection_policy\" Upper_Tester->>DUT: sid option -ble_cfg 1 1 12 12 0 10 Upper_Tester->>DUT: sid option -ble_cfg 0 1 DUT->>Upper_Tester: Print Connection Parameters \"connection_parameters_are_updated\" Upper_Tester->>DUT: sid option -ble_cfg 1 1 3200 3200 2 3200 Upper_Tester->>DUT: sid option -ble_cfg 0 1 DUT->>Upper_Tester: Print Connection Parameters \"connection_parameters_are_updated\" Upper_Tester->>DUT: sid option -ble_cfg 1 1 25 25 499 3200 Upper_Tester->>DUT: sid option -ble_cfg 0 1 DUT->>Upper_Tester: Print Connection Parameters \"connection_parameters_are_updated\" . 15.7.4 Expected Results . 15.7.4.1 Pass Verdict . The connection parameters on DUT are updated according to the configuration. ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#157-ble-ep-connectionpolicy-longlived-bv-02-long-lived-connection-policy-with-connection-parameters-configured", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#157-ble-ep-connectionpolicy-longlived-bv-02-long-lived-connection-policy-with-connection-parameters-configured" },"67": { "doc": "15. BLE Connection Policy Test Cases", "title": "15.8 BLE-EP-CONNECTIONPOLICY-LONGLIVED-BV-03: Long lived connection policy with both advertisement interval and connection parameters configured.", "content": "15.8.1 Test Purpose . Verify both advertisement parameters, connection parameters and advertising interval of BLE beacons on long lived connection policy. 15.8.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 15.8.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid option -ble_con 1 1 0 or sid option -ble_con 1 1 1 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Long_lived_connection_policy\" Upper_Tester->>DUT: sid option -ble_cfg 1 2 32 0 1600 0 12 12 0 10 Upper_Tester->>DUT: sid option -ble_cfg 0 2 DUT->>Upper_Tester: Print Advertisement and Connection Parameters \"advertisement_and_connection_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 20ms+-2ms Upper_Tester->>DUT: sid option -ble_cfg 1 2 8192 65535 8192 65535 3200 3200 2 3200 Upper_Tester->>DUT: sid option -ble_cfg 0 2 DUT->>Upper_Tester: Print Advertisement and Connection Parameters \"advertisement_and_connection_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 5120ms+-512ms Upper_Tester->>DUT: sid option -ble_cfg 1 2 8192 65535 8192 65535 25 25 499 3200 Upper_Tester->>DUT: sid option -ble_cfg 0 2 DUT->>Upper_Tester: Print Advertisement and Connection Parameters \"advertisement_and_connection_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 5120ms+-512ms . 15.8.4 Expected Results . 15.8.4.1 Pass Verdict . The advertisement parameters, connection parameters and advertising interval on DUT are updated according to the configuration. ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#158-ble-ep-connectionpolicy-longlived-bv-03-long-lived-connection-policy-with-both-advertisement-interval-and-connection-parameters-configured", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#158-ble-ep-connectionpolicy-longlived-bv-03-long-lived-connection-policy-with-both-advertisement-interval-and-connection-parameters-configured" },"68": { "doc": "15. BLE Connection Policy Test Cases", "title": "15.9 BLE-EP-CONNECTIONPOLICY-LONGLIVED-BV-04: Long lived connection policy with inactivity timeout.", "content": "15.9.1 Test Purpose . Verify that BLE would be disconnected after inactivity timeout on long lived connection policy. 15.9.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 15.9.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid option -ble_con 1 1 0 or sid option -ble_con 1 1 1 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Long_lived_connection_policy\" Upper_Tester->>DUT: sid option -ble_cfg 1 3 1 Upper_Tester->>DUT: sid option -ble_cfg 0 3 DUT->>Upper_Tester: Print Inactivity Timeout \"1_second_inactivity_timeout\" Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Note over Lower_Tester,Upper_Tester: Wait for 2s DUT->>Lower_Tester: BLE is still connected DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid option -ble_con 1 0 Note over Lower_Tester,Upper_Tester: Wait for 2s DUT->>Lower_Tester: BLE is disconnected DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid option -ble_cfg 0 3 DUT->>Upper_Tester: Print Inactivity Timeout \"1_second_inactivity_timeout\" Upper_Tester->>DUT: sid option -ble_con 1 1 0 or sid option -ble_con 1 1 1 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Long_lived_connection_policy\" Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Note over Lower_Tester,Upper_Tester: Wait for 2s DUT->>Lower_Tester: BLE is still connected DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid option -ble_con 1 2 Note over Lower_Tester,Upper_Tester: Wait for 2s DUT->>Lower_Tester: BLE is disconnected DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid option -ble_cfg 0 3 DUT->>Upper_Tester: Print Inactivity Timeout \"1_second_inactivity_timeout\" . 15.9.4 Expected Results . 15.9.4.1 Pass Verdict . When switching to a long-lived connection policy, the automatic disconnect due to inactivity is disabled. When switching away from a long-lived policy, the inactivity timeout is re-enabled with a specified delay period. ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#159-ble-ep-connectionpolicy-longlived-bv-04-long-lived-connection-policy-with-inactivity-timeout", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#159-ble-ep-connectionpolicy-longlived-bv-04-long-lived-connection-policy-with-inactivity-timeout" },"69": { "doc": "15. BLE Connection Policy Test Cases", "title": "15.10 BLE-EP-CONNECTIONPOLICY-OPTIMALADVERTISING-BV-01: Optimal advertising connection policy with advertisement interval configured.", "content": "15.10.1 Test Purpose . Verify advertisement parameters and advertising interval of BLE beacons on optimal advertising connection policy. 15.10.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 15.10.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid option -ble_con 1 2 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Optimal_advertising_connection_policy\" Upper_Tester->>DUT: sid option -ble_cfg 1 0 32 0 1600 0 Upper_Tester->>DUT: sid option -ble_cfg 0 0 DUT->>Upper_Tester: Print Advertisement Parameters \"advertisement_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 20ms+-2ms Upper_Tester->>DUT: sid option -ble_cfg 1 0 8192 65535 8192 65535 Upper_Tester->>DUT: sid option -ble_cfg 0 0 DUT->>Upper_Tester: Print Advertisement Parameters \"advertisement_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 5120ms+-512ms . 15.10.4 Expected Results . 15.10.4.1 Pass Verdict . Both the advertisement parameters and advertising interval on DUT are updated according to the configuration. ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#1510-ble-ep-connectionpolicy-optimaladvertising-bv-01-optimal-advertising-connection-policy-with-advertisement-interval-configured", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#1510-ble-ep-connectionpolicy-optimaladvertising-bv-01-optimal-advertising-connection-policy-with-advertisement-interval-configured" },"70": { "doc": "15. BLE Connection Policy Test Cases", "title": "15.11 BLE-EP-CONNECTIONPOLICY-OPTIMALADVERTISING-BV-02: Optimal advertising connection policy with connection parameters configured.", "content": "15.11.1 Test Purpose . Verify DUT connection parameters on optimal advertising connection policy. 15.11.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 15.11.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid option -ble_con 1 2 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Optimal_advertising_connection_policy\" Upper_Tester->>DUT: sid option -ble_cfg 1 1 12 12 0 10 Upper_Tester->>DUT: sid option -ble_cfg 0 1 DUT->>Upper_Tester: Print Connection Parameters \"connection_parameters_are_updated\" Upper_Tester->>DUT: sid option -ble_cfg 1 1 3200 3200 2 3200 Upper_Tester->>DUT: sid option -ble_cfg 0 1 DUT->>Upper_Tester: Print Connection Parameters \"connection_parameters_are_updated\" Upper_Tester->>DUT: sid option -ble_cfg 1 1 25 25 499 3200 Upper_Tester->>DUT: sid option -ble_cfg 0 1 DUT->>Upper_Tester: Print Connection Parameters \"connection_parameters_are_updated\" . 15.11.4 Expected Results . 15.11.4.1 Pass Verdict . The connection parameters on DUT are updated according to the configuration. ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#1511-ble-ep-connectionpolicy-optimaladvertising-bv-02-optimal-advertising-connection-policy-with-connection-parameters-configured", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#1511-ble-ep-connectionpolicy-optimaladvertising-bv-02-optimal-advertising-connection-policy-with-connection-parameters-configured" },"71": { "doc": "15. BLE Connection Policy Test Cases", "title": "15.12 BLE-EP-CONNECTIONPOLICY-OPTIMALADVERTISING-BV-03: Optimal advertising connection policy with both advertisement interval and connection parameters configured.", "content": "15.12.1 Test Purpose . Verify both advertisement parameters, connection parameters and advertising interval of BLE beacons on optimal advertising connection policy. 15.12.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 15.12.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid option -ble_con 1 2 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Optimal_advertising_connection_policy\" Upper_Tester->>DUT: sid option -ble_cfg 1 2 32 0 1600 0 12 12 0 10 Upper_Tester->>DUT: sid option -ble_cfg 0 2 DUT->>Upper_Tester: Print Advertisement and Connection Parameters \"advertisement_and_connection_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 20ms+-2ms Upper_Tester->>DUT: sid option -ble_cfg 1 2 8192 65535 8192 65535 3200 3200 2 3200 Upper_Tester->>DUT: sid option -ble_cfg 0 2 DUT->>Upper_Tester: Print Advertisement and Connection Parameters \"advertisement_and_connection_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 5120ms+-512ms Upper_Tester->>DUT: sid option -ble_cfg 1 2 8192 65535 8192 65535 25 25 499 3200 Upper_Tester->>DUT: sid option -ble_cfg 0 2 DUT->>Upper_Tester: Print Advertisement and Connection Parameters \"advertisement_and_connection_parameters_are_updated\" Note over Lower_Tester,Upper_Tester: Use sniffer to catch beacons for 35 seconds, the average BLE beacon interval is 5120ms+-512ms . 15.12.4 Expected Results . 15.12.4.1 Pass Verdict . The advertisement parameters, connection parameters and advertising interval on DUT are updated according to the configuration. ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#1512-ble-ep-connectionpolicy-optimaladvertising-bv-03-optimal-advertising-connection-policy-with-both-advertisement-interval-and-connection-parameters-configured", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#1512-ble-ep-connectionpolicy-optimaladvertising-bv-03-optimal-advertising-connection-policy-with-both-advertisement-interval-and-connection-parameters-configured" },"72": { "doc": "15. BLE Connection Policy Test Cases", "title": "15.13 BLE-EP-CONNECTIONPOLICY-OPTIMALADVERTISING-BV-04: Optimal advertising connection policy with inactivity timeout.", "content": "15.13.1 Test Purpose . Verify that BLE would be disconnected after inactivity timeout on optimal advertising connection policy. 15.13.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 15.13.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid option -ble_con 1 2 Upper_Tester->>DUT: sid option -ble_con 0 DUT->>Upper_Tester: Print Connection Policy \"Optimal_advertising_connection_policy\" Upper_Tester->>DUT: sid option -ble_cfg 1 3 1 Upper_Tester->>DUT: sid option -ble_cfg 0 3 DUT->>Upper_Tester: Print Inactivity Timeout \"1_second_inactivity_timeout\" Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Note over Lower_Tester,Upper_Tester: Wait for 1s DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid option -ble_cfg 1 3 3600 Upper_Tester->>DUT: sid option -ble_cfg 0 3 DUT->>Upper_Tester: Print Inactivity Timeout \"3600_seconds_inactivity_timeout\" Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Note over Lower_Tester,Upper_Tester: Wait for 3600s DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" . 15.13.4 Expected Results . 15.13.4.1 Pass Verdict . BLE connection can be established and will be dropped after inactivity timeout. ", "url": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#1513-ble-ep-connectionpolicy-optimaladvertising-bv-04-optimal-advertising-connection-policy-with-inactivity-timeout", "relUrl": "/specifications/sidewalk-test-spec/ble-connection-policy-test-cases.html#1513-ble-ep-connectionpolicy-optimaladvertising-bv-04-optimal-advertising-connection-policy-with-inactivity-timeout" },"73": { "doc": "14. BLE Connection Policy Test Cases", "title": "BLE Connection Policy Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#ble-connection-policy-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#ble-connection-policy-test-cases" },"74": { "doc": "14. BLE Connection Policy Test Cases", "title": "Test Case ID: BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-01: Default connection policy with advertisement interval configured", "content": "| Field | Value | . | Case ID | C103619378 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | EN set to default policysid option -ble_con 1 0 | Check connection policy--> sid option -ble_con 0--> [02040569] <info> app: CMD: ERR: 0 BLE conn policy 0 | . | 2 | EN set minimum advertisement parameterssid option -ble_cfg 1 0 32 0 1600 0 | Check advertisement parameters are updated--> sid option -ble_cfg 0 0--> [02288644] <info> app: CMD: ERR: 0 BLE adv, fast_int 32(20ms), fast_to 0(0ms), slow_int 1600(1000ms), slow_to 0(0ms) | . | 3 | Use sidewalk BLE sniffer to catch beacons | Key check: Measure time between beacons for 35 seconds, average of the interval time should be around 20ms | . | 4 | EN set maximum advertisement parameterssid option -ble_cfg 1 0 8192 65535 8192 65535 | Check advertisement parameters are updated--> sid option -ble_cfg 0 0--> [03256879] <info> app: CMD: ERR: 0 BLE adv, fast_int 8192(5120ms), fast_to 65535(655350ms), slow_int 8192(5120ms), slow_to 65535(655350ms) | . | 5 | Use sidewalk BLE sniffer to catch beacons | Key check: Measure time between beacons for 35 seconds, average of the interval time should be around 5120ms | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-default-bv-01-default-connection-policy-with-advertisement-interval-configured", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-default-bv-01-default-connection-policy-with-advertisement-interval-configured" },"75": { "doc": "14. BLE Connection Policy Test Cases", "title": "Test Case ID: BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-02: Default connection policy with connection parameters configured", "content": "| Field | Value | . | Case ID | C103619379 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | EN set to default policysid option -ble_con 1 0 | Check connection policy--> sid option -ble_con 0--> [02040569] <info> app: CMD: ERR: 0 BLE conn policy 0 | . | 2 | EN set minimum connection parameterssid option -ble_cfg 1 1 12 12 0 10 | Check connection parameters are updatedsid option -ble_cfg 0 1--> [00228962] <info> app: CMD: ERR: 0 BLE conn, min_int: 12(15ms), max_int 12(15ms), sl 0, timeout 10(100ms) | . | 3 | EN set maximum connection parameters1. sid option -ble_cfg 1 1 3200 3200 2 32002. sid option -ble_cfg 1 1 25 25 499 3200 | Check connection parameters are updated1. --> sid option -ble_cfg 0 1--> [01971481] <info> app: CMD: ERR: 0 BLE conn, min_int: 3200(4000ms), max_int 3200(4000ms), sl 2, timeout 3200(32000ms)2. --> sid option -ble_cfg 0 1--> [02006218] <info> app: CMD: ERR: 0 BLE conn, min_int: 25(31ms), max_int 25(31ms), sl 499, timeout 3200(32000ms) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-default-bv-02-default-connection-policy-with-connection-parameters-configured", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-default-bv-02-default-connection-policy-with-connection-parameters-configured" },"76": { "doc": "14. BLE Connection Policy Test Cases", "title": "Test Case ID: BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-03: Default connection policy with both advertisement interval and connection parameters configured", "content": "| Field | Value | . | Case ID | C103619380 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | EN set to default policysid option -ble_con 1 0 | Check connection policy--> sid option -ble_con 0--> [02040569] <info> app: CMD: ERR: 0 BLE conn policy 0 | . | 2 | EN set minimum advertisement parameters and connection parameterssid option -ble_cfg 1 2 32 0 1600 0 12 12 0 10 | Check connection parameters are updated--> sid option -ble_cfg 0 2[02687376] <info> app: CMD: ERR: 0 BLE adv, fast_int 32(20ms), fast_to 0(0ms), slow_int 1600(1000ms), slow_to 0(0ms)--> [02687376] <info> app: CMD: ERR: 0 BLE conn, min_int: 12(15ms), max_int 12(15ms), sl 0, timeout 10(100ms) | . | 3 | Use sidewalk BLE sniffer to catch beacons | Key check: Measure time between beacons for 35 seconds, average of the interval time should be around 20ms | . | 4 | EN set maximum advertisement parameters and connection parameters1. sid option -ble_cfg 1 2 8192 65535 8192 65535 3200 3200 2 32002. sid option -ble_cfg 1 2 8192 65535 8192 65535 25 25 499 3200 | Check connection parameters are updated1. --> sid option -ble_cfg 0 2[03000420] <info> app: CMD: ERR: 0 BLE adv, fast_int 8192(5120ms), fast_to 65535(655350ms), slow_int 8192(5120ms), slow_to 65535(655350ms)--> [03000421] <info> app: CMD: ERR: 0 BLE conn, min_int: 3200(4000ms), max_int 3200(4000ms), sl 2, timeout 3200(32000ms)2. --> sid option -ble_cfg 0 2[03168389] <info> app: CMD: ERR: 0 BLE adv, fast_int 8192(5120ms), fast_to 65535(655350ms), slow_int 8192(5120ms), slow_to 65535(655350ms)--> [03168390] <info> app: CMD: ERR: 0 BLE conn, min_int: 25(31ms), max_int 25(31ms), sl 499, timeout 3200(32000ms) | . | 5 | Use sidewalk BLE sniffer to catch beacons | Key check: Measure time between beacons for 35 seconds, average of the interval time should be around 5120ms | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-default-bv-03-default-connection-policy-with-both-advertisement-interval-and-connection-parameters-configured", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-default-bv-03-default-connection-policy-with-both-advertisement-interval-and-connection-parameters-configured" },"77": { "doc": "14. BLE Connection Policy Test Cases", "title": "Test Case ID: BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-04: Default connection policy", "content": "| Field | Value | . | Case ID | C103619381 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | EN set to default policysid option -ble_con 1 0 | — | . | 2 | Use sidewalk BLE sniffer to catch beacons | Key check: Measure time between beacons for first 30 seconds, average of the interval time should be around 160ms | . | 3 | Check advertisement parameters and connection parameters | Should be default value--> sid option -ble_cfg 0 2[00012909] <info> app: CMD: ERR: 0 BLE adv, fast_int 256(160ms), fast_to 3000(30000ms), slow_int 1600(1000ms), slow_to 0(0ms)--> [00012909] <info> app: CMD: ERR: 0 BLE conn, min_int: 16(20ms), max_int 60(75ms), sl 0, timeout 400(4000ms) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-default-bv-04-default-connection-policy", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-default-bv-04-default-connection-policy" },"78": { "doc": "14. BLE Connection Policy Test Cases", "title": "Test Case ID: BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-05: Default connection policy with inactivity timeout", "content": "| Field | Value | . | Case ID | C103619382 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | EN set to default policysid option -ble_con 1 0 | Check connection policy--> sid option -ble_con 0--> [02040569] <info> app: CMD: ERR: 0 BLE conn policy 0 | . | 2 | EN set minimum inactivity timeoutsid option -ble_cfg 1 3 1 | Check connection parameters are updatedsid option -ble_cfg 0 3--> [00075451] <info> app: CMD: ERR: 0 BLE inactivity timeout 1s | . | 3 | Establish BLE connection, after connected, wait for 2ssid conn_req 1 | Key check: BLE is disconnected after 1s | . | 4 | EN set maximum inactivity timeoutsid option -ble_cfg 1 3 3600 | Check connection parameters are updatedsid option -ble_cfg 0 3--> [00075451] <info> app: CMD: ERR: 0 BLE inactivity timeout 3600s | . | 5 | Establish BLE connection, after connected, wait for 3601ssid conn_req 1 | Key check: BLE is disconnected after 3600s | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-default-bv-05-default-connection-policy-with-inactivity-timeout", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-default-bv-05-default-connection-policy-with-inactivity-timeout" },"79": { "doc": "14. BLE Connection Policy Test Cases", "title": "Test Case ID: BLE-EP-CONNECTIONPOLICY-LONGLIVED-BV-01: Long lived connection policy with advertisement interval configured", "content": "| Field | Value | . | Case ID | C103619385 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | EN set to long live policy- sid option -ble_con 1 1 0 (Power Optimized)- sid option -ble_con 1 1 1 (Latency Optimized) | Check connection policyPower Optimized:--> sid option -ble_con 0[00062756] <info> app: CMD: ERR: 0 BLE conn policy 1--> [00062756] <info> app: CMD: ERR: 0 Long lived connection optimized for 0Latency Optimized:--> sid option -ble_con 0[00062756] <info> app: CMD: ERR: 0 BLE conn policy 1--> [00062756] <info> app: CMD: ERR: 0 Long lived connection optimized for 1 | . | 2 | EN set minimum advertisement parameterssid option -ble_cfg 1 0 32 0 1600 0 | Check advertisement parameters are updated--> sid option -ble_cfg 0 0--> [02288644] <info> app: CMD: ERR: 0 BLE adv, fast_int 32(20ms), fast_to 0(0ms), slow_int 1600(1000ms), slow_to 0(0ms) | . | 3 | Use sidewalk BLE sniffer to catch beacons | Key check: Measure time between beacons for 35 seconds, average of the interval time should be around 20ms | . | 4 | EN set maximum advertisement parameterssid option -ble_cfg 1 0 8192 65535 8192 65535 | Check advertisement parameters are updated--> sid option -ble_cfg 0 0--> [03256879] <info> app: CMD: ERR: 0 BLE adv, fast_int 8192(5120ms), fast_to 65535(655350ms), slow_int 8192(5120ms), slow_to 65535(655350ms) | . | 5 | Use sidewalk BLE sniffer to catch beacons | Key check: Measure time between beacons for 35 seconds, average of the interval time should be around 5120ms | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-longlived-bv-01-long-lived-connection-policy-with-advertisement-interval-configured", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-longlived-bv-01-long-lived-connection-policy-with-advertisement-interval-configured" },"80": { "doc": "14. BLE Connection Policy Test Cases", "title": "Test Case ID: BLE-EP-CONNECTIONPOLICY-LONGLIVED-BV-02: Long lived connection policy with connection parameters configured", "content": "| Field | Value | . | Case ID | C103619386 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | EN set to long live policy1. sid option -ble_con 1 1 0 (Power Optimized)2. sid option -ble_con 1 1 1 (Latency Optimized) | Check connection policyPower Optimized:--> sid option -ble_con 0[00062756] <info> app: CMD: ERR: 0 BLE conn policy 1--> [00062756] <info> app: CMD: ERR: 0 Long lived connection optimized for 0Latency Optimized:--> sid option -ble_con 0[00062756] <info> app: CMD: ERR: 0 BLE conn policy 1--> [00062756] <info> app: CMD: ERR: 0 Long lived connection optimized for 1 | . | 2 | EN set minimum connection parameterssid option -ble_cfg 1 1 12 12 0 10 | Check connection parameters are updatedsid option -ble_cfg 0 1--> [00228962] <info> app: CMD: ERR: 0 BLE conn, min_int: 12(15ms), max_int 12(15ms), sl 0, timeout 10(100ms) | . | 3 | EN set maximum connection parameters1. sid option -ble_cfg 1 1 3200 3200 2 32002. sid option -ble_cfg 1 1 25 25 499 3200 | Check connection parameters are updated1. --> sid option -ble_cfg 0 1--> [01971481] <info> app: CMD: ERR: 0 BLE conn, min_int: 3200(4000ms), max_int 3200(4000ms), sl 2, timeout 3200(32000ms)2. --> sid option -ble_cfg 0 1--> [02006218] <info> app: CMD: ERR: 0 BLE conn, min_int: 25(31ms), max_int 25(31ms), sl 499, timeout 3200(32000ms) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-longlived-bv-02-long-lived-connection-policy-with-connection-parameters-configured", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-longlived-bv-02-long-lived-connection-policy-with-connection-parameters-configured" },"81": { "doc": "14. BLE Connection Policy Test Cases", "title": "Test Case ID: BLE-EP-CONNECTIONPOLICY-LONGLIVED-BV-03: Long lived connection policy with both advertisement interval and connection parameters configured", "content": "| Field | Value | . | Case ID | C103619387 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | EN set to long live policy- sid option -ble_con 1 1 0 (Power Optimized)- sid option -ble_con 1 1 1 (Latency Optimized) | Check connection policyPower Optimized:--> sid option -ble_con 0[00062756] <info> app: CMD: ERR: 0 BLE conn policy 1--> [00062756] <info> app: CMD: ERR: 0 Long lived connection optimized for 0Latency Optimized:--> sid option -ble_con 0[00062756] <info> app: CMD: ERR: 0 BLE conn policy 1--> [00062756] <info> app: CMD: ERR: 0 Long lived connection optimized for 1 | . | 2 | EN set minimum advertisement parameters and connection parameterssid option -ble_cfg 1 2 32 0 1600 0 12 12 0 10 | Check connection parameters are updated--> sid option -ble_cfg 0 2[02687376] <info> app: CMD: ERR: 0 BLE adv, fast_int 32(20ms), fast_to 0(0ms), slow_int 1600(1000ms), slow_to 0(0ms)--> [02687376] <info> app: CMD: ERR: 0 BLE conn, min_int: 12(15ms), max_int 12(15ms), sl 0, timeout 10(100ms) | . | 3 | Use sidewalk BLE sniffer to catch beacons | Key check: Measure time between beacons for 35 seconds, average of the interval time should be around 20ms | . | 4 | EN set maximum advertisement parameters and connection parameters1. sid option -ble_cfg 1 2 8192 65535 8192 65535 3200 3200 2 32002. sid option -ble_cfg 1 2 8192 65535 8192 65535 25 25 499 3200 | Check connection parameters are updated1. --> sid option -ble_cfg 0 2[03000420] <info> app: CMD: ERR: 0 BLE adv, fast_int 8192(5120ms), fast_to 65535(655350ms), slow_int 8192(5120ms), slow_to 65535(655350ms)--> [03000421] <info> app: CMD: ERR: 0 BLE conn, min_int: 3200(4000ms), max_int 3200(4000ms), sl 2, timeout 3200(32000ms)2. --> sid option -ble_cfg 0 2[03168389] <info> app: CMD: ERR: 0 BLE adv, fast_int 8192(5120ms), fast_to 65535(655350ms), slow_int 8192(5120ms), slow_to 65535(655350ms)--> [03168390] <info> app: CMD: ERR: 0 BLE conn, min_int: 25(31ms), max_int 25(31ms), sl 499, timeout 3200(32000ms) | . | 5 | Use sidewalk BLE sniffer to catch beacons | Key check: Measure time between beacons for 35 seconds, average of the interval time should be around 5120ms | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-longlived-bv-03-long-lived-connection-policy-with-both-advertisement-interval-and-connection-parameters-configured", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-longlived-bv-03-long-lived-connection-policy-with-both-advertisement-interval-and-connection-parameters-configured" },"82": { "doc": "14. BLE Connection Policy Test Cases", "title": "Test Case ID: BLE-EP-CONNECTIONPOLICY-LONGLIVED-BV-04: Long lived connection policy with inactivity timeout", "content": "| Field | Value | . | Case ID | C103619388 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | EN set to long live policy1. sid option -ble_con 1 1 0 (Power Optimized)2. sid option -ble_con 1 1 1 (Latency Optimized) | Check connection policyPower Optimized:--> sid option -ble_con 0[00062756] <info> app: CMD: ERR: 0 BLE conn policy 1--> [00062756] <info> app: CMD: ERR: 0 Long lived connection optimized for 0Latency Optimized:--> sid option -ble_con 0[00062756] <info> app: CMD: ERR: 0 BLE conn policy 1--> [00062756] <info> app: CMD: ERR: 0 Long lived connection optimized for 1 | . | 2 | EN set minimum inactivity timeoutsid option -ble_cfg 1 3 1 | Check connection parameters are updatedsid option -ble_cfg 0 3--> [00075451] <info> app: CMD: ERR: 0 BLE inactivity timeout 1s | . | 3 | Establish BLE connection, after connected, wait for 2ssid conn_req 1 | Key check: BLE is not disconnected | . | 4 | EN set to default policy and wait for 2ssid option -ble_con 1 0 | Check connection policy--> sid option -ble_con 0--> [02040569] <info> app: CMD: ERR: 0 BLE conn policy 0Key check: BLE is disconnected after 2s | . | 5 | EN set to long live policy1. sid option -ble_con 1 1 0 (Power Optimized)2. sid option -ble_con 1 1 1 (Latency Optimized) | Check connection policyPower Optimized:--> sid option -ble_con 0[00062756] <info> app: CMD: ERR: 0 BLE conn policy 1--> [00062756] <info> app: CMD: ERR: 0 Long lived connection optimized for 0Latency Optimized:--> sid option -ble_con 0[00062756] <info> app: CMD: ERR: 0 BLE conn policy 1--> [00062756] <info> app: CMD: ERR: 0 Long lived connection optimized for 1 | . | 6 | Establish BLE connection, after connected, wait for 2ssid conn_req 1 | Key check: BLE is not disconnected | . | 7 | EN set to optimal advertising policy and wait for 2 secsid option -ble_con 1 2 | Check connection policy--> sid option -ble_con 0--> [02040569] <info> app: CMD: ERR: 0 BLE conn policy 2Key check: BLE disconnected after 2 sec | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-longlived-bv-04-long-lived-connection-policy-with-inactivity-timeout", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-longlived-bv-04-long-lived-connection-policy-with-inactivity-timeout" },"83": { "doc": "14. BLE Connection Policy Test Cases", "title": "Test Case ID: BLE-EP-CONNECTIONPOLICY-OPTIMALADVERTISING-BV-01: Optimal advertising connection policy with advertisement interval configured", "content": "| Field | Value | . | Case ID | C103619392 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | EN set to optimal advertising policysid option -ble_con 1 2 | Check connection policy--> sid option -ble_con 0--> [02040569] <info> app: CMD: ERR: 0 BLE conn policy 2 | . | 2 | EN set minimum advertisement parameterssid option -ble_cfg 1 0 32 0 1600 0 | Check advertisement parameters are updated--> sid option -ble_cfg 0 0--> [02288644] <info> app: CMD: ERR: 0 BLE adv, fast_int 32(20ms), fast_to 0(0ms), slow_int 1600(1000ms), slow_to 0(0ms) | . | 3 | Use sidewalk BLE sniffer to catch beacons | Key check: Measure time between beacons for 35 seconds, average of the interval time should be around 20ms | . | 4 | EN set maximum advertisement parameterssid option -ble_cfg 1 0 8192 65535 8192 65535 | Check advertisement parameters are updated--> sid option -ble_cfg 0 0--> [03256879] <info> app: CMD: ERR: 0 BLE adv, fast_int 8192(5120ms), fast_to 65535(655350ms), slow_int 8192(5120ms), slow_to 65535(655350ms) | . | 5 | Use sidewalk BLE sniffer to catch beacons | Key check: Measure time between beacons for 35 seconds, average of the interval time should be around 5120ms | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-optimaladvertising-bv-01-optimal-advertising-connection-policy-with-advertisement-interval-configured", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-optimaladvertising-bv-01-optimal-advertising-connection-policy-with-advertisement-interval-configured" },"84": { "doc": "14. BLE Connection Policy Test Cases", "title": "Test Case ID: BLE-EP-CONNECTIONPOLICY-OPTIMALADVERTISING-BV-02: Optimal advertising connection policy with connection parameters configured", "content": "| Field | Value | . | Case ID | C103619393 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | EN set to optimal advertising policysid option -ble_con 1 2 | Check connection policy--> sid option -ble_con 0--> [02040569] <info> app: CMD: ERR: 0 BLE conn policy 2 | . | 2 | EN set minimum connection parameterssid option -ble_cfg 1 1 12 12 0 10 | Check connection parameters are updatedsid option -ble_cfg 0 1--> [00228962] <info> app: CMD: ERR: 0 BLE conn, min_int: 12(15ms), max_int 12(15ms), sl 0, timeout 10(100ms) | . | 3 | EN set maximum connection parameters1. sid option -ble_cfg 1 1 3200 3200 2 32002. sid option -ble_cfg 1 1 25 25 499 3200 | Check connection parameters are updated1. --> sid option -ble_cfg 0 1--> [01971481] <info> app: CMD: ERR: 0 BLE conn, min_int: 3200(4000ms), max_int 3200(4000ms), sl 2, timeout 3200(32000ms)2. --> sid option -ble_cfg 0 1--> [02006218] <info> app: CMD: ERR: 0 BLE conn, min_int: 25(31ms), max_int 25(31ms), sl 499, timeout 3200(32000ms) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-optimaladvertising-bv-02-optimal-advertising-connection-policy-with-connection-parameters-configured", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-optimaladvertising-bv-02-optimal-advertising-connection-policy-with-connection-parameters-configured" },"85": { "doc": "14. BLE Connection Policy Test Cases", "title": "Test Case ID: BLE-EP-CONNECTIONPOLICY-OPTIMALADVERTISING-BV-03: Optimal advertising connection policy with both advertisement interval and connection parameters configured", "content": "| Field | Value | . | Case ID | C103619394 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | EN set to optimal advertising policysid option -ble_con 1 2 | Check connection policy--> sid option -ble_con 0--> [02040569] <info> app: CMD: ERR: 0 BLE conn policy 2 | . | 2 | EN set minimum advertisement parameters and connection parameterssid option -ble_cfg 1 2 32 0 1600 0 12 12 0 10 | Check connection parameters are updated--> sid option -ble_cfg 0 2[02687376] <info> app: CMD: ERR: 0 BLE adv, fast_int 32(20ms), fast_to 0(0ms), slow_int 1600(1000ms), slow_to 0(0ms)--> [02687376] <info> app: CMD: ERR: 0 BLE conn, min_int: 12(15ms), max_int 12(15ms), sl 0, timeout 10(100ms) | . | 3 | Use sidewalk BLE sniffer to catch beacons | Key check: Measure time between beacons for 35 seconds, average of the interval time should be around 20ms | . | 4 | EN set maximum advertisement parameters and connection parameters1. sid option -ble_cfg 1 2 8192 65535 8192 65535 3200 3200 2 32002. sid option -ble_cfg 1 2 8192 65535 8192 65535 25 25 499 3200 | Check connection parameters are updated1. --> sid option -ble_cfg 0 2[03000420] <info> app: CMD: ERR: 0 BLE adv, fast_int 8192(5120ms), fast_to 65535(655350ms), slow_int 8192(5120ms), slow_to 65535(655350ms)--> [03000421] <info> app: CMD: ERR: 0 BLE conn, min_int: 3200(4000ms), max_int 3200(4000ms), sl 2, timeout 3200(32000ms)2. --> sid option -ble_cfg 0 2[03168389] <info> app: CMD: ERR: 0 BLE adv, fast_int 8192(5120ms), fast_to 65535(655350ms), slow_int 8192(5120ms), slow_to 65535(655350ms)--> [03168390] <info> app: CMD: ERR: 0 BLE conn, min_int: 25(31ms), max_int 25(31ms), sl 499, timeout 3200(32000ms) | . | 5 | Use sidewalk BLE sniffer to catch beacons | Key check: Measure time between beacons for 35 seconds, average of the interval time should be around 5120ms | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-optimaladvertising-bv-03-optimal-advertising-connection-policy-with-both-advertisement-interval-and-connection-parameters-configured", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-optimaladvertising-bv-03-optimal-advertising-connection-policy-with-both-advertisement-interval-and-connection-parameters-configured" },"86": { "doc": "14. BLE Connection Policy Test Cases", "title": "Test Case ID: BLE-EP-CONNECTIONPOLICY-OPTIMALADVERTISING-BV-04: Optimal advertising connection policy with inactivity timeout", "content": "| Field | Value | . | Case ID | C103619395 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | EN set to optimal advertising connection policysid option -ble_con 1 2 | Check connection policy--> sid option -ble_con 0--> [02040569] <info> app: CMD: ERR: 0 BLE conn policy 2 | . | 2 | EN set minimum inactivity timeoutsid option -ble_cfg 1 3 1 | Check connection parameters are updatedsid option -ble_cfg 0 3--> [00075451] <info> app: CMD: ERR: 0 BLE inactivity timeout 1s | . | 3 | Establish BLE connection, after connected, wait for 2ssid conn_req 1 | Key check: BLE is disconnected after 1s | . | 4 | EN set maximum inactivity timeoutsid option -ble_cfg 1 3 3600 | Check connection parameters are updatedsid option -ble_cfg 0 3--> [00075451] <info> app: CMD: ERR: 0 BLE inactivity timeout 3600s | . | 5 | Establish BLE connection, after connected, wait for 3601ssid conn_req 1 | Key check: BLE is disconnected after 3600s | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-optimaladvertising-bv-04-optimal-advertising-connection-policy-with-inactivity-timeout", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html#test-case-id-ble-ep-connectionpolicy-optimaladvertising-bv-04-optimal-advertising-connection-policy-with-inactivity-timeout" },"87": { "doc": "14. BLE Connection Policy Test Cases", "title": "14. BLE Connection Policy Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-connection-policy-test-cases.html" },"88": { "doc": "BLE Gateway Location (L1)", "title": "BLE Gateway Location (L1)", "content": " ", "url": "/app-notes/location-library/ble-gateway-location-l1.html", "relUrl": "/app-notes/location-library/ble-gateway-location-l1.html" },"89": { "doc": "BLE Gateway Location (L1)", "title": "Introduction", "content": "BLE gateway location is the lowest-effort mechanism. When the device has a BLE connection to a Sidewalk gateway, it signals Amazon Sidewalk, which resolves the device’s position from the gateway’s own known position. The device performs no scan: it only signals over the connection it already has, so there is no device-side measurement to resolve and the fix is entirely gateway-derived. ", "url": "/app-notes/location-library/ble-gateway-location-l1.html#introduction", "relUrl": "/app-notes/location-library/ble-gateway-location-l1.html#introduction" },"90": { "doc": "BLE Gateway Location (L1)", "title": "How the Cloud Resolves the Fix", "content": "A BLE uplink is resolved from the position of the gateway (or gateways) that reported the device, not by multilateration (which is LoRa-only). | Gateway position lookup. For each gateway that reports the device, Amazon Sidewalk looks up that gateway’s known location. | Inline (bonded) fast path. If the reporting gateway is a PAN gateway that carried its own location inline in the uplink (for example, a mobile-app gateway whose phone supplies GPS), that location is used directly, skipping the lookup, clustering, and validation steps. | Clustering. When a device is reported by several gateways, Amazon Sidewalk clusters the located gateways and derives the fix from the cluster, using the gateway closest to the centroid as the primary gateway. A single reporting gateway yields that gateway’s own position. | Time binning. When gateway reports carry uplink timestamps, they are evaluated in 30-second bins, anchored on the most recent report and walking back through older bins until one resolves, so reports from different passes are not mixed together. | . Before a fix is published, Amazon Sidewalk validates it: a BSSID cross-check against the gateway’s known access-point layout (when available), and a speed/plausibility check against the device’s recent location history. A fix that is physically implausible for the device’s movement is not published. ", "url": "/app-notes/location-library/ble-gateway-location-l1.html#how-the-cloud-resolves-the-fix", "relUrl": "/app-notes/location-library/ble-gateway-location-l1.html#how-the-cloud-resolves-the-fix" },"91": { "doc": "BLE Gateway Location (L1)", "title": "Accuracy and Constraints", "content": ". | Requires an active BLE connection to a Sidewalk gateway. | Accuracy is gateway-granularity: the fix is the gateway’s position (or a centroid of several gateways), not a measured device position. It is only as accurate as the gateway’s own known location. | . ", "url": "/app-notes/location-library/ble-gateway-location-l1.html#accuracy-and-constraints", "relUrl": "/app-notes/location-library/ble-gateway-location-l1.html#accuracy-and-constraints" },"92": { "doc": "1. BLE Power Optimization", "title": "1. BLE Power Optimization", "content": " ", "url": "/app-notes/power-optimization/ble-power-optimization.html", "relUrl": "/app-notes/power-optimization/ble-power-optimization.html" },"93": { "doc": "1. BLE Power Optimization", "title": "1.1 Introduction", "content": "Bluetooth Low Energy (BLE) in Amazon Sidewalk provides local connectivity and serves as a bridge to cloud services. This chapter focuses on power optimization through proper configuration of and options. ", "url": "/app-notes/power-optimization/ble-power-optimization.html#11-introduction", "relUrl": "/app-notes/power-optimization/ble-power-optimization.html#11-introduction" },"94": { "doc": "1. BLE Power Optimization", "title": "1.2 BLE Configuration Options", "content": "1.2.1 SID_OPTION_BLE_USER_CONFIG . The option provides full customizable parameter configuration for BLE operations, allowing fine-tuned power optimization: . typedef struct sid_ble_user_config { sid_ble_cfg_adv_param_t adv_param; sid_ble_cfg_conn_param_t conn_param; bool is_set; // True: Set, False: Get enum sid_ble_user_config_type cfg_type; // Configuration type uint32_t inactivity_timeout; } sid_ble_user_config_t; enum sid_ble_user_config_type { SID_BLE_USER_CFG_ADV, SID_BLE_USER_CFG_CONN, SID_BLE_USER_CFG_ADV_AND_CONN, SID_BLE_USER_CFG_INACTIVITY_TIMEOUT, }; . 1.2.2 SID_OPTION_BLE_CONNECTION_POLICY . The option provides pre-configured settings (overridable with ) and long-lived connection policies to reduce frequent advertising and connection establishment overhead: . typedef struct sid_ble_connection_policy { bool is_set; enum sid_ble_llc_optimization_policy llc_policy; enum sid_ble_conn_policy conn_policy; } sid_ble_connection_policy_t; enum sid_ble_llc_optimization_policy { SID_BLE_LLC_POWER_OPTIMIZED, SID_BLE_LLC_LATENCY_OPTIMIZED, }; enum sid_ble_conn_policy { SID_BLE_CONN_POLICY_DEFAULT, SID_BLE_CONN_POLICY_LONG_LIVED_CONNECTION, SID_BLE_CONN_POLICY_OPTIMAL_ADVERTISING, }; . ", "url": "/app-notes/power-optimization/ble-power-optimization.html#12-ble-configuration-options", "relUrl": "/app-notes/power-optimization/ble-power-optimization.html#12-ble-configuration-options" },"95": { "doc": "1. BLE Power Optimization", "title": "1.3 Advertisement Power Optimization", "content": "1.3.1 Advertisement Interval Configuration . Advertisement intervals should be configured based on application requirements and power constraints: . // Example advertisement configuration - tune for your application sid_ble_user_config_t adv_config = { .is_set = true, .cfg_type = SID_BLE_USER_CFG_ADV, .adv_param = { .fast_interval = 800, // Adjust based on discovery requirements .fast_timeout = 3000, // Tune for your application .slow_interval = 3200, // Balance power vs discoverability .slow_timeout = 0 // Set timeout as needed } }; // Apply configuration sid_error_t err = sid_option(handle, SID_OPTION_BLE_USER_CONFIG, &adv_config, sizeof(adv_config)); . : Custom advertisement intervals allow balancing discovery time vs power consumption based on specific application needs. ", "url": "/app-notes/power-optimization/ble-power-optimization.html#13-advertisement-power-optimization", "relUrl": "/app-notes/power-optimization/ble-power-optimization.html#13-advertisement-power-optimization" },"96": { "doc": "1. BLE Power Optimization", "title": "1.4 Connection Power Management", "content": "1.4.1 Connection Parameter Configuration . Connection parameters should be configured based on application data rate and power requirements: . // Example connection parameters - adjust for your use case sid_ble_user_config_t conn_config = { .is_set = true, .cfg_type = SID_BLE_USER_CFG_CONN, .conn_param = { .min_conn_interval = 400, // Adjust based on data rate needs .max_conn_interval = 800, // Longer intervals = lower power .slave_latency = 9, // Higher latency = lower power .conn_sup_timeout = 6000 // Set appropriate for application } }; sid_error_t err = sid_option(handle, SID_OPTION_BLE_USER_CONFIG, &conn_config, sizeof(conn_config)); . 1.4.2 Connection Policy Configuration . Select pre-configured policies based on application usage patterns: . // Example connection policy - choose based on usage sid_ble_connection_policy_t policy_config = { .is_set = true, .llc_policy = SID_BLE_LLC_POWER_OPTIMIZED, // vs SID_BLE_LLC_LATENCY_OPTIMIZED .conn_policy = SID_BLE_CONN_POLICY_LONG_LIVED_CONNECTION // Choose based on needs }; sid_error_t err = sid_option(handle, SID_OPTION_BLE_CONNECTION_POLICY, &policy_config, sizeof(policy_config)); . : Long-lived connections avoid frequent advertising and connection establishment, which are power-intensive operations. The device maintains connection longer, reducing overall power consumption. ", "url": "/app-notes/power-optimization/ble-power-optimization.html#14-connection-power-management", "relUrl": "/app-notes/power-optimization/ble-power-optimization.html#14-connection-power-management" },"97": { "doc": "1. BLE Power Optimization", "title": "1.5 Inactivity Timeout Configuration", "content": "1.5.1 Inactivity Timeout Configuration . Configure automatic disconnection when BLE has no activity: . // Configure inactivity timeout sid_ble_user_config_t timeout_config = { .is_set = true, .cfg_type = SID_BLE_USER_CFG_INACTIVITY_TIMEOUT, .inactivity_timeout = 30000 // Tune based on usage patterns }; sid_error_t err = sid_option(handle, SID_OPTION_BLE_USER_CONFIG, &timeout_config, sizeof(timeout_config)); . : Automatically breaks BLE connections when inactive, preventing unnecessary power drain from maintaining idle connections. ", "url": "/app-notes/power-optimization/ble-power-optimization.html#15-inactivity-timeout-configuration", "relUrl": "/app-notes/power-optimization/ble-power-optimization.html#15-inactivity-timeout-configuration" },"98": { "doc": "1. BLE Power Optimization", "title": "1.6 Configuration Strategy", "content": "1.6.1 Policy vs Custom Configuration . Choose between pre-configured policies and custom parameters: . // Option 1: Use pre-configured policy (recommended for most cases) void use_preconfigured_policy(sid_handle_t handle) { sid_ble_connection_policy_t policy = { .is_set = true, .llc_policy = SID_BLE_LLC_POWER_OPTIMIZED, .conn_policy = SID_BLE_CONN_POLICY_LONG_LIVED_CONNECTION }; sid_option(handle, SID_OPTION_BLE_CONNECTION_POLICY, &policy, sizeof(policy)); } // Option 2: Override with custom parameters for specific needs void override_with_custom_config(sid_handle_t handle) { // Custom config overrides policy settings sid_ble_user_config_t config = { .is_set = true, .cfg_type = SID_BLE_USER_CFG_ADV_AND_CONN, .adv_param = { .fast_interval = 1600, .slow_interval = 8000 }, .conn_param = { .min_conn_interval = 400, .slave_latency = 9 } }; sid_option(handle, SID_OPTION_BLE_USER_CONFIG, &config, sizeof(config)); } . ", "url": "/app-notes/power-optimization/ble-power-optimization.html#16-configuration-strategy", "relUrl": "/app-notes/power-optimization/ble-power-optimization.html#16-configuration-strategy" },"99": { "doc": "3. BLE Test Cases", "title": "3. BLE Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html" },"100": { "doc": "3. BLE Test Cases", "title": "3.1 BLE/EP/CONN/REG/BV/01: An unregistered Endpoint successfully completes Sidewalk device registration over BLE.", "content": "3.1.1 Test Purpose . An unregistered DUT configures the Sidewalk stack in BLE mode. It accepts a BLE connection from the Lower Tester and completes registration. After it has registered it uses BLE radio for Amazon Sidewalk network activities. 3.1.2 Initial Conditions . | DUT is not registered with Amazon Sidewalk network. | The Sidewalk stack (BLE) is initialized and started on the DUT. | Lower Tester operates in BLE mode. | . 3.1.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Not Registered, Link Mask 0, BLE Disconnected Lower_Tester->>DUT: Establish BLE connection Note over Lower_Tester,Upper_Tester: Wait until registration process is finished DUT->>Lower_Tester: Packet with successful registration result DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, BLE Disconnected\" Lower_Tester->>DUT: Drop BLE connection DUT->>Lower_Tester: Beacon with time sync request Lower_Tester->>DUT: Establish BLE connection Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE disconnected\" . 3.1.4 Expected Results . 3.1.4.1 Pass Verdict . DUT with Sidewalk stack (BLE) initialized is successfully registered with Amazon Sidewalk network. Afterwards, DUT completes time synchronization over BLE. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#31-bleepconnregbv01-an-unregistered-endpoint-successfully-completes-sidewalk-device-registration-over-ble", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#31-bleepconnregbv01-an-unregistered-endpoint-successfully-completes-sidewalk-device-registration-over-ble" },"101": { "doc": "3. BLE Test Cases", "title": "3.2 BLE/EP/CONN/REG/BV/02: An unregistered Endpoint successfully completes Sidewalk device registration with use of FFN.", "content": "3.2.1 Test Purpose . An unregistered DUT configures the Sidewalk stack in BLE mode. Lower tester establishes BLE connection after detecting beacon with provisioning request. DUT starts registration flow by sending “PROV_INIT_REQ” packet to Lower Tester. At the end of the registration flow, DUT receives SET_CONFIGURATION_COMPLETE packet from Lower Tester and responds with RESP_CONFIGURATION_COMPLETE packet, which is a sign of successful device registration. After that BLE connection is dropped and DUT continues to work using BLE radio for Amazon Sidewalk network activities. 3.2.2 Initial Conditions . | DUT is fully unregistered from Amazon Sidewalk network (both Cloud and DUT side) . | Lower Tester operates in BLE mode. | . 3.2.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Not Registered, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon with provisioning request: Application ID: 0x4 (Sidewalk Cloud Service), Device mode: Registration mode (0x1) Lower_Tester->>DUT: Establish BLE connection Note over Lower_Tester,Upper_Tester: Sidewalk Registration DUT->>Lower_Tester: PROV_INIT_REQ DUT->>Lower_Tester: NOTIFY_PROV_INIT_REQ_SIG Lower_Tester->>DUT: RESP_PROV_INIT_REQ Lower_Tester->>DUT: PROV_INIT_SIG DUT->>Lower_Tester: RESP_PROV_INIT_SIG Lower_Tester->>DUT: GET_DEVICE_ECDH_SIG DUT->>Lower_Tester: RESP_DEVICE_ECDH_SIG Lower_Tester->>DUT: HAND_SHAKE_REQ DUT->>Lower_Tester: HAND_SHAKE_RESP Lower_Tester->>DUT: SET_PAN_ID DUT->>Lower_Tester: RESP_PAN_ID Lower_Tester->>DUT: SET_P2P_CHANNEL DUT->>Lower_Tester: RESP_P2P_CHANNEL Lower_Tester->>DUT: SET_P2P_BROADCAST_KEY DUT->>Lower_Tester: SET_P2P_BROADCAST_KEY Lower_Tester->>DUT: SET_WAN_SEC_PARAMS DUT->>Lower_Tester: RESP_WAN_SEC_PARAMS Note over Lower_Tester,Upper_Tester: Continued on next page . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Application Registration Lower_Tester->>DUT: RESP_PROV_INIT_REQ Lower_Tester->>DUT: PROV_INIT_SIG DUT->>Lower_Tester: RESP_PROV_INIT_SIG Lower_Tester->>DUT: GET_DEVICE_ECDH_SIG DUT->>Lower_Tester: RESP_GET_DEVICE_ECDH_SIG Lower_Tester->>DUT: SET_APP_SEC_PARAMS DUT->>Lower_Tester: RESP_APP_SEC_PARAMS Lower_Tester->>DUT: HAND_SHAKE_REQ DUT->>Lower_Tester: HAND_SHAKE_RESP Lower_Tester->>DUT: SET_CONFIGURATION_COMPLETE DUT->>Lower_Tester: RESP_CONFIGURATION_COMPLETE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, BLE Disconnected\" Lower_Tester->>DUT: Drop BLE connection DUT->>Lower_Tester: Beacon with time sync request Lower_Tester->>DUT: Establish BLE connection Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE disconnected\" . 3.2.4 Expected Results . 3.2.4.1 Pass Verdict . Before registration, DUT is transmitting beacons with provisioning request. This information is located in: “Application ID” - 5th octet of Manufacturing Data - 0x4 (Sidewalk Cloud Service) “Device State” - second and third bit in 6th octet of Manufacturing Data . | Registration mode (0x1). | . There may be more than one beacon transmitted by DUT before the BLE connection with Lower Tester is established, however this should not negatively affect the registration process. Lower Tester establishes BLE connection with DUT, after detecting a beacon with provisioning request. DUT sends “PROV_INIT_REQ” packet to initiate the registration flow. Every registration related packet is successfully exchanged between Lower Tester and DUT. DUT receives “SET_CONFIGURATION_COMPLETE” packet from Lower Tester and responds with “RESP_CONFIGURATION_COMPLETE”. Those two packets signify that DUT is successfully registered with Amazon Sidewalk network with use of FFN. Registration status on DUT changes to: “Registered”. Afterwards, DUT completes time synchronization over BLE. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#32-bleepconnregbv02-an-unregistered-endpoint-successfully-completes-sidewalk-device-registration-with-use-of-ffn", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#32-bleepconnregbv02-an-unregistered-endpoint-successfully-completes-sidewalk-device-registration-with-use-of-ffn" },"102": { "doc": "3. BLE Test Cases", "title": "3.3 BLE/EP/CONN/REG/BV/03: Endpoint can be deregistered from Sidewalk network.", "content": "3.3.1 Test Purpose . To verify that the DUT is able to be deregistered from the Amazon Sidewalk network. After deregistration DUT starts transmitting beacons with provisioning request. 3.3.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | The Sidewalk stack (BLE) is initialized and started on the DUT. | . 3.3.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE Disconnected Upper_Tester->>DUT: sid_set_factory_reset() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Not registered, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon with provisioning request: Application ID: 0x4 (Sidewalk Cloud Service), Device mode: Registration mode (0x1) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Not registered, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 3.3.4 Expected Results . 3.3.4.1 Pass Verdict . Calling the method should force the change in registration status of DUT to “not registered”. After deregistration, DUT starts transmitting beacons with provisioning request. This information is located in: “Application ID” - 5th octet of Manufacturing Data - 0x4 (Sidewalk Cloud Service) “Device State” - second and third bit in 6th octet of Manufacturing Data . | Registration mode (0x1). | . ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#33-bleepconnregbv03-endpoint-can-be-deregistered-from-sidewalk-network", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#33-bleepconnregbv03-endpoint-can-be-deregistered-from-sidewalk-network" },"103": { "doc": "3. BLE Test Cases", "title": "3.4 BLE/EP/DATA/DL/BV/01: Endpoint receives downlink packets with various sizes of Command data.", "content": "3.4.1 Test Purpose . DUT is able to receive downlink packets with various sizes of Command data (1B, 125B, 255B) sent from the Lower Tester. 3.4.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 3.4.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE Disconnected DUT->>Lower_Tester: Beacon Lower_Tester->>DUT: Establish BLE connection(triggered by upcoming downlink packet) DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with 1B of Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: 1B\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with 125B of Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: 125B\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with 255B of Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: 255B\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.4.4 Expected Results . 3.4.4.1 Pass Verdict . Packets with various sizes of Command data sent by Lower Tester are able to reach the DUT. The Command data content shall be verified for correctness on the Upper Tester side. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#34-bleepdatadlbv01-endpoint-receives-downlink-packets-with-various-sizes-of-command-data", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#34-bleepdatadlbv01-endpoint-receives-downlink-packets-with-various-sizes-of-command-data" },"104": { "doc": "3. BLE Test Cases", "title": "3.5 BLE/EP/DATA/UL/BV/01: Gateway receives uplink packets with various sizes of Command data from Endpoint.", "content": "3.5.1 Test Purpose . Lower Tester is able to receive uplink packets with various sizes of Command data(1B, 125B, 255B) sent from the DUT. 3.5.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 3.5.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE disconnected DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: 1B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: 125B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 125B of Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: 255B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 255B of Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.5.4 Expected Results . 3.5.4.1 Pass Verdict . Packets with various sizes of Command data sent by DUT are able to reach the Lower Tester. The Command data content of each packet shall be verified for correctness on the Lower Tester side. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#35-bleepdataulbv01-gateway-receives-uplink-packets-with-various-sizes-of-command-data-from-endpoint", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#35-bleepdataulbv01-gateway-receives-uplink-packets-with-various-sizes-of-command-data-from-endpoint" },"105": { "doc": "3. BLE Test Cases", "title": "3.6 BLE/EP/CONN/EST/BV/01: Gateway establishes BLE connection on Endpoint’s request.", "content": "3.6.1 Test Purpose . To verify that Lower Tester successfully establishes BLE connection with DUT, after detecting connection request in the payload of the DUT’s advertising beacon. 3.6.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 3.6.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE Disconnected DUT->>Lower_Tester: Beacon Device Mode: Normal mode (0x0) Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Device Mode: Connection request (0x2) Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.6.4 Expected Results . 3.6.4.1 Pass Verdict . When BLE connection is requested, DUT should change beacon payload to include connection request. Change occurs in Device State - 6th octet of Manufacturing Data in the beacon. Within the Device State, second and third bits signify Device Mode, where: 0x0 - Normal mode, 0x2 - Connection request. Payload of the beacons to be checked with BLE sniffer on Lower Tester side. Device Mode before setting the connection request: Normal mode (0x0). Device Mode after setting the connection request: Connection request (0x2). Lower Tester establishes BLE connection with DUT, after receiving beacon with connection request. After BLE connection is established, DUT triggers “()” with “Link Mask” value of 1, which indicates that the BLE connection was established. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#36-bleepconnestbv01-gateway-establishes-ble-connection-on-endpoints-request", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#36-bleepconnestbv01-gateway-establishes-ble-connection-on-endpoints-request" },"106": { "doc": "3. BLE Test Cases", "title": "3.7 BLE/EP/CONN/EST/BV/02: Endpoint can connect with Gateway via BLE, after reinitializing Sidewalk library.", "content": "3.7.1 Test Purpose . To verify that DUT and Lower Tester can establish a BLE connection, after Sidewalk library is reinitialized. 3.7.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 3.7.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE Disconnected Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon with time sync request Lower_Tester->>DUT: Establish BLE connection Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.7.4 Expected Results . 3.7.4.1 Pass Verdict . After reinitializing Sidewalk library DUT and Lower Tester establish BLE connection to complete time synchronization. DUT is able to request and establish BLE connection with Lower Tester, when the time synchronization is completed. During time synchronization and after requesting BLE connection, DUT triggers “()” with “Link Mask” value of 1, which indicates that the BLE connection was established. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#37-bleepconnestbv02-endpoint-can-connect-with-gateway-via-ble-after-reinitializing-sidewalk-library", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#37-bleepconnestbv02-endpoint-can-connect-with-gateway-via-ble-after-reinitializing-sidewalk-library" },"107": { "doc": "3. BLE Test Cases", "title": "3.8 BLE/EP/CONN/EST/BV/03: Endpoint can connect with Gateway via BLE, after restarting Sidewalk library.", "content": "3.8.1 Test Purpose . To verify that DUT and Lower Tester can establish a BLE connection, after Sidewalk library is restarted. 3.8.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 3.8.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE Disconnected Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon with time sync request Lower_Tester->>DUT: Establish BLE connection Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.8.4 Expected Results . 3.8.4.1 Pass Verdict . After restarting Sidewalk library DUT and Lower Tester establish BLE connection to complete time synchronization. DUT is able to request and establish BLE connection with Lower Tester, when the time synchronization is completed. During time synchronization and after requesting BLE connection, DUT triggers “()” with “Link Mask” value of 1, which indicates that the BLE connection was established. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#38-bleepconnestbv03-endpoint-can-connect-with-gateway-via-ble-after-restarting-sidewalk-library", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#38-bleepconnestbv03-endpoint-can-connect-with-gateway-via-ble-after-restarting-sidewalk-library" },"108": { "doc": "3. BLE Test Cases", "title": "3.9 BLE/EP/CONN/DSC/BV/01: BLE connection between Gateway and Endpoint is dropped after 30 seconds of being idle.", "content": "3.9.1 Test Purpose . To verify that BLE connection is dropped after 30 seconds, if there is no uplink/downlink traffic generated. 3.9.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 3.9.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Note over Lower_Tester,Upper_Tester: Wait for 30s DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.9.4 Expected Results . 3.9.4.1 Pass Verdict . BLE connection is dropped after 30 seconds, from the time it was established. There should be no connection drops and reconnects before the 30 seconds timeout is reached. After the timeout, DUT triggers “()” with “Link Mask” value of 0, which indicates that the BLE connection was dropped. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#39-bleepconndscbv01-ble-connection-between-gateway-and-endpoint-is-dropped-after-30-seconds-of-being-idle", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#39-bleepconndscbv01-ble-connection-between-gateway-and-endpoint-is-dropped-after-30-seconds-of-being-idle" },"109": { "doc": "3. BLE Test Cases", "title": "3.10 BLE/EP/CONN/DSC/BV/02: BLE connection between Gateway and Endpoint is extended by uplink packet and dropped after additional 30 seconds.", "content": "3.10.1 Test Purpose . To verify that BLE connection is dropped 30 seconds after uplink packet transmission was finished, which results in extending total time the devices are connected. 3.10.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 3.10.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Note over Lower_Tester,Upper_Tester: Wait for 15s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: Wait for 30s DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.10.4 Expected Results . 3.10.4.1 Pass Verdict . BLE connection is dropped after 30 seconds, from the time the uplink packet transmission was finished. There should be no connection drops and reconnects before the 30 seconds timeout is reached. After the timeout, DUT triggers “()” with “Link Mask” value of 0, which indicates that the BLE connection was dropped. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#310-bleepconndscbv02-ble-connection-between-gateway-and-endpoint-is-extended-by-uplink-packet-and-dropped-after-additional-30-seconds", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#310-bleepconndscbv02-ble-connection-between-gateway-and-endpoint-is-extended-by-uplink-packet-and-dropped-after-additional-30-seconds" },"110": { "doc": "3. BLE Test Cases", "title": "3.11 BLE/EP/CONN/DSC/BV/03: BLE connection between Gateway and Endpoint is extended by downlink packet and dropped after additional 30 seconds.", "content": "3.11.1 Test Purpose . To verify that BLE connection is dropped 30 seconds after downlink packet transmission was finished, which results in extending total time the devices are connected. 3.11.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 3.11.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Note over Lower_Tester,Upper_Tester: Wait for 15s Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: any\" Note over Lower_Tester,Upper_Tester: Wait for 30s DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.11.4 Expected Results . 3.11.4.1 Pass Verdict . BLE connection is dropped after 30 seconds, from the time the downlink packet transmission was finished. There should be no connection drops and reconnects before the 30 seconds timeout is reached. After the timeout, DUT triggers “()” with “Link Mask” value of 0, which indicates that the BLE connection was dropped. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#311-bleepconndscbv03-ble-connection-between-gateway-and-endpoint-is-extended-by-downlink-packet-and-dropped-after-additional-30-seconds", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#311-bleepconndscbv03-ble-connection-between-gateway-and-endpoint-is-extended-by-downlink-packet-and-dropped-after-additional-30-seconds" },"111": { "doc": "3. BLE Test Cases", "title": "3.12 BLE/EP/CONN/DSC/BV/06: Endpoint drops BLE connection after stopping Sidewalk library.", "content": "3.12.1 Test Purpose . To verify that DUT drops BLE connection if Sidewalk library is stopped. 3.12.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 3.12.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE Disconnected Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.12.4 Expected Results . 3.12.4.1 Pass Verdict . After sending the command to stop Sidewalk library, DUT triggers “()” with “Link Mask” value of 0, which indicates that the BLE connection was dropped. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#312-bleepconndscbv06-endpoint-drops-ble-connection-after-stopping-sidewalk-library", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#312-bleepconndscbv06-endpoint-drops-ble-connection-after-stopping-sidewalk-library" },"112": { "doc": "3. BLE Test Cases", "title": "3.13 BLE/EP/CONN/DSC/BV/07: Endpoint drops BLE connection after deinitializing Sidewalk library.", "content": "3.13.1 Test Purpose . To verify that DUT drops BLE connection if Sidewalk library is deinitialized. 3.13.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 3.13.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE Disconnected Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid_deinit() DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.13.4 Expected Results . 3.13.4.1 Pass Verdict . After sending the command to deinitialize Sidewalk library, DUT triggers “()” with “Link Mask” value of 0, which indicates that the BLE connection was dropped. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#313-bleepconndscbv07-endpoint-drops-ble-connection-after-deinitializing-sidewalk-library", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#313-bleepconndscbv07-endpoint-drops-ble-connection-after-deinitializing-sidewalk-library" },"113": { "doc": "3. BLE Test Cases", "title": "3.14 BLE/EP/CONN/BCN/BV/01: Endpoint transmits beacons only when BLE connection is not established.", "content": "3.14.1 Test Purpose . To verify that DUT transmits beacons before establishing BLE connection and after disconnecting. During the active connection, no beacons should be transmitted. 3.14.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 3.14.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE disconnected DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Note over Lower_Tester,Upper_Tester: Wait for 30 seconds, during that time no beacons should be detected DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.14.4 Expected Results . 3.14.4.1 Pass Verdict . DUT transmits beacons before establishing BLE connection. DUT stops transmitting beacons after establishing BLE connection. DUT starts transmitting beacons again after disconnecting from the BLE connection. All the beaconing activities to be checked with BLE sniffer on Lower Tester side. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#314-bleepconnbcnbv01-endpoint-transmits-beacons-only-when-ble-connection-is-not-established", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#314-bleepconnbcnbv01-endpoint-transmits-beacons-only-when-ble-connection-is-not-established" },"114": { "doc": "3. BLE Test Cases", "title": "3.15 BLE/EP/CONN/BCN/BV/02: Endpoint transmits beacons that contain Identifier (TX-ID), which changes every 15 minutes.", "content": "3.15.1 Test Purpose . To verify that DUT transmits beacons with Identifier (TX-ID). The Identifier is changed every 15 minutes, which can be verified in the application specific data of subsequent beacons. 3.15.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 3.15.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE disconnected DUT->>Lower_Tester: Beacon with first TX-ID 1 DUT->>Lower_Tester: Beacon with first TX-ID 1 DUT->>Lower_Tester: Beacon with first TX-ID 1 Note over Lower_Tester,Upper_Tester: Keep checking payload of the beacons until TX-ID changes (duration: up to 15 minutes) Note over Lower_Tester,DUT: ... DUT->>Lower_Tester: Beacon with second TX-ID 2 DUT->>Lower_Tester: Beacon with second TX-ID 2 DUT->>Lower_Tester: Beacon with second TX-ID 2 Note over Lower_Tester,Upper_Tester: Keep checking payload of the beacons until TX-ID changes again (duration: 15 minutes starting from previous TX-ID change) Note over Lower_Tester,DUT: ... DUT->>Lower_Tester: Beacon with third TX-ID 3 DUT->>Lower_Tester: Beacon with third TX-ID 3 DUT->>Lower_Tester: Beacon with third TX-ID 3 Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.15.4 Expected Results . 3.15.4.1 Pass Verdict . DUT transmits beacons with payload that contains TX-ID. TX-ID is 5 bytes long and is located in 2nd-6th octets of the “Application Specific Data”, in “Manufacturing Data” section of the beacon. First TX-ID change occurs within 15 minutes and is used as a starting point of second TX-ID change duration. Second TX-ID change occurs 15 minutes after the first one. There should be no additional changes in the data of TX-ID. All the beaconing activities to be checked with BLE sniffer on Lower Tester side. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#315-bleepconnbcnbv02-endpoint-transmits-beacons-that-contain-identifier-tx-id-which-changes-every-15-minutes", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#315-bleepconnbcnbv02-endpoint-transmits-beacons-that-contain-identifier-tx-id-which-changes-every-15-minutes" },"115": { "doc": "3. BLE Test Cases", "title": "3.16 BLE/EP/CONN/BCN/BV/03: Endpoint transmits beacons with 160ms interval for the first 30 seconds after starting BLE protocol.", "content": "3.16.1 Test Purpose . To verify that DUT transmits a beacon every 160ms, with +/-10ms of acceptable range (150ms-170ms) for the first 30 seconds after starting BLE protocol. Lower Tester should not react to the beacons with BLE connection establishment, so that the beacon transmission interval stays uninterrupted. 3.16.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | . 3.16.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE disconnected\" Note over Lower_Tester,Upper_Tester: Interval of 160ms (+/- 10ms) between the upcoming beacons DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Wait for 29 seconds, from the time the Sidewalk library was started Note over Lower_Tester,Upper_Tester: Interval of 160ms (+/- 10ms) between the upcoming beacons DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 3.16.4 Expected Results . 3.16.4.1 Pass Verdict . The interval of 160ms (+/- 10ms) in beacon transmission is respected by DUT for the first 30 seconds after starting Sidewalk library. At least 4 beacons to be verified in terms of the valid interval in both cases: immediately after starting Sidewalk library, and 29 seconds after starting Sidewalk library. All the beaconing activities to be checked with BLE sniffer on Lower Tester side. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#316-bleepconnbcnbv03-endpoint-transmits-beacons-with-160ms-interval-for-the-first-30-seconds-after-starting-ble-protocol", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#316-bleepconnbcnbv03-endpoint-transmits-beacons-with-160ms-interval-for-the-first-30-seconds-after-starting-ble-protocol" },"116": { "doc": "3. BLE Test Cases", "title": "3.17 BLE/EP/CONN/BCN/BV/04: Endpoint transmits beacons with customized interval, 30 seconds after starting BLE protocol.", "content": "3.17.1 Test Purpose . To verify that DUT transmits a beacon with customized interval (default: every 1000ms) with +/-10ms of acceptable range, 30 seconds after starting BLE protocol. Lower Tester should not react to the beacons with BLE connection establishment, so that the beacon transmission interval stays uninterrupted. 3.17.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | . 3.17.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE disconnected\" Note over Lower_Tester,Upper_Tester: Wait for 30 seconds Note over Lower_Tester,Upper_Tester: Customized interval (default: 1000ms) +/- 10ms between the upcoming beacons DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 3.17.4 Expected Results . 3.17.4.1 Pass Verdict . The customized beacon transmission interval (default: 1000ms) +/- 10ms is respected by the device under test (DUT) 30 seconds after starting the Sidewalk library. At least 4 beacons to be verified in terms of the valid interval. All the beaconing activities to be checked with BLE sniffer on Lower Tester side. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#317-bleepconnbcnbv04-endpoint-transmits-beacons-with-customized-interval-30-seconds-after-starting-ble-protocol", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#317-bleepconnbcnbv04-endpoint-transmits-beacons-with-customized-interval-30-seconds-after-starting-ble-protocol" },"117": { "doc": "3. BLE Test Cases", "title": "3.18 BLE/EP/CONN/DUP/BV/01: BLE connection is closed after Endpoint receives 10 packets with duplicate SEQ number within one minute (filter duplicates enabled).", "content": "3.18.1 Test Purpose . To verify that DUT closes BLE connection after total of 10 packets with duplicate sequence number reach it within one minute. To confirm this behavior “filter duplicates” option has to be enabled on DUT. 3.18.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | “Filter duplicates” option enabled on the DUT. | . 3.18.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE Disconnected DUT->>Lower_Tester: Beacon Lower_Tester->>DUT: Establish BLE connection(triggered by upcoming downlink packet) DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Note over Lower_Tester,Upper_Tester: 10 upcoming packets with duplicate sequence number shall be sent within one minute period. Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.18.4 Expected Results . 3.18.4.1 Pass Verdict . The first CUSTOM_NOTIFY_CMD packet with sequence number equal to 1 should be sent from the Lower Tester, correctly decoded and verified against the on the DUT side. Information about this packet should be reported on the Upper Tester side. Ten CUSTOM_NOTIFY_CMD packets with duplicate sequence number equal to 1 shall be sent from Lower within the one minute period. One minute period starts after Lower Tester finishes transmission of the first downlink packet with duplicate sequence number. All packets with duplicate sequence number are rejected by DUT. Information about them will not be reported on the Upper Tester side. Upon arrival of the last CUSTOM_NOTIFY_CMD packet, DUT triggers “()” with “Link Mask” value of 0, which indicates that the BLE connection was dropped. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#318-bleepconndupbv01-ble-connection-is-closed-after-endpoint-receives-10-packets-with-duplicate-seq-number-within-one-minute-filter-duplicates-enabled", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#318-bleepconndupbv01-ble-connection-is-closed-after-endpoint-receives-10-packets-with-duplicate-seq-number-within-one-minute-filter-duplicates-enabled" },"118": { "doc": "3. BLE Test Cases", "title": "3.19 BLE/EP/CONN/DUP/BV/02: BLE connection is closed after Endpoint receives 10 packets with various duplicate SEQ numbers within one minute (filter duplicates enabled).", "content": "3.19.1 Test Purpose . To verify that DUT closes BLE connection after total of 10 packets with various duplicate sequence numbers reach it within one minute. To confirm this behavior “filter duplicates” option has to be enabled on DUT. 3.19.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | “Filter duplicates” option enabled on the DUT. | . 3.19.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE Disconnected DUT->>Lower_Tester: Beacon Lower_Tester->>DUT: Establish BLE connection(triggered by upcoming downlink packet) DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=2) DUT->>Upper_Tester: on_msg_received() \"seq_num=2\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=3) DUT->>Upper_Tester: on_msg_received() \"seq_num=3\" Note over Lower_Tester,Upper_Tester: 10 upcoming packets with various duplicate sequence numbers shall be sent within one minute period. Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=2) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=2) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=2) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=3) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=3) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=3) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=3) DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.19.4 Expected Results . 3.19.4.1 Pass Verdict . The first three CUSTOM_NOTIFY_CMD packets with sequence numbers increasing sequentially from 1 to 3 should be sent from the Lower Tester, correctly decoded and verified against the on the DUT side. Information about all three of these packets should be reported on the Upper Tester side. Ten CUSTOM_NOTIFY_CMD packets with various duplicate sequence numbers ranging from 1 to 3, sent from the Lower Tester within the one minute period. One minute period starts after Lower Tester finishes transmission of the first downlink packet with duplicate sequence number. All packets with duplicate sequence number are rejected by DUT. Information about them will not be reported on the Upper Tester side. Upon arrival of the last CUSTOM_NOTIFY_CMD packet, DUT triggers “()” with “Link Mask” value of 0, which indicates that the BLE connection was dropped. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#319-bleepconndupbv02-ble-connection-is-closed-after-endpoint-receives-10-packets-with-various-duplicate-seq-numbers-within-one-minute-filter-duplicates-enabled", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#319-bleepconndupbv02-ble-connection-is-closed-after-endpoint-receives-10-packets-with-various-duplicate-seq-numbers-within-one-minute-filter-duplicates-enabled" },"119": { "doc": "3. BLE Test Cases", "title": "3.20 BLE/EP/CONN/DUP/BV/03: BLE connection is not closed after Endpoint receives 10 packets with duplicate SEQ number within one minute (filter duplicates disabled).", "content": "3.20.1 Test Purpose . To verify that DUT does not close BLE connection after total of 10 packets with duplicate sequence number reach it within one minute. To confirm this behavior “filter duplicates” option has to be disabled on DUT. 3.20.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | “Filter duplicates” option disabled on the DUT. | . 3.20.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE Disconnected DUT->>Lower_Tester: Beacon Lower_Tester->>DUT: Establish BLE connection(triggered by upcoming downlink packet) DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Note over Lower_Tester,Upper_Tester: 10 upcoming packets with duplicate sequence number shall be sent within one minute period. Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.20.4 Expected Results . 3.20.4.1 Pass Verdict . The first CUSTOM_NOTIFY_CMD packet with sequence number equal to 1 should be sent from the Lower Tester, correctly decoded and verified against the on the DUT side. Information about this packet should be reported on the Upper Tester side. Ten CUSTOM_NOTIFY_CMD packets with duplicate sequence number equal to 1 shall be sent from Lower within the one minute period. One minute period starts after Lower Tester finishes transmission of the first downlink packet with duplicate sequence number. All packets with duplicate sequence number are rejected by DUT. Information about them will not be reported on the Upper Tester side. Upon arrival of the last CUSTOM_NOTIFY_CMD packet, DUT does not trigger “()”, which means that “Link Mask” value remains unchanged and the BLE connection was not dropped. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#320-bleepconndupbv03-ble-connection-is-not-closed-after-endpoint-receives-10-packets-with-duplicate-seq-number-within-one-minute-filter-duplicates-disabled", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#320-bleepconndupbv03-ble-connection-is-not-closed-after-endpoint-receives-10-packets-with-duplicate-seq-number-within-one-minute-filter-duplicates-disabled" },"120": { "doc": "3. BLE Test Cases", "title": "3.21 BLE/EP/CONN/DUP/BV/04: BLE connection is not closed after Endpoint receives 10 packets with various duplicate SEQ numbers within one minute (filter duplicates disabled).", "content": "3.21.1 Test Purpose . To verify that DUT does not close BLE connection after total of 10 packets with various duplicate sequence numbers reach it within one minute. To confirm this behavior “filter duplicates” option has to be disabled on DUT. 3.21.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | “Filter duplicates” option disabled on the DUT. | . 3.21.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE Disconnected DUT->>Lower_Tester: Beacon Lower_Tester->>DUT: Establish BLE connection(triggered by upcoming downlink packet) DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=2) DUT->>Upper_Tester: on_msg_received() \"seq_num=2\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=3) DUT->>Upper_Tester: on_msg_received() \"seq_num=3\" Note over Lower_Tester,Upper_Tester: 10 upcoming packets with various duplicate sequence numbers shall be sent within one minute period. Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=2) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=2) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=2) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=3) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=3) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=3) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=3) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.21.4 Expected Results . 3.21.4.1 Pass Verdict . The first three CUSTOM_NOTIFY_CMD packets with sequence numbers increasing sequentially from 1 to 3 should be sent from the Lower Tester, correctly decoded and verified against the on the DUT side. Information about all three of these packets should be reported on the Upper Tester side. Ten CUSTOM_NOTIFY_CMD packets with various duplicate sequence numbers ranging from 1 to 3, sent from the Lower Tester within the one minute period. One minute period starts after Lower Tester finishes transmission of the first downlink packet with duplicate sequence number. All packets with duplicate sequence number are rejected by DUT. Information about them will not be reported on the Upper Tester side. Upon arrival of the last CUSTOM_NOTIFY_CMD packet, DUT does not trigger “()”, which means that “Link Mask” value remains unchanged and the BLE connection was not dropped. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#321-bleepconndupbv04-ble-connection-is-not-closed-after-endpoint-receives-10-packets-with-various-duplicate-seq-numbers-within-one-minute-filter-duplicates-disabled", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#321-bleepconndupbv04-ble-connection-is-not-closed-after-endpoint-receives-10-packets-with-various-duplicate-seq-numbers-within-one-minute-filter-duplicates-disabled" },"121": { "doc": "3. BLE Test Cases", "title": "3.22 BLE/EP/CONN/DUP/BV/05: BLE connection is not closed after 10 packets with duplicate SEQ number reach Endpoint, if not all of those packets are sent within one minute.", "content": "3.22.1 Test Purpose . To verify that DUT does not close BLE connection, when 10th packet with duplicate SEQ number is received by Endpoint more than one minute after the first one. DUT will reset the counter of duplicates after a minute passes, starting from the first packet with duplicate sequence number reaching DUT. To confirm this behavior “filter duplicates” option has to be enabled on DUT. 3.22.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT has completed the time synchronization. | “Filter duplicates” option enabled on the DUT. | . 3.22.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 0, BLE Disconnected DUT->>Lower_Tester: Beacon Lower_Tester->>DUT: Establish BLE connection(triggered by upcoming downlink packet) DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Note over Lower_Tester,Upper_Tester: 9 upcoming packets with duplicate sequence number shall be sent within one minute period and with a consistent interval of 6 seconds between the packets. Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Note over Lower_Tester,Upper_Tester: Upcoming packet with duplicate sequence number shall be sent after the one minute period has ended, within the next 6 seconds. Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 3.22.4 Expected Results . 3.22.4.1 Pass Verdict . The first CUSTOM_NOTIFY_CMD packet with sequence number equal to 1 should be sent from the Lower Tester, correctly decoded and verified against the on the DUT side. Information about this packet should be reported on the Upper Tester side. Ten CUSTOM_NOTIFY_CMD packets with duplicate sequence number equal to 1 shall be sent from Lower Tester, where: Nine CUSTOM_NOTIFY_CMD packets are sent within the one minute period and with a consistent interval of 6 seconds between the packets. One CUSTOM_NOTIFY_CMD packet is sent after the one minute period has ended, within the next 6 seconds. One minute period starts after Lower Tester finishes transmission of the first downlink packet with duplicate sequence number. All packets with duplicate sequence number are rejected by DUT. Information about them will not be reported on the Upper Tester side. Upon arrival of the last CUSTOM_NOTIFY_CMD packet, DUT does not trigger “()”, which means that “Link Mask” value remains unchanged and the BLE connection was not dropped. ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#322-bleepconndupbv05-ble-connection-is-not-closed-after-10-packets-with-duplicate-seq-number-reach-endpoint-if-not-all-of-those-packets-are-sent-within-one-minute", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#322-bleepconndupbv05-ble-connection-is-not-closed-after-10-packets-with-duplicate-seq-number-reach-endpoint-if-not-all-of-those-packets-are-sent-within-one-minute" },"122": { "doc": "3. BLE Test Cases", "title": "3.23 BLE/EP/NW/SYNC/TIME/BV/01: Endpoint completes the initial time sync procedure.", "content": "3.23.1 Test Purpose . DUT is able to pass the initial time synchronization procedure. Payload of the beacons transmitted by DUT is appropriate to the time sync state. 3.23.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 3.23.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon with time sync request: Application ID: 0x3 (Sidewalk Cloud Service) Lower_Tester->>DUT: Establish BLE connection Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Up, Time Synced, Link Mask 1, BLE Connected\" DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon without time sync request: Application ID: 0x21 (IoT Wireless Application) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, BLE Disconnected\" . 3.23.4 Expected Results . 3.23.4.1 Pass Verdict . Depending on the time sync state of DUT, advertising beacon may contain the time sync request. This information is located in “Application ID” - 5th octet of Manufacturing Data in the beacon. Value of the Application ID signifies whether DUT is requesting time sync (0x3 . | Sidewalk Cloud Service) or if it was already completed (0x21 - IoT Wireless Application). Payload of the beacons to be checked with BLE sniffer on Lower Tester side. | . Before starting time sync procedure, DUT transmits beacons with time sync request - Application ID: 0x3 (Sidewalk Cloud Service). There may be more than one beacon transmitted by DUT before the BLE connection with Lower Tester is established, however this should not negatively affect the time synchronization procedure. Lower Tester establishes BLE connection with DUT after receiving beacon with time sync request. The RESP_TIME packet will be sent to DUT right after establishing the BLE connection. DUT is able to acquire time from the network. No other UL transmission should take place until the DUT receives a correct RESP_TIME packet which will be reported via Time Status: synced. After completing time synchronization procedure, DUT triggers “()” twice: With “Link Mask” value of 1, Link status Up and Time synced, which indicate that the BLE connection was established and time synchronization was completed. With “Link Mask” value of 0 and Link status Down, which indicate that the BLE connection was dropped right after. Completion of the time synchronization procedure should also result in DUT transmitting beacons to the app server (without time sync request) - Application ID: 0x21 (IoT Wireless Application). ", "url": "/specifications/sidewalk-test-spec/ble-test-cases.html#323-bleepnwsynctimebv01-endpoint-completes-the-initial-time-sync-procedure", "relUrl": "/specifications/sidewalk-test-spec/ble-test-cases.html#323-bleepnwsynctimebv01-endpoint-completes-the-initial-time-sync-procedure" },"123": { "doc": "4. BLE Test Cases", "title": "BLE Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#ble-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#ble-test-cases" },"124": { "doc": "4. BLE Test Cases", "title": "Test Case ID: CMN/EN/API/INF/BV-01: End Node has correct MCU version after launching Sidewalk application", "content": "| Field | Value | . | Case ID | C103619213 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Check response on command: sid sdk_version | Response example: app: 1.19.5-36 (rev. 0) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-cmnenapiinfbv-01-end-node-has-correct-mcu-version-after-launching-sidewalk-application", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-cmnenapiinfbv-01-end-node-has-correct-mcu-version-after-launching-sidewalk-application" },"125": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/REG/BV/01: An unregistered End Node successfully completes Sidewalk device registration over BLE", "content": "| Field | Value | . | Case ID | C103619399 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Run the following commands on the EN device: sid init 1 sid start | Each command returns: CMD: ERR: 0 | . | 2 | Place EN next to a registered GW and wait for BLE registration to complete. Verify registration status with: sid last_status | EVENT SID STATUS: State: 1, Reg: 0, Time: 1, Link_Mask: 0 Key check: Reg: 0 (registered) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnregbv01-an-unregistered-end-node-successfully-completes-sidewalk-device-registration-over-ble", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnregbv01-an-unregistered-end-node-successfully-completes-sidewalk-device-registration-over-ble" },"126": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/REG/BV/02: An unregistered End Node successfully completes Sidewalk device registration with use of FFN", "content": "| Field | Value | . | Case ID | C103619414 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Run the following commands on the EN device: sid init 1 sid start | Each command returns: CMD: ERR: 0 | . | 2 | Place the EN next to a GW | Registration process should start automatically | . | 3 | Verify registration status with: sid last_status | EVENT SID STATUS: State: 1, Reg: 0, Time: 1, Link_Mask: 0 Key check: Reg: 0 (registered) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnregbv02-an-unregistered-end-node-successfully-completes-sidewalk-device-registration-with-use-of-ffn", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnregbv02-an-unregistered-end-node-successfully-completes-sidewalk-device-registration-with-use-of-ffn" },"127": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/REG/BV/03: End Node can be deregistered from Sidewalk network", "content": "| Field | Value | . | Case ID | C103619400 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Run the following command to deregister the device: sid factory_reset | CMD: ERR: 0 | . | 2 | Verify deregistration status with: sid last_status | EVENT SID STATUS: State: 1, Reg: 1, Time: 1, Link_Mask: 0 Key check: Reg: 1 (deregistered) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnregbv03-end-node-can-be-deregistered-from-sidewalk-network", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnregbv03-end-node-can-be-deregistered-from-sidewalk-network" },"128": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/DATA/DL/BV/01: Endpoint receives downlink packets with various sizes of Command data", "content": "| Field | Value | . | Case ID | C103619402 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 1 downlink packet from AWS IoT to EN with 1 byte payload | EVENT SID RECEIVED: TYPE: 1, ID: <id>, LEN: 1, LINK: 1, LINK_MODE: <x>, ACK_REQUESTED: <x>, ACK: <x>, DUP: <x>, RSSI: <x>, SNR: <x> Data: <payload> Key check: ID matches sent packet, LEN: 1 | . | 2 | Send 1 downlink packet from AWS IoT to EN with 125 bytes payload | EVENT SID RECEIVED: TYPE: 1, ID: <id>, LEN: 125, LINK: 1, LINK_MODE: <x>, ACK_REQUESTED: <x>, ACK: <x>, DUP: <x>, RSSI: <x>, SNR: <x> Data: <payload> Key check: ID matches sent packet, LEN: 125 | . | 3 | Send 1 downlink packet from AWS IoT to EN with 255 bytes payload | EVENT SID RECEIVED: TYPE: 1, ID: <id>, LEN: 255, LINK: 1, LINK_MODE: <x>, ACK_REQUESTED: <x>, ACK: <x>, DUP: <x>, RSSI: <x>, SNR: <x> Data: <payload> Key check: ID matches sent packet, LEN: 255 | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleendatadlbv01-endpoint-receives-downlink-packets-with-various-sizes-of-command-data", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleendatadlbv01-endpoint-receives-downlink-packets-with-various-sizes-of-command-data" },"129": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/DATA/UL/BV/01: Gateway receives uplink packet with different payload sizes from End Node", "content": "| Field | Value | . | Case ID | C103619403 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | BT connection is established (sid conn_req 1) | . Test Steps . | Step | Description | Expected Result | . | 1 | Run the following command on EN to send 1 UL packet with 1 byte payload: sid send <1-byte-payload> | CMD: ERR: 0 TYPE: 2 ID: <id> EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 1 LINK_MODE: 0 ADDITIONAL ATTRS: 0 Key check: SID ERR: 0 (sent successfully), packet received on AWS IoT | . | 2 | Run the following command on EN to send 1 UL packet with 125 bytes payload: sid send <125-byte-payload> | CMD: ERR: 0 TYPE: 2 ID: <id> EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 1 LINK_MODE: 0 ADDITIONAL ATTRS: 0 Key check: SID ERR: 0 (sent successfully), packet received on AWS IoT | . | 3 | Run the following command on EN to send 1 UL packet with 255 bytes payload: sid send <255-byte-payload> | CMD: ERR: 0 TYPE: 2 ID: <id> EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 1 LINK_MODE: 0 ADDITIONAL ATTRS: 0 Key check: SID ERR: 0 (sent successfully), packet received on AWS IoT | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleendataulbv01-gateway-receives-uplink-packet-with-different-payload-sizes-from-end-node", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleendataulbv01-gateway-receives-uplink-packet-with-different-payload-sizes-from-end-node" },"130": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE-EP-CONN-EST-BV/01: Gateway establishes BLE connection on Endpoint’s request", "content": "| Field | Value | . | Case ID | C103619417 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | . Test Steps . | Step | Description | Expected Result | . | 1 | Run the following command on EN: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (BLE connected) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-ble-ep-conn-est-bv01-gateway-establishes-ble-connection-on-endpoints-request", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-ble-ep-conn-est-bv01-gateway-establishes-ble-connection-on-endpoints-request" },"131": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/EST/BV/02: End Node can connect with Gateway via BLE, after reinitializing Sidewalk library", "content": "| Field | Value | . | Case ID | C103619412 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | . Test Steps . | Step | Description | Expected Result | . | 1 | Deinitialize Sidewalk: sid deinit | CMD: ERR: 0 | . | 2 | Initialize and start Sidewalk, then wait for time sync: sid init 1 sid start | Each command returns: CMD: ERR: 0 Then wait for time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 Key check: Time: 0 (time synced) | . | 3 | Wait for BLE disconnected, verify with: sid last_status | EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: BLE: 0 (disconnected) | . | 4 | Set connection request on EN: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (BLE connected) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnestbv02-end-node-can-connect-with-gateway-via-ble-after-reinitializing-sidewalk-library", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnestbv02-end-node-can-connect-with-gateway-via-ble-after-reinitializing-sidewalk-library" },"132": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/EST/BV/03: End Node can connect with Gateway via BLE, after restarting Sidewalk library", "content": "| Field | Value | . | Case ID | C103619413 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | . Test Steps . | Step | Description | Expected Result | . | 1 | Stop Sidewalk: sid stop | CMD: ERR: 0 | . | 2 | Start Sidewalk: sid start | CMD: ERR: 0 | . | 3 | Verify BLE is disconnected: sid last_status | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: BLE: 0 (disconnected) | . | 4 | Set connection request on EN: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (BLE connected) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnestbv03-end-node-can-connect-with-gateway-via-ble-after-restarting-sidewalk-library", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnestbv03-end-node-can-connect-with-gateway-via-ble-after-restarting-sidewalk-library" },"133": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/DSC/BV/01: BLE connection between Gateway and End Node is dropped after 30 seconds of being idle", "content": "| Field | Value | . | Case ID | C103619404 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (connected) | . | 2 | Do not send any UL or DL for 30 seconds. Verify BLE is disconnected: sid last_status | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: BLE: 0 (disconnected after 30s idle) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconndscbv01-ble-connection-between-gateway-and-end-node-is-dropped-after-30-seconds-of-being-idle", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconndscbv01-ble-connection-between-gateway-and-end-node-is-dropped-after-30-seconds-of-being-idle" },"134": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/DSC/BV/02: BLE connection between Gateway and End Node is extended by uplink packet and dropped after additional 30 seconds", "content": "| Field | Value | . | Case ID | C103619405 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (connected) | . | 2 | Wait 15 seconds. Do not send any UL or DL. | BLE connection still active BLE: 1 | . | 3 | Send UL packet from EN: sid send TEST | CMD: ERR: 0 TYPE: 2 ID: <id> EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 1 LINK_MODE: 0 ADDITIONAL ATTRS: 0 Key check: SID ERR: 0 (sent successfully) | . | 4 | Wait 30 seconds after UL sent. Verify BLE is disconnected: sid last_status | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: BLE: 0 (disconnected after 30s) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconndscbv02-ble-connection-between-gateway-and-end-node-is-extended-by-uplink-packet-and-dropped-after-additional-30-seconds", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconndscbv02-ble-connection-between-gateway-and-end-node-is-extended-by-uplink-packet-and-dropped-after-additional-30-seconds" },"135": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/DSC/BV/03: BLE connection between Gateway and End Node is extended by downlink packet and dropped after additional 30 seconds", "content": "| Field | Value | . | Case ID | C103619406 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN is time synchronized | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (connected) | . | 2 | Wait 15 seconds. Do not send any UL or DL. | BLE connection still active BLE: 1 | . | 3 | Send DL packet from AWS IoT to EN via REST API | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 1, LINK_MODE: <x>, ACK_REQUESTED: <x>, ACK: <x>, DUP: <x>, RSSI: <x>, SNR: <x> Data: <payload> Key check: DL received on EN | . | 4 | Wait 30 seconds after DL received. Verify BLE is disconnected: sid last_status | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: BLE: 0 (disconnected after 30s) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconndscbv03-ble-connection-between-gateway-and-end-node-is-extended-by-downlink-packet-and-dropped-after-additional-30-seconds", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconndscbv03-ble-connection-between-gateway-and-end-node-is-extended-by-downlink-packet-and-dropped-after-additional-30-seconds" },"136": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/DSC/BV/06: End Node drops BLE connection after stopping Sidewalk library", "content": "| Field | Value | . | Case ID | C103619410 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (connected) | . | 2 | Stop Sidewalk: sid stop | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: Link_Mask: 0, BLE: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconndscbv06-end-node-drops-ble-connection-after-stopping-sidewalk-library", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconndscbv06-end-node-drops-ble-connection-after-stopping-sidewalk-library" },"137": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/DSC/BV/07: End Node drops BLE connection after deinitializing Sidewalk library", "content": "| Field | Value | . | Case ID | C103619411 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (connected) | . | 2 | Deinitialize Sidewalk: sid deinit | EVENT SID STATUS: State: 1, Reg: 0, Time: 1, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: Link_Mask: 0, BLE: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconndscbv07-end-node-drops-ble-connection-after-deinitializing-sidewalk-library", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconndscbv07-end-node-drops-ble-connection-after-deinitializing-sidewalk-library" },"138": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/BCN/BV/01: End Node transmits beacons only when BLE connection is not established", "content": "| Field | Value | . | Case ID | C103619407 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | BT sniffer is ready | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (connected) | . | 2 | While BLE connection is active, monitor BT sniffer for 10 seconds | No beacons captured by BT sniffer. Key check: Beacon is invisible when BLE connected | . | 3 | Wait for BLE to disconnect (idle 30s). Monitor BT sniffer for 10 seconds. | BLE disconnected: EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Beacons captured by BT sniffer. Key check: Beacon is visible after BLE disconnected | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnbcnbv01-end-node-transmits-beacons-only-when-ble-connection-is-not-established", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnbcnbv01-end-node-transmits-beacons-only-when-ble-connection-is-not-established" },"139": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/BCN/BV/02: End Node transmits beacons that contain Identifier (TX-ID) which changes every 15 minutes", "content": "| Field | Value | . | Case ID | C103619416 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack and wait for BLE disconnected: sid init 1 sid start | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: BLE disconnected | . | 2 | Use BLE sniffer to collect 2 TX-ID rotations (wait up to 20 min each): Monitor beacon TX-ID changes in application specific data | TX-ID rotates twice. Each rotation logged with elapsed time. Key check: TX-ID changes observed in beacon data | . | 3 | Verify TX-ID rotation interval is within 14~16 minutes | Rotation time: 840s~960s (14~16 min). Key check: TX-ID rotates every ~15 minutes per Sidewalk spec | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnbcnbv02-end-node-transmits-beacons-that-contain-identifier-tx-id-which-changes-every-15-minutes", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnbcnbv02-end-node-transmits-beacons-that-contain-identifier-tx-id-which-changes-every-15-minutes" },"140": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/BCN/BV/03: End Node transmits beacons with 160ms interval for the first 30 seconds after starting Sidewalk library", "content": "| Field | Value | . | Case ID | C103619408 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | GW is turned off | BT sniffer is ready | . Test Steps . | Step | Description | Expected Result | . | 1 | Power on device, catch beacons | Measure the time between beacons for 30 seconds. The mean interval should be around 160 ms. | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnbcnbv03-end-node-transmits-beacons-with-160ms-interval-for-the-first-30-seconds-after-starting-sidewalk-library", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnbcnbv03-end-node-transmits-beacons-with-160ms-interval-for-the-first-30-seconds-after-starting-sidewalk-library" },"141": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/CONN/BCN/BV/04: End Node transmits beacons with 1 s interval, 30 seconds after starting Sidewalk library", "content": "| Field | Value | . | Case ID | C103619409 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | GW is turned off | BT sniffer is ready | . Test Steps . | Step | Description | Expected Result | . | 1 | Power on device, wait 2 min, catch beacons | Measure the time between beacons for 30 seconds. The mean interval should be around 1000ms. | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnbcnbv04-end-node-transmits-beacons-with-1-s-interval-30-seconds-after-starting-sidewalk-library", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleenconnbcnbv04-end-node-transmits-beacons-with-1-s-interval-30-seconds-after-starting-sidewalk-library" },"142": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE-EP-CONN-DUP-BV/01: BLE connection is closed after Endpoint receives 10 packets with duplicate SEQ number within one minute (filter duplicates enabled)", "content": "| Field | Value | . | Case ID | C103619419 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | Duplicate filter enabled: sid option -d 0 | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (connected) | . | 2 | Send 1 DL packet from AWS IoT with SEQ number <seq> | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 1, LINK_MODE: <x>, ACK_REQUESTED: <x>, ACK: <x>, DUP: <x>, RSSI: <x>, SNR: <x> Data: <payload> Key check: DL received on EN | . | 3 | Send 10 DL packets with the same SEQ number as Step 2, all within 1 minute | BLE connection terminated after 10th duplicate DL received: [INFO]: BLE (Disconnected|DISCONNECTED) Key check: BLE disconnected | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-ble-ep-conn-dup-bv01-ble-connection-is-closed-after-endpoint-receives-10-packets-with-duplicate-seq-number-within-one-minute-filter-duplicates-enabled", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-ble-ep-conn-dup-bv01-ble-connection-is-closed-after-endpoint-receives-10-packets-with-duplicate-seq-number-within-one-minute-filter-duplicates-enabled" },"143": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE-EP-CONN-DUP-BV/02: BLE connection is closed after Endpoint receives 10 packets with various duplicate SEQ numbers within one minute (filter duplicates enabled)", "content": "| Field | Value | . | Case ID | C103619418 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | Duplicate filter enabled: sid option -d 0 | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (connected) | . | 2 | Send 3 DL packets with various SEQ numbers (e.g. SEQ=1, SEQ=2, SEQ=3) | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 1, ... Data: <payload> Key check: All 3 DL packets received on EN | . | 3 | Send within 1 minute: 3x DL with SEQ=1, 3x DL with SEQ=2, 4x DL with SEQ=3 | BLE connection terminated after 10th duplicate DL received: [INFO]: BLE (Disconnected|DISCONNECTED) Key check: BLE disconnected | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-ble-ep-conn-dup-bv02-ble-connection-is-closed-after-endpoint-receives-10-packets-with-various-duplicate-seq-numbers-within-one-minute-filter-duplicates-enabled", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-ble-ep-conn-dup-bv02-ble-connection-is-closed-after-endpoint-receives-10-packets-with-various-duplicate-seq-numbers-within-one-minute-filter-duplicates-enabled" },"144": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE-EP-CONN-DUP-BV/03: BLE connection is not closed after Endpoint receives 10 packets with duplicate SEQ number within one minute (filter duplicates disabled)", "content": "| Field | Value | . | Case ID | C103619420 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | Duplicate filter disabled: sid option -d 1 | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (connected) | . | 2 | Send 1 DL packet from AWS IoT with SEQ number <seq> | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 1, ... Data: <payload> Key check: DL received on EN | . | 3 | Send 10 DL packets with the same SEQ number as Step 2, all within 1 minute | BLE connection remains active after 10th duplicate DL received. Key check: BLE NOT disconnected | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-ble-ep-conn-dup-bv03-ble-connection-is-not-closed-after-endpoint-receives-10-packets-with-duplicate-seq-number-within-one-minute-filter-duplicates-disabled", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-ble-ep-conn-dup-bv03-ble-connection-is-not-closed-after-endpoint-receives-10-packets-with-duplicate-seq-number-within-one-minute-filter-duplicates-disabled" },"145": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE-EP-CONN-DUP-BV/04: BLE connection is not closed after Endpoint receives 10 packets with various duplicate SEQ numbers within one minute (filter duplicates disabled)", "content": "| Field | Value | . | Case ID | C103619421 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | Duplicate filter disabled: sid option -d 1 | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (connected) | . | 2 | Send 3 DL packets with various SEQ numbers (e.g. SEQ=1, SEQ=2, SEQ=3) | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 1, ... Data: <payload> Key check: All 3 DL packets received on EN | . | 3 | Send within 1 minute: 3x DL with SEQ=1, 3x DL with SEQ=2, 4x DL with SEQ=3 | BLE connection remains active after 10th duplicate DL received. Key check: BLE NOT disconnected | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-ble-ep-conn-dup-bv04-ble-connection-is-not-closed-after-endpoint-receives-10-packets-with-various-duplicate-seq-numbers-within-one-minute-filter-duplicates-disabled", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-ble-ep-conn-dup-bv04-ble-connection-is-not-closed-after-endpoint-receives-10-packets-with-various-duplicate-seq-numbers-within-one-minute-filter-duplicates-disabled" },"146": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE-EP-CONN-DUP-BV/05: BLE connection is not closed after 10 packets with duplicate SEQ number reach Endpoint, if not all of those packets are sent within one minute", "content": "| Field | Value | . | Case ID | C103619422 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | EN has time synchronized | Duplicate filter enabled: sid option -d 0 | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request: sid conn_req 1 | CMD: ERR: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE: 1 (connected) | . | 2 | Send 1 DL packet from AWS IoT with SEQ number <seq> | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 1, ... Data: <payload> Key check: DL received on EN | . | 3 | Send 10 DL packets with the same SEQ number as Step 2, with 7s interval between each (10th duplicate DL received more than 1 minute after 1st duplicate) | BLE connection remains active after 10th duplicate DL received. Key check: BLE NOT disconnected (packets spread over >1 minute) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-ble-ep-conn-dup-bv05-ble-connection-is-not-closed-after-10-packets-with-duplicate-seq-number-reach-endpoint-if-not-all-of-those-packets-are-sent-within-one-minute", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-ble-ep-conn-dup-bv05-ble-connection-is-not-closed-after-10-packets-with-duplicate-seq-number-reach-endpoint-if-not-all-of-those-packets-are-sent-within-one-minute" },"147": { "doc": "4. BLE Test Cases", "title": "Test Case ID: BLE/EN/NW-SYNC/TIME/BV/01: End Node completes the initial time sync procedure", "content": "| Field | Value | . | Case ID | C103619401 | . | Executable by Customer | Yes | . Preconditions . | GW is registered in Sidewalk network | EN is registered in Sidewalk network | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start Sidewalk, then wait for time sync: sid init 1 sid start | Each command returns: CMD: ERR: 0 Then wait for time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 Key check: Time: 0 (time synced) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleennw-synctimebv01-end-node-completes-the-initial-time-sync-procedure", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html#test-case-id-bleennw-synctimebv01-end-node-completes-the-initial-time-sync-procedure" },"148": { "doc": "4. BLE Test Cases", "title": "4. BLE Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/ble-test-cases.html" },"149": { "doc": "CES 2026", "title": "CES 2026 Partner Demos", "content": "Check out our partner demos at CES 2026 . | Partner | Description | Location | . | | See the Amazon Sidewalk protocol stack running on ESP32-C6 based Arduino Nesso N1 board, showcasing multi-link concurrency with BLE and Sub-GHz | Venetian, Level 4, Zeno 4805 | . | | See Nordic’s new “nRF Sidewalk EB” plug and play development board for Amazon Sidewalk, featuring nRF54 + LR1110 | Venetian Expo, Booth #52039 | . | | See the Silicon Labs Amazon Sidewalk Out-of-Box Demo showing how you can power up, connect, and experience Amazon Sidewalk performance in minutes | Venetian, Level 3, Toscana 3710 | . | | Discover demos featuring Amazon Sidewalk enabling Smart Asset Tracking, cold chain, and sensitive cargo plus Amazon Sidewalk Location Services | The Wynn Las Vegas, Bandol 1 Ballroom | . | | See Telink’s Amazon Sidewalk-enabled connectivity solution for IoT devices | Venetian Expo, Booth #51759 | . | | See TI’s CC2652R7 based Amazon Sidewalk IoT node in action with temperature sensor data delivered over Sidewalk, demonstrating the platform’s ability to extend connectivity for diverse smart applications beyond your home network | LVCC, North Hall meeting rooms - N115 | . ", "url": "/events/ces-2026.html#ces-2026-partner-demos", "relUrl": "/events/ces-2026.html#ces-2026-partner-demos" },"150": { "doc": "CES 2026", "title": "CES 2026", "content": " ", "url": "/events/ces-2026.html", "relUrl": "/events/ces-2026.html" },"151": { "doc": "3. Change History", "title": "Change History", "content": "| Version | Summary of Changes | . | Protocol Stack 1.0, Document Revision A | First release of Location Library Developer Guide. | . | Protocol Stack 1.0, Document Revision A.1 | Fix sid_location_status enum values. Add auto_link_pause_resume field. Add raw_gnss_data fields. Update example code with context field. | . ", "url": "/app-notes/location-library/change-history.html#change-history", "relUrl": "/app-notes/location-library/change-history.html#change-history" },"152": { "doc": "3. Change History", "title": "3. Change History", "content": " ", "url": "/app-notes/location-library/change-history.html", "relUrl": "/app-notes/location-library/change-history.html" },"153": { "doc": "16. Change History", "title": "16. Change History", "content": "| Version | Summary of Changes | . | Protocol Stack 1.0, Document Revision A | First release of specification. | . | Protocol Stack 1.0, Document Revision A.1 | Expanded Introduction section to provide background on tester roles.Corrected test case IDs to use slash separators.Layout changes to message sequence charts. | . | Protocol Stack 1.0, Document Revision A.2 | Add multi-link test cases. | . | Protocol Stack 1.0, Document Revision A.3 | Add file-transfer test cases. | . | Protocol Stack 1.0, Document Revision A.4 | Add PICS appendix. | . | Protocol Stack 1.0, Document Revision A.5 | Add endpoint metrics test cases. | . | Protocol Stack 1.0, Document Revision A.6 | Add endpoint capability test cases. | . | Protocol Stack 1.0, Document Revision A.7 | Add MAC address test cases. | . | Protocol Stack 1.0, Document Revision A.8 | Add location service E2E test cases. | . | Protocol Stack 1.0, Document Revision A.9 | Add location service MCU test cases. | . | Protocol Stack 1.0, Document Revision A.10 | Add power optimization test cases. | . | Protocol Stack 1.0, Document Revision A.11 | Add BLE connection policy test cases. | . ", "url": "/specifications/sidewalk-test-spec/change-history.html", "relUrl": "/specifications/sidewalk-test-spec/change-history.html" },"154": { "doc": "1. Change History", "title": "Change History", "content": "| Version | Date | Description | . | 1.0 | 2026-04-17 | Initial release | . ", "url": "/specifications/sidewalk-compliance-test-guide/change-history.html#change-history", "relUrl": "/specifications/sidewalk-compliance-test-guide/change-history.html#change-history" },"155": { "doc": "1. Change History", "title": "1. Change History", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/change-history.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/change-history.html" },"156": { "doc": "C Change History", "title": "Appendix C", "content": " ", "url": "/specifications/sidewalk-protocol-spec/glossary/change-history.html#appendix-c", "relUrl": "/specifications/sidewalk-protocol-spec/glossary/change-history.html#appendix-c" },"157": { "doc": "C Change History", "title": "Change History", "content": "| Version | Summary of Changes | . | Protocol Stack 1.0, Document Revision A | First release of specification. | . | Protocol Stack 1.0, Document Revision A.1 | Add Sidewalk File transfer. | . | Protocol Stack 1.0, Document Revision A.2 | Add Sidewalk metrics and capabilities. | . | Protocol Stack 1.0, Document Revision A.3 | Add LoRa Profile C specification for continuous RX mode. | . ", "url": "/specifications/sidewalk-protocol-spec/glossary/change-history.html#change-history", "relUrl": "/specifications/sidewalk-protocol-spec/glossary/change-history.html#change-history" },"158": { "doc": "C Change History", "title": "C Change History", "content": " ", "url": "/specifications/sidewalk-protocol-spec/glossary/change-history.html", "relUrl": "/specifications/sidewalk-protocol-spec/glossary/change-history.html" },"159": { "doc": "Change History", "title": "Change History", "content": "| Version | Summary of Changes | . | Amazon Sidewalk SID API Developer Guide, Revision A | First release of SID API Dev Guide. | . | Amazon Sidewalk SID API Developer Guide, Revision A.1 | Add Sidewalk File transfer and Multi-link feature support. | . | Amazon Sidewalk SID API Developer Guide, Revision A.2 | Add End Point Capability and Traffic throttling limit support. | . | Amazon Sidewalk SID API Developer Guide, Revision A.3 | Add LoRa Profile C documentation. Update SID_OPTION enum. Fix Location API documentation. Update BLE user config constraints. | . | Amazon Sidewalk SID API Developer Guide, Revision A.4 | Merge Location Library Developer Guide into main API Developer Guide. Add full location overview, usage guide, and examples. | . | Amazon Sidewalk SID API Developer Guide, Revision A.5 | Add registration over a wired link (SID_LINK_TYPE_8 and the serial registration API), factory-registered Endpoints and the lite build variants. Add LoRa data rate, higher-data-rate RX window interval, keep-alive payload and Gateway Session Key documentation. | . ", "url": "/sid-api-dg/change-history.html", "relUrl": "/sid-api-dg/change-history.html" },"160": { "doc": "6. Choosing a GSK Configuration", "title": "6. Choosing a GSK configuration", "content": "idle_timeout_sec — how long a lull do I need before interrupting my link is acceptable? . L = min( shortest routine gap between my sub-GHz messages, smallest effective keep-alive interval across my enabled sub-GHz links ) idle_timeout_sec <= 0.75 * L i.e. leave at least 25 % of L as margin . Figure 6.1: Sizing rule for `idle_timeout_sec`. The second term of L is easy to miss; read the effective keep-alive interval (§4). Count every uplink your product generates, including location resolve uplinks (sid_location, Amazon Sidewalk Location Library Developer Guide). app_ack_miss_threshold — how many unacknowledged ack-requested uplinks in a row before I stop trusting the session? Detection latency is N × K, where K is the shortest candidate cadence (Figure 6.2, Table 6.1). | Candidate term of K | Applies when | . | Your own request_ack = true cadence | You send ack-requested uplinks | . | The keep-alive interval | The link and profile arm one; see the Amazon Sidewalk Keep-Alive (KA) Application Note | . Table 6.1: Candidate terms of K, the ack-requested-uplink cadence. latency ~= N * K where N = app_ack_miss_threshold, K = the effective ack-requested-uplink cadence above . Figure 6.2: Worst-case desync detection latency. Treat that latency as an upper bound: in a real desync the keep-alive’s own teardown and rejoin usually resolves the session sooner (§2.2). idle_timeout_sec changes only where a disruption lands, never its cost (§2.1): a short window accepts one inside a traffic burst, a long window pushes it into a lull. If that latency is too slow, three levers shorten it, ordered by available room: . | Lower the keep-alive interval with SID_OPTION_DL_ROUTE_VALIDITY (19). Keep it above idle_timeout_sec, or no session establishes (§4). Prefer nwsync_time × 60 s ≥ 4/3 × idle_timeout_sec for the Figure 6.1 margin. | Send your own periodic ack-requested uplink. This lowers K directly, whatever currently sets it. | Lower app_ack_miss_threshold. The 3–10 bound makes it the smallest change available. | . retry_interval_sec — how long may the Endpoint run in non-GSK mode after a fallback? It trades recovery latency against repeated attempt cost (§3): take the 43200 s (12 h) minimum where establishment normally succeeds, and keep the 86400 s default on a SubG-CSS device at the fringe of MDR coverage, where each attempt that reaches MDR and then fails pays the switch to MDR and the re-initialization back to LDR (unless the application selected MDR, §2.1). Rule of thumb, and it differs by link. Set app_ack_miss_threshold from the cost of a false positive. On SubG-CSS where MDR is offered a false positive costs link-layer acknowledgement and retries until the next establishment retry (§3), and returns the link to LDR for that whole wait (unless the application selected MDR, §2.1), so bias toward 6 or higher. On SubG-FSK it costs at most one retry interval in non-GSK mode, with no PHY or throughput penalty, so 4 is defensible. 3 discards a good key on a short RF outage on either link. ", "url": "/app-notes/gateway-session-key/choosing-a-configuration.html#6-choosing-a-gsk-configuration", "relUrl": "/app-notes/gateway-session-key/choosing-a-configuration.html#6-choosing-a-gsk-configuration" },"161": { "doc": "6. Choosing a GSK Configuration", "title": "6. Choosing a GSK Configuration", "content": " ", "url": "/app-notes/gateway-session-key/choosing-a-configuration.html", "relUrl": "/app-notes/gateway-session-key/choosing-a-configuration.html" },"162": { "doc": "A Command List", "title": "A Command List", "content": " ", "url": "/specifications/sidewalk-protocol-spec/glossary/command-list.html", "relUrl": "/specifications/sidewalk-protocol-spec/glossary/command-list.html" },"163": { "doc": "A Command List", "title": "Appendix A", "content": " ", "url": "/specifications/sidewalk-protocol-spec/glossary/command-list.html#appendix-a", "relUrl": "/specifications/sidewalk-protocol-spec/glossary/command-list.html#appendix-a" },"164": { "doc": "A Command List", "title": "A.1 SubG-FSK Mode Connection Profile 2 Command List", "content": "| ABRV / Command Class / ID / OP Code / Source / Destination / Encryption | Information Content | . | JOIN-REQ 0x0 / 0x22F / 0x1 / End Device / Destination / SID_SEC_KEY_WAN_GCM_128 | JOIN-REQ message carries requested link characteristics for both uplink and downlink messaging expected on the end device.1. Uplink Link-Latency Characteristics: Describes the time interval between two uplink opportunities. The value is described in units of slot interval, i.e. 63 ms.2. Uplink Load Characteristics: Expected traffic rate for each uplink opportunity. The load is mapped to a range of values in interval [0-255], where 0 indicates lowest load and 255 indicates highest load of 1 packet per uplink opportunity.3. Downlink Link-Latency Characteristics: Describes the time interval between two downlink opportunities. The value is described in units of slot interval, i.e. 63 ms.4. Downlink Load Characteristics: Expected traffic rate for each DL opportunity. The load is mapped to a range of values in interval [0-255], where 0 indicates lowest load and 255 indicates highest load of 1 packet per downlink opportunity.5. GWID6. Link Allocation duration | . | JOIN-RESP 0x0 / 0x22F / 0x3 / GW / End Device / SID_SEC_KEY_WAN_JOIN_RESP_GCM_128 | JOIN-RESP message carries assigned schedule, i.e. A-UL and A-DL for the FSK-WAN-EN.1. Request Accepted/Rejected (If rejected no other information should be there)2. Uplink Schedule: Offset and Periodicity3. Uplink Contention Param: Sub-slot window size, Slot window size4. Downlink Schedule: Offset and Periodicity5. Link Allocation duration | . | AUTH-RESP 0xFF / 0xD / 0x1 / Cloud / GW / SID_SEC_KEY_WAN_GCM_128 | 1. A boolean accepting and rejecting the request2. JOIN-REQ contents:  a. R-TX-ID of the requesting Endpoint  b. UL3. Uplink Link-Latency Characteristics:  a. Uplink Load Characteristics  b. DL4. Downlink Link-Latency Characteristics5. Downlink Load Characteristics6. One time key to be used for downlink encryption/authentication7. Link Allocation duration8. SID_SEC_KEY_WAN_JOIN_RESP_GCM_128 key of the Endpoint | . Table A.1 Information content of the synchronous mode profile's connection establishment commands . ", "url": "/specifications/sidewalk-protocol-spec/glossary/command-list.html#a1-subg-fsk-mode-connection-profile-2-command-list", "relUrl": "/specifications/sidewalk-protocol-spec/glossary/command-list.html#a1-subg-fsk-mode-connection-profile-2-command-list" },"165": { "doc": "2. Common Test Cases", "title": "2. Common Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/common-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/common-test-cases.html" },"166": { "doc": "2. Common Test Cases", "title": "2.1 CMN/EP/API/INF/BV/01: Endpoint has correct MCU version after launching Sidewalk application.", "content": "2.1.1 Test Purpose . DUT is able to start Sidewalk application and capture all values related to the MCU version. Captured values are consistent with the MCU build used by the DUT. 2.1.2 Initial Conditions . | DUT is flashed with a valid MCU build. | . 2.1.3 Test Procedure . sequenceDiagram participant DUT as DUT participant Upper_Tester as Upper Tester Note over DUT,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_version() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: \"MAJOR_VERSION\", \"MINOR_VERSION\", \"PATCH_VERSION\", \"BUILD_VERSION\" . 2.1.4 Expected Results . 2.1.4.1 Pass Verdict . DUT can successfully start the Sidewalk application. DUT is able to utilize sid_version API call and capture the following values related to the MCU version: MAJOR_VERSION, MINOR_VERSION, PATCH_VERSION, BUILD_VERSION. All obtained values are in line with the MCU build that is flashed on the DUT. ", "url": "/specifications/sidewalk-test-spec/common-test-cases.html#21-cmnepapiinfbv01-endpoint-has-correct-mcu-version-after-launching-sidewalk-application", "relUrl": "/specifications/sidewalk-test-spec/common-test-cases.html#21-cmnepapiinfbv01-endpoint-has-correct-mcu-version-after-launching-sidewalk-application" },"167": { "doc": "6. Confirming the Region in Use", "title": "6 Confirming the region in use", "content": "Confirm, during bring-up in each target market, that each device operates on that market’s sub-GHz parameters: . | End device. The device reports its region in its device-information response. Read it back after setup to confirm the value was stored, then confirm after the next platform initialisation that the radio operates on the same region’s band (§4.2). A registered device with no stored region reports North America (§4.3). | Gateway. There is nothing to confirm on the gateway itself; it establishes its region automatically (§3). Confirm only that your target market is a supported country (§2.2). | . A provisioning request for an unsupported region fails with a not-supported error rather than taking effect (§4.4). ", "url": "/app-notes/internationalization/confirming-the-region-in-use.html#6-confirming-the-region-in-use", "relUrl": "/app-notes/internationalization/confirming-the-region-in-use.html#6-confirming-the-region-in-use" },"168": { "doc": "6. Confirming the Region in Use", "title": "6. Confirming the Region in Use", "content": " ", "url": "/app-notes/internationalization/confirming-the-region-in-use.html", "relUrl": "/app-notes/internationalization/confirming-the-region-in-use.html" },"169": { "doc": "5.6 Connection maintenance with network synchronization", "title": "5.6 Connection maintenance with network synchronization", "content": "Endpoints in a WAN network are not always connected to a Gateway that belongs to the same account. Endpoints may roam from one Gateway to another Gateway or lose the connection to it, and thus to the cloud. Therefore, Endpoints in the WAN network keep monitoring the connection with the cloud by sending synchronization requests to the cloud either periodically or sporadically in specific states. There are three types of synchronization requests, included in two application layer commands for network synchronization, . | Time management command described in section 3.2.2.1. | JOIN command described in section 3.2.2.2. | In the specified piggybacking state, uplink data is piggybacked with synchronization request TLV, described in network diagnostic data Format ID in section 5.1.2.2.3. When the cloud receives uplink data with this format ID, it replies JOIN command with type “Notify” to Endpoints as a synchronization response. This process is described in section 3.2.2.2. | . In any state, when Endpoints receive responses to the above commands, Endpoints will be set as synchronized for a certain period. See figure 5.82 - an Endpoint sends a synchronization request and a synchronization response is received. In this way, the Endpoints are able to know the status of connectivity with the network. This also ensures Endpoints are updating the routing table in the cloud, so that the cloud can deliver the downlink packet to the correct Gateway. When the network is detected as not synchronized, Endpoints working in SubG-FSK connection mode will trigger Beacon discovery, looking for a new Gateway to which a synchronization request can be sent. For Endpoints working in SubG-CSS connection mode, uplink might still be connected. Hence, Endpoints will stay in the piggybacking state, any uplink data in this state will be synchronization request, receiving a synchronization response can bring device back to synchronized. Based on the Endpoint’s connection profile setting, the behavior of network synchronization will be slightly different. For further information, see the following subsections. fig 5.82 Network synchronization . 5.6.1 Connection Profiles 1 and 2 . The behavior of time synchronization is the same for Connection Profiles 1 and 2. Periodic synchronization is activated for them. Endpoints are set as synchronized for 840 s when receiving a synchronization response and enter the piggybacking state at the halfway point of the synchronized period, 420 s. If no synchronization responses are received within the synchronized period, JOIN command described in section 3.2.2.2 is sent due to activation of periodic synchronization. Endpoints trigger Beacon discovery autonomously when they have failed to synchronize with the network. See figure 5.83. Endpoints may leave the piggybacking state earlier and are set as synchronized for another 840 s when receiving a synchronization response in the piggybacking state. See figure 5.84. fig 5.83 Profile 1 and 2 network synchronization . fig 5.84 Profile 1 and 2 synchronized in the piggybacking state . 5.6.2 Connection Profile A . To save energy, there is no periodic synchronization required for Profile A. Most of the time, Endpoints stay in the piggybacking state. When a synchronization response is received, Endpoints are set as synchronized for a period of 300 s. Endpoints enter the piggybacking state again at the halfway point of the synchronized period, 150 s. If no synchronization responses are received in the synchronized period, Endpoints are set as not synchronized and remain in the piggybacking state. See figure 5.85. Similar to Profiles 1 and 2, Endpoints leave the piggybacking state earlier and are set as synchronized for another 300 s when receiving a synchronization response in the piggybacking state. fig 5.85 Profile A network synchronization . 5.6.3 Connection Profile B . Periodic synchronization is activated for Profile B. As in Profile A, Endpoints are set as synchronized for 300 s when receiving a synchronization response and enter the piggybacking state at the halfway point of the synchronized period, 150 s. If no synchronization responses are received within the synchronized period, JOIN command described in section 3.2.2.2 is sent due to the activation of periodic synchronization. On failure of the first periodic synchronization, the Endpoints are set as not synchronized and periodic synchronization will be retried three times, then Endpoints stop it and stay in the piggybacking state. See figure 5.86. Same as Profile A, Endpoints leave the piggybacking state earlier and are set as synchronized for another 300 s when receiving a synchronization response in the piggybacking state. fig 5.86 Profile B network synchronization . 5.6.4 Connection Profile C . Profile C operates in continuous RX mode, providing the lowest downlink latency among all asynchronous profiles. To save energy, there is no periodic synchronization required for Profile C (same as Profile A). Most of the time, Endpoints stay in the piggybacking state. When a synchronization response is received, Endpoints are set as synchronized for a period of 300 s. Endpoints enter the piggybacking state again at the halfway point of the synchronized period, 150 s. If no synchronization responses are received in the synchronized period, Endpoints are set as not synchronized and remain in the piggybacking state. Profile C is characterized by: . | Continuous RX mode - the device stays in receive mode continuously | rx_window_count = 0xFF (SID_RX_WINDOW_CONTINUOUS) | dl_separation = 0 (SID_LINK3_RX_WINDOW_SEPARATION_CONTINUOUS) | No periodic network sync (same behavior as Profile A) | Highest power consumption among asynchronous profiles | Lowest downlink latency - immediate response to incoming messages | . This profile is suitable for line-powered devices that require minimal downlink latency and are not constrained by power consumption. Table 5.4 Profile C parameters . | Parameter | Value | Note | . | rx_window_count | 0xFF | continuous RX mode | . | dl_separation | 0 | continuous, no interval | . 5.6.5 Connection Profile D - Offline operation mode . The offline Gateway operation, Connection Profile D, is also called “Distress Gateway” mode. The Gateway that loses the direct internet connectivity to the cloud shall automatically switch to Distress Gateway mode. The Gateway shall establish Amazon Sidewalk Cloud connectivity through another Gateway using LoRa modulation. Gateways that provide connection to the Distress Gateway are called assisting Gateways. When the link is recovered then the Gateway switches to a normal operation state automatically. During the distress mode of operation, the Distress Gateway may send Beacons periodically but this is dependent on the initial operation mode: . | multirate mode - the Gateway sends a Beacon periodically; | SubG-FSK-only mode - the Gateway sends a Beacon periodically; | SubG-CSS-only mode - the Gateway does not send a Beacon periodically. | . The Gateway notifies the cloud that the link is lost using a distress message. The message is sent frequently with different time intervals between two consecutive messages. The first interval has minimum value min_dis_mess_int and increases exponentially for subsequent distress messages up to max_dis_mess_int. When an ACK is received from the cloud, the Gateway continues sending the message with the maximum defined interval max_dis_mess_int. When ACK is not received and the maximum defined time interval between two consecutive messages is reached then the Gateway shall reset the interval to min_dis_mess_int and repeat the exponential increase of the interval between distress messages up to max_dis_mess_int. The Distress Gateway has two ways to communicate with the cloud: . | common channel - this shall be used for sporadic message exchange. | dedicated link over separate channel - this method uses a different channel from a common one for bulky data transfer - e.g. file transfer. The Gateway shall start distress mode using the common channel and may optionally switch to a dedicated channel with a message from the Amazon Sidewalk Cloud over the common channel. The channel selection and criteria for switching to a dedicated channel is controlled by the cloud. The assisting Gateway which handles the connection over a dedicated link cannot support traffic from other SubG-CSS devices but is still able to support SubG-FSK Endpoints. | . The transmission between two Gateways, the Distress Gateway and the assisting Gateway, is fully asynchronous in both uplink and downlink directions. This is the only difference when compared to the communication scheme between a SubG-CSS Endpoint and a Gateway where downlink is synchronized based on the uplink Epoch frame. The Epoch frames are not used in distress mode communication between Gateways. Additionally, a long preamble is used in both directions for downlink and uplink on the PHY Layer. ", "url": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/connection-maintenance-with-network-synchronization.html", "relUrl": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/connection-maintenance-with-network-synchronization.html" },"170": { "doc": "3. Gateway Discovery Control Events", "title": "3. Gateway Discovery Control Events", "content": "To notify the developer about major events related to Gateway Discovery, the Amazon Sidewalk stack uses the SID_CONTROL_EVENT_LINK2_GW_DISCOVERY_STATUS control event. The event_data member contains information about the event. By subscribing to control events, the developer will be notified of a gateway discovery timeout, as well as of a synchronization event or beacon loss. For example, in the case of a gateway discovery timeout, the developer can change the policy and retry discovery. The following GW Discovery events are supported. /** * The set of control events that are notified to the developer. * @see on_control_event_notify in #sid_event_callbacks. */ enum sid_control_event_type { /** Event indicating change in low latency * configuration for #SID_LINK_TYPE_3 */ SID_CONTROL_EVENT_LOW_LATENCY_CONFIG_UPDATE = 0, /** Event indicating the device exceeded the traffic thresholds */ SID_CONTROL_EVENT_TRAFFIC_THRESHOLD_RATE_EXCEEDED = 1, /** Indicating gateway discovery status events. * The event_data contains information about the event. * See enum sid_link_type_2_gw_discovery_event for details */ SID_CONTROL_EVENT_LINK2_GW_DISCOVERY_STATUS = 2, /** Delimiter to enum sid_control_event_type */ SID_CONTROL_EVENT_LAST, }; /** * Describes the LINK2 GW Discovery events. * These events are notified to the developer through network control events */ enum sid_link_type_2_gw_discovery_event { /** Event indicating gateway under the * selected discovered policy is not found */ SID_LINK_TYPE_2_GW_DISCOVERY_EVENT_DISC_FAILED = 0, /** Event indicating the gateway is selected and beacon sync is done */ SID_LINK_TYPE_2_GW_DISCOVERY_EVENT_BEACON_SYNC = 1, /** Event indicating the beacon sync was lost with the selected gateway */ SID_LINK_TYPE_2_GW_DISCOVERY_EVENT_BEACON_SYNC_LOST = 2, }; . The following code example shows how to implement a user callback on_sidewalk_control_event() to handle network control events. // Callback to invoke when the Sidewalk library notifies network control event static void on_sidewalk_control_event( const struct sid_control_event_data *data, void *context) { if (data->event_type == SID_CONTROL_EVENT_LINK2_GW_DISCOVERY_STATUS) { enum sid_link_type_2_gw_discovery_event *discovery_event = data->event_data; switch (*discovery_event) { case SID_LINK_TYPE_2_GW_DISCOVERY_EVENT_DISC_FAILED: { // An event indicating that a gateway was not found // within the scanning timeout break; } case SID_LINK_TYPE_2_GW_DISCOVERY_EVENT_BEACON_SYNC: { // The beacon sync was done with the selected gateway break; } case SID_LINK_TYPE_2_GW_DISCOVERY_EVENT_BEACON_SYNC_LOST: { // The beacon sync was lost break; } } } } // The set of user callbacks struct sid_event_callbacks event_callbacks = { .context = &g_app_context, .on_event = on_sidewalk_event, .on_msg_received = on_sidewalk_msg_received, .on_msg_sent = on_sidewalk_msg_sent, .on_send_error = on_sidewalk_send_error, .on_status_changed = on_sidewalk_status_changed, .on_factory_reset = on_sidewalk_factory_reset, // Pass our callback to Sidewalk library .on_control_event_notify = on_sidewalk_control_event, }; // The characteristics of the end device struct sid_end_device_characteristics dev_ch = { .type = SID_END_DEVICE_TYPE_STATIC, .power_type = SID_END_DEVICE_POWERED_BY_BATTERY_AND_LINE_POWER, .qualification_id = 0x0001, }; struct sid_config config = { .link_mask = SID_LINK_TYPE_2, .dev_ch = dev_ch, .callbacks = &event_callbacks, .link_config = app_get_ble_config(), .sub_ghz_link_config = app_get_sub_ghz_config(), // update sub GHz config }; static struct sid_handle *sidewalk_handle = NULL; sid_error_t ret = sid_init(config, &sidewalk_handle); . ", "url": "/app-notes/gateway-discovery-selection/control-events.html", "relUrl": "/app-notes/gateway-discovery-selection/control-events.html" },"171": { "doc": "7.2 Design Architecture", "title": "7.2 Design Architecture", "content": "The following chapter provides details about the design architecture, data flows, and specific mechanisms of the SBDT feature. 7.2.1 Sidewalk Data Transfer Supported Flows . A successful file transfer (for the purpose of OTA or generic file) requires complex coordination between devices, device firmware, network connectivity, and cloud. The file transfer architecture is chosen to ensure that devices receive the latest file/updates more efficiently and that the process saves both time and processing effort and needs to be scalable to handle fleets of devices. The architecture also depends on the devices themselves (WAN vs PAN, internal policies) and the availability of the gateways as that dictates the file transfer/OTA flow that can be used to efficiently deliver the updates to the device. Our approach emphasizes file integrity, safeguarding against image corruption end-to-end during file transfer. The architecture’s flexibility is evident in features like real-time transfer status monitoring, allowing users to track and confirm successful updates. Additionally, the capability to schedule file transfers at a predetermined time optimizes network usage. The diagram below demonstrates the current support flow of Sidewalk bulk data transfer by using the cloud driven flow over the Sidewalk BLE connectivity. The current flows doesn’t require any Sidewalk Gateway involvement as it is treated as pass through. fig 7.1 End to End Architecture for SBDT . 7.2.2 Messaging . The end to end feature uses a combination of application layer and network layer messaging to deliver the file from the developer application to the end device. All the down link and uplink messages are encrypted and sent uni-cast to each device. The application layer messages are control and handshake messages between the application server and the device and the network layer messages are the data transport messages in the Sidewalk file transfer between the network server and the device. 7.2.3 File Transfer Delivery Mechanisms . The (SBDT) feature incorporates a file transfer protocol designed to handle down link file transfers between cloud device and end nodes on the Sidewalk network. The file transfer is initiated by the developer’s application when it uploads the File into an S3 bucket and starts a File transfer session through the application server using the AWS IoT FUOTA APIs. Cloud-to-device transfer are initiated through a File Updates Over The Air (FUOTA) task API, triggered by the cloud application service. 7.2.3.1 Cloud Driven Delivery . For this mechanism, files are delivered to reachable devices as soon as they are uploaded and triggered from AWS IoT Core for Amazon Sidewalk. The cloud immediately attempts to transfer files to target devices that are available at the time of release and devices that are constrained like performing critical activities, low on battery, flash and RAM limited will receive the files the next time they become available. This allows us to deliver to targeted reachable devices and at the same time avoid disrupting active devices. ", "url": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/design-architecture.html", "relUrl": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/design-architecture.html" },"172": { "doc": "6. Device Firmware Integration", "title": "6. Device Firmware Integration", "content": "The reference integration is the sid_diagnostics application. Where it does not exist for your platform, this chapter is the porting contract. A port is typically one source file of 200 to 350 lines, plus build system changes. Section 6.1 is for the engineer who adds ROW to a Factory Diagnostic Firmware. If an image with ROW support already exists for your platform, go straight to Section 6.2, which applies to every product. The firmware reaches the line PC over one host interface, which is selected when the image is built: UART, or SEGGER RTT through a J-Link debug probe. Both interfaces carry the same wire protocol (Section 6.1.2), and the tool handles both in the same way. The reference application builds one image per host interface, and the RTT image is the default where both exist. ", "url": "/app-notes/registration-over-wire/device-firmware-integration.html", "relUrl": "/app-notes/registration-over-wire/device-firmware-integration.html" },"173": { "doc": "6. Device Firmware Integration", "title": "6.1 Factory Diagnostic Firmware", "content": "The Factory Diagnostic Firmware runs ROW on the factory line (Chapter 5). It is flashed first, and is replaced by the production firmware after registration. 6.1.1 Feature macros and libraries . Define the following for the Factory Diagnostic Firmware image: . # Compiles in the `register ...` CLI commands (default off); the stack itself is the three libraries linked below target_compile_definitions(sid_on_dev_cert_cli PRIVATE SID_SDK_INTERNAL_CONFIG_ENABLE_SERIAL_REGISTRATION=1) target_link_libraries(<your_app> PRIVATE sid_serial_registration sid_network_link_wired_ifc sid_network_link_wired) . 6.1.2 Wire protocol . The host interface is one byte stream in each direction. On UART it is a serial port at 115200 baud, 8N1, no flow control. On RTT it is channel 0, the terminal channel, of the SEGGER RTT control block; no second RTT channel is used. In both cases the stream carries two kinds of traffic, which are separated on the first byte of each unit: . | Text CLI. ASCII command lines (cert ..., register ...) terminated by \\r or \\n. The device answers them in text: {CERT ...} and {REGISTRATION ...} status lines. The cert ... commands are the same Factory Diagnostic Firmware certificate commands used in the existing mass production flow. | Binary frames. The format is identical in both directions: 0xAA | LEN (1 byte) | payload, with a payload of at most 255 bytes. The wired link MTU of 184 bytes keeps traffic within this limit. A host-to-device frame with a 1-byte payload is the registration-complete indication, and is consumed by the SDK. Payloads are opaque encrypted messages: the firmware only frames and deframes them. | . Console output of the firmware, such as the CLI prompt, the command echo and log lines, may share the stream with this traffic. The tool treats every byte that is not part of a frame as console text. Console text must therefore be 7-bit ASCII, so that the sync byte 0xAA never occurs in it, and a frame must be written as one unit, so that no console output is inserted into it. The framing is version-paired with the tool. Earlier releases used a 2-byte host-to-device length field. If the versions do not match, the tool and the device cannot communicate. 6.1.3 Serial interface callbacks . Implement all four callbacks of struct serial_ifc_context (sid_serial_ifc.h). The callbacks are called from task context. | Callback | Contract | . | serial_init | One-time initialization of the host interface (UART or RTT) and of the demultiplexer. It is called by sid_on_dev_cert_serial_registration_init() when the transport is registered, and must be idempotent | . | serial_read | Non-blocking. Returns one complete deframed payload, or zero bytes. It must never return a partial frame | . | serial_write | Emits 0xAA, the 1-byte length and the payload as one unit. It must reject a length greater than 255 | . | serial_mfg_data_write | Same as serial_write, preceded by a pacing delay of approximately 10 ms on UART. On RTT the delay is optional | . The receive demultiplexer must behave as follows: . | Accumulate CLI text only while waiting for the sync byte (0xAA). | Inside a frame, treat every byte as part of the frame. | Validate the length (0 < len ≤ buffer size). On an invalid length, drop the frame and return to waiting for the sync byte. | Hand completed CLI lines to the CLI runtime from the main loop, never from interrupt context. The reference backends either feed the demultiplexed text to the runtime through stdio, where sid_cli_process() reads and dispatches it, or pass each completed line to the CLI runtime directly from the main loop. | . 6.1.4 Integration and lifecycle . sid_cli_init(); /* CLI runtime, required */ sid_diagnostics_cli_init(); /* reference diagnostics commands, optional */ sid_on_dev_cert_cli_init(); /* cert ... commands, required */ sid_on_dev_cert_serial_registration_init(&serial_ifc); /* register ... commands and the transport; calls serial_init() */ for (;;) { /* flush platform logs */ sid_serial_registration_process(); /* no-op until the host starts registration */ sid_cli_process(); /* dispatches the command lines received on the host interface */ } . sid_cli_init() and sid_cli_process() are required: the command lines the tool sends arrive through the host interface backend (UART or RTT) and are handed to the CLI runtime as described in Section 6.1.3, and sid_cli_process() runs the CLI runtime and its event queue. sid_on_dev_cert_cli_init() registers the cert command set, and sid_on_dev_cert_serial_registration_init() registers the register command set together with the serial transport. sid_diagnostics_cli_init() adds the reference diagnostics commands and is optional. | The host tool drives the lifecycle. The tool sends register start and, at security-level-low, register commit_keys. Do not call sid_serial_registration_init() or sid_serial_registration_start() from application code. register start already calls them, and a second initialization fails with SID_ERROR_ALREADY_INITIALIZED. | Completion. The host tool determines completion from the Amazon Sidewalk cloud and sends the registration-complete indication (Section 6.1.2). The firmware needs no completion logic of its own; register get_state prints the device state for debugging. | Retry. A failed attempt leaves the stack initialized. Reset the device before retrying device register. | . The following rules apply: . | Exactly one reader owns the receive side of the host interface, and it feeds the demultiplexer. Console output and command echo may share the interface with the frames (Section 6.1.2), but the interface must pass bytes unchanged: disable LF-to-CRLF conversion and every other translation, keep console text to 7-bit ASCII, and write each frame as one unit so that no log line is inserted into it. | Process CLI commands outside interrupt context. | Never run ROW while the Sidewalk radio stack is started (sid_init and sid_start). | Size the buffers for the payload plus 2 framing bytes. | . 6.1.5 Bring-up steps . Bring up the integration in the following order. Each step isolates one layer. | Send help from a terminal program: a serial terminal on the port (115200 baud, 8N1) for a UART image, or J-Link RTT Viewer on channel 0 for an RTT image. The response appears in the same terminal. This verifies the receive path of the host interface and the CLI demultiplexer. Close the terminal program before running the tool, because a serial port has one reader and a J-Link probe serves one host program at a time. | Run device provision .... The first commands, cert init and cert smsn, are text round trips: the device answers {CERT OK} (preceded by the informational {CERT BASE64_MTU=32}), then the SMSN as {CERT <base64>} fragments followed by {CERT OK}. This verifies the CLI path in both directions. The following cert csr and the chunked cert chain write and cert app_key write commands verify the cryptography and the host-to-device text path. The tool errors identify the failing layer: <command>: no {CERT OK} / {CERT ERROR} within <N>s means that no reply reached the tool on the host interface it reads (the console output of the image goes to another interface, the image lacks the cert commands, or a second program reads the same port or probe), and device answered with a <N>-byte binary frame instead of {CERT ...} text means the firmware image predates the text replies. | Run device register. The device answers register start with {REGISTRATION STARTED} and then sends the first 0xAA frames. This verifies the binary framing in both directions, the encrypted handshake and the registration-complete indication. UART: no sync byte (0xAA) within <N>s or RTT: no complete frame within <N>s means that the device sent no frame: the image has no ROW support, or serial_write writes to another interface. UART: read timed out after <N> bytes still pending or RTT: no complete frame within <N>s; incomplete frame, <N> byte(s) still pending means that a frame started but did not complete, which indicates a transmit framing or length problem. | Run device onboard end to end. The tool reports Device registered over the wire. | Send help again. This detects demultiplexer ownership defects that appear only after binary traffic. | . 6.1.6 UART and RTT backends . The reference application implements the callbacks of Section 6.1.3 in one backend per host interface, selected when the image is built (see the table at the start of this chapter). Both backends implement the wire protocol of Section 6.1.2 without change. | UART backend. One UART at 115200 baud, 8N1, no flow control, carries the frames and the console. The receive path feeds every received byte to the demultiplexer: frame bytes go to the ROW buffer, every other byte to the CLI. Automatic LF-to-CRLF conversion on the port is disabled, because it would alter frame bytes. The console output of the image uses the same port, so prompt, echo and replies are visible on the wire. The backend owns the UART; no other function of the image may use it. | RTT backend. SEGGER RTT channel 0, the terminal channel, carries the frames and the console. No second channel is configured, so the RTT configuration of the image does not change. The line PC reads and writes the channel through the J-Link probe over the debug port, so the backend claims no UART and leaves it available to other functions of the image. The receive path drains channel 0 in the main loop: frame bytes go to the ROW buffer, every other byte to a console ring from which the CLI reads through stdio. Bytes stay in the RTT down buffer while a frame is pending or the ring is full, so nothing is lost. A frame is written under the RTT lock, whole or not at all, with a retry of up to 200 ms for the host to drain the up buffer; a short write is reported as a failure, so that a log line from another context cannot be inserted into a frame. The RTT down buffer is small (16 bytes in the reference configuration), and the tool writes command lines and frames in pieces as the device drains it. The main loop must therefore run often enough to drain the buffer: the tool waits at most 2 seconds for the device to accept a write. | . ", "url": "/app-notes/registration-over-wire/device-firmware-integration.html#61-factory-diagnostic-firmware", "relUrl": "/app-notes/registration-over-wire/device-firmware-integration.html#61-factory-diagnostic-firmware" },"174": { "doc": "6. Device Firmware Integration", "title": "6.2 Production firmware", "content": "The production firmware is the image the device ships with. It contains no ROW or serial registration support. It runs the device as a factory-registered Sidewalk endpoint, including field activation and credential handling. 6.2.1 Feature macros . A factory-registered production image exists in two configurations, one per security level (Section 7.1). Both set SID_SDK_INTERNAL_CONFIG_IS_FACTORY_REGISTERED=1. They differ in the SDK variant, the advertised security level and the tool setting the device must be registered with. Choose one column and use it for both the firmware and the tool. The SDK variants themselves are described in the Amazon Sidewalk SID API Developer Guide, Section 2.15 (Reference 7). This section lists only the settings that ROW adds or constrains. | Setting | Lite build (security-level-low) | Full build (security-level-high) | . | SDK variant | Lite, single link: sid_api_ble.c, sid_api_fsk.c or sid_api_lora.c | Full, multi-link: sid_api.c | . | Reference build (sid_dut) | BUILD_SID_SDK_LINK_TYPE=BLE_LITE, FSK_LITE or LORA_LITE (sets every macro below) | BUILD_SID_SDK_LINK_TYPE=DEFAULT, BLE, FSK, BLE_FSK, BLE_LORA or FSK_LORA, plus BUILD_FACTORY_REGISTERED=1 | . | CMake variant selector (own build system) | set(SID_SDK_CONFIG_BUILD_BLE_ONLY ON), _FSK_ONLY or _LORA_ONLY, before include(sid_common.cmake) | None. The default compiles sid_api.c | . | SID_SDK_CONFIG_ENABLE_LINK_TYPE_1/2/3 | 1 for the single link, 0 for the other two | 1 for each link the product uses | . | SID_SDK_INTERNAL_CONFIG_IS_FACTORY_REGISTERED | 1 | 1 | . | SID_SDK_CONFIG_SECURITY_LEVEL | SID_SDK_CONFIG_SECURITY_LEVEL_LOW | Default (SID_SDK_CONFIG_SECURITY_LEVEL_HIGH) | . | SID_SDK_INTERNAL_CONFIG_ENABLE_GSK | 0 | Default (1) | . | SID_SDK_INTERNAL_CONFIG_ENABLE_CAPABILITIES_LITE_FRAMEWORK, SID_SDK_INTERNAL_CONFIG_ENABLE_METRICS_LITE_FRAMEWORK | 1 | Not set | . | Link-specific settings | FSK: SID_SDK_CONFIG_ENABLE_LINK_TYPE_2_REGISTRATION=0 (removes the Sidewalk FFS registration path over FSK). LoRa: SID_SDK_ENABLE_LORA_BUILD=1 (bypasses the LoRa-only build assertion) | None | . | Tool security_level (Chapter 4) | low: register commit_keys is sent, and the credentials are also written to the manufacturing page | high (default): commit_keys is skipped, and the credentials are stored in the KV store only | . SID_SDK_INTERNAL_CONFIG_IS_FACTORY_REGISTERED enables the handling of factory-registered devices in the SDK. The FSK and LoRa links prompt the Amazon Sidewalk cloud for field activation, a LoRa-only device is allowed to start while factory-registered, and the build check that otherwise requires an over-the-air registration path is relaxed. Without this macro, a factory-registered device never performs field activation. SID_SDK_CONFIG_SECURITY_LEVEL only sets the security level bit in the endpoint capability notification. The security-level-low behavior itself is built into the lite sid_api variant and is absent from the full variant. That behavior consists of restoring the manufacturing page credentials into the KV store at boot and carrying the live key across a factory reset. For this reason, the lite variant must advertise LOW and the full variant must advertise HIGH. No serial registration macro belongs in the production image. Register every device with the tool setting that matches its production firmware: . | A lite image registered at security-level-high never comes up registered. The boot-time restore finds no manufacturing page copy, and the lite variant has no over-the-air registration path. | A full image registered at security-level-low receives a manufacturing page copy that it never reads. | . 6.2.2 Storage layout continuity . Registration credentials are stored according to the build-time flash configuration. The Factory Diagnostic Firmware and the production firmware must use a compatible layout: . | Always match the manufacturing page flash address. | At security-level-high, also match the KV region (address and size) and the Sidewalk KV group IDs (SID_PAL_STORAGE_KV_INTERNAL_*_GROUP_ID overrides). At security-level-low, the boot-time restore populates the KV layout of the production build. | . A mismatch is not detected at the factory. It appears in the field as an unregistered device. Verify each production firmware release by flashing it onto a factory-registered bench unit and confirming field activation. Lite SDK variants exclude the registration stack. On these variants, sid_init fails with SID_ERROR_NOSUPPORT unless the device is registered or factory-registered. ", "url": "/app-notes/registration-over-wire/device-firmware-integration.html#62-production-firmware", "relUrl": "/app-notes/registration-over-wire/device-firmware-integration.html#62-production-firmware" },"175": { "doc": "2. Device Profiles", "title": "2. Device Profiles", "content": " ", "url": "/app-notes/sub-ghz-device-profile/device-profiles.html", "relUrl": "/app-notes/sub-ghz-device-profile/device-profiles.html" },"176": { "doc": "2. Device Profiles", "title": "2.1 Introduction", "content": "Amazon Sidewalk creates a low-bandwidth wireless network with the help of Amazon Sidewalk Gateway devices including select Echo and Ring devices. There are three main components to Amazon Sidewalk - Endpoints, Gateways and the Amazon Sidewalk Cloud. Gateway devices act as bridges and connect to Endpoints on one side and to the Amazon Sidewalk Cloud on the other, thus providing an end-to-end path. Endpoints which are sensor devices, such as a mailbox sensor, a tracker, a smoke detector or a motion detector connect over wireless channels to the Gateways. The Amazon Sidewalk Sub-GHz Protocol is a proprietary protocol developed by Amazon that enables message exchange between Gateways and Endpoints over the Sub-GHz channel. The protocol offers two different modes of communication - SubG-CSS (asynchronous) and SubG-FSK (synchronous). IoT applications are sensitive to the following parameters: range, data rate, reliability, power consumption, mobility, latency and reachability. The Amazon Sidewalk protocol offers IoT application developers the flexibility to configure an Amazon Sidewalk profile through power, mobility and reachability parameters according to their application needs. To this end, we have introduced the concept of profiles. A profile in the Amazon Sidewalk protocol context is a configuration in the protocol that lets developers choose the best fit power, mobility, latency, and reachability settings for their application. Profiles are applicable only to Endpoints. Let us explore three IoT applications to understand the relationship between power, mobility, reachability and latency: . | Mailbox Sensor: A mailbox sensor is a device that will notify the owner when mail arrives in their mailbox. The sensor sends the notification as an uplink message over Amazon Sidewalk to the application residing on the cloud. The mailbox sensor may send its health metric once in 24 hours. Almost all of the data exchanged for this use case originates from the sensor device and terminates at the application logic on the cloud. The use case does not have strict downlink (DL) constraints, as data from the application on the cloud to the application on the device is extremely rare. These devices are typically powered by AAA batteries and hence need to be extremely power-efficient. | Car Tracker: A car tracker is a device that keeps the owner updated about the status of their car. Users are alerted if their car is bumped, or door movement occurs. Users will have the option to turn on live tracking through their application to get real time updates about the vehicle’s location. Upon an alert of possible intrusion, a user may be able to activate the camera (if available) on the tracker to capture a picture or turn on video recording. While the device should be able to immediately send the uplink data upon an event, it should also be able to receive a downlink command in real time and perform any necessary action. These devices also need to be power-efficient. | Delivery Truck Tracker: A delivery truck tracker is a device that keeps the owner updated about the whereabouts of the truck and the delivery points the truck has visited. It differs from the car tracker due to the fact that a delivery truck is required to stop at specific delivery locations along its journey. The owner is alerted every time the truck stops at a delivery point. If necessary, the owner can turn on live tracking through their application to get real time updates about the truck’s location. While the sensor device should be able to immediately send the uplink data upon an event, it should also be able to receive a downlink command in real time and perform necessary action. | . See more examples in the Appendix. The following section describes in detail the profiles offered in the Amazon Sidewalk protocol for both synchronous (SubG-FSK) and asynchronous (SubG-CSS) modes of operation. ", "url": "/app-notes/sub-ghz-device-profile/device-profiles.html#21-introduction", "relUrl": "/app-notes/sub-ghz-device-profile/device-profiles.html#21-introduction" },"177": { "doc": "2. Device Profiles", "title": "2.2 Device Profile Definitions", "content": "2.2.1 Asynchronous Mode (SubG-CSS) . Asynchronous connection mode allows devices to connect to the network using the ALOHA channel access protocol. A frame can be transmitted by an Endpoint when needed without the need to synchronize with a Gateway. | Device Profile A: An Endpoint operating in Profile A is characterized by limited reachability from the Amazon Sidewalk Cloud since it opens a limited number of RX (receive) windows separated by 5 s, after the device has sent an uplink packet. This profile is best suited to devices that have strict power budget and sporadic uplink data requirements. Uplink is triggered when the application on the Endpoint wants to send data to the application hosted on the cloud. Following the uplink transmission, the Endpoint opens up a configured number of receive windows separated by 5 s. These windows are receive opportunities for downlink data from the application logic on the cloud in response to the uplink. Attributes: limited downlink reachability, Very low power consumption e.g.: mailbox sensor, water leak detector, smoke detector . Device Profile A . | Device Profile B: This profile is suited to Endpoint devices that have strict downlink reachability requirements as opposed to Profile A Endpoints. These Endpoints are less constrained by power. The device opens up continuous RX windows for possible downlink data from the application logic residing on the cloud every 5 s. Endpoints operating in this profile perform a network sync procedure every 5 min, to advertise their presence to the Amazon Sidewalk Cloud. Attributes: downlink reachable every 5 s, higher power consumption due to continuous RX wake-ups - e.g.: car tracker, motion detector . Device Profile B . | . 2.2.2 Synchronous Mode (SubG-FSK) . Endpoints working in synchronous connection mode shall be synchronized with a Gateway before an uplink or downlink transmission is performed. Synchronization is achieved through the process of discovering Beacon frames sent by the Gateways. | Device Profile 1: This profile is best suited to moving Endpoints such as a delivery truck tracker or an elderly person tracker that keeps switching Gateways. This is the default profile of operation for a device operating in synchronous mode (SubG-FSK). The device automatically establishes an ad hoc mode of communication after discovering a Beacon from a nearby Gateway. In this Profile, there are a limited number of CS-UL (Common Slot UL) and CS-DL (Common Slot DL) slots defined in one Beacon interval (10.08 s), for uplink and downlink transmissions respectively. The Gateway makes the choice of the CS-UL slots and the CS-DL slots. The Endpoint does not have control over the choice of slots and will adhere to the slots chosen by the Gateway. The device decodes every Beacon from the Gateway to keep track of the ad hoc slots for that Beacon interval (10.08 s). Due to the nature of the profile, the Endpoint can go to power save mode for most of the Beacon interval. Attributes: high downlink latency, high uplink latency, low power consumption - e.g.: delivery truck tracker . Device Profile 1 . | Device Profile 2: This profile is suitable for Endpoints that have strict uplink and downlink latency requirements. Endpoints that are not mobile, resulting in a long period of association with a particular Gateway, should choose this profile. In this profile, the Endpoint negotiates for DL and UL allocation from the Gateway based on the application needs, thus ensuring that latency requirements are met. Based on the negotiation with the Gateway, the Endpoint can operate at a higher power consumption with lower latency or lower power consumption with higher latency. The timing diagram below shows the Rx latency configured to 5 slots = 63*5 ms = 315 ms. The Rx latency can be configured from 1 slot (= 63 ms) up to 80 slots (=5040 ms). Attributes: suited to static Endpoints - Endpoint negotiation with Gateway can ensure low power consumption - e.g.: mailbox sensor, smoke detector, water leak sensor . Device Profile 2 . | . 2.2.3 Dynamic Profile Switching . | For asynchronous (SubG-CSS) profiles, the Amazon Sidewalk protocol allows dynamic profile switching between Profile A and Profile B. | For synchronous (SubG-FSK) profiles, the Amazon Sidewalk protocol allows dynamic profile switching Profile 1 to Profile 2. | . Dynamic profile switching applies only after JOIN responses are received, and the change of profile will be persistent, that is, the switched profile remains after device reboot. ", "url": "/app-notes/sub-ghz-device-profile/device-profiles.html#22-device-profile-definitions", "relUrl": "/app-notes/sub-ghz-device-profile/device-profiles.html#22-device-profile-definitions" },"178": { "doc": "2. Device Profiles", "title": "2.3 SID API", "content": "The sid_option API call is used to change the device profiles. sid_error_t sid_option(struct sid_handle h, enum sid_option option, void *data, size_t len) . The sid_option takes the following input parameters: . | h is the IOCTL handle returned by the call to function sid_init() at the time of Amazon Sidewalk initialization by the application | option takes the value SID_OPTION_900MHZ_SET_DEVICE_PROFILE (=1) | *data is a pointer to type sid_device_profile | . The data and len parameters have the following values: . | data->unicast_params.device_profile_id is the profile ID of type sid_device_profile_id | data->unicast_params.rx_window_count is of type sid_rx_window_count Note: For SID_LINK2_PROFILE_1 device there is no effect of rx_window and may be defaulted to 0 | data->unicast_params.async_rx_interval_ms defaults to 5000 ms in this version of the protocol for Asynchronous Mode (SubG-CSS) | data->unicast_params.sync_rx_interval_ms is of type sid_link2_rx_window_separation_ms for Synchronous Mode (SubG-FSK) | data->unicast_params.beacon_interval_unit specifies the beacon interval unit for FSK communication. Valid values are SID_LINK2_BEACON_INTERVAL_UNIT_1, SID_LINK2_BEACON_INTERVAL_UNIT_2, and SID_LINK2_BEACON_INTERVAL_UNIT_3 (applicable only to Synchronous Mode SubG-FSK) | data->unicast_params.l2_rx_duration_sec defines the Layer 2 receive duration in seconds for FSK links. Valid range is 0 to 65535 seconds (applicable only to Synchronous Mode SubG-FSK) | data->unicast_params.wakeup_type shall be set to SID_TX_AND_RX_WAKEUP(= 3) | len indicates the size of *data and should be set to size of(sid_device_profile) and evaluates to 8 | . 2.3.1 Examples . | Setting the Asynchronous (SubG-CSS) profile PROFILE_A with rx_window_count parameter to 5. Suitable for the mailbox sensor described above. sid_option(h, SID_OPTION_900MHZ_SET_DEVICE_PROFILE, *data, sizeof(sid_device_profile)) . The sid_option takes the following input parameters: . | h is the IOCTL handle received in the call to sid_init() when the Amazon Sidewalk protocol is initialized | *data is a pointer of type sid_device_profile | . The data and len parameters have the following values: . | data->unicast_params.device_profile_id = SID_LINK3_PROFILE_A | data->unicast_params.rx_window_count = 5 | data->unicast_params.unicast_window_interval.async_rx_interval_ms = 5000 | data->unicast_params.wakeup_type = SID_TX_AND_RX_WAKEUP | len evaluates to 8 which is the size of sid_device_profile | . | Setting the Asynchronous (SubG-CSS) profile PROFILE_B with rx_window_count parameter to 0 (INFINITE). Suitable for the car tracker and the delivery truck tracker described above. sid_option(h, SID_OPTION_900MHZ_SET_DEVICE_PROFILE, *data, sizeof(sid_device_profile)) . The sid_option takes the following input parameters: . | h is the IOCTL handle received in the call to sid_init() when the Amazon Sidewalk protocol is initialized | *data is a pointer of type sid_device_profile | . The data and len parameters have the following values: . | data->unicast_params.device_profile_id = SID_LINK3_PROFILE_B | data->unicast_params.rx_window_count = 0 | data->unicast_params.unicast_window_interval.async_rx_interval_ms = 5000 | data->unicast_params.wakeup_type = SID_TX_AND_RX_WAKEUP | len evaluates to 8 which is the size of sid_device_profile | . Note: rx_window_count for Profile B shall be set to 0 always . | Setting the Synchronous (SubG-FSK) profile PROFILE_1, rx_interval_ms has no consequence here and may be defaulted to 0. Suitable for the delivery truck tracker described above. sid_option(h, SID_OPTION_900MHZ_SET_DEVICE_PROFILE, *data, sizeof(sid_device_profile)) . The sid_option takes the following input parameters: . | h is the IOCTL handle received in the call to sid_init() when the Amazon Sidewalk protocol is initialized | *data is a pointer of type sid_device_profile | . The data and len parameters have the following values: . | data->unicast_params.device_profile_id = SID_LINK2_PROFILE_1 | data->unicast_params.rx_window_count = 0 | data->unicast_params.beacon_interval_unit = SID_LINK2_BEACON_INTERVAL_UNIT_1 (default) | data->unicast_params.l2_rx_duration_sec = 0 (default) | data->unicast_params.wakeup_type = SID_TX_AND_RX_WAKEUP | len evaluates to 8 which is the size of sid_device_profile | . Note: data->unicast_params.unicast_window_interval.sync_rx_interval_ms does not apply to PROFILE_1. | Setting the Synchronous (SubG-FSK) profile PROFILE_2 with sync_rx_interval parameter to 315 ms (=63*5 ms). Suitable for the mailbox sensor described above. sid_option(h, SID_OPTION_900MHZ_SET_DEVICE_PROFILE, *data, sizeof(sid_device_profile)) . The sid_option takes the following input parameters: . | h is the IOCTL handle received in the call to sid_init() when the Amazon Sidewalk protocol is initialized | *data is a pointer of type sid_device_profile | . The data and len parameters have the following values: . | data->unicast_params.device_profile_id = SID_LINK2_PROFILE_2 | data->unicast_params.rx_window_count = 0 | data->unicast_params.unicast_window_interval.sync_rx_interval_ms = 315 | data->unicast_params.beacon_interval_unit = SID_LINK2_BEACON_INTERVAL_UNIT_1 (configurable) | data->unicast_params.l2_rx_duration_sec = 3600 (example: 1 hour) | data->unicast_params.wakeup_type = SID_TX_AND_RX_WAKEUP | len evaluates to 8 which is the size of sid_device_profile | . | . ", "url": "/app-notes/sub-ghz-device-profile/device-profiles.html#23-sid-api", "relUrl": "/app-notes/sub-ghz-device-profile/device-profiles.html#23-sid-api" },"179": { "doc": "2. Device Profiles", "title": "References", "content": ". | Amazon Sidewalk Specification | Amazon Sidewalk SID API Developer Guide | . ", "url": "/app-notes/sub-ghz-device-profile/device-profiles.html#references", "relUrl": "/app-notes/sub-ghz-device-profile/device-profiles.html#references" },"180": { "doc": "2. Device Profiles", "title": "Appendix", "content": ". | Connected Smoke Detector: A smoke detector is a device that will signal an alarm upon detecting smoke. These devices are expected to have extremely low uplink (UL) latency - i.e. latency of communication between the sensor device to the cloud application upon detection of smoke. Under normal circumstances, the sensor may send its health metric once in 24 hours. The use case does not demand strict downlink (DL) constraints, as data from the application on the cloud to the application on the smoke detector is extremely rare. These devices are typically powered by AAA batteries and hence need to be extremely power-efficient. | Pet Tracker: A pet tracker is a device that keeps an owner updated about the location of their pet. The owner may define a geo-fence around their home where they do not expect real time data about the whereabouts of their pet. If the pet wanders away from the geo-fence, then the owner is notified. Upon receiving the notification the owner has the option to request real-time tracking, which will be a downlink command to the Endpoint and needs to be serviced immediately. In this example, both uplink latency and downlink latency are the driving factors. Reducing latency increases power consumption. | . ", "url": "/app-notes/sub-ghz-device-profile/device-profiles.html#appendix", "relUrl": "/app-notes/sub-ghz-device-profile/device-profiles.html#appendix" },"181": { "doc": "4.7 Encrypted messaging", "title": "4.7 Encrypted messaging", "content": "Encrypted messaging protects communication between an Endpoint and the Amazon Sidewalk Cloud. Encrypted messaging has two layers of security: Network Layer security and Application Layer security. Each encrypted layer is used to encrypt different parts of the Message frame. The Network Encryption Layer encrypts the Network Layer frame payload. The Application Layer security may encrypt the “Application command” part of the Presentation Layer frame. Link Layer frame parts such as “Frame control”, “Source address”, “Destination address”, “Sequence number” are always sent as plaintext (see section 5.1.1, and section 5.1.1.1). Network Layer frame parts such as “Frame control” and “Authentication tag” are always sent as plaintext (see section 5.1.2, section 5.1.2.1, and section 5.1.2.2) figure 4.12 shows which security layers encrypt the different parts of the Link Layer and Network Layer frames. Information on whether Network Layer encryption is enabled can be found in the Network Layer frame in the encr_ena field of the Frame control part (see section 5.1.2.2.1). Information on whether Application Layer encryption is enabled can be found in the Presentation Layer frame in the app_encr_ena field of the Application Support Layer header part (see section 5.1.3). Network-only Messages do not use Application Layer encryption. Beacon frame (see section 5.1.3.1) is always sent as plaintext. The Authentication tag that is included in the Beacon frame format is not used (see section 5.1.3.1.9). figure 4.12 Message frame format encryption . Network Layer encryption and Application Layer encryption use different algorithms for encryption, decryption and MAC generation. Network Layer security shall use the AES-GCM algorithm for encryption, decryption, MAC generation and verification. Application Layer security shall only use the AES-CTR algorithm for encryption and decryption. Application Layer security shall not use the MAC for verifying the sender. During time synchronization, MAC generation shall use the AES-CMAC algorithm. Time sync messages shall be authenticated. Encrypted messaging requires the Endpoint clock to be synchronized with the Amazon Sidewalk Cloud before end-to-end communication is established. Algorithms AES-GCM and AES-CTR use symmetric keys that are generated based on the global clock for all Amazon Sidewalk application commands. When the Endpoint clock is out of synchronization, AES-CMAC uses symmetric keys that are generated based on the counter for time synchronization commands (GET_TIME, RESP_TIME). When the Endpoint clock is synchronized, AES-CMAC also use symmetric keys that are generated based on the global clock for time synchronization commands. The end-to-end message is not encrypted and MAC verification is applied only for time synchronization commands. For more information on clock synchronization feature, see section 4.2. For more information on keys used for encryption, decryption and MAC generation, see section 4.7.1 . The AES-GCM algorithm used for encryption and MAC generation requires the following input parameters - see figure 4.13): . Table 4.7 Input data for AES-GCM packet encryption . | Inputs | Size in bytes | Description | . | Security key | 16 | symmetric key | . | IV | 12 | Initialization Vector used in Network Layer security | . | AAD | 8 | Additional Authenticated Data used for encryption in Network Layer security | . | Byte array | N | data to be encrypted | . The output of the algorithm is: . | N bytes of the ciphertext | MAC size is 4 B for sub-GHz encryption | . fig 4.13 Network layer security - packet encryption . fig 4.14 Network layer security - packet decryption . The AES-GCM algorithm used for decryption and MAC verification requires the following input parameters (see figure 4.14): . Table 4.8 Input data for AES-GCM packet decryption . | Inputs | Size in bytes | Description | . | Security key | 16 | symmetric key | . | IV | 12 | Initialization Vector used in the Network Layer security | . | AAD | 8 | Additional Authentication Data used for encryption in the Network Layer security | . | Byte array | N | N bytes of the received ciphertext | . | MAC | 4 | received MAC for decryption in sub-GHz | . The output of the algorithm is N bytes of plaintext. The AES-CTR algorithm used for encryption requires the following input parameters (figure 4.15): . Table 4.9 Input data for AES-CTR packet encryption . | Inputs | Size in bytes | Description | . | Security key | 16 | symmetric key | . | IV | 16 | Initialization Vector used in the Application Layer security | . | Byte array | N | bytes of the string to be encrypted | . fig 4.15 Application layer security - packet encryption . The output of the algorithm is N bytes of the ciphertext. The AES-CTR algorithm used for decryption requires the following input parameters (see figure 4.16): “” . Table 4.10 Input data for AES-CTR packet decryption . | Inputs | Size in bytes | Description | . | Security key | 16 | symmetric key | . | IV | 16 | Initialization Vector used in the Application layer security | . | Byte array | N | received ciphertext | . fig 4.16 Application layer security - packet decryption . The packet decryption algorithm outputs bytes of plaintext. The AES-CMAC algorithm used for MAC generation requires the following input parameters (see figure 4.17): . Table 4.11 Input data for AES-CMAC . | Inputs | Size in bytes | Description | . | Security key | 16 | symmetric key | . | AAD | 16 | Additional Authentication Data used for MAC generation | . | Byte array | N | message to be authenticated | . | MAC | 4 |   | . The output of the algorithm is the MAC. The MAC size for SubG-CSS devices is 4 B. The MAC size for SubG-FSK devices is 12 B. 4.17 MAC generation . The message to be authenticated is the Network Layer frame payload. The input to the AES-CMAC algorithm that contains “Message | 16B of AAD” is the concatenation of the Message and Additional Authenticated Data (AAD). For more information on the Symmetric keys that are used in the AES-GCM, AES-CMAC and AES-CTR algorithms, see section 4.7.1. For more information on Initialization Vector generation and format, see section 4.7.2. For more information on Additional Authentication Data generation and formats, see section 4.7.3. 4.7.1 Symmetric keys used in encrypted messaging . Symmetric keys are used for encrypted messaging by Network Layer encryption, and Application Layer encryption. For more information on Symmetric key generation and rotation rules, see section 4.4. Keys used by the Network Layer security for encrypted messaging are shown in table 4.12. The following keys are used in encrypted messaging on the Application security level: . Application Layer security is not applicable when the Endpoint clock is not synchronized. 4.7.2 Initialization Vector . The Initialization Vector (IV) has different formats for the Network Layer security and Application Layer security. Network Layer security uses 12 B IV format that is presented in figure 4.18. Application Layer security uses a 16 B IV format, as shown in figure 4.19. The IV is never reused with the same encryption key as the monotonically increasing sequence number has 14 bits of entropy within a 1-min time reference window. In the sub-GHz link, the 14 bits of the sequence number will never be repeated within 1 min. Table 4.12 Symmetric keys used in encrypted messaging - Network Layer . | Key | Description | . | GCM_KEY | used as AES-GCM input (encryption, decryption, MAC generation and verification) when the Endpoint clock is synchronized. It may be used for all commands except time synchronization commands | . | CMAC_CTRREF_KEY | used as AES-CMAC input (MAC generation) for GET_TIME command when the Endpoint clock is not synchronized | . | TSYNC_RESP_KEY | used as AES-CMAC input (MAC generation) for RESP_TIME command when the Endpoint clock is synchronized | . | TSYNC_RESP_CTRREF_KEY | used as AES-CMAC input (MAC generation) for RESP_TIME command when the Endpoint clock is not synchronized | . | JOIN_RESP_GCM_KEY | used as AES-GCM input (encryption, decryption, MAC generation and verification) for RESP_JOIN_REQ command | . The following keys are used in encrypted messaging on the Application security level: . Table 4.13 Symmetric keys used in encrypted messaging - Application Security . | Key | Description | . | APP_CTR_KEY | used as AES-CTR input (encryption and decryption) when the Endpoint clock is synchronized. It may be used for all commands except time synchronization commands | . 4.7.2.1 Network encryption layer IV . The 12 B IV format is a concatenation of the following values: . | Source ID is the Amazon Sidewalk ID of the Endpoint and the Cloud Service ID of the sender | Sequence number is in the Link Layer header which is a monotonically incremented number (see section 5.1.3) . Link Layer packet sequence number size may be 1, 2 or 3 B. The IV generation shall use a 3 B format. When sequence number size is less than 3 B in the Link Layer then 0x00 value shall be added as MSB byte/s to compose a sequence number for IV generation e.g. when the sequence number is encoded in 2 B “12 34” then “00 12 34” shall be used for IV generation. | Reference time expressed in seconds is calculated based on the following formula: Time = ROUNDDOWN(T_current /T_IV_ref) * T_IV_ref where T_current - current network time T_IV_ref - validity of reference time in IV (see Appendix B.3 for the exact value of T_IV_ref) . T_IV_ref = 60 s . | . fig 4.18 IV format for the Network security layer . 4.7.2.2 Application Layer security IV . The 16 B IV format is a concatenation of the following values: . | Source ID is the Amazon Sidewalk ID of the Endpoint and the Cloud Service ID of the sender | UL/DL indicates the message direction. Bit set to “0” indicates the downlink, bit set to “1” indicates the uplink | Application layer sequence number is the same as in sequence number field present in the ASL header / Presentation Layer . Application sequence number size may have 1 or 2B. IV generation shall use a 2 B format. When the application sequence number size is less than 2 B then 0x00 value is added as MSB byte to compose the sequence number for IV generation e.g. Sequence number is 0x2, the sequence number portion of IV is 0x000002 for the downlink and 0x800002 for the uplink. | Reference time is the same as the Network Layer encryption reference time | 4 B, the LSB is reserved and the default value is 0x00000000 | . fig 4.19 IV format for the Application security layer . The generated IVs are rotated in intervals equal to T_IV_ref. 4.7.3 AEAD - Authenticated Encryption with Associated Data . The Authenticated Encryption with Associated Data (AEAD) has a different format of Additional Authentication Data (AAD) for Network Layer security and MAC generation. Network Layer security uses an 8 B format that is shown in Figure 4.20. MAC generation uses a 16 B format that is shown in Figure 4.21. AEAD is the concatenation of the following parameters: . | Sequence number is the Link Layer packet sequence number (see section 5.1.3.2). The Sequence number is only used in packet authentication AEAD generation. NOTE: The Link Layer packet sequence number size may be 1, 2 or 3B. The IV generation shall use a 3 B format. When the Link Layer sequence number is less than 3 B then 0x00 value shall be added as MSB byte/s to compose a sequence number for IV generation e.g. when the sequence number is encoded as 2 B “12 34” then “00 12 34” shall be used. | Source ID is sender entity ID. Source ID depends on the message source. Source ID can be the Device ID or the Cloud Service ID - see section 4.3. | Destination ID is the destination identity used in the Link Layer frame format. The Destination ID can be the Device ID or the Cloud Service ID. NOTE: Source ID and Destination ID size may be in the range 1 to 5 B. AEAD generation shall use a 5 B format. When Source ID or Destination ID size is less than 5 B in the Link Layer then the value 0x00 shall be added as LSB byte/s to compose an ID for AEAD generation e.g. when Destination ID is encoded in 2 B “12 34” then “12 34 00 00 00” shall be used. | Security reference is included in the Network Layer frame format (sec_ref field) when ext_hdr field is set to 1. When ext_hdr field is set to 0 and sec_ref is not included then the value shall be set to 0 by default. | Security topology is included in the “Frame control” block of the Network Layer frame format (sec_top field) . NOTE: The current release of the protocol supports only one security topology. This bit shall be set to 1 by default. | Authentication code size is included in the “Frame control” block of the Network Layer frame format (auth_code_size field). | Encryption enabled is included in the “Frame control” block of the Network Layer frame format (encr_ena field). | Destination format and Source format are included in the “Frame control” block of the Link Layer frame format (src_frmt and dst_frmt fields). | RF frame protocol version is included in the “Frame control” block of the Link Layer frame format (prot_ver field). NOTE: The Link Layer contains a 4 bit prot_ver field that contains the protocol version, but AEAD requires a 1 B value. The value taken from the Link Layer shall have 4 bits with 0 value prepended to prot_ver field to fit the AEAD protocol version size. | . fig 4.20 8B AAD for the Network security layer . 4.21 16B AAD for MAC generation . ", "url": "/specifications/sidewalk-protocol-spec/security/encrypted-messaging.html", "relUrl": "/specifications/sidewalk-protocol-spec/security/encrypted-messaging.html" },"182": { "doc": "7.3 End Device", "title": "7.3 End Device", "content": "The File transfer feature has a direct impact on end device resources, especially the flash and RAM. The amount of RAM needed depends on the fragmentation size selected by the user. The design of the feature is such that the device doesn’t need to have the entire file size memory available to transfer the entire file. The end device also has some scratch internal buffers that are used for receiving the encrypted fragments and decrypted fragments. The end device is expected to have available flash to host the entire file being transferred and the feature also requires scratch flash storage for storing meta data related to the file transfer. ", "url": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/end-device.html", "relUrl": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/end-device.html" },"183": { "doc": "4. End Devices", "title": "4 End devices", "content": "Unlike a gateway, an end device does not determine its own region. The region is supplied to it, and an end device is therefore the case in which the region can be set incorrectly, set late, or set to a value the device cannot support. The remainder of this section is what an application developer is responsible for on an end device. As with a gateway, regional support is compiled in: an end device can only be provisioned to a region its firmware includes. Build end-device firmware with REGION_LITE, which compiles in both North America and Europe; provisioning a device to a region its build omits is refused as described in §4.4. Use REGION_LITE on its own: the single-region options REGION_US915 and REGION_EU868 are alternatives to it, not additions, and defining REGION_EU868 alongside it changes the default region described in §4.3 from North America to Europe. ", "url": "/app-notes/internationalization/end-devices.html#4-end-devices", "relUrl": "/app-notes/internationalization/end-devices.html#4-end-devices" },"184": { "doc": "4. End Devices", "title": "4.1 The region values", "content": "An end device’s region is one of the values of enum sid_device_region, defined in the Amazon Sidewalk API guide (§2.16.1). The current build supports SID_DEVICE_REGION_NORTH_AMERICA and SID_DEVICE_REGION_EUROPE; SID_DEVICE_REGION_UNSET means no region has been set. The radio region passed at platform initialisation (§4.2) uses the same numeric value for each region, so a single stored value can supply both. ", "url": "/app-notes/internationalization/end-devices.html#41-the-region-values", "relUrl": "/app-notes/internationalization/end-devices.html#41-the-region-values" },"185": { "doc": "4. End Devices", "title": "4.2 Configuring the radio and reporting the region", "content": "An end device uses its region in two separate places, and the application supplies both: . | Radio region. The sub-GHz radio is configured from the region the application passes to sid_platform_init(), in the platform_init_parameters.region and platform_init_parameters.iso_country fields of platform_parameters_t. This value sets the band, spreading factor, transmit power and channel-access rules. Platform initialisation runs once per boot. | Reported region. The stack writes and reads the provisioned region through the set_info and get_info callbacks in struct sid_device_info_callbacks, with information type SID_DEVICE_INFO_TYPE_REGION. It uses this value to report the region during setup, to allow or block network registration, and to decide whether to start the sub-GHz links (§4.3). It does not configure the radio. | . The stack does not connect the two, so the application must keep them consistent by deriving both from one stored value: . | In set_info, store the provisioned region persistently before returning success. | In get_info, return the stored value as an enum sid_device_region, or SID_DEVICE_REGION_UNSET if none is stored. | At every boot, pass the stored region to sid_platform_init(), rather than a fixed compile-time value. Because platform initialisation runs once per boot, a newly provisioned region reaches the radio after the next reboot. | If no region is stored, pass a region the build includes, for example North America. The device still reports SID_DEVICE_REGION_UNSET, so the sub-GHz links stay off until the region is provisioned. | On factory reset, clear the stored region. | . If the two values differ, the device reports one region while its radio operates on the parameters of another. For the field definitions and integration steps, see the Amazon Sidewalk API guide §3.1 (platform_init_parameters) and §2.16.3 (integration steps). ", "url": "/app-notes/internationalization/end-devices.html#42-configuring-the-radio-and-reporting-the-region", "relUrl": "/app-notes/internationalization/end-devices.html#42-configuring-the-radio-and-reporting-the-region" },"186": { "doc": "4. End Devices", "title": "4.3 When no region is reported", "content": "What the stack does when get_info reports no region depends on whether the device is already registered: . | Not yet registered. Network registration is blocked, and sid_start() starts only Bluetooth Low Energy; the sub-GHz links are not started, and a request to start only sub-GHz links returns SID_ERROR_INVALID_STATE. Bluetooth Low Energy remains available so that the region can be provisioned over it during setup. This is the normal state of a new device; treat it as a start-up state, not an error. | Already registered. A device built with REGION_LITE is treated as North America for registration and reporting. This covers a device registered before region support was available, for example one that later receives a firmware update adding it. Initialise its radio for North America as well, so that the two values agree. | . If the application does not report a region at all — get_info does not handle SID_DEVICE_INFO_TYPE_REGION — none of the above applies: registration is not gated and no default is applied. This is the behaviour of firmware without region support. Because the application clears the stored region on factory reset (§4.2), a reset device returns to the first case above. ", "url": "/app-notes/internationalization/end-devices.html#43-when-no-region-is-reported", "relUrl": "/app-notes/internationalization/end-devices.html#43-when-no-region-is-reported" },"187": { "doc": "4. End Devices", "title": "4.4 An unsupported region", "content": "If setup provisions a region the device firmware does not support — for the current build, any region other than North America or Europe (§4) — the stack rejects the request with a not-supported error and does not pass the region to the application. The device keeps its previous region, or remains without one. The error is definitive. Setup should stop rather than retry: the request is rejected every time until the device runs firmware that supports the region. ", "url": "/app-notes/internationalization/end-devices.html#44-an-unsupported-region", "relUrl": "/app-notes/internationalization/end-devices.html#44-an-unsupported-region" },"188": { "doc": "4. End Devices", "title": "4. End Devices", "content": " ", "url": "/app-notes/internationalization/end-devices.html", "relUrl": "/app-notes/internationalization/end-devices.html" },"189": { "doc": "10. Endpoint Capability Test Cases", "title": "10. Endpoint Capability Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html" },"190": { "doc": "10. Endpoint Capability Test Cases", "title": "10.1 CMN-EP-CAPABILITY-REPORT-BV-01: When KV store does not have the capability report saved, the event to send capability is scheduled.", "content": "10.1.1 Test Purpose . Verify capability report flow when endpoint attempt to schedule report. 10.1.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in supported links mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 10.1.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: iterate: Each Sidewalk operation mode Upper_Tester->>DUT: print_clear_cap(CAPABILITY_AND_CONFIGURE) DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Sidewalk application started Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0 DUT->>Lower_Tester: UPLINK_CAPABILITY_COMMAND Lower_Tester->>DUT: SEND_DOWNLINK_COMMAND Note over Lower_Tester,Upper_Tester: end of iteration Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 10.1.4 Expected Results . 10.1.4.1 Pass Verdict . When the capability information of Endpoint is not equal to the capability information stored in the KV store, the event to send capability is performed. ", "url": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#101-cmn-ep-capability-report-bv-01-when-kv-store-does-not-have-the-capability-report-saved-the-event-to-send-capability-is-scheduled", "relUrl": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#101-cmn-ep-capability-report-bv-01-when-kv-store-does-not-have-the-capability-report-saved-the-event-to-send-capability-is-scheduled" },"191": { "doc": "10. Endpoint Capability Test Cases", "title": "10.2 CMN-EP-CAPABILITY-REPORT-BV-02: When Capability stored in the KV store is equal to the capability of the Endpoint, the Capability event report is not generated.", "content": "10.2.1 Test Purpose . Verify capability report flow when the Capability information stored in KV store capability is equal to the capability of the endpoint. 10.2.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in supported links mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 10.2.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: iterate: Each Sidewalk operation mode Upper_Tester->>DUT: print_clear_cap(CAPABILITY_AND_CONFIGURE) DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Sidewalk application started Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0 DUT->>Lower_Tester: UPLINK_CAPABILITY_COMMAND Lower_Tester->>DUT: SEND_DOWNLINK_COMMAND Upper_Tester->>DUT: reboot DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: iterate: Each Sidewalk operation mode Note over Lower_Tester,Upper_Tester: Sidewalk application started Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0 Note over Lower_Tester,Upper_Tester: No UPLINK_CAPABILITY_COMMAND send Note over Lower_Tester,Upper_Tester: end of iteration Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 10.2.4 Expected Results . 10.2.4.1 Pass Verdict . Capability information stored in the KV store is equal to capability information of the device. The event to report capability information is not scheduled. ", "url": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#102-cmn-ep-capability-report-bv-02-when-capability-stored-in-the-kv-store-is-equal-to-the-capability-of-the-endpoint-the-capability-event-report-is-not-generated", "relUrl": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#102-cmn-ep-capability-report-bv-02-when-capability-stored-in-the-kv-store-is-equal-to-the-capability-of-the-endpoint-the-capability-event-report-is-not-generated" },"192": { "doc": "10. Endpoint Capability Test Cases", "title": "10.3 CMN-EP-CAPABILITY-REPORT-BV-03: Endpoint default capability report.", "content": "10.3.1 Test Purpose . Verify on clearing the configuration, the capability and configuration shall be set to defaults. 10.3.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in supported links mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 10.3.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: iterate: Each Sidewalk operation mode Note over Lower_Tester,Upper_Tester: Sidewalk application started Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0 Upper_Tester->>DUT: print_clear_cap(CAPABILITY_AND_CONFIGURE) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: print_get_cap(CAPABILITY_AND_CONFIGURE) DUT->>Upper_Tester: Print Capability \"Default_capability_and_configure\" Note over Lower_Tester,Upper_Tester: end of iteration Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 10.3.4 Expected Results . 10.3.4.1 Pass Verdict . The capability and configuration information are equal to the default values. ", "url": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#103-cmn-ep-capability-report-bv-03-endpoint-default-capability-report", "relUrl": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#103-cmn-ep-capability-report-bv-03-endpoint-default-capability-report" },"193": { "doc": "10. Endpoint Capability Test Cases", "title": "10.4 CMN-EP-CAPABILITY-REQUEST-BV-01: Endpoint is online, send request to get endpoint capability.", "content": "10.4.1 Test Purpose . Verify endpoint sends updated capability when user initiates request capability. 10.4.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in supported links mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 10.4.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: iterate: Each Sidewalk operation mode Note over Lower_Tester,Upper_Tester: Sidewalk application started Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced Upper_Tester->>DUT: INITIATE_REQUEST_CAPABILITY Lower_Tester->>DUT: SEND_DOWNLINK_COMMAND DUT->>Lower_Tester: SEND_CAPABILITY_COMMAND DUT->>Lower_Tester: GET_CAPABILITY \"Configure_is_same_as_DUT\" Note over Lower_Tester,Upper_Tester: end of iteration Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 10.4.4 Expected Results . 10.4.4.1 Pass Verdict . Endpoint reports updated capability report when requested by the user. ", "url": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#104-cmn-ep-capability-request-bv-01-endpoint-is-online-send-request-to-get-endpoint-capability", "relUrl": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#104-cmn-ep-capability-request-bv-01-endpoint-is-online-send-request-to-get-endpoint-capability" },"194": { "doc": "10. Endpoint Capability Test Cases", "title": "10.5 CMN-EP-CAPABILITY-CONFIGURE-BV-01: Endpoint configuration shall be updated on user setting.", "content": "10.5.1 Test Purpose . Verify configuration of the endpoint is updated after it is set by the user. 10.5.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in supported links. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 10.5.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: iterate: Each Sidewalk operation mode Note over Lower_Tester,Upper_Tester: Sidewalk application started Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced Upper_Tester->>DUT: SET_EACH_CONFIGURE Lower_Tester->>DUT: SEND_DOWNLINK_COMMAND DUT->>Lower_Tester: SEND_CONFIGURATION_DOWNLOAD_ACK Upper_Tester->>DUT: print_get_cap(CONFIGURATION) DUT->>Upper_Tester: Print Capability \"Each_configure_is_updated\" DUT->>Lower_Tester: GET_CAPABILITY \"Each_configure_is_updated\" Note over Lower_Tester,Upper_Tester: end of iteration Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 10.5.4 Expected Results . 10.5.4.1 Pass Verdict . The configuration on DUT is updated. ", "url": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#105-cmn-ep-capability-configure-bv-01-endpoint-configuration-shall-be-updated-on-user-setting", "relUrl": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#105-cmn-ep-capability-configure-bv-01-endpoint-configuration-shall-be-updated-on-user-setting" },"195": { "doc": "10. Endpoint Capability Test Cases", "title": "10.6 CMN-EP-CAPABILITY-REGISTER-BV-01: Endpoint capability is set to default after re-registration.", "content": "10.6.1 Test Purpose . Verify capability of Endpoint shall have default configuration on re-registration. 10.6.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in supported links(BLE or FSK) mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 10.6.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: iterate: BLE and FSK mode Note over Lower_Tester,Upper_Tester: Sidewalk application started Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0 Upper_Tester->>DUT: SET_EACH_CONFIGURE Lower_Tester->>DUT: SEND_DOWNLINK_COMMAND DUT->>Lower_Tester: SEND_CONFIGURATION_DOWNLOAD_ACK Upper_Tester->>DUT: print_get_cap(CONFIGURATION) DUT->>Upper_Tester: Print Capability \"Each_configure_is_updated\" Upper_Tester->>DUT: sid_set_factory_reset() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: NOTIFY_RESET(RESET_HARD) DUT->>Upper_Tester: on_status_changed() \"Status: Not registered, Link Mask 0\" Note over Lower_Tester,Upper_Tester: Sidewalk stack initialized and started, DUT Status: Not Registered Note over Lower_Tester,Upper_Tester: Wait until registration process is finished DUT->>Upper_Tester: on_status_changed() \"Status: Registered\" DUT->>Lower_Tester: UPLINK_CAPABILITY_COMMAND Lower_Tester->>DUT: SEND_DOWNLINK_COMMAND Upper_Tester->>DUT: print_get_cap(CONFIGURATION) DUT->>Upper_Tester: Print Capability \"Each_configure_is_return_to_default\" DUT->>Lower_Tester: GET_CAPABILITY \"Each_configure_is_return_to_default\" Note over Lower_Tester,Upper_Tester: end of iteration Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 10.6.4 Expected Results . 10.6.4.1 Pass Verdict . Configuration is set to defaults on re-registration. ", "url": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#106-cmn-ep-capability-register-bv-01-endpoint-capability-is-set-to-default-after-re-registration", "relUrl": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#106-cmn-ep-capability-register-bv-01-endpoint-capability-is-set-to-default-after-re-registration" },"196": { "doc": "10. Endpoint Capability Test Cases", "title": "10.7 CMN-EP-CAPABILITY-THRESHOLD-BV-01: Traffic threshold reset mechanism.", "content": "10.7.1 Test Purpose . Verify traffic thresholds are reset when the device is reset but not when sidewalk stack is stopped and started. 10.7.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in supported links mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 10.7.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: iterate: Each Sidewalk operation mode Note over Lower_Tester,Upper_Tester: Sidewalk application started Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced Upper_Tester->>DUT: SET_CONFIGURATION Lower_Tester->>DUT: SEND_DOWNLINK_COMMAND DUT->>Lower_Tester: SEND_CONFIGURATION_DOWNLOAD_ACK Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: Wait for 2s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: Wait for 2s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_send_error(SID_ERROR_THRESHOLD_EXCEEDED) Upper_Tester->>DUT: reboot DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: iterate: Each Sidewalk operation mode Note over Lower_Tester,Upper_Tester: Sidewalk application started Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: Wait for 2s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: Wait for 2s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: end of iteration . 10.7.4 Expected Results . 10.7.4.1 Pass Verdict .  After messages on a particular link exceed traffic threshold, stopping and starting the stack shall not allow new uplink messages to be sent. After messages on a particular link exceed traffic threshold, a reboot of device can allow new uplink messages to be sent. ", "url": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#107-cmn-ep-capability-threshold-bv-01-traffic-threshold-reset-mechanism", "relUrl": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#107-cmn-ep-capability-threshold-bv-01-traffic-threshold-reset-mechanism" },"197": { "doc": "10. Endpoint Capability Test Cases", "title": "10.8 CMN-EP-CAPABILITY-PERIODICITY-BV-01: Set metrics periodicity.", "content": "10.8.1 Test Purpose . Verify metrics are sent at a periodicity set in the endpoint metrics periodicity configuration. 10.8.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in supported links mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 10.8.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: iterate: Each Sidewalk operation mode Note over Lower_Tester,Upper_Tester: Sidewalk application started Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced Upper_Tester->>DUT: SET_CONFIGURATION \"enableMetricsReport: True, metricsPeriodicity: 1\" Lower_Tester->>DUT: SEND_DOWNLINK_COMMAND DUT->>Lower_Tester: SEND_CONFIGURATION_DOWNLOAD_ACK Upper_Tester->>DUT: print_get_cap(CONFIGURATION) DUT->>Upper_Tester: Print Capability \"enableMetricsReport: True, metricsPeriodicity: 1\" Note over Lower_Tester,Upper_Tester: Wait for 6 hours DUT->>Lower_Tester: NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_sent() Lower_Tester->>DUT: ACK_NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_received() Note over Lower_Tester,Upper_Tester: end of iteration Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 10.8.4 Expected Results . 10.8.4.1 Pass Verdict . configuration is updated after setting. DUT successfully transmits metrics according to the configured periodicity. DUT receives Cloud acknowledgment for the transmitted metrics messages. ", "url": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#108-cmn-ep-capability-periodicity-bv-01-set-metrics-periodicity", "relUrl": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#108-cmn-ep-capability-periodicity-bv-01-set-metrics-periodicity" },"198": { "doc": "10. Endpoint Capability Test Cases", "title": "10.9 CMN-EP-CAPABILITY-PERIODICITY-BV-02: Set metrics periodicity when link metrics is disabled.", "content": "10.9.1 Test Purpose . Verify the metrics periodicity configuration shall be set successfully even when link is disabled. 10.9.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in supported links mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 10.9.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: iterate: Each Sidewalk operation mode Note over Lower_Tester,Upper_Tester: Sidewalk application started Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced Upper_Tester->>DUT: SET_CONFIGURATION \"enableMetricsReport: False, metricsPeriodicity: 1\" Lower_Tester->>DUT: SEND_DOWNLINK_COMMAND DUT->>Lower_Tester: SEND_CONFIGURATION_DOWNLOAD_ACK Upper_Tester->>DUT: print_get_cap(CONFIGURATION) DUT->>Upper_Tester: Print Capability \"enableMetricsReport: False, metricsPeriodicity: 1\" Note over Lower_Tester,Upper_Tester: Wait for 6 hours Note over Lower_Tester,Upper_Tester: No metrics sent Note over Lower_Tester,Upper_Tester: end of loop Note over Lower_Tester,Upper_Tester: end of iteration Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 10.9.4 Expected Results . 10.9.4.1 Pass Verdict . Configuration is updated after setting. Metrics are sent only at the periodicity configuration. ", "url": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#109-cmn-ep-capability-periodicity-bv-02-set-metrics-periodicity-when-link-metrics-is-disabled", "relUrl": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#109-cmn-ep-capability-periodicity-bv-02-set-metrics-periodicity-when-link-metrics-is-disabled" },"199": { "doc": "10. Endpoint Capability Test Cases", "title": "10.10 BLE-EP-CAPABILITY-THRESHOLD-BV-01: Verify traffic thresholds for BLE stack.", "content": "10.10.1 Test Purpose . After traffic on BLE link exceeds the BLE traffic thresholds, the user messages shall be dropped. 10.10.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | . 10.10.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: SET_CONFIGURATION \"table: 1, BLE_max_packets_per_min: 1, enableThrottling: True\" Lower_Tester->>DUT: SEND_DOWNLINK_COMMAND DUT->>Lower_Tester: SEND_CONFIGURATION_DOWNLOAD_ACK Upper_Tester->>DUT: print_get_cap(CONFIGURATION) DUT->>Upper_Tester: Print Capability \"Traffic_threshold_table_id: 1\", \"BLE_max_packets_per_min: 1\", \"BLE_max_packets_per_day: 1440\" Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: Wait for 25s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_send_error(SID_ERROR_THRESHOLD_EXCEEDED) Note over Lower_Tester,Upper_Tester: Wait for 25s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_send_error(SID_ERROR_THRESHOLD_EXCEEDED) Note over Lower_Tester,Upper_Tester: Wait for 15s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 10.10.4 Expected Results . 10.10.4.1 Pass Verdict .  Traffic threshold configuration shall reflect the correct setting. User messages shall be allowed after the traffic threshold timeouts. ", "url": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#1010-ble-ep-capability-threshold-bv-01-verify-traffic-thresholds-for-ble-stack", "relUrl": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#1010-ble-ep-capability-threshold-bv-01-verify-traffic-thresholds-for-ble-stack" },"200": { "doc": "10. Endpoint Capability Test Cases", "title": "10.11 FSK-EP-CAPABILITY-THRESHOLD-BV-01: Verify traffic threshold for FSK stack.", "content": "10.11.1 Test Purpose . When messages on FSK exceed thresholds, messages shall be dropped. 10.11.2 Initial Conditions . | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in FSK mode. | . 10.11.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 2, FSK connected Upper_Tester->>DUT: SET_CONFIGURATION \"table: 1, enableThrottling: True, fsk_packet_Per_Min: 1\" Lower_Tester->>DUT: SEND_DOWNLINK_COMMAND DUT->>Lower_Tester: SEND_CONFIGURATION_DOWNLOAD_ACK Upper_Tester->>DUT: print_get_cap(CONFIGURATION) DUT->>Upper_Tester: Print Capability \"Traffic_threshold_table_id: 1\", \"FSK_max_packets_per_min: 1\", \"FSK_max_packets_per_day: 1440\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: Wait for 25s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_send_error(SID_ERROR_THRESHOLD_EXCEEDED) Note over Lower_Tester,Upper_Tester: Wait for 25s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_send_error(SID_ERROR_THRESHOLD_EXCEEDED) Note over Lower_Tester,Upper_Tester: Wait for 15s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 10.11.4 Expected Results . 10.11.4.1 Pass Verdict .  Traffic threshold configuration shall reflect the correct setting. After traffic on FSK link exceeds the FSK traffic thresholds, the user messages shall be dropped. User messages shall be allowed after the traffic threshold timeouts. ", "url": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#1011-fsk-ep-capability-threshold-bv-01-verify-traffic-threshold-for-fsk-stack", "relUrl": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#1011-fsk-ep-capability-threshold-bv-01-verify-traffic-threshold-for-fsk-stack" },"201": { "doc": "10. Endpoint Capability Test Cases", "title": "10.12 LORA-EP-CAPABILITY-THRESHOLD-BV-01: Verify traffic threshold on static endpoint of LoRa.", "content": "10.12.1 Test Purpose . When messages on LoRa exceed thresholds, messages shall be dropped. 10.12.2 Initial Conditions . | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode. | . 10.12.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 4, LoRa connected Upper_Tester->>DUT: SET_CONFIGURATION Lower_Tester->>DUT: SEND_DOWNLINK_COMMAND DUT->>Lower_Tester: SEND_CONFIGURATION_DOWNLOAD_ACK Upper_Tester->>DUT: print_get_cap(CONFIGURATION) DUT->>Upper_Tester: Print Capability Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: Wait for 25s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_send_error(SID_ERROR_THRESHOLD_EXCEEDED) Note over Lower_Tester,Upper_Tester: Wait for 25s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_send_error(SID_ERROR_THRESHOLD_EXCEEDED) Note over Lower_Tester,Upper_Tester: Wait for 15s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: Wait for 61s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: Wait for 65s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_send_error(SID_ERROR_THRESHOLD_EXCEEDED) Note over Lower_Tester,Upper_Tester: Wait for 10s Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_send_error(SID_ERROR_THRESHOLD_EXCEEDED) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 10.12.4 Expected Results . 10.12.4.1 Pass Verdict .  Traffic threshold configuration shall reflect the correct setting. After traffic on LoRa link exceeds the LoRa traffic thresholds, the user messages shall be dropped. User messages shall be allowed after the traffic threshold timeouts. ", "url": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#1012-lora-ep-capability-threshold-bv-01-verify-traffic-threshold-on-static-endpoint-of-lora", "relUrl": "/specifications/sidewalk-test-spec/endpoint-capability-test-cases.html#1012-lora-ep-capability-threshold-bv-01-verify-traffic-threshold-on-static-endpoint-of-lora" },"202": { "doc": "9. Endpoint Metrics Test Cases", "title": "9. Endpoint Metrics Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html" },"203": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.1 CMN/EP/EPMETRICS/METRICS/BV/01: Verify Endpoint has corresponding metrics but not invalid metrics enabled.", "content": "9.1.1 Test Purpose . DUT only has the metrics that correspond to enabled protocol stacks, with no irrelevant metrics present. 9.1.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | . 9.1.3 Test Procedure . sequenceDiagram participant DUT as DUT participant Upper_Tester as Upper Tester Note over DUT,Upper_Tester: iterate: Each Sidewalk operation mode Note over DUT,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_ALL) DUT->>Upper_Tester: Print all applicable metrics for enabled stacks Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over DUT,Upper_Tester: end of iteration . 9.1.4 Expected Results . 9.1.4.1 Pass Verdict . DUT maintains only metrics associated with currently enabled protocol stacks, with no irrelevant metrics present. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#91-cmnepepmetricsmetricsbv01-verify-endpoint-has-corresponding-metrics-but-not-invalid-metrics-enabled", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#91-cmnepepmetricsmetricsbv01-verify-endpoint-has-corresponding-metrics-but-not-invalid-metrics-enabled" },"204": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.2 BLE/EP/EPMETRICS/REPORT/BV/01: Verify Endpoint sends Endpoint Metrics to Cloud over BLE in a specific time interval.", "content": "9.2.1 Test Purpose . DUT demonstrates capability to transmit endpoint metrics through BLE connectivity based on the configured metrics periodicity. 9.2.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | DUT is configured with metrics capability enabled. | Lower Tester operates in BLE mode. | . 9.2.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Note over Lower_Tester,Upper_Tester: Wait: metrics periodicity cycle - 1 minute post initial time synchronization Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_ALL) DUT->>Upper_Tester: Print all applicable metrics for enabled stacks Note over Lower_Tester,Upper_Tester: Wait: remaining 1 minute to complete periodicity cycle DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_sent() Lower_Tester->>DUT: ACK_NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_received() Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_ALL) DUT->>Upper_Tester: Print all applicable metrics for enabled stacks Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 9.2.4 Expected Results . 9.2.4.1 Pass Verdict . Following time synchronization, DUT successfully transmits metrics over BLE according to the configured periodicity. DUT receives Cloud acknowledgment for the transmitted metrics package. DUT resets metrics after periodic reporting completion. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#92-bleepepmetricsreportbv01-verify-endpoint-sends-endpoint-metrics-to-cloud-over-ble-in-a-specific-time-interval", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#92-bleepepmetricsreportbv01-verify-endpoint-sends-endpoint-metrics-to-cloud-over-ble-in-a-specific-time-interval" },"205": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.3 BLE/EP/EPMETRICS/REPORT/BV/02: Verify Endpoint sends remaining Endpoint Metrics to Cloud over BLE via piggybacking on a periodic reporting.", "content": "9.3.1 Test Purpose . DUT implements metrics piggybacking over subsequent BLE uplinks to complete metrics transmission when single periodic uplink capacity is insufficient. 9.3.2 Initial Conditions . | The Sidewalk stack (BLE+FSK), (BLE+LORA) or (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | DUT is configured with metrics capability enabled. | Lower Tester operates in BLE mode. | . 9.3.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Note over Lower_Tester,Upper_Tester: Configure individual metrics to their respective boundary values Upper_Tester->>DUT: metrics_set(Category_ID, Metric_ID, boundary_value) Note over Lower_Tester,Upper_Tester: Manually trigger periodic metrics reporting Upper_Tester->>DUT: metrics_send() DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_sent() Lower_Tester->>DUT: ACK_NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_received() Note over Lower_Tester,Upper_Tester: loop: Send uplinks until all remaining metrics are piggybacked via BLE Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: 1B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data and piggybacked metrics) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: end of loop Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 9.3.4 Expected Results . 9.3.4.1 Pass Verdict . DUT transmits remaining metrics from periodic reporting via BLE uplink piggybacking. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#93-bleepepmetricsreportbv02-verify-endpoint-sends-remaining-endpoint-metrics-to-cloud-over-ble-via-piggybacking-on-a-periodic-reporting", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#93-bleepepmetricsreportbv02-verify-endpoint-sends-remaining-endpoint-metrics-to-cloud-over-ble-via-piggybacking-on-a-periodic-reporting" },"206": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.4 BLE/EP/EPMETRICS/REPORT/BV/03: Verify Endpoint Metrics are uploaded via Piggybacking over BLE if the explicit reporting is disabled.", "content": "9.4.1 Test Purpose . When metrics capability is disabled, DUT is able to transmit endpoint metrics via BLE piggybacking instead of periodic reporting during regular reporting intervals. 9.4.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | DUT is configured with metrics capability disabled. | Lower Tester operates in BLE mode. | . 9.4.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Note over Lower_Tester,Upper_Tester: Manually trigger periodic metrics reporting Upper_Tester->>DUT: metrics_send() DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Note over Lower_Tester,Upper_Tester: loop: Send uplinks until all metrics are piggybacked via BLE Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: 1B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data and piggybacked metrics) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: end of loop Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 9.4.4 Expected Results . 9.4.4.1 Pass Verdict . DUT transmits all metrics through BLE piggybacking instead of periodic reporting. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#94-bleepepmetricsreportbv03-verify-endpoint-metrics-are-uploaded-via-piggybacking-over-ble-if-the-explicit-reporting-is-disabled", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#94-bleepepmetricsreportbv03-verify-endpoint-metrics-are-uploaded-via-piggybacking-over-ble-if-the-explicit-reporting-is-disabled" },"207": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.5 BLE/EP/EPMETRICS/UL/BV/01: Verify Uplink messages Metrics.", "content": "9.5.1 Test Purpose . DUT captures BLE uplink metrics. 9.5.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | . 9.5.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid_ble_bcn_connection_request(set) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: clear_metrics(SID_METRICS_CAT_ALL) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_BLE_LINK) DUT->>Upper_Tester: Print BLE_LINK metrics \"num_ul: 0\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with the Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_BLE_LINK) DUT->>Upper_Tester: Print BLE_LINK metrics \"num_ul: 1\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with the Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_BLE_LINK) DUT->>Upper_Tester: Print BLE_LINK metrics \"num_ul: 2\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with the Command data) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: Continued on next page. sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Continued from previous page Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_BLE_LINK) DUT->>Upper_Tester: Print BLE_LINK metrics \"num_ul: 3\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 9.5.4 Expected Results . 9.5.4.1 Pass Verdict . DUT’s BLE uplink metrics increment after each BLE uplink transmission. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#95-bleepepmetricsulbv01-verify-uplink-messages-metrics", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#95-bleepepmetricsulbv01-verify-uplink-messages-metrics" },"208": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.6 BLE/EP/EPMETRICS/DL/BV/01: Verify Downlink messages Metrics.", "content": "9.6.1 Test Purpose . DUT captures BLE downlink metrics. 9.6.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | . 9.6.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: clear_metrics(SID_METRICS_CAT_ALL) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_BLE_LINK) DUT->>Upper_Tester: Print BLE_LINK metrics \"num_dl: 0\" Note over Lower_Tester,Upper_Tester: Continued on next page. sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Continued from previous page Lower_Tester->>DUT: Establish BLE connection (triggered by upcoming downlink packets) DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_BLE_LINK) DUT->>Upper_Tester: Print BLE_LINK metrics \"num_dl: 1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_BLE_LINK) DUT->>Upper_Tester: Print BLE_LINK metrics \"num_dl: 2\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_BLE_LINK) DUT->>Upper_Tester: Print BLE_LINK metrics \"num_dl: 3\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 9.6.4 Expected Results . 9.6.4.1 Pass Verdict . DUT’s BLE downlink metrics increment after each BLE downlink reception. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#96-bleepepmetricsdlbv01-verify-downlink-messages-metrics", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#96-bleepepmetricsdlbv01-verify-downlink-messages-metrics" },"209": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.7 BLE/EP/EPMETRICS/CONN-BV-01: Verify Connection attempts Metrics.", "content": "9.7.1 Test Purpose . DUT captures BLE connection attempts metrics. 9.7.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized on the DUT. | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | . 9.7.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack BLE is initialized but not started Upper_Tester->>DUT: sid_start(ble_start: true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_BLE_LINK) DUT->>Upper_Tester: Print BLE_LINK metrics \"num_conn_attempts: 1\" DUT->>Lower_Tester: Beacon with time sync request Lower_Tester->>DUT: Establish BLE connection Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_BLE_LINK) DUT->>Upper_Tester: Print BLE_LINK metrics \"num_conn_attempts: 1\" Upper_Tester->>DUT: sid_ble_bcn_connection_request(set) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_BLE_LINK) DUT->>Upper_Tester: Print BLE_LINK metrics \"num_conn_attempts: 2\" Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Note over Lower_Tester,Upper_Tester: Wait: 30 sec DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: metrics_send() DUT->>Lower_Tester: Beacon with connection request Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_BLE_LINK) DUT->>Upper_Tester: Print BLE_LINK metrics \"num_conn_attempts: 3\" Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_sent() Lower_Tester->>DUT: ACK_NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 9.7.4 Expected Results . 9.7.4.1 Pass Verdict . DUT’s BLE connection attempts metrics increment after BLE start and each DUT-initiated BLE connection request. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#97-bleepepmetricsconn-bv-01-verify-connection-attempts-metrics", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#97-bleepepmetricsconn-bv-01-verify-connection-attempts-metrics" },"210": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.8 FSK/EP/EPMETRICS/REPORT/BV/01: Verify Endpoint sends Endpoint Metrics to Cloud over FSK in a specific time interval.", "content": "9.8.1 Test Purpose . DUT demonstrates capability to transmit endpoint metrics through FSK connectivity based on the configured metrics periodicity. 9.8.2 Initial Conditions . | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | DUT is configured with metrics capability enabled. | Lower Tester operates in FSK mode. | . 9.8.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 2, FSK connected Note over Lower_Tester,Upper_Tester: Wait: metrics periodicity cycle - 1 minute post initial time synchronization Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_ALL) DUT->>Upper_Tester: Print all applicable metrics for enabled stacks Note over Lower_Tester,Upper_Tester: Wait: remaining 1 minute to complete periodicity cycle DUT->>Lower_Tester: NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_sent() Lower_Tester->>DUT: ACK_NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_received() Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_ALL) DUT->>Upper_Tester: Print all applicable metrics for enabled stacks Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 9.8.4 Expected Results . 9.8.4.1 Pass Verdict . Following time synchronization, DUT successfully transmits metrics over FSK according to the configured periodicity. DUT receives Cloud acknowledgment for the transmitted metrics package. DUT resets metrics after periodic reporting completion. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#98-fskepepmetricsreportbv01-verify-endpoint-sends-endpoint-metrics-to-cloud-over-fsk-in-a-specific-time-interval", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#98-fskepepmetricsreportbv01-verify-endpoint-sends-endpoint-metrics-to-cloud-over-fsk-in-a-specific-time-interval" },"211": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.9 FSK/EP/EPMETRICS/REPORT/BV/02: Verify Endpoint sends remaining Endpoint Metrics to Cloud over FSK via piggybacking on a periodic reporting.", "content": "9.9.1 Test Purpose . DUT implements metrics piggybacking over subsequent FSK uplinks to complete metrics transmission when single periodic uplink capacity is insufficient. 9.9.2 Initial Conditions . | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | DUT is configured with metrics capability enabled. | Lower Tester operates in FSK mode. | . 9.9.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 2, FSK connected Note over Lower_Tester,Upper_Tester: Configure individual metrics to their respective boundary values Upper_Tester->>DUT: metrics_set(Category_ID, Metric_ID, boundary_value) Note over Lower_Tester,Upper_Tester: Manually trigger periodic metrics reporting Upper_Tester->>DUT: metrics_send() DUT->>Lower_Tester: NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_sent() Lower_Tester->>DUT: ACK_NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_received() Note over Lower_Tester,Upper_Tester: Continued on next page. sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Continued from previous page Note over Lower_Tester,Upper_Tester: loop: Send uplinks until all remaining metrics are piggybacked via FSK Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: 1B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data and piggybacked metrics) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: end of loop Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 9.9.4 Expected Results . 9.9.4.1 Pass Verdict . DUT transmits remaining metrics from periodic reporting via FSK uplink piggybacking. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#99-fskepepmetricsreportbv02-verify-endpoint-sends-remaining-endpoint-metrics-to-cloud-over-fsk-via-piggybacking-on-a-periodic-reporting", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#99-fskepepmetricsreportbv02-verify-endpoint-sends-remaining-endpoint-metrics-to-cloud-over-fsk-via-piggybacking-on-a-periodic-reporting" },"212": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.10 FSK/EP/EPMETRICS/REPORT/BV/03: Verify Endpoint Metrics are uploaded via Piggybacking over FSK if the explicit reporting is disabled.", "content": "9.10.1 Test Purpose . When metrics capability is disabled, DUT is able to transmit endpoint metrics via FSK piggybacking instead of periodic reporting during regular reporting intervals. 9.10.2 Initial Conditions . | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | DUT is configured with metrics capability disabled. | Lower Tester operates in FSK mode. | . 9.10.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 2, FSK disconnected Note over Lower_Tester,Upper_Tester: Manually trigger periodic metrics reporting Upper_Tester->>DUT: metrics_send() Note over Lower_Tester,Upper_Tester: loop: Send uplinks until all metrics are piggybacked via FSK Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: 1B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data and piggybacked metrics) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: end of loop Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 9.10.4 Expected Results . 9.10.4.1 Pass Verdict . DUT transmits all metrics through FSK piggybacking instead of periodic reporting. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#910-fskepepmetricsreportbv03-verify-endpoint-metrics-are-uploaded-via-piggybacking-over-fsk-if-the-explicit-reporting-is-disabled", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#910-fskepepmetricsreportbv03-verify-endpoint-metrics-are-uploaded-via-piggybacking-over-fsk-if-the-explicit-reporting-is-disabled" },"213": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.11 FSK/EP/EPMETRICS/UL/BV/01: Verify Uplink messages Metrics and Total number of TX unique packets Metrics.", "content": "9.11.1 Test Purpose . DUT captures FSK uplink metrics and TX packets metrics. 9.11.2 Initial Conditions . | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in FSK mode. | . 9.11.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 2, FSK connected Upper_Tester->>DUT: clear_metrics(SID_METRICS_CAT_ALL) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_LINK) DUT->>Upper_Tester: Print FSK_LINK metrics \"num_ul: 0\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_MAC) DUT->>Upper_Tester: Print FSK_MAC metrics \"num_TX: 0\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE \"TX CRID: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_LINK) DUT->>Upper_Tester: Print FSK_LINK metrics \"num_ul: 1\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with the Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_MAC) DUT->>Upper_Tester: Print FSK_MAC metrics \"num_TX: 1\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE \"TX CRID: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_LINK) DUT->>Upper_Tester: Print FSK_LINK metrics \"num_ul: 2\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with the Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_MAC) DUT->>Upper_Tester: Print FSK_MAC metrics \"num_TX: 2\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE \"TX CRID: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_LINK) DUT->>Upper_Tester: Print FSK_LINK metrics \"num_ul: 3\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with the Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_MAC) DUT->>Upper_Tester: Print FSK_MAC metrics \"num_TX: 3\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 9.11.4 Expected Results . 9.11.4.1 Pass Verdict . DUT’s FSK uplink metrics increment after each FSK uplink transmission. DUT’s FSK TX packets metrics increment after each FSK packet transmission. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#911-fskepepmetricsulbv01-verify-uplink-messages-metrics-and-total-number-of-tx-unique-packets-metrics", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#911-fskepepmetricsulbv01-verify-uplink-messages-metrics-and-total-number-of-tx-unique-packets-metrics" },"214": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.12 FSK/EP/EPMETRICS/DL/BV/01: Verify Downlink messages Metrics and Total number of RX unique packets Metrics.", "content": "9.12.1 Test Purpose . DUT captures FSK downlink metrics and RX packets metrics. 9.12.2 Initial Conditions . | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in FSK mode. | . 9.12.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 2, FSK connected Upper_Tester->>DUT: clear_metrics(SID_METRICS_CAT_ALL) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_LINK) DUT->>Upper_Tester: Print FSK_LINK metrics \"num_dl: 0\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_MAC) DUT->>Upper_Tester: Print FSK_MAC metrics \"num_RX: 0\" Note over Lower_Tester,Upper_Tester: Continued on next page. sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Continued from previous page Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_LINK) DUT->>Upper_Tester: Print FSK_LINK metrics \"num_dl: 1\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_MAC) DUT->>Upper_Tester: Print FSK_MAC metrics \"num_RX: 1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_LINK) DUT->>Upper_Tester: Print FSK_LINK metrics \"num_dl: 2\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_MAC) DUT->>Upper_Tester: Print FSK_MAC metrics \"num_RX: 2\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_LINK) DUT->>Upper_Tester: Print FSK_LINK metrics \"num_dl: 3\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_FSK_MAC) DUT->>Upper_Tester: Print FSK_MAC metrics \"num_RX: 3\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 9.12.4 Expected Results . 9.12.4.1 Pass Verdict . DUT’s FSK downlink metrics increment after each FSK downlink reception. DUT’s FSK RX packets metrics increment after each FSK packet reception. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#912-fskepepmetricsdlbv01-verify-downlink-messages-metrics-and-total-number-of-rx-unique-packets-metrics", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#912-fskepepmetricsdlbv01-verify-downlink-messages-metrics-and-total-number-of-rx-unique-packets-metrics" },"215": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.13 LORA/EP/EPMETRICS/REPORT/BV/01: Verify Endpoint sends Endpoint Metrics to Cloud over LoRa in a specific time interval.", "content": "9.13.1 Test Purpose . DUT demonstrates capability to transmit endpoint metrics through LoRa connectivity based on the configured metrics periodicity. 9.13.2 Initial Conditions . | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | DUT is configured with metrics capability enabled. | Lower Tester operates in LoRa mode. | . 9.13.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 4, LoRa connected Note over Lower_Tester,Upper_Tester: Wait: metrics periodicity cycle - 1 minute post initial time synchronization Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_ALL) DUT->>Upper_Tester: Print all applicable metrics for enabled stacks Note over Lower_Tester,Upper_Tester: Wait: remaining 1 minute to complete periodicity cycle DUT->>Lower_Tester: NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_sent() Lower_Tester->>DUT: ACK_NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_received() Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_ALL) DUT->>Upper_Tester: Print all applicable metrics for enabled stacks Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 9.13.4 Expected Results . 9.13.4.1 Pass Verdict . Following time synchronization, DUT successfully transmits metrics over LoRa according to the configured periodicity. DUT receives Cloud acknowledgment for the transmitted metrics package. DUT resets metrics after periodic reporting completion. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#913-loraepepmetricsreportbv01-verify-endpoint-sends-endpoint-metrics-to-cloud-over-lora-in-a-specific-time-interval", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#913-loraepepmetricsreportbv01-verify-endpoint-sends-endpoint-metrics-to-cloud-over-lora-in-a-specific-time-interval" },"216": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.14 LORA/EP/EPMETRICS/REPORT/BV/02: Verify Endpoint sends remaining Endpoint Metrics to Cloud over LoRa via piggybacking on a periodic reporting.", "content": "9.14.1 Test Purpose . DUT implements metrics piggybacking over subsequent LoRa uplinks to complete metrics transmission when single periodic uplink capacity is insufficient. 9.14.2 Initial Conditions . | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | DUT is configured with metrics capability enabled. | Lower Tester operates in LoRa mode. | . 9.14.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 4, LoRa connected Note over Lower_Tester,Upper_Tester: Manually trigger periodic metrics reporting Upper_Tester->>DUT: metrics_send() DUT->>Lower_Tester: NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_sent() Lower_Tester->>DUT: ACK_NTFY_READ_METRICS_FWK DUT->>Upper_Tester: on_metrics_received() Note over Lower_Tester,Upper_Tester: loop: Send uplinks until all remaining metrics are piggybacked via LoRa Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: 1B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data and piggybacked metrics) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: end of loop Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 9.14.4 Expected Results . 9.14.4.1 Pass Verdict . DUT transmits remaining metrics from periodic reporting via LoRa uplink piggybacking. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#914-loraepepmetricsreportbv02-verify-endpoint-sends-remaining-endpoint-metrics-to-cloud-over-lora-via-piggybacking-on-a-periodic-reporting", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#914-loraepepmetricsreportbv02-verify-endpoint-sends-remaining-endpoint-metrics-to-cloud-over-lora-via-piggybacking-on-a-periodic-reporting" },"217": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.15 LORA/EP/EPMETRICS/REPORT/BV/03: Verify Endpoint Metrics are uploaded via Piggybacking over LoRa if the explicit reporting is disabled.", "content": "9.15.1 Test Purpose . When metrics capability is disabled, DUT is able to transmit endpoint metrics via LoRa piggybacking instead of periodic reporting during regular reporting intervals. 9.15.2 Initial Conditions . | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | DUT is configured with metrics capability disabled. | Lower Tester operates in LoRa mode. | . 9.15.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 4, LoRa disconnected Note over Lower_Tester,Upper_Tester: Manually trigger periodic metrics reporting Upper_Tester->>DUT: metrics_send() Note over Lower_Tester,Upper_Tester: loop: Send uplinks until all metrics are piggybacked via LoRa Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: 1B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data and piggybacked metrics) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: end of loop Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 9.15.4 Expected Results . 9.15.4.1 Pass Verdict . DUT transmits all metrics through LoRa piggybacking instead of periodic reporting. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#915-loraepepmetricsreportbv03-verify-endpoint-metrics-are-uploaded-via-piggybacking-over-lora-if-the-explicit-reporting-is-disabled", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#915-loraepepmetricsreportbv03-verify-endpoint-metrics-are-uploaded-via-piggybacking-over-lora-if-the-explicit-reporting-is-disabled" },"218": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.16 LORA/EP/EPMETRICS/UL/BV/01: Verify Uplink messages Metrics and Total number of TX normal packets Metrics.", "content": "9.16.1 Test Purpose . DUT captures LoRa uplink metrics and TX normal packets metrics. 9.16.2 Initial Conditions . | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode. | . 9.16.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 4, LoRa connected Upper_Tester->>DUT: clear_metrics(SID_METRICS_CAT_ALL) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_LINK) DUT->>Upper_Tester: Print LORA_LINK metrics \"num_ul: 0\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_MAC) DUT->>Upper_Tester: Print LORA_MAC metrics \"num_TX: 0\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE \"TX CRID: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_LINK) DUT->>Upper_Tester: Print LORA_LINK metrics \"num_ul: 1\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with the Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_MAC) DUT->>Upper_Tester: Print LORA_MAC metrics \"num_TX: 1\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE \"TX CRID: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_LINK) DUT->>Upper_Tester: Print LORA_LINK metrics \"num_ul: 2\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with the Command data) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: Continued on next page. sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Continued from previous page Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_MAC) DUT->>Upper_Tester: Print LORA_MAC metrics \"num_TX: 2\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE \"TX CRID: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_LINK) DUT->>Upper_Tester: Print LORA_LINK metrics \"num_ul: 3\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with the Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_MAC) DUT->>Upper_Tester: Print LORA_MAC metrics \"num_TX: 3\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 9.16.4 Expected Results . 9.16.4.1 Pass Verdict . DUT’s LoRa uplink metrics increment after each LoRa uplink transmission. DUT’s LoRa TX packets metrics increment after each LoRa packet transmission. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#916-loraepepmetricsulbv01-verify-uplink-messages-metrics-and-total-number-of-tx-normal-packets-metrics", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#916-loraepepmetricsulbv01-verify-uplink-messages-metrics-and-total-number-of-tx-normal-packets-metrics" },"219": { "doc": "9. Endpoint Metrics Test Cases", "title": "9.17 LORA/EP/EPMETRICS/DL/BV/01: Verify Downlink messages Metrics and Total number of RX packets Metrics.", "content": "9.17.1 Test Purpose . DUT captures LoRa downlink metrics and RX packets metrics. 9.17.2 Initial Conditions . | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode. | . 9.17.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 4, LoRa connected Upper_Tester->>DUT: clear_metrics(SID_METRICS_CAT_ALL) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_LINK) DUT->>Upper_Tester: Print LORA_LINK metrics \"num_dl: 0\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_MAC) DUT->>Upper_Tester: Print LORA_MAC metrics \"num_RX: 0\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_LINK) DUT->>Upper_Tester: Print LORA_LINK metrics \"num_dl: 1\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_MAC) DUT->>Upper_Tester: Print LORA_MAC metrics \"num_RX: 1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_LINK) DUT->>Upper_Tester: Print LORA_LINK metrics \"num_dl: 2\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_MAC) DUT->>Upper_Tester: Print LORA_MAC metrics \"num_RX: 2\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with any Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: any\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_LINK) DUT->>Upper_Tester: Print LORA_LINK metrics \"num_dl: 3\" Upper_Tester->>DUT: print_metrics(SID_METRICS_CAT_LORA_MAC) DUT->>Upper_Tester: Print LORA_MAC metrics \"num_RX: 3\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 9.17.4 Expected Results . 9.17.4.1 Pass Verdict . DUT’s LoRa downlink metrics increment after each LoRa downlink reception. DUT’s LoRa RX packets metrics increment after each LoRa normal packet reception. ", "url": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#917-loraepepmetricsdlbv01-verify-downlink-messages-metrics-and-total-number-of-rx-packets-metrics", "relUrl": "/specifications/sidewalk-test-spec/endpoint-metrics-test-cases.html#917-loraepepmetricsdlbv01-verify-downlink-messages-metrics-and-total-number-of-rx-packets-metrics" },"220": { "doc": "4.3 Entity identification", "title": "4.3 Entity identification", "content": "Devices and services in Amazon Sidewalk have unique identification numbers. Endpoints are identified by a Device ID number, Cloud Services are identified by a Cloud Service ID. 4.3.1 Device ID . Device ID is a number that uniquely identifies a device in the Amazon Sidewalk network. Amazon Sidewalk has three types of Device ID: . | 32 B SMSN | 5 B Sidewalk ID | 5 B TXID | . 4.3.2 Sidewalk Manufacturing Serial Number (SMSN) . For registration, the Amazon Sidewalk protocol shall use a subset(Size encoded 5B) of the Amazon Sidewalk Manufacturing Serial Number (SMSN) as the Device ID. The SMSN is constructed by calculating a hash over numbers of device-unique fields, using the following formula: . | SMSN=SHA256(DMS-DeviceType, ([DSN | unique serial number], APID)) | . where: . | SMSN - Unique identifier generated from values controlled by the customer. The unique identifier is the result of a SHA256 hashing calculation | DMS-DeviceType - device type issued by DMS for the customer. | DSN or Unique Serial Number - customer provided identifier that is unique to a particular device. If the customer has the concept of a Device Serial Number (DSN) this can be used, otherwise a UUID is sufficient. | APID- Advertised Product ID - shortened product ID delivered by DMS present in the MFG page. | . 4.3.3 Amazon Sidewalk ID . The Amazon Sidewalk ID is onboarded to the Endpoint during the registration process. After the registration process, the Amazon Sidewalk ID is not used for communication within the Amazon Sidewalk network. The Amazon Sidewalk ID is not used after registration to help protect user privacy. Instead of the Amazon Sidewalk ID, TXID is used in the Amazon Sidewalk network. The process of assigning a ”random ID” (TXID) to a device is called obfuscation. For more information, see section 4.6. Table 4.5 Device ID types . | Device ID Type | Sub-Type | Usage | Periodicity | . | SMSN |   | Device Registration | Pre-registration | . | Sidewalk ID |   | Device Registration | During registration | . | TX_ID | Counter-based | 1. Time sync on device when device has no notion of time 2. Deregistration from cloud Service when device has no notion of time | During time synchronization and factory reset | . | TX_ID | Time Based | 1. Regular Sidewalk data path communication 2. Periodic time sync for error correction in deviation when device has notion of time 3. Deregistration from cloud Service when device has notion of time | Every 15 min | . For the Endpoint, the first 3 bits are defined as 0b101 and the remaining 37 bits allow more than 137 billion devices to be addressed. Device identity (Device ID and credentials) is built during the manufacturing provisioning process. During device provisioning, device control records containing the device serial number (SMSN) and public keys issued are stored in control logs, and uploaded to AWS. For more information, see section 4.4.2. 4.3.4 Service ID . Cloud services are identified by a unique Cloud Service ID number. Because Cloud Service ID can have a value from 0 to 237 - 1, it is not required to send 5 B size-encoded Cloud Service ID address over the air.Figure 4.5 is an example of Cloud Service ID 36 (0x24) being converted to a size-encoded address. fig 4.5 Service ID . There are four types of devices in the Amazon Sidewalk network (Endpoint, Gateway, Amazon Sidewalk Network Server and Application Server). Each device contains a unique ID (identity). IDs are secured by identity credentials built into the device during device manufacturing/releasing. Keys and certificates are issued based on the PKI security model using PKI certificates stored in the devices. Devices are connected by encrypting network and application data with separate keys. Links between termination points at each layer are secured by encryption with an ephemeral key exchange. Endpoint ’K’ (one of k Endpoints connected to a Gateway ’M’) contains credentials related to its own ID, Link Layer related to temporary Endpoint’s TXID, application layer and PKI infrastructure. Gateway ’M’ (one of m Gateways connected to a Network Server) contains credentials related to its own ID, Network Server credentials associated with its own ID and PKI certificates. Network Server contains its own credentials, a list of credentials related to each of the Gateways connected to the Network Server at the Network Layer, and a list of credentials of each Endpoint (addressed by TXID and Device ID) at the Link Layer. Application Server contains its own credentials and also Endpoint credentials. Figure 4.6 shows an overview of certificate and key locations within the system. Associated credentials are presented in dotted boxes. fig 4.6 Sidewalk network security . ", "url": "/specifications/sidewalk-protocol-spec/security/entity-identification.html", "relUrl": "/specifications/sidewalk-protocol-spec/security/entity-identification.html" },"221": { "doc": "11. EP Capability Test Cases", "title": "EP Capability Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#ep-capability-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#ep-capability-test-cases" },"222": { "doc": "11. EP Capability Test Cases", "title": "Test Case ID: CMN-EP-CAPABILITY-REPORT-BV-01: When KV store does not have the capability report saved, the event to send capability is scheduled", "content": "| Field | Value | . | Case ID | C103619346 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Clear capability KV store to simulate first-time setup (no capability report saved):print clear_cap 3 | CMD: ERR: 0Key check: KV store cleared, EN will send capability report on next startup | . | 2 | Initialize stack and start:BLE: sid init 1 / sid startFSK: sid init 2 / sid startLoRa: sid init 3 / sid start | CMD: ERR: 0 | . | 3 | Wait for time sync and join:BLE: Wait for time sync onlyFSK/LoRa: Wait for time sync and join | Time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: -Join (FSK/LoRa): Njoin(1, 2) st 2->6 | . | 4 | Check EN sends capability report and receives ACKBLE: establish BLE connection first: sid conn_req 1 | ECPFG(2) st 2->5 (Ready to send)Sent capability and config message: [Tx][0:2:2:- ] st:0ECPFG(5) st 5->6 (Waiting for ACK)ECPFG(2) st 6->2 (ACK received, back to check state)ECPFG(6) st 2->7 (Updating KV store)Received capability and config message: [Rx][0:2:3:- ] err:0ECPFG(2) st 7->10 (Done, idle)Key check: Capability report sent and ACK received | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-report-bv-01-when-kv-store-does-not-have-the-capability-report-saved-the-event-to-send-capability-is-scheduled", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-report-bv-01-when-kv-store-does-not-have-the-capability-report-saved-the-event-to-send-capability-is-scheduled" },"223": { "doc": "11. EP Capability Test Cases", "title": "Test Case ID: CMN-EP-CAPABILITY-REPORT-BV-02: When Capability stored in the KV store is equal to the capability of the Endpoint, the Capability event report is not generated", "content": "| Field | Value | . | Case ID | C103619347 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Clear capability KV store to simulate first-time setup (no capability report saved):print clear_cap 3 | CMD: ERR: 0Key check: KV store cleared, EN will send capability report on next startup | . | 2 | Initialize stack and start:BLE: sid init 1 / sid startFSK: sid init 2 / sid startLoRa: sid init 3 / sid start | CMD: ERR: 0 | . | 3 | Wait for time sync and join:BLE: Wait for time sync onlyFSK/LoRa: Wait for time sync and join | Time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: -Join (FSK/LoRa): Njoin(1, 2) st 2->6 | . | 4 | Check EN sends capability report and receives ACKBLE: establish BLE connection first: sid conn_req 1 | ECPFG(2) st 2->5 (Ready to send)Sent capability and config message: [Tx][0:2:2:- ] st:0ECPFG(5) st 5->6 (Waiting for ACK)ECPFG(2) st 6->2 (ACK received, back to check state)ECPFG(6) st 2->7 (Updating KV store)Received capability and config message: [Rx][0:2:3:- ] err:0ECPFG(2) st 7->10 (Done, idle)Key check: Capability report sent and ACK received | . | 5 | Wait 5 seconds, then reinitialize stack and wait for time sync/join:sid deinitBLE: sid init 1 / sid startFSK: sid init 2 / sid startLoRa: sid init 3 / sid startBLE: Wait for time sync only, then: sid conn_req 1FSK/LoRa: Wait for time sync and join | Time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: -Join (FSK/LoRa): Njoin(1, 2) st 2->6 | . | 6 | Verify EN does NOT send capability report again | No [Tx][0:2:2:- ] within 20 secondsKey check: Capability report NOT sent (KV store already synced with cloud) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-report-bv-02-when-capability-stored-in-the-kv-store-is-equal-to-the-capability-of-the-endpoint-the-capability-event-report-is-not-generated", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-report-bv-02-when-capability-stored-in-the-kv-store-is-equal-to-the-capability-of-the-endpoint-the-capability-event-report-is-not-generated" },"224": { "doc": "11. EP Capability Test Cases", "title": "Test Case ID: CMN-EP-CAPABILITY-REPORT-BV-03: Endpoint default capability report", "content": "| Field | Value | . | Case ID | C103619348 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Init and start stack:sid init <stack>sid start | CMD: ERR: 0 | . | 2 | Wait until time sync and join complete, for BLE, wait time sync complete only | Time sync complete: [Rx][0:108:3:4] err:0Join complete: [Rx][0:22F:3:4] err:0 | . | 3 | Check if EN send capability report and receive ACK, for BLE, need to establish BLE connection first (if KV store of EN synced with cloud, ignore this step) | ECPFG(2) st 2->5Sent capability and config message: [Tx][0:2:2:<stack>] st:0ECPFG(5) st 5->6ECPFG(2) st 6->2ECPFG(6) st 2->7Received capability and config message: [Rx][0:2:3:<stack>] err:0ECPFG(2) st 7->10 | . | 4 | Print the current capabilities:print get_cap 3 | Shows EP capability content including: Capability version, SDK version, links enabled, features_support, Qualification id, Traffic threshold table id, metrics periodicity, TX power values, threshold rates | . | 5 | Get capability via API | Check the capability is same as step 4 (enableMetricsReport, featuresSupported, linksSupported, manufacturerType, maxTxPower, metricsPeriodicity, qualificationId, sdkVersion, trafficThresholdTable) | . | 6 | Search on splunk, if KV store of EN already synced with cloud on step 3, initiateRequestCapabilities via API then search on splunk:index=halo_operations* <sidewalkID> methodIdentifier = \"NotifyCapabilityHandler\" | All values should same as step 4 | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-report-bv-03-endpoint-default-capability-report", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-report-bv-03-endpoint-default-capability-report" },"225": { "doc": "11. EP Capability Test Cases", "title": "Test Case ID: CMN-EP-CAPABILITY-REQUEST-BV-01: Endpoint is online, send request to get endpoint capability", "content": "| Field | Value | . | Case ID | C103619350 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize stack, start, and wait for time sync/join:BLE: sid init 1 / sid start / Wait for time syncFSK: sid init 2 / sid start / Wait for time sync and joinLoRa: sid init 3 / sid start / Wait for time sync and join | Time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: -Join (FSK/LoRa): Njoin(1, 2) st 2->6 | . | 2 | Initiate request capability via API, then check EN sends capability report and ACK received | API response: {\"requestId\": \"<id>\", \"status\": \"SUCCESS\"}On EN: [Rx][0:2:0:- ] err:0 (Read request received)ECPFG(2) st 2->5 (Ready to send)Sent capability and config message: [Tx][0:2:3:- ] st:0ECPFG(5) st 5->10 (Done, idle)Key check: EN received capability request and sent response | . | 3 | Wait 20 seconds for cloud to update, then get capability via API and verify it matches EN:print get_cap 3 | API response capability matches EN capability valuesKey check: Cloud capability same as EN capability | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-request-bv-01-endpoint-is-online-send-request-to-get-endpoint-capability", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-request-bv-01-endpoint-is-online-send-request-to-get-endpoint-capability" },"226": { "doc": "11. EP Capability Test Cases", "title": "Test Case ID: CMN-EP-CAPABILITY-CONFIGURE-BV-01: Endpoint configuration shall be updated on user setting", "content": "| Field | Value | . | Case ID | C103619351 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize stack, start, and wait for time sync/join:BLE: sid init 1 / sid start / Wait for time syncFSK: sid init 2 / sid start / Wait for time sync and joinLoRa: sid init 3 / sid start / Wait for time sync and join | Time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: -Join (FSK/LoRa): Njoin(1, 2) st 2->6 | . | 2 | Set configuration via API with custom values (trafficThresholdTable with tableId=1, custom LoRa/FSK/BLE rates, enableTrafficThrottling=false, enableMetricsReport=false, metricsPeriodicity=9) | Received write capability and config message:[Rx][0:2:1:- ] err:0ECPFG(8) st 10->2 (SET_CFG event)ECPFG(2) st 2->5 (Ready to send)Response write capability and config message:[Tx][0:2:3:- ] st:0ECPFG(5) st 5->10 (Done, idle)Key check: EN received configuration and sent response | . | 3 | Wait 20 seconds for cloud to update, then verify cloud capability matches EN:print get_cap 3 | API response capability matches EN capability valuesKey check: Cloud capability same as EN capability after configuration update | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-configure-bv-01-endpoint-configuration-shall-be-updated-on-user-setting", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-configure-bv-01-endpoint-configuration-shall-be-updated-on-user-setting" },"227": { "doc": "11. EP Capability Test Cases", "title": "Test Case ID: CMN-EP-CAPABILITY-REGISTER-BV-01: Endpoint capability is set to default after re-registration", "content": "| Field | Value | . | Case ID | C103619352 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize stack, start, and wait for time sync/join:BLE: sid init 1 / sid start / Wait for time syncFSK: sid init 2 / sid start / Wait for time sync and join | Time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: -Join (FSK): Njoin(1, 2) st 2->6 | . | 2 | Set configuration via API with custom values (trafficThresholdTable with tableId=3, all rates=1, enableTrafficThrottling=false, enableMetricsReport=false, metricsPeriodicity=1) | Received write capability and config message:[Rx][0:2:1:- ] err:0ECPFG(8) st 10->2ECPFG(2) st 2->5Response write capability and config message:[Tx][0:2:3:- ] st:0ECPFG(5) st 5->10Key check: EN received configuration and sent response | . | 3 | Deregister EN via API | EVENT SID STATUS: State: 1, Reg: 1, Time: 1, Link_Mask: 0Key check: EN deregistered (Reg: 1) | . | 4 | Re-register EN, then reinitialize stack and wait for time sync/join:BLE: sid init 1 / sid start / Wait for time sync / sid conn_req 1FSK: sid init 2 / sid start / Wait for time sync and join | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: -Join (FSK): Njoin(1, 2) st 2->6Key check: EN re-registered (Reg: 0) | . | 5 | Check EN sends capability report and receives ACKBLE: establish BLE connection first: sid conn_req 1 | ECPFG(2) st 2->5 (Ready to send)Sent capability and config message: [Tx][0:2:2:- ] st:0ECPFG(5) st 5->6 (Waiting for ACK)ECPFG(2) st 6->2 (ACK received)ECPFG(6) st 2->7 (Updating KV store)Received capability and config message: [Rx][0:2:3:- ] err:0ECPFG(2) st 7->10 (Done, idle)Key check: Capability report sent and ACK received | . | 6 | Verify capability back to default and matches cloud:print get_cap 3 | All capabilities should return to default valuesAPI response capability matches EN default capabilityKey check: Capability reset to default after re-registration | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-register-bv-01-endpoint-capability-is-set-to-default-after-re-registration", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-register-bv-01-endpoint-capability-is-set-to-default-after-re-registration" },"228": { "doc": "11. EP Capability Test Cases", "title": "Test Case ID: CMN-EP-CAPABILITY-THRESHOLD-BV-01: Traffic threshold reset mechanism", "content": "| Field | Value | . | Case ID | C103619353 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize stack, start, and wait for time sync/join:BLE: sid init 1 / sid start / Wait for time syncFSK: sid init 2 / sid start / Wait for time sync and joinLoRa: sid init 3 / sid start / Wait for time sync and join | Time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: -Join (FSK/LoRa): Njoin(1, 2) st 2->6 | . | 2 | Set configuration via API (low threshold, enable throttling): trafficThresholdTable with tableId=1, LoRa staticMaxPacketPerDay=3, FSK packetsPerMin=3, BLE packetsPerMin=3, enableTrafficThrottling=true | Received write capability and config message:[Rx][0:2:1:- ] err:0ECPFG(8) st 10->2ECPFG(2) st 2->5Response write capability and config message:[Tx][0:2:3:- ] st:0ECPFG(5) st 5->10Key check: EN received configuration and sent response | . | 3 | Verify EN applied new traffic config:print get_cap 3 | Features support ... Traffic throttling enabled 1Traffic threshold table id 1Key check: New traffic config applied | . | 4 | Send 3 ULs (BLE: establish connection first):BLE: sid conn_req 1sid send TEST (repeat 3 times) | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: - LINK_MODE: 0 ADDITIONAL ATTRS: 0Key check: All 3 ULs sent successfully | . | 5 | sid stop / sid start, wait for joined (BLE: connect again):sid stopsid startBLE: sid conn_req 1FSK/LoRa: Wait for join | Time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: -Join (FSK/LoRa): Njoin(1, 2) st 2->6 | . | 6 | Send 1 UL (should be dropped - threshold not reset by sid stop/start):sid send TEST | TRAFFIC THRESHOLD RATE EXCEEDED on LINK - FOR LIMIT TYPE 0CMD: ERR: -20Key check: UL dropped (threshold not reset by sid stop/start) | . | 7 | Reinitialize stack to reset threshold:sid deinitBLE: sid init 1 / sid start / Wait for time sync / sid conn_req 1FSK: sid init 2 / sid start / Wait for time sync and joinLoRa: sid init 3 / sid start / Wait for time sync and join | Time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: -Join (FSK/LoRa): Njoin(1, 2) st 2->6 | . | 8 | Send 3 ULs (threshold reset after reinit):sid send TEST (repeat 3 times) | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: - LINK_MODE: 0 ADDITIONAL ATTRS: 0Key check: All 3 ULs sent successfully (threshold reset) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-threshold-bv-01-traffic-threshold-reset-mechanism", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-threshold-bv-01-traffic-threshold-reset-mechanism" },"229": { "doc": "11. EP Capability Test Cases", "title": "Test Case ID: CMN-EP-CAPABILITY-PERIODICITY-BV-01: Set metrics periodicity", "content": "| Field | Value | . | Case ID | C103619354 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize stack and wait for time sync/join:BLE: sid init 1 / sid start / Wait for time syncFSK: sid init 2 / sid start / Wait for time sync and joinLoRa: sid init 3 / sid start / Wait for time sync and joinPlease choose either one | Time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: -Join (FSK/LoRa): Njoin(1, 2) st 2->6 | . | 2 | Check EN sends capability report and receives ACKBLE: establish BLE connection first: sid conn_req 1 | ECPFG(2) st 2->5 (Ready to send)Sent capability and config message: [Tx][0:2:2:- ] st:0ECPFG(5) st 5->6 (Waiting for ACK)ECPFG(2) st 6->2 (ACK received)ECPFG(6) st 2->7 (Updating KV store)Received capability and config message: [Rx][0:2:3:- ] err:0ECPFG(2) st 7->10 (Done, idle)Key check: Capability report sent and ACK received | . | 3 | Set metricsPeriodicity to 1 and enableMetricsReport to true via API:{\"deviceId\": \"{<DEVICE_ID>}\", \"enableMetricsReport\": true, \"metricsPeriodicity\": 1} | Received write capability and config message:[Rx][0:2:1:- ] err:0ECPFG(8) st 10->2 (SET_CFG event)ECPFG(2) st 2->5 (Ready to send)Response write capability and config message:[Tx][0:2:3:- ] st:0ECPFG(5) st 5->10 (Done, idle)Key check: EN received configuration and sent response | . | 4 | Get capability via API, verify metricsPeriodicity and enableMetricsReport | enableMetricsReport: truemetricsPeriodicity: 1Key check: metricsPeriodicity = 1 (6 hours), enableMetricsReport = true | . | 5 | Print capabilities on EN:print get_cap 3 | metrics periodicity 6 hoursmetrics enabled 1Key check: EN shows correct metrics periodicity | . | 6 | Reboot EN and restart stack, then wait 6 hours:rebootBLE: sid init 1 / sid start / Wait for time syncFSK: sid init 2 / sid start / Wait for time sync and joinLoRa: sid init 3 / sid start / Wait for time sync and joinWait 6 hours | Time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: -After 6 hours: metrics send to cloudENC-S: M:15 [B:E:2] err 0 | . | 7 | Search on Splunk to verify metrics report sent:index=halo_operations* <sidewalkID> methodIdentifier = \"NotifyCapabilityHandler\" | Metrics report found on SplunkKey check: EN sent metrics report after 6 hours | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-periodicity-bv-01-set-metrics-periodicity", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-periodicity-bv-01-set-metrics-periodicity" },"230": { "doc": "11. EP Capability Test Cases", "title": "Test Case ID: CMN-EP-CAPABILITY-PERIODICITY-BV-02: Set metrics periodicity when link metrics is disabled", "content": "| Field | Value | . | Case ID | C103619355 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize stack and wait for time sync/join:BLE: sid init 1 / sid start / Wait for time syncFSK: sid init 2 / sid start / Wait for time sync and joinLoRa: sid init 3 / sid start / Wait for time sync and join | Time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: -Join (FSK/LoRa): Njoin(1, 2) st 2->6 | . | 2 | Check EN sends capability report and receives ACKBLE: establish BLE connection first: sid conn_req 1 | ECPFG(2) st 2->5 (Ready to send)Sent capability and config message: [Tx][0:2:2:- ] st:0ECPFG(5) st 5->6 (Waiting for ACK)ECPFG(2) st 6->2 (ACK received)ECPFG(6) st 2->7 (Updating KV store)Received capability and config message: [Rx][0:2:3:- ] err:0ECPFG(2) st 7->10 (Done, idle)Key check: Capability report sent and ACK received | . | 3 | Set metricsPeriodicity to 1 and enableMetricsReport to false via API:{\"deviceId\": \"{<DEVICE_ID>}\", \"enableMetricsReport\": false, \"metricsPeriodicity\": 1} | Received write capability and config message:[Rx][0:2:1:- ] err:0ECPFG(8) st 10->2 (SET_CFG event)ECPFG(2) st 2->5 (Ready to send)Response write capability and config message:[Tx][0:2:3:- ] st:0ECPFG(5) st 5->10 (Done, idle)Key check: EN received configuration and sent response | . | 4 | Get capability via API, verify metricsPeriodicity and enableMetricsReport | enableMetricsReport: falsemetricsPeriodicity: 1Key check: metricsPeriodicity = 1 (6 hours), enableMetricsReport = false | . | 5 | Print capabilities on EN:print get_cap 3 | metrics periodicity 6 hoursmetrics enabled 0Key check: EN shows metrics disabled | . | 6 | Reboot EN and restart stack, then wait 6 hours:rebootBLE: sid init 1 / sid start / Wait for time syncFSK: sid init 2 / sid start / Wait for time sync and joinLoRa: sid init 3 / sid start / Wait for time sync and joinWait 6 hours | Time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: - | . | 7 | Search on Splunk to verify metrics report NOT sent:index=halo_operations* <sidewalkID> methodIdentifier = \"NotifyCapabilityHandler\" | No metrics report found on SplunkKey check: EN did NOT send metrics report (enableMetricsReport = false) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-periodicity-bv-02-set-metrics-periodicity-when-link-metrics-is-disabled", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-cmn-ep-capability-periodicity-bv-02-set-metrics-periodicity-when-link-metrics-is-disabled" },"231": { "doc": "11. EP Capability Test Cases", "title": "Test Case ID: BLE-EP-CAPABILITY-THRESHOLD-BV-01: Verify traffic thresholds for BLE stack", "content": "| Field | Value | . | Case ID | C103619361 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack and wait for time sync:sid init 1sid start | CMD: ERR: 0EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 | . | 2 | Establish BLE connection:sid conn_req 1 | CMD: ERR: 0EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1Key check: BLE connected | . | 3 | Check EN capability synced with cloud (KV_STORE updated) | ECPFG(2) st 7->10 (Done, idle)Key check: Capability synced | . | 4 | Set configuration via API (low threshold, enable throttling): trafficThresholdTable with tableId=1, BLE packetsPerMin=1, enableTrafficThrottling=true | Received write capability and config message:[Rx][0:2:1:- ] err:0ECPFG(8) st 10->2ECPFG(2) st 2->5Response write capability and config message:[Tx][0:2:3:- ] st:0ECPFG(5) st 5->10Key check: EN received configuration and sent response | . | 5 | Verify EN applied new traffic config:print get_cap 3 | Traffic throttling enabled 1BLE max packets per min 1Key check: New traffic config applied | . | 6 | Send 4 ULs with BLE connection:sid conn_req 1T=0s: sid send TEST (1st UL)T=25s: sid send TEST (2nd UL)T=47s: sid send TEST (3rd UL)T=65s: sid send TEST (4th UL) | 1st UL: EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: - LINK_MODE: 0 ADDITIONAL ATTRS: 02nd UL: TRAFFIC THRESHOLD RATE EXCEEDED on LINK - FOR LIMIT TYPE 0 CMD: ERR: -203rd UL: TRAFFIC THRESHOLD RATE EXCEEDED on LINK - FOR LIMIT TYPE 0 CMD: ERR: -204th UL: EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: - LINK_MODE: 0 ADDITIONAL ATTRS: 0Key check: UL 2~3 dropped (threshold exceeded), UL 4 success after threshold reset | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-ble-ep-capability-threshold-bv-01-verify-traffic-thresholds-for-ble-stack", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-ble-ep-capability-threshold-bv-01-verify-traffic-thresholds-for-ble-stack" },"232": { "doc": "11. EP Capability Test Cases", "title": "Test Case ID: FSK-EP-CAPABILITY-THRESHOLD-BV-01: Verify traffic threshold for FSK stack", "content": "| Field | Value | . | Case ID | C103619362 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize FSK stack and wait for time sync and join:sid init 2sid start | CMD: ERR: 0EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2Njoin(1, 2) st 2->6 | . | 2 | Check EN capability synced with cloud (KV_STORE updated) | ECPFG(2) st 7->10 (Done, idle)Key check: Capability synced | . | 3 | Set configuration via API (low threshold, enable throttling): trafficThresholdTable with tableId=1, FSK packetsPerMin=1, enableTrafficThrottling=true | Received write capability and config message:[Rx][0:2:1:- ] err:0ECPFG(8) st 10->2ECPFG(2) st 2->5Response write capability and config message:[Tx][0:2:3:- ] st:0ECPFG(5) st 5->10Key check: EN received configuration and sent response | . | 4 | Verify EN applied new traffic config:print get_cap 3 | Traffic throttling enabled 1FSK max packets per min 1Key check: New traffic config applied | . | 5 | Send 4 ULs:T=0s: sid send TEST (1st UL)T=25s: sid send TEST (2nd UL)T=47s: sid send TEST (3rd UL)T=65s: sid send TEST (4th UL) | 1st UL: EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: - LINK_MODE: 0 ADDITIONAL ATTRS: 02nd UL: TRAFFIC THRESHOLD RATE EXCEEDED on LINK - FOR LIMIT TYPE 0 CMD: ERR: -203rd UL: TRAFFIC THRESHOLD RATE EXCEEDED on LINK - FOR LIMIT TYPE 0 CMD: ERR: -204th UL: EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: - LINK_MODE: 0 ADDITIONAL ATTRS: 0Key check: UL 2~3 dropped (threshold exceeded), UL 4 success after threshold reset | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-fsk-ep-capability-threshold-bv-01-verify-traffic-threshold-for-fsk-stack", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-fsk-ep-capability-threshold-bv-01-verify-traffic-threshold-for-fsk-stack" },"233": { "doc": "11. EP Capability Test Cases", "title": "Test Case ID: LORA-EP-CAPABILITY-THRESHOLD-BV-01: Verify traffic threshold on static endpoint of LoRa", "content": "| Field | Value | . | Case ID | C103619363 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize LoRa stack and wait for time sync and join:sid init 3sid start | CMD: ERR: 0EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4Njoin(1, 2) st 2->6 | . | 2 | Check EN capability synced with cloud (KV_STORE updated) | ECPFG(2) st 7->10 (Done, idle)Key check: Capability synced | . | 3 | Set configuration via API (low threshold, enable throttling): trafficThresholdTable with tableId=1, LoRa staticMaxPacketPerDay=3, staticBurstRate=1 second, enableTrafficThrottling=true | Received write capability and config message:[Rx][0:2:1:- ] err:0ECPFG(8) st 10->2ECPFG(2) st 2->5Response write capability and config message:[Tx][0:2:3:- ] st:0ECPFG(5) st 5->10Key check: EN received configuration and sent response | . | 4 | Verify EN applied new traffic config:print get_cap 3 | Traffic throttling enabled 1LoRa static burst rate 1 message every 1 secondsLoRa static max packets per day 3Key check: New traffic config applied | . | 5 | Send 4 ULs (verify burst rate):T=0s: sid send TEST (1st UL)T=25s: sid send TEST (2nd UL)T=47s: sid send TEST (3rd UL)T=65s: sid send TEST (4th UL) | 1st UL: EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: - LINK_MODE: 0 ADDITIONAL ATTRS: 02nd UL: TRAFFIC THRESHOLD RATE EXCEEDED on LINK - FOR LIMIT TYPE 0 CMD: ERR: -203rd UL: TRAFFIC THRESHOLD RATE EXCEEDED on LINK - FOR LIMIT TYPE 0 CMD: ERR: -204th UL: EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: - LINK_MODE: 0 ADDITIONAL ATTRS: 0Key check: UL 2~3 dropped (threshold exceeded), UL 4 success after threshold reset | . | 6 | Wait 61 seconds, then send 3 more ULs (verify max packets per day):T=0s: sid send TEST (1st UL)T=65s: sid send TEST (2nd UL)T=75s: sid send TEST (3rd UL) | 1st UL: EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: - LINK_MODE: 0 ADDITIONAL ATTRS: 02nd UL: TRAFFIC THRESHOLD RATE EXCEEDED on LINK - FOR LIMIT TYPE 0 CMD: ERR: -203rd UL: TRAFFIC THRESHOLD RATE EXCEEDED on LINK - FOR LIMIT TYPE 0 CMD: ERR: -20Key check: Max packets per day (3) reached, subsequent ULs dropped | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-lora-ep-capability-threshold-bv-01-verify-traffic-threshold-on-static-endpoint-of-lora", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html#test-case-id-lora-ep-capability-threshold-bv-01-verify-traffic-threshold-on-static-endpoint-of-lora" },"234": { "doc": "11. EP Capability Test Cases", "title": "11. EP Capability Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-capability-test-cases.html" },"235": { "doc": "10. EP Metrics Test Cases", "title": "EP Metrics Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#ep-metrics-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#ep-metrics-test-cases" },"236": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: CMN/EP/EPMETRICS/METRICS/BV/01: Verify Endpoint has corresponding metrics but not invalid metrics enabled", "content": "| Field | Value | . | Case ID | C103619324 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize stack and start:sid init 1 / sid start (BLE only)sid init 2 / sid start (FSK only)sid init 3 / sid start (LoRa only)sid init 4 / sid start (BLE+LoRa)sid init 5 / sid start (BLE+FSK)sid init 6 / sid start (FSK+LoRa)sid init 7 / sid start (BLE+FSK+LoRa) | CMD: ERR: 0 | . | 2 | For non-LoRa stacks (BLE, FSK, BLE+LoRa, BLE+FSK, FSK+LoRa, BLE+FSK+LoRa), initialize SBDT:sbdt init | CMD: ERR: 0 | . | 3 | Verify expected metrics categories exist, unexpected ones do not:print metrics 0x36 | Integration Type / Present / Not Present:BLE only: BLE_LINK, SBDT / LORA_MAC, FSK_MAC, NWK_SYNC, GWDFSK only: FSK_MAC, FSK_LINK, NWK_SYNC, GWD, FFN, SBDT / LORA_MAC, BLE_LINKLoRa only: LORA_MAC, LORA_LINK, NWK_SYNC / FSK_MAC, BLE_LINK, GWD, SBDTBLE + LoRa: LORA_MAC, LORA_LINK, BLE_LINK, NWK_SYNC, SBDT / FSK_MAC, GWDBLE + FSK: FSK_MAC, FSK_LINK, BLE_LINK, NWK_SYNC, GWD, FFN, SBDT / LORA_MACFSK + LoRa: LORA_MAC, LORA_LINK, FSK_MAC, FSK_LINK, NWK_SYNC, GWD, FFN, SBDT / BLE_LINKBLE + FSK + LoRa: All categories present / None | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-cmnepepmetricsmetricsbv01-verify-endpoint-has-corresponding-metrics-but-not-invalid-metrics-enabled", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-cmnepepmetricsmetricsbv01-verify-endpoint-has-corresponding-metrics-but-not-invalid-metrics-enabled" },"237": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: BLE/EP/EPMETRICS/REPORT/BV/01: Verify Endpoint sends Endpoint Metrics to Cloud over BLE in a specific time interval", "content": "| Field | Value | . | Case ID | C103619325 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack and wait for time sync:sid init 1 (or 4, 5, 7 - any stack with BLE enabled)sid start | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1Key check: Time synced (Time: 0) | . | 2 | Print all metrics:print metrics 0x36 | EN shows metrics data | . | 3 | Wait uploading interval for periodic reporting or trigger by command:metrics sendDefault uploading interval is 24 hoursCheck current interval: print get_cap 3 -> metrics periodicity | ENC: M:15 [B:E:2]TX CRID: <crid>Key check: EN creates BLE connection and sends metrics to cloud | . | 4 | Check on Splunk by TX CRID:index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PERIODIC\" | Metrics data uploaded to cloud | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-bleepepmetricsreportbv01-verify-endpoint-sends-endpoint-metrics-to-cloud-over-ble-in-a-specific-time-interval", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-bleepepmetricsreportbv01-verify-endpoint-sends-endpoint-metrics-to-cloud-over-ble-in-a-specific-time-interval" },"238": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: BLE/EP/EPMETRICS/REPORT/BV/02: Verify Endpoint sends remaining Endpoint Metrics to Cloud over BLE via piggybacking on a periodic reporting", "content": "| Field | Value | . | Case ID | C103619326 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack and wait for time sync:sid init 7sid start | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1Key check: Time synced (Time: 0) | . | 2 | Initialize SBDT:sbdt init | CMD: ERR: 0 | . | 3 | Set all metrics to boundary value to exceed BLE MTU (255). Set all metrics categories (LoRa MAC, LoRa Link, FSK MAC, FSK Link, BLE Link, Time Sync, Network Sync, Link Message Manager, Security State Machine, Gateway Discovery and Tracking, Registration and Key Refresh, FFS/FFN, SBDT, Multi-Link Manager, Autoconnect Manager, Gateway Scanning and Selection) to their maximum boundary values using:metrics set <category> <metric_id> <max_value> | CMD: ERR: 0 for each command | . | 4 | Print all metrics:print metrics 0x36 | EN shows all metrics data | . | 5 | Establish BLE connection and trigger metrics send or wait for periodic reporting:sid conn_req 1metrics send | ENC: M:15 [B:E:2]TX CRID: <crid>MET: NDB5 st:0Key check: EN sends metrics via BLE, remaining metrics via piggybacking (NDB) | . | 6 | Send ULs until no more metrics in NDB (all metrics uploaded):sid send TEST (repeat until MET: NDB5 st:0 no longer appears) | While metrics remain: MET: NDB5 st:0 (metrics piggybacked on UL)When complete: No MET: NDB5 st:0 after sid sendKey check: All metrics uploaded via piggybacking | . | 7 | Check on Splunk by TX CRID:index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PERIODIC\" | Metrics data uploaded to cloud | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-bleepepmetricsreportbv02-verify-endpoint-sends-remaining-endpoint-metrics-to-cloud-over-ble-via-piggybacking-on-a-periodic-reporting", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-bleepepmetricsreportbv02-verify-endpoint-sends-remaining-endpoint-metrics-to-cloud-over-ble-via-piggybacking-on-a-periodic-reporting" },"239": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: BLE/EP/EPMETRICS/REPORT/BV/03: Verify Endpoint Metrics are uploaded via Piggybacking over BLE if the explicit reporting is disabled", "content": "| Field | Value | . | Case ID | C103619327 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack and wait for time sync:sid init 1sid start | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1Key check: Time synced (Time: 0) | . | 2 | Disable metrics reporting via API:{\"deviceId\": \"{<DEVICE_ID>}\", \"enableMetricsReport\": false} | Received write capability and config message:[Rx][0:2:1:1] err:0ECPFG(8) st 10->2ECPFG(2) st 2->5Response write capability and config message:[Tx][0:2:3:1] st:0ECPFG(5) st 5->10Key check: EN received configuration and sent response | . | 3 | Print all metrics:print metrics 0x36 | EN shows all metrics data | . | 4 | Establish BLE connection and trigger metrics send, verify piggybacking:sid conn_req 1metrics sendsid send TEST (repeat until MET: NDB5 st:0 no longer appears) | MET: NDB5 st:0 (remaining metrics piggybacked on UL)When complete: No MET: NDB5 st:0 after sid sendKey check: All metrics uploaded via piggybacking even though explicit reporting is disabled | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-bleepepmetricsreportbv03-verify-endpoint-metrics-are-uploaded-via-piggybacking-over-ble-if-the-explicit-reporting-is-disabled", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-bleepepmetricsreportbv03-verify-endpoint-metrics-are-uploaded-via-piggybacking-over-ble-if-the-explicit-reporting-is-disabled" },"240": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: BLE/EP/EPMETRICS/UL/BV/01: Verify Uplink messages Metrics", "content": "| Field | Value | . | Case ID | C103619328 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack, wait for time sync, establish BLE connection, clear metrics:sid init 1sid startsid conn_req 1clear metrics | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1CMD: ERR: 0 | . | 2 | Send 3 ULs and verify ul_msg counter increments after each:sid send TEST (1st UL)print metrics 0x05 (check BLE_LINK: ul_msg = 1)sid send TEST (2nd UL)print metrics 0x05 (check BLE_LINK: ul_msg = 2)sid send TEST (3rd UL)print metrics 0x05 (check BLE_LINK: ul_msg = 3) | After 1st UL: BLE_LINK: ul_msg = 1After 2nd UL: BLE_LINK: ul_msg = 2After 3rd UL: BLE_LINK: ul_msg = 3Key check: ul_msg counter increments by 1 after each UL | . | 3 | Upload to Cloud to check via S360:https://360.sidewalk.amazon/jobs/createJob Type: Perform Action For Endpoint MetricsAction: Get MetricsMetrics Category: BLE LINKIndividual Metrics: Uplink Messages Per Day | ENC: M:15 [B:E:3]TX CRID: <crid>Key check: Metrics uploaded, note the TX CRID | . | 4 | Check on Splunk by TX CRID | The metrics is in the event | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-bleepepmetricsulbv01-verify-uplink-messages-metrics", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-bleepepmetricsulbv01-verify-uplink-messages-metrics" },"241": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: BLE/EP/EPMETRICS/DL/BV/01: Verify Downlink messages Metrics", "content": "| Field | Value | . | Case ID | C103619329 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack, wait for time sync, clear metrics:sid init 1 (or 4, 5, 7)sid startprint clear_metrics 0x36 | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1BLE_LINK: dl_msg = 0 | . | 2 | Send 3 DLs from AWS IoT and verify dl_msg counter increments after each:Send DL (seq=0) -> print metrics 0x05Send DL (seq=1) -> print metrics 0x05Send DL (seq=2) -> print metrics 0x05 | After 1st DL: EVENT SID RECEIVED: ... LINK: 1 ... / BLE_LINK: dl_msg = 1After 2nd DL: EVENT SID RECEIVED: ... LINK: 1 ... / BLE_LINK: dl_msg = 2After 3rd DL: EVENT SID RECEIVED: ... LINK: 1 ... / BLE_LINK: dl_msg = 3Key check: dl_msg counter increments by 1 after each DL | . | 3 | Upload metrics to Cloud via S360:https://gamma.360.sidewalk.amazon/jobs/createJob Type: Periodic Metrics Upload | ENC: M:15 [B:E:3]TX CRID: <crid>Key check: Metrics uploaded, note the TX CRID | . | 4 | Check on Splunk by TX CRID:index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PERIODIC\" | Metrics data found on Splunk with correct dl_msg value | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-bleepepmetricsdlbv01-verify-downlink-messages-metrics", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-bleepepmetricsdlbv01-verify-downlink-messages-metrics" },"242": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: BLE/EP/EPMETRICS/CONN-BV-01: Verify Connection attempts Metrics", "content": "| Field | Value | . | Case ID | C103619330 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack, wait for time sync, wait for BLE disconnected, clear metrics:sid init 1sid startWait for BLE disconnectedprint clear_metrics 0x36 | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0BLE_LINK: conn_attempts = 0 | . | 2 | Establish BLE connection 2 times and verify conn_attempts increments:sid conn_req 1print metrics 0x05 (check BLE_LINK: conn_attempts = 1)sid conn_req 1print metrics 0x05 (check BLE_LINK: conn_attempts = 2) | After 1st connection: BLE_LINK: conn_attempts = 1After 2nd connection: BLE_LINK: conn_attempts = 2Key check: conn_attempts counter increments by 1 after each connection attempt | . | 3 | Upload to Cloud to check via S360:https://gamma.360.sidewalk.amazon/jobs/createJob Type: Perform Action For Endpoint MetricsAction: Get MetricsMetrics Category: BLE LINKIndividual Metrics: Connection Attempts Per Day | ENC: M:15 [B:E:3]TX CRID: <crid>Key check: Metrics uploaded, note the TX CRID | . | 4 | Check on Splunk by TX CRID | The metrics is in the event | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-bleepepmetricsconn-bv-01-verify-connection-attempts-metrics", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-bleepepmetricsconn-bv-01-verify-connection-attempts-metrics" },"243": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: FSK/EP/EPMETRICS/REPORT/BV/01: Verify Endpoint sends Endpoint Metrics to Cloud over FSK in a specific time interval", "content": "| Field | Value | . | Case ID | C103619332 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize FSK stack and wait for time sync and join:sid init 2 (or 5, 6, 7)sid start | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2Njoin(1, 2) st 2->6Key check: Time synced and joined | . | 2 | Print all metrics:print metrics 0x36 | EN shows metrics data | . | 3 | Wait uploading interval for periodic reporting or trigger by command:metrics sendDefault uploading interval is 24 hoursCheck current interval: print get_cap 3 -> metrics periodicity | ENC: M:15 [B:E:2]TX CRID: <crid>Key check: EN sends metrics to cloud via FSK | . | 4 | Check on Splunk by TX CRID:index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PERIODIC\" | Metrics data found on Splunk | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-fskepepmetricsreportbv01-verify-endpoint-sends-endpoint-metrics-to-cloud-over-fsk-in-a-specific-time-interval", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-fskepepmetricsreportbv01-verify-endpoint-sends-endpoint-metrics-to-cloud-over-fsk-in-a-specific-time-interval" },"244": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: FSK/EP/EPMETRICS/REPORT/BV/02: Verify Endpoint sends remaining Endpoint Metrics to Cloud over FSK via piggybacking on a periodic reporting", "content": "| Field | Value | . | Case ID | C103619333 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack and wait for time sync and join:sid init 7sid start | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2Njoin(1, 2) st 2->6 | . | 2 | Initialize SBDT:sbdt init | CMD: ERR: 0 | . | 3 | Set all metrics to boundary value to exceed FSK MTU (200). Set all metrics categories (FSK MAC, FSK Link, Time Sync, Network Sync, Link Message Manager, Security State Machine, Gateway Discovery and Tracking, Registration and Key Refresh, FFS/FFN, SBDT, Multi-Link Manager, Autoconnect Manager, Gateway Scanning and Selection) to their maximum boundary values using:metrics set <category> <metric_id> <max_value> | CMD: ERR: 0 for each command | . | 4 | Print all metrics:print metrics 0x36 | EN shows all metrics data | . | 5 | Trigger metrics send:metrics sendsid send TEST (repeat until MET: NDB5 st:0 no longer appears) | ENC: M:15 [B:E:2]TX CRID: <crid>MET: NDB5 st:0 (remaining metrics piggybacked on UL)When complete: No MET: NDB5 st:0 after sid sendKey check: EN sends metrics via FSK, remaining via piggybacking | . | 6 | Check on Splunk by TX CRID:index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PERIODIC\" | Metrics data found on Splunk | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-fskepepmetricsreportbv02-verify-endpoint-sends-remaining-endpoint-metrics-to-cloud-over-fsk-via-piggybacking-on-a-periodic-reporting", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-fskepepmetricsreportbv02-verify-endpoint-sends-remaining-endpoint-metrics-to-cloud-over-fsk-via-piggybacking-on-a-periodic-reporting" },"245": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: FSK/EP/EPMETRICS/REPORT/BV/03: Verify Endpoint Metrics are uploaded via Piggybacking over FSK if the explicit reporting is disabled", "content": "| Field | Value | . | Case ID | C103619334 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize FSK stack and wait for time sync and join:sid init 2 (or 5, 6, 7)sid start | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2Njoin(1, 2) st 2->6 | . | 2 | Disable metrics reporting via API:{\"deviceId\": \"{<DEVICE_ID>}\", \"enableMetricsReport\": false} | Received write capability and config message:[Rx][0:2:1:2] err:0ECPFG(8) st 10->2ECPFG(2) st 2->5Response write capability and config message:[Tx][0:2:3:2] st:0ECPFG(5) st 5->10Key check: EN received configuration and sent response | . | 3 | Print all metrics:print metrics 0x36 | EN shows all metrics data | . | 4 | Trigger metrics send and verify piggybacking:metrics sendsid send TEST (repeat until MET: NDB5 st:0 no longer appears) | MET: NDB5 st:0 (remaining metrics piggybacked on UL)When complete: No MET: NDB5 st:0 after sid sendKey check: All metrics uploaded via piggybacking even though explicit reporting is disabled | . | 5 | Recover metrics reporting setting:print clear_cap 1 | CMD: ERR: 0 | . | 6 | Check on Splunk by TX CRID:index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PERIODIC\" | Metrics data found on Splunk | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-fskepepmetricsreportbv03-verify-endpoint-metrics-are-uploaded-via-piggybacking-over-fsk-if-the-explicit-reporting-is-disabled", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-fskepepmetricsreportbv03-verify-endpoint-metrics-are-uploaded-via-piggybacking-over-fsk-if-the-explicit-reporting-is-disabled" },"246": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: FSK/EP/EPMETRICS/UL/BV/01: Verify Uplink messages Metrics and Total number of TX unique packets Metrics", "content": "| Field | Value | . | Case ID | C103619335 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize FSK stack, wait for time sync and join, clear metrics:sid init 2 (or 5, 6, 7)sid startprint clear_metrics 0x36 | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2Njoin(1, 2) st 2->6FSK_MAC: fsk_tx_pkts = 0 | . | 2 | Send UL and verify fsk_tx_pkts increments:sid send TESTprint metrics 0x03 (check FSK_MAC: fsk_tx_pkts = 1) | FskTx:TxDone sqn:<sqn> dst_id:0x<id> ch:<ch> pktlen:<len> tx_st:0FSK_MAC: fsk_tx_pkts = 1Key check: fsk_tx_pkts increments by 1 after each TX | . | 3 | Upload metrics to Cloud via S360:https://360.sidewalk.amazon/jobs/createJob Type: Periodic Metrics Upload | ENC: M:15 [B:E:3]TX CRID: <crid>Key check: Metrics uploaded, note the TX CRID | . | 4 | Check on Splunk by TX CRID:index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PERIODIC\" | Metrics data found on Splunk | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-fskepepmetricsulbv01-verify-uplink-messages-metrics-and-total-number-of-tx-unique-packets-metrics", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-fskepepmetricsulbv01-verify-uplink-messages-metrics-and-total-number-of-tx-unique-packets-metrics" },"247": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: FSK/EP/EPMETRICS/DL/BV/01: Verify Downlink messages Metrics and Total number of RX unique packets Metrics", "content": "| Field | Value | . | Case ID | C103619336 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize FSK stack, wait for time sync and join, clear metrics:sid init 2 (or 5, 6, 7)sid startprint clear_metrics 0x36 | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2Njoin(1, 2) st 2->6FSK_MAC: fsk_rx_pkts = 0 | . | 2 | Send DL from AWS IoT and verify fsk_rx_pkts increments:Send DL from AWS IoTprint metrics 0x03 (check FSK_MAC: fsk_rx_pkts = 1) | FskRx:RxDone sqn:<sqn> src_id:0x<id> dst_id:0x<id> ch:<ch> pktlen:<len> rx_st:0FSK_MAC: fsk_rx_pkts = 1Key check: fsk_rx_pkts increments by 1 after each RX | . | 3 | Upload metrics to Cloud via S360:https://360.sidewalk.amazon/jobs/createJob Type: Periodic Metrics Upload | ENC: M:15 [B:E:3]TX CRID: <crid>Key check: Metrics uploaded, note the TX CRID | . | 4 | Check on Splunk by TX CRID:index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PERIODIC\" | Metrics data found on Splunk | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-fskepepmetricsdlbv01-verify-downlink-messages-metrics-and-total-number-of-rx-unique-packets-metrics", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-fskepepmetricsdlbv01-verify-downlink-messages-metrics-and-total-number-of-rx-unique-packets-metrics" },"248": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: LORA/EP/EPMETRICS/REPORT/BV/01: Verify Endpoint sends Endpoint Metrics to Cloud over LoRa in a specific time interval", "content": "| Field | Value | . | Case ID | C103619339 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize LoRa stack and wait for time sync and join:sid init 3 (or 4, 6, 7)sid start | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4Njoin(1, 2) st 2->6Key check: Time synced and joined | . | 2 | Print all metrics:print metrics 0x36 | EN shows metrics data | . | 3 | Wait uploading interval for periodic reporting or trigger by command:metrics sendDefault uploading interval is 24 hoursCheck current interval: print get_cap 3 -> metrics periodicity | ENC: M:15 [B:E:2]TX CRID: <crid>Key check: EN sends metrics to cloud via LoRa | . | 4 | Check on Splunk by TX CRID:index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PERIODIC\" | Metrics data found on Splunk | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-loraepepmetricsreportbv01-verify-endpoint-sends-endpoint-metrics-to-cloud-over-lora-in-a-specific-time-interval", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-loraepepmetricsreportbv01-verify-endpoint-sends-endpoint-metrics-to-cloud-over-lora-in-a-specific-time-interval" },"249": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: LORA/EP/EPMETRICS/REPORT/BV/02: Verify Endpoint sends remaining Endpoint Metrics to Cloud over LoRa via piggybacking on a periodic reporting", "content": "| Field | Value | . | Case ID | C103619340 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack and wait for time sync and join:sid init 7sid start | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4Njoin(1, 2) st 2->6 | . | 2 | Set all metrics to boundary value (see BLE/EP/EPMETRICS/REPORT/BV/02 step 3 for full command list) | CMD: ERR: 0 for each command | . | 3 | Print all metrics:print metrics 0x36 | EN shows all metrics data | . | 4 | Trigger metrics send:metrics sendsid send TEST (repeat until MET: NDB5 st:0 no longer appears) | ENC: M:15 [B:E:2]TX CRID: <crid>MET: NDB5 st:0 (remaining metrics piggybacked on UL)When complete: No MET: NDB5 st:0 after sid sendKey check: EN sends metrics via LoRa, remaining via piggybacking | . | 5 | Check on Splunk by TX CRIDs:index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PERIODIC\"index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PIGGYBACK\" | Metrics data found on Splunk (both periodic and piggybacked) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-loraepepmetricsreportbv02-verify-endpoint-sends-remaining-endpoint-metrics-to-cloud-over-lora-via-piggybacking-on-a-periodic-reporting", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-loraepepmetricsreportbv02-verify-endpoint-sends-remaining-endpoint-metrics-to-cloud-over-lora-via-piggybacking-on-a-periodic-reporting" },"250": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: LORA/EP/EPMETRICS/REPORT/BV/03: Verify Endpoint Metrics are uploaded via Piggybacking over LoRa if the explicit reporting is disabled", "content": "| Field | Value | . | Case ID | C103619341 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize LoRa stack and wait for time sync and join:sid init 3 (or 4, 6, 7)sid start | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4Njoin(1, 2) st 2->6 | . | 2 | Disable metrics reporting via API:{\"deviceId\": \"{<DEVICE_ID>}\", \"enableMetricsReport\": false} | Received write capability and config message:[Rx][0:2:1:4] err:0ECPFG(8) st 10->2ECPFG(2) st 2->5Response write capability and config message:[Tx][0:2:3:4] st:0ECPFG(5) st 5->10Key check: EN received configuration and sent response | . | 3 | Verify metrics reporting is disabled:print get_cap 1 | metrics enabled 0 | . | 4 | Print all metrics:print metrics 0x36 | EN shows all metrics data | . | 5 | Trigger metrics send and verify piggybacking:metrics sendsid send TEST (repeat until MET: NDB5 st:0 no longer appears) | MET: NDB5 st:0 (remaining metrics piggybacked on UL)When complete: No MET: NDB5 st:0 after sid sendKey check: All metrics uploaded via piggybacking even though explicit reporting is disabled | . | 6 | Recover metrics reporting setting:print clear_cap 1 | CMD: ERR: 0 | . | 7 | Check on Splunk by TX CRIDs:index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PIGGYBACK\" | Metrics data found on Splunk (piggybacked only, no periodic) | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-loraepepmetricsreportbv03-verify-endpoint-metrics-are-uploaded-via-piggybacking-over-lora-if-the-explicit-reporting-is-disabled", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-loraepepmetricsreportbv03-verify-endpoint-metrics-are-uploaded-via-piggybacking-over-lora-if-the-explicit-reporting-is-disabled" },"251": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: LORA/EP/EPMETRICS/UL/BV/01: Verify Uplink messages Metrics and Total number of TX normal packets Metrics", "content": "| Field | Value | . | Case ID | C103619342 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize LoRa stack, wait for time sync and join, clear metrics:sid init 3 (or 4, 6, 7)sid startprint clear_metrics 0x36 | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4Njoin(1, 2) st 2->6LORA_MAC: lora_tx_normal_pkts = 0 | . | 2 | Send UL and verify lora_tx_normal_pkts increments:sid send TESTprint metrics 0x01 (check LORA_MAC: lora_tx_normal_pkts = 1) | LoraTx:TxDone sqn:<sqn> dst_id:0x<id> ch:<ch> pktlen:<len> tx_st:0LORA_MAC: lora_tx_normal_pkts = 1Key check: lora_tx_normal_pkts increments by 1 after each TX | . | 3 | Upload metrics to Cloud via S360:https://gamma.360.sidewalk.amazon/jobs/createJob Type: Periodic Metrics Upload | ENC: M:15 [B:E:3]TX CRID: <crid>Key check: Metrics uploaded, note the TX CRID | . | 4 | Check on Splunk by TX CRID:index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PERIODIC\" | Metrics data found on Splunk | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-loraepepmetricsulbv01-verify-uplink-messages-metrics-and-total-number-of-tx-normal-packets-metrics", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-loraepepmetricsulbv01-verify-uplink-messages-metrics-and-total-number-of-tx-normal-packets-metrics" },"252": { "doc": "10. EP Metrics Test Cases", "title": "Test Case ID: LORA/EP/EPMETRICS/DL/BV/01: Verify Downlink messages Metrics and Total number of RX packets Metrics", "content": "| Field | Value | . | Case ID | C103619343 | . | Executable by Customer | No | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize LoRa stack, wait for time sync and join, clear metrics:sid init 3 (or 4, 6, 7)sid startprint clear_metrics 0x36 | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4Njoin(1, 2) st 2->6LORA_MAC: lora_rx_pkts = 0 | . | 2 | Send DL from AWS IoT and verify lora_rx_pkts increments:Send DL from AWS IoTprint metrics 0x01 (check LORA_MAC: lora_rx_pkts = 1) | LoraRx:RxDone sqn:<sqn> src_id:0x<id> dst_id:0x<id> ch:<ch> pktlen:<len> rx_st:0LORA_MAC: lora_rx_pkts = 1Key check: lora_rx_pkts increments by 1 after each RX | . | 3 | Upload metrics to Cloud via S360:https://gamma.360.sidewalk.amazon/jobs/createJob Type: Periodic Metrics Upload | ENC: M:15 [B:E:3]TX CRID: <crid>Key check: Metrics uploaded, note the TX CRID | . | 4 | Check on Splunk by TX CRID:index=halo_operations* <sidewalkID> methodIdentifier = \"ENDPOINT_METRICS_PERIODIC\" | Metrics data found on Splunk | . ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-loraepepmetricsdlbv01-verify-downlink-messages-metrics-and-total-number-of-rx-packets-metrics", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html#test-case-id-loraepepmetricsdlbv01-verify-downlink-messages-metrics-and-total-number-of-rx-packets-metrics" },"253": { "doc": "10. EP Metrics Test Cases", "title": "10. EP Metrics Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/ep-metrics-test-cases.html" },"254": { "doc": "5. Amazon Sidewalk Error Codes", "title": "5. Amazon Sidewalk Error Codes", "content": "For the values of the Amazon Sidewalk error codes see 5.1. ", "url": "/sid-api-dg/error-codes.html", "relUrl": "/sid-api-dg/error-codes.html" },"255": { "doc": "5. Amazon Sidewalk Error Codes", "title": "5.1 Amazon Sidewalk Error Codes", "content": "| Sidewalk Error Code | Value | . | SID_ERROR_NONE | 0 | . | SID_ERROR_GENERIC | -1 | . | SID_ERROR_TIMEOUT | -2 | . | SID_ERROR_OUT_OF_RESOURCES | -3 | . | SID_ERROR_OOM | -4 | . | SID_ERROR_OUT_OF_HANDLES | -5 | . | SID_ERROR_NOSUPPORT | -6 | . | SID_ERROR_NO_PERMISSION | -7 | . | SID_ERROR_NOT_FOUND | -8 | . | SID_ERROR_NULL_POINTER | -9 | . | SID_ERROR_PARAM_OUT_OF_RANGE | -10 | . | SID_ERROR_INVALID_ARGS | -11 | . | SID_ERROR_INCOMPATIBLE_PARAMS | -12 | . | SID_ERROR_IO_ERROR | -13 | . | SID_ERROR_TRY_AGAIN | -14 | . | SID_ERROR_BUSY | -15 | . | SID_ERROR_DEAD_LOCK | -16 | . | SID_ERROR_DATA_TYPE_OVERFLOW | -17 | . | SID_ERROR_BUFFER_OVERFLOW | -18 | . | SID_ERROR_IN_PROGRESS | -19 | . | SID_ERROR_CANCELED | -20 | . | SID_ERROR_OWNER_DEAD | -21 | . | SID_ERROR_UNRECOVERABLE | -22 | . | SID_ERROR_PORT_INVALID | -23 | . | SID_ERROR_PORT_NOT_OPEN | -24 | . | SID_ERROR_UNINITIALIZED | -25 | . | SID_ERROR_ALREADY_INITIALIZED | -26 | . | SID_ERROR_ALREADY_EXISTS | -27 | . | SID_ERROR_BELOW_THRESHOLD | -28 | . | SID_ERROR_STOPPED | -29 | . | SID_ERROR_STORAGE_READ_FAIL | -30 | . | SID_ERROR_STORAGE_WRITE_FAIL | -31 | . | SID_ERROR_STORAGE_ERASE_FAIL | -32 | . | SID_ERROR_STORAGE_FULL | -33 | . | SID_ERROR_AUTHENTICATION_FAIL | -34 | . | SID_ERROR_ENCRYPTION_FAIL | -35 | . | SID_ERROR_DECRYPTION_FAIL | -36 | . | SID_ERROR_ID_OBFUSCATION_FAIL | -37 | . | SID_ERROR_NO_ROUTE_AVAILABLE | -38 | . | SID_ERROR_INVALID_RESPONSE | -39 | . | SID_ERROR_INVALID_STATE | -40 | . | SID_ERROR_INSUFFICIENT_RESULTS | -41 | . ", "url": "/sid-api-dg/error-codes.html#51-amazon-sidewalk-error-codes", "relUrl": "/sid-api-dg/error-codes.html#51-amazon-sidewalk-error-codes" },"256": { "doc": "4. Existing Settings GSK Interacts With", "title": "4. Existing settings GSK interacts with", "content": "All but the last are set and read with sid_option(). sid_config.time_sync_config is passed to sid_init(). | Setting | Value type | Why it matters to GSK | . | SID_OPTION_DL_ROUTE_VALIDITY (19) | struct sid_dlrv_config { uint16_t time; uint16_t nwsync_time; bool is_set; } | time is the downlink route validity, 1–1440 min. nwsync_time overrides the keep-alive interval in minutes, and is one value shared by both sub-GHz links. The keep-alive interval is the dominant term in detection latency (§6). | . | SID_OPTION_900MHZ_SET_DEVICE_PROFILE (1), SID_OPTION_900MHZ_GET_DEVICE_PROFILE (2) | struct sid_device_profile | The stack re-resolves the MDR RX-window separation from l3_mdr_rx_window_interval_ms on every entry to MDR, including at boot. A product that needs 500 ms or 1000 ms sets the field once, and a GSK data-rate transition cannot lose it. Setting a profile while a session is active does not tear the session down, but an accepted change on a started, network-synchronized LoRa link takes the link out of network synchronization, which your application sees as the same link_status_mask bounce as a GSK transition (§2.2). | . | sid_config.time_sync_config | struct sid_time_sync_config { const uint16_t *adaptive_sync_intervals_h; uint8_t num_intervals; } | Each interval is between TIME_SYNC_INTERVAL_MIN_HOURS = 2 and TIME_SYNC_INTERVAL_MAX_HOURS = 720 hours. NULL or an invalid set selects the SDK default. Sparse intervals lengthen the windows in which nothing establishes. | . Table 4.1: Existing settings whose values change GSK behavior. The effective keep-alive interval must be longer than idle_timeout_sec. If it is not, the quiet window never elapses and no session is established. Read the interval in effect with is_set = false. It is reported even if you never set one. Never override the keep-alive interval with 0. 0 means not set. SubG-FSK and LoRa Profile C fall back to their own default, but LoRa Profile B discards its 5 minute default and reads back the 2 minute floor (§7). nwsync_time has its own range, dependent on the link and device profile. For the ranges and how the interval is derived, see the Amazon Sidewalk Keep-Alive (KA) Application Note. Out of range returns SID_ERROR_INVALID_ARGS (-11). A value below the 2 min floor is accepted, then floored by the scheduler. ", "url": "/app-notes/gateway-session-key/existing-settings-interaction.html#4-existing-settings-gsk-interacts-with", "relUrl": "/app-notes/gateway-session-key/existing-settings-interaction.html#4-existing-settings-gsk-interacts-with" },"257": { "doc": "4. Existing Settings GSK Interacts With", "title": "4. Existing Settings GSK Interacts With", "content": " ", "url": "/app-notes/gateway-session-key/existing-settings-interaction.html", "relUrl": "/app-notes/gateway-session-key/existing-settings-interaction.html" },"258": { "doc": "8. File-Transfer Test Cases", "title": "8. File-Transfer Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html" },"259": { "doc": "8. File-Transfer Test Cases", "title": "8.1 BLE/EP/API/FILETRANSFER/BV/01: Initialize the feature and start receiving a file.", "content": "8.1.1 Test Purpose . DUT is able to initialize the feature and be ready for the coming request of data transfer. DUT is able to finish a transfer. 8.1.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates as a SID API user. | Upper Tester is ready on AWS IoT side. | . 8.1.3 Test Procedure . sequenceDiagram participant Lower_Tester_(Sid_API_User) as Lower Tester (SID API User) participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester_(Sid_API_User),Upper_Tester: DUT Status: Registered Lower_Tester_(Sid_API_User)->>DUT: sbdt init Upper_Tester->>DUT: TRANSFER_APPLICATION_REQUEST DUT->>Lower_Tester_(Sid_API_User): on_transfer_request() Lower_Tester_(Sid_API_User)->>DUT: scratch buffer, accept transfer request DUT->>Upper_Tester: TRANSFER_APPLICATION_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST DUT->>Upper_Tester: TRANSFER_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: transferring all blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Lower_Tester_(Sid_API_User): on_finalize_request() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_finalize() DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Upper_Tester->>DUT: TRANSFER_FILE_EXIT DUT->>Lower_Tester_(Sid_API_User): on_release_scratch() . 8.1.4 Expected Results . 8.1.4.1 Pass Verdict . The DUT should successfully complete the data transfer with the Upper Tester and send a task complete notify to AWS IoT side. ", "url": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#81-bleepapifiletransferbv01-initialize-the-feature-and-start-receiving-a-file", "relUrl": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#81-bleepapifiletransferbv01-initialize-the-feature-and-start-receiving-a-file" },"260": { "doc": "8. File-Transfer Test Cases", "title": "8.2 BLE/EP/API/FILETRANSFER/BV/02: Cancel ongoing transfer.", "content": "8.2.1 Test Purpose . DUT is able to cancel the ongoing data transfer with a given file_id. 8.2.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates as a SID API user. | Upper Tester is ready on AWS IoT side. | . 8.2.3 Test Procedure . sequenceDiagram participant Lower_Tester_(Sid_API_User) as Lower Tester (SID API User) participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester_(Sid_API_User),Upper_Tester: DUT Status: Registered Lower_Tester_(Sid_API_User)->>DUT: sbdt init Upper_Tester->>DUT: TRANSFER_APPLICATION_REQUEST DUT->>Lower_Tester_(Sid_API_User): on_transfer_request() Lower_Tester_(Sid_API_User)->>DUT: scratch buffer, accept transfer request DUT->>Upper_Tester: TRANSFER_APPLICATION_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST DUT->>Upper_Tester: TRANSFER_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: transferring data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over Lower_Tester_(Sid_API_User),Upper_Tester: CANCEL Path 1: Cancel while transferring Lower_Tester_(Sid_API_User)->>DUT: sbdt cancel file_id reason_id DUT->>Upper_Tester: TRANSFER_CANCEL_NOTIFY DUT->>Lower_Tester_(Sid_API_User): on_cancel_request() DUT->>Lower_Tester_(Sid_API_User): on_release_scratch() Note over DUT,Upper_Tester: end of CANCEL Path 1 Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop Note over Lower_Tester_(Sid_API_User),Upper_Tester: CANCEL Path 2: Cancel after just finished transfer DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Lower_Tester_(Sid_API_User)->>DUT: sbdt cancel file_id reason_id DUT->>Upper_Tester: TRANSFER_CANCEL_NOTIFY DUT->>Lower_Tester_(Sid_API_User): on_cancel_request() DUT->>Lower_Tester_(Sid_API_User): on_release_scratch() Note over DUT,Upper_Tester: end of CANCEL Path 2 . 8.2.4 Expected Results . 8.2.4.1 Pass Verdict . The DUT should successfully cancel the ongoing transfer with a specific given reason. The DUT should report the reason to the Upper Tester. ", "url": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#82-bleepapifiletransferbv02-cancel-ongoing-transfer", "relUrl": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#82-bleepapifiletransferbv02-cancel-ongoing-transfer" },"261": { "doc": "8. File-Transfer Test Cases", "title": "8.3 BLE/EP/API/FILETRANSFER/BV/03: Print the progress of the transfer and current file offset.", "content": "8.3.1 Test Purpose . DUT is able to output the progress of the transfer as a percent and the current file offset. 8.3.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates as a SID API user. | Upper Tester is ready on AWS IoT side. | . 8.3.3 Test Procedure . sequenceDiagram participant Lower_Tester_(Sid_API_User) as Lower Tester (SID API User) participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester_(Sid_API_User),Upper_Tester: DUT Status: Registered Lower_Tester_(Sid_API_User)->>DUT: sbdt init Upper_Tester->>DUT: TRANSFER_APPLICATION_REQUEST DUT->>Lower_Tester_(Sid_API_User): on_transfer_request() Lower_Tester_(Sid_API_User)->>DUT: scratch buffer, accept transfer request DUT->>Upper_Tester: TRANSFER_APPLICATION_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST DUT->>Upper_Tester: TRANSFER_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: before_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop Lower_Tester_(Sid_API_User)->>DUT: sbdt stats file_id DUT->>Lower_Tester_(Sid_API_User): Print progress of transfer as percentage and current file offset Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: after_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Lower_Tester_(Sid_API_User): on_finalize_request() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_finalize() DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Upper_Tester->>DUT: TRANSFER_FILE_EXIT DUT->>Lower_Tester_(Sid_API_User): on_release_scratch() . 8.3.4 Expected Results . 8.3.4.1 Pass Verdict . The DUT should successfully print out the progress of the transfer and current file offset. ", "url": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#83-bleepapifiletransferbv03-print-the-progress-of-the-transfer-and-current-file-offset", "relUrl": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#83-bleepapifiletransferbv03-print-the-progress-of-the-transfer-and-current-file-offset" },"262": { "doc": "8. File-Transfer Test Cases", "title": "8.4 BLE/EP/API/FILETRANSFER/BV/04: Print various parameters of the transfer.", "content": "8.4.1 Test Purpose . DUT is able to output the various parameters of the transfer. 8.4.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates as a SID API user. | Upper Tester is ready on AWS IoT side. | . 8.4.3 Test Procedure . sequenceDiagram participant Lower_Tester_(Sid_API_User) as Lower Tester (SID API User) participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester_(Sid_API_User),Upper_Tester: DUT Status: Registered Lower_Tester_(Sid_API_User)->>DUT: sbdt init Upper_Tester->>DUT: TRANSFER_APPLICATION_REQUEST DUT->>Lower_Tester_(Sid_API_User): on_transfer_request() Lower_Tester_(Sid_API_User)->>DUT: scratch buffer, accept transfer request DUT->>Upper_Tester: TRANSFER_APPLICATION_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST DUT->>Upper_Tester: TRANSFER_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: before_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop Lower_Tester_(Sid_API_User)->>DUT: sbdt params file_id DUT->>Lower_Tester_(Sid_API_User): Print parameters of the ongoing transfer Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: after_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Lower_Tester_(Sid_API_User): on_finalize_request() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_finalize() DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Upper_Tester->>DUT: TRANSFER_FILE_EXIT DUT->>Lower_Tester_(Sid_API_User): on_release_scratch() . 8.4.4 Expected Results . 8.4.4.1 Pass Verdict . The DUT should successfully print out various parameters relevant to file transfer. ", "url": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#84-bleepapifiletransferbv04-print-various-parameters-of-the-transfer", "relUrl": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#84-bleepapifiletransferbv04-print-various-parameters-of-the-transfer" },"263": { "doc": "8. File-Transfer Test Cases", "title": "8.5 BLE/EP/API/FILETRANSFER/RECOVERY/BI/01: Recover transfer after EP powered off and back on.", "content": "8.5.1 Test Purpose . DUT is able to recover the transfer after EP power off for a valid time slot and back on. 8.5.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates as a SID API user. | Upper Tester is ready on AWS IoT side. | . 8.5.3 Test Procedure . sequenceDiagram participant Lower_Tester_(Sid_API_User) as Lower Tester (SID API User) participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester_(Sid_API_User),Upper_Tester: DUT Status: Registered Lower_Tester_(Sid_API_User)->>DUT: sbdt init Upper_Tester->>DUT: TRANSFER_APPLICATION_REQUEST DUT->>Lower_Tester_(Sid_API_User): on_transfer_request() Lower_Tester_(Sid_API_User)->>DUT: scratch buffer, accept transfer request DUT->>Upper_Tester: TRANSFER_APPLICATION_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST DUT->>Upper_Tester: TRANSFER_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: before_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop DUT->>DUT: EP Powered off for a valid time slot DUT->>DUT: EP back on Lower_Tester_(Sid_API_User)->>DUT: sid_init and sid_start Lower_Tester_(Sid_API_User)->>DUT: sbdt init Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: after_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Lower_Tester_(Sid_API_User): on_finalize_request() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_finalize() DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Upper_Tester->>DUT: TRANSFER_FILE_EXIT DUT->>Lower_Tester_(Sid_API_User): on_release_scratch() . 8.5.4 Expected Results . 8.5.4.1 Pass Verdict . The DUT should successfully recover the transfer after EP power off for a valid time slot and back on. ", "url": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#85-bleepapifiletransferrecoverybi01-recover-transfer-after-ep-powered-off-and-back-on", "relUrl": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#85-bleepapifiletransferrecoverybi01-recover-transfer-after-ep-powered-off-and-back-on" },"264": { "doc": "8. File-Transfer Test Cases", "title": "8.6 BLE/EP/API/FILETRANSFER/RECOVERY/BI/02: Recover transfer after EP was out of range from GW.", "content": "8.6.1 Test Purpose . DUT is able to recover the transfer after out of range from GW for a valid time slot and back on. 8.6.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates as a SID API user. | Upper Tester is ready on AWS IoT side. | . 8.6.3 Test Procedure . sequenceDiagram participant Lower_Tester_(Sid_API_User) as Lower Tester (SID API User) participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester_(Sid_API_User),Upper_Tester: DUT Status: Registered Lower_Tester_(Sid_API_User)->>DUT: sbdt init Upper_Tester->>DUT: TRANSFER_APPLICATION_REQUEST DUT->>Lower_Tester_(Sid_API_User): on_transfer_request() Lower_Tester_(Sid_API_User)->>DUT: scratch buffer, accept transfer request DUT->>Upper_Tester: TRANSFER_APPLICATION_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST DUT->>Upper_Tester: TRANSFER_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: before_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop DUT->>DUT: EP out of range from GW for a valid time slot DUT->>DUT: EP back on Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: after_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Lower_Tester_(Sid_API_User): on_finalize_request() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_finalize() DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Upper_Tester->>DUT: TRANSFER_FILE_EXIT DUT->>Lower_Tester_(Sid_API_User): on_release_scratch() . 8.6.4 Expected Results . 8.6.4.1 Pass Verdict . The DUT should successfully recover the transfer after out of range from GW for a valid time slot and back on. ", "url": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#86-bleepapifiletransferrecoverybi02-recover-transfer-after-ep-was-out-of-range-from-gw", "relUrl": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#86-bleepapifiletransferrecoverybi02-recover-transfer-after-ep-was-out-of-range-from-gw" },"265": { "doc": "8. File-Transfer Test Cases", "title": "8.7 BLE/EP/API/FILETRANSFER/RECOVERY/BI/03: Recover transfer after GW that was using to send packets switched to another GW.", "content": "8.7.1 Test Purpose . DUT is able to recover the transfer after GW that is using to send packets switched to another GW. 8.7.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates as a SID API user. | Upper Tester is ready on AWS IoT side. | . 8.7.3 Test Procedure . sequenceDiagram participant Lower_Tester_(Sid_API_User) as Lower Tester (SID API User) participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester_(Sid_API_User),Upper_Tester: DUT Status: Registered Lower_Tester_(Sid_API_User)->>DUT: sbdt init Upper_Tester->>DUT: TRANSFER_APPLICATION_REQUEST DUT->>Lower_Tester_(Sid_API_User): on_transfer_request() Lower_Tester_(Sid_API_User)->>DUT: scratch buffer, accept transfer request DUT->>Upper_Tester: TRANSFER_APPLICATION_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST DUT->>Upper_Tester: TRANSFER_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: before_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop DUT->>DUT: EP switch the GW that is transmitting packets to another GW Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: after_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Lower_Tester_(Sid_API_User): on_finalize_request() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_finalize() DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Upper_Tester->>DUT: TRANSFER_FILE_EXIT DUT->>Lower_Tester_(Sid_API_User): on_release_scratch() . 8.7.4 Expected Results . 8.7.4.1 Pass Verdict . The DUT should successfully recover the transfer after GW that is using to send packets switched to another GW. ", "url": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#87-bleepapifiletransferrecoverybi03-recover-transfer-after-gw-that-was-using-to-send-packets-switched-to-another-gw", "relUrl": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#87-bleepapifiletransferrecoverybi03-recover-transfer-after-gw-that-was-using-to-send-packets-switched-to-another-gw" },"266": { "doc": "8. File-Transfer Test Cases", "title": "8.8 BLE/EP/API/FILETRANSFER/RECOVERY/BI/04: Recover transfer after GW that was using to send packets being opt-out.", "content": "8.8.1 Test Purpose . DUT is able to recover the transfer after GW that was using to send packets being opt-out. 8.8.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates as a SID API user. | Upper Tester is ready on AWS IoT side. | . 8.8.3 Test Procedure . sequenceDiagram participant Lower_Tester_(Sid_API_User) as Lower Tester (SID API User) participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester_(Sid_API_User),Upper_Tester: DUT Status: Registered Lower_Tester_(Sid_API_User)->>DUT: sbdt init Upper_Tester->>DUT: TRANSFER_APPLICATION_REQUEST DUT->>Lower_Tester_(Sid_API_User): on_transfer_request() Lower_Tester_(Sid_API_User)->>DUT: scratch buffer, accept transfer request DUT->>Upper_Tester: TRANSFER_APPLICATION_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST DUT->>Upper_Tester: TRANSFER_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: before_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop DUT->>DUT: GW that using to transmit packets is being opt-out Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: after_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Lower_Tester_(Sid_API_User): on_finalize_request() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_finalize() DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Upper_Tester->>DUT: TRANSFER_FILE_EXIT DUT->>Lower_Tester_(Sid_API_User): on_release_scratch() . 8.8.4 Expected Results . 8.8.4.1 Pass Verdict . The DUT should successfully recover the transfer after GW that was using to send packets being opt-out. ", "url": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#88-bleepapifiletransferrecoverybi04-recover-transfer-after-gw-that-was-using-to-send-packets-being-opt-out", "relUrl": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#88-bleepapifiletransferrecoverybi04-recover-transfer-after-gw-that-was-using-to-send-packets-being-opt-out" },"267": { "doc": "8. File-Transfer Test Cases", "title": "8.9 BLE/EP/API/FILETRANSFER/RECOVERY/BI/05: Recover transfer after GW that was using to send packets powered off for a while and back on.", "content": "8.9.1 Test Purpose . DUT is able to recover the transfer after GW powered off for a valid time slot and back on. 8.9.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates as a SID API user. | Upper Tester is ready on AWS IoT side. | . 8.9.3 Test Procedure . sequenceDiagram participant Lower_Tester_(Sid_API_User) as Lower Tester (SID API User) participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester_(Sid_API_User),Upper_Tester: DUT Status: Registered Lower_Tester_(Sid_API_User)->>DUT: sbdt init Upper_Tester->>DUT: TRANSFER_APPLICATION_REQUEST DUT->>Lower_Tester_(Sid_API_User): on_transfer_request() Lower_Tester_(Sid_API_User)->>DUT: scratch buffer, accept transfer request DUT->>Upper_Tester: TRANSFER_APPLICATION_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST DUT->>Upper_Tester: TRANSFER_REQUEST_RESPONSE Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: before_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop DUT->>DUT: GW that using to transmit packets powered off for a valid time slot DUT->>DUT: GW back on Note over Lower_Tester_(Sid_API_User),Upper_Tester: loop: after_interrupt_blocks Note over DUT,Upper_Tester: loop: data_chunks Upper_Tester->>DUT: TRANSFER_BLOCK_DATA Note over DUT,Upper_Tester: end of loop DUT->>Lower_Tester_(Sid_API_User): on_data_received() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_release_buffer() DUT->>Upper_Tester: TRANSFER_FILE_DATA_RESPONSE Note over Lower_Tester_(Sid_API_User),Upper_Tester: end of loop Upper_Tester->>DUT: TRANSFER_REQUEST_FINALIZE DUT->>Lower_Tester_(Sid_API_User): on_finalize_request() Lower_Tester_(Sid_API_User)->>DUT: sid_bulk_data_transfer_finalize() DUT->>Upper_Tester: TRANSFER_REQUEST_FINALIZE_RESPONSE Upper_Tester->>DUT: TRANSFER_FILE_EXIT DUT->>Lower_Tester_(Sid_API_User): on_release_scratch() . 8.9.4 Expected Results . 8.9.4.1 Pass Verdict . The DUT should successfully recover transfer after GW that was using to send packets powered off for a valid time slot and back on. ", "url": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#89-bleepapifiletransferrecoverybi05-recover-transfer-after-gw-that-was-using-to-send-packets-powered-off-for-a-while-and-back-on", "relUrl": "/specifications/sidewalk-test-spec/file-transfer-test-cases.html#89-bleepapifiletransferrecoverybi05-recover-transfer-after-gw-that-was-using-to-send-packets-powered-off-for-a-while-and-back-on" },"268": { "doc": "9. File Transfer Test Cases", "title": "File Transfer Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#file-transfer-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#file-transfer-test-cases" },"269": { "doc": "9. File Transfer Test Cases", "title": "Test Case ID: BLE/EP/API/FILETRANSFER/BV/01: Initialize the feature and start receiving a file", "content": "| Field | Value | . | Case ID | C103619294 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | BLE stack initialized | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack, start, and initialize SBDT:sid init 1sid startsbdt init | SBDT: [NO LOAD] dup drop: 29000000 (3)MET: SRC: 13CMD: ERR: 0Key check: SBDT initialized, no pending transfer | . | 2 | Create a FUOTA task on AWS:File: fuota_test_file_2048bytes.txt, block_size: 1024Note the task_id from response | FUOTA task created successfullyResponse: { \"Id\": \"<task_id>\" }Key check: task_id obtained | . | 3 | Associate EN wireless device ID with the FUOTA task:wireless_device_id: <wireless_device_id>task_id: <task_id> | Response: 2xxKey check: EN associated with FUOTA task | . | 4 | Schedule start time for the FUOTA task (at least 5 minutes from now):task_id: <task_id>start_time: <time> | Response: 2xxKey check: FUOTA task scheduled | . | 5 | Wait for BLE disconnected, establish BLE connection and send UL:sid conn_req 1sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 1Key check: UL sent via BLE | . | 6 | Wait for file transfer to complete (timeout: 600s):Monitor EN log | DEC: M:15 [3:D:2]Key check: File transfer completed | . | 7 | Check file transfer task status on cloud:task_id: <task_id> | Task status: FuotaDoneWireless device status: SuccessfulKey check: Cloud confirms transfer complete | . ", "url": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferbv01-initialize-the-feature-and-start-receiving-a-file", "relUrl": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferbv01-initialize-the-feature-and-start-receiving-a-file" },"270": { "doc": "9. File Transfer Test Cases", "title": "Test Case ID: BLE/EP/API/FILETRANSFER/BV/02: Cancel ongoing transfer", "content": "| Field | Value | . | Case ID | C103619295 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | BLE stack initialized | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack, start, and initialize SBDT:sid init 1sid startsbdt init | SBDT: [NO LOAD]CMD: ERR: 0Key check: SBDT initialized | . | 2 | Create a FUOTA task on AWS:File: fuota_test_file_10240bytes.txt, block_size: 1024Note the task_id from response | FUOTA task created successfullyResponse: { \"Id\": \"<task_id>\" }Key check: task_id obtained | . | 3 | Associate EN wireless device ID with the FUOTA task | Response: 2xxKey check: EN associated with FUOTA task | . | 4 | Schedule start time for the FUOTA task (at least 5 minutes from now) | Response: 2xxKey check: FUOTA task scheduled | . | 5 | Wait for BLE disconnected, establish BLE connection and send UL:sid conn_req 1sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 1Key check: UL sent via BLE | . | 6 | Wait for file transfer to start (blocks transferring):Monitor EN log | DEC: M:15 [3:5:1]Key check: File transfer started | . | 7 | Cancel the file transfer:sbdt cancel 0 0x00 | CMD: ERR: 0Key check: File transfer cancelled. Note: The cancel is not immediate; chunks in flight from GW or cloud will continue to arrive. Device tags them as errors and sends response [3:5:3] (by design). SDK triggers on_sbdt_error. | . | 8 | Check file transfer task status on cloud | Task status: FuotaDoneWireless device status: SuccessfulKey check: Cloud confirms task complete | . ", "url": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferbv02-cancel-ongoing-transfer", "relUrl": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferbv02-cancel-ongoing-transfer" },"271": { "doc": "9. File Transfer Test Cases", "title": "Test Case ID: BLE/EP/API/FILETRANSFER/BV/03: Print the progress of the transfer and current file offset", "content": "| Field | Value | . | Case ID | C103619296 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | BLE stack initialized | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack, start, and initialize SBDT:sid init 1sid startsbdt init | SBDT: [NO LOAD]CMD: ERR: 0Key check: SBDT initialized | . | 2 | Create a FUOTA task on AWS:File: fuota_test_file_10240bytes.txt, block_size: 1024Note the task_id from response | FUOTA task created successfullyResponse: { \"Id\": \"<task_id>\" }Key check: task_id obtained | . | 3 | Associate EN wireless device ID with the FUOTA task | Response: 2xxKey check: EN associated with FUOTA task | . | 4 | Schedule start time for the FUOTA task (at least 5 minutes from now) | Response: 2xxKey check: FUOTA task scheduled | . | 5 | Wait for BLE disconnected, establish BLE connection and send UL:sid conn_req 1sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 1Key check: UL sent via BLE | . | 6 | Wait for file transfer to start (blocks transferring):Monitor EN log | DEC: M:15 [3:5:1]Key check: File transfer started | . | 7 | Print file transfer progress:sbdt stats 0 | FILE_OFFSET: 2048, FILE_PROGRESS: 49Key check: Progress and file offset retrieved successfully | . ", "url": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferbv03-print-the-progress-of-the-transfer-and-current-file-offset", "relUrl": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferbv03-print-the-progress-of-the-transfer-and-current-file-offset" },"272": { "doc": "9. File Transfer Test Cases", "title": "Test Case ID: BLE/EP/API/FILETRANSFER/BV/04: Print various parameters of the transfer", "content": "| Field | Value | . | Case ID | C103619297 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | BLE stack initialized | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack, start, and initialize SBDT:sid init 1sid startsbdt init | SBDT: [NO LOAD]CMD: ERR: 0Key check: SBDT initialized | . | 2 | Create a FUOTA task on AWS:File: fuota_test_file_10240bytes.txt, block_size: 1024Note the task_id from response | FUOTA task created successfullyResponse: { \"Id\": \"<task_id>\" }Key check: task_id obtained | . | 3 | Associate EN wireless device ID with the FUOTA task | Response: 2xxKey check: EN associated with FUOTA task | . | 4 | Schedule start time for the FUOTA task (at least 5 minutes from now) | Response: 2xxKey check: FUOTA task scheduled | . | 5 | Wait for BLE disconnected, establish BLE connection and send UL:sid conn_req 1sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 1Key check: UL sent via BLE | . | 6 | Wait for file transfer to start (blocks transferring):Monitor EN log | DEC: M:15 [3:5:1]Key check: File transfer started | . | 7 | Print file transfer parameters:sbdt params 0 | FILE_ID: 0, FILE_SIZE: 4098, BLOCK_SIZE: 1024, MIN_SCRATCH_SPACE: 2712, FILE_DESCRIPTOR_SIZE: 0, SCRATCH_BUFFER_SIZE: 6144Key check: Parameters retrieved successfully | . ", "url": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferbv04-print-various-parameters-of-the-transfer", "relUrl": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferbv04-print-various-parameters-of-the-transfer" },"273": { "doc": "9. File Transfer Test Cases", "title": "Test Case ID: BLE/EP/API/FILETRANSFER/RECOVERY/BI/01: Recover transfer after EP powered off and back on", "content": "| Field | Value | . | Case ID | C103619298 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | BLE stack initialized | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack, start, and initialize SBDT:sid init 1sid startsbdt init | SBDT: [NO LOAD]CMD: ERR: 0Key check: SBDT initialized | . | 2 | Create a FUOTA task on AWS:File: fuota_test_file_10240bytes.txt, block_size: 1024Note the task_id from response | FUOTA task created successfullyResponse: { \"Id\": \"<task_id>\" }Key check: task_id obtained | . | 3 | Associate EN wireless device ID with the FUOTA task | Response: 2xxKey check: EN associated with FUOTA task | . | 4 | Schedule start time for the FUOTA task (at least 5 minutes from now) | Response: 2xxKey check: FUOTA task scheduled | . | 5 | Wait for BLE disconnected, establish BLE connection and send UL:sid conn_req 1sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 1Key check: UL sent via BLE | . | 6 | Wait for file transfer to start (blocks transferring):Monitor EN log | DEC: M:15 [3:5:1]Key check: File transfer started | . | 7 | Power off EN and re-initialize:sbdt deinitsid deinitReboot ENWait 10 seconds to simulate EN offlinesid init 1sid startsbdt init | SBDT: LOAD [...]CMD: ERR: 0Key check: EN re-initialized, pending transfer detected (LOAD) | . | 8 | Wait for file transfer to complete (timeout: 600s):Monitor EN log | DEC: M:15 [3:D:2]Key check: File transfer resumed and completed | . | 9 | Check file transfer task status on cloud:task_id: <task_id> | Task status: FuotaDoneWireless device status: SuccessfulKey check: Cloud confirms transfer complete | . ", "url": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferrecoverybi01-recover-transfer-after-ep-powered-off-and-back-on", "relUrl": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferrecoverybi01-recover-transfer-after-ep-powered-off-and-back-on" },"274": { "doc": "9. File Transfer Test Cases", "title": "Test Case ID: BLE/EP/API/FILETRANSFER/RECOVERY/BI/02: Recover transfer after EP was out of range from GW", "content": "| Field | Value | . | Case ID | C103619299 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | BLE stack initialized | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack and start:sid init 1sid startsbdt init | EN is started and time syncedKey check: SBDT initialized | . | 2 | Create FUOTA task, associate EN, and schedule start:Call CreateFuotaTask APICall AssociateFuotaTask APICall ScheduleFuotaTask API (Gamma 3 min, Prod 5 min later) | FUOTA task created and scheduledKey check: Task ready | . | 3 | After data blocks start sending, move EN out of GW range | Transfer interruptedKey check: EN out of range | . | 4 | After 1 minute, move EN back to GW range | File transfer recovered. Sidewalk Cloud resends remaining blocks.Device receives uncorrupted file.Expected Finalize Response:DEC: M:15 [3:8:1]ENC: M:15 [3:8:3]DEC: M:15 [3:D:2]Key check: File transfer completed successfully | . ", "url": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferrecoverybi02-recover-transfer-after-ep-was-out-of-range-from-gw", "relUrl": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferrecoverybi02-recover-transfer-after-ep-was-out-of-range-from-gw" },"275": { "doc": "9. File Transfer Test Cases", "title": "Test Case ID: BLE/EP/API/FILETRANSFER/RECOVERY/BI/03: Recover transfer after GW that was using to send packets switched to another GW", "content": "| Field | Value | . | Case ID | C103619300 | . | Executable by Customer | No | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | BLE stack initialized | Two GWs available (GW1, GW2) | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack and start:sid init 1sid startsbdt init | EN is started and time syncedKey check: SBDT initialized | . | 2 | Create FUOTA task, associate EN, and schedule start:Call CreateFuotaTask APICall AssociateFuotaTask APICall ScheduleFuotaTask API (Gamma 3 min, Prod 5 min later) | FUOTA task created and scheduledKey check: Task ready | . | 3 | After data blocks start sending, turn off GW1 and turn on GW2 | File transfer recovered via GW2. Sidewalk Cloud resends remaining blocks.Device receives uncorrupted file.Expected Finalize Response:DEC: M:15 [3:8:1]ENC: M:15 [3:8:3]DEC: M:15 [3:D:2]Key check: File transfer completed successfully | . ", "url": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferrecoverybi03-recover-transfer-after-gw-that-was-using-to-send-packets-switched-to-another-gw", "relUrl": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferrecoverybi03-recover-transfer-after-gw-that-was-using-to-send-packets-switched-to-another-gw" },"276": { "doc": "9. File Transfer Test Cases", "title": "Test Case ID: BLE/EP/API/FILETRANSFER/RECOVERY/BI/04: Recover transfer after GW that was using to send packets being opt-out", "content": "| Field | Value | . | Case ID | C103619301 | . | Executable by Customer | No | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | BLE stack initialized | (Preconditions to be provided.) | . Test Steps . No test steps available for this test case. ", "url": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferrecoverybi04-recover-transfer-after-gw-that-was-using-to-send-packets-being-opt-out", "relUrl": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferrecoverybi04-recover-transfer-after-gw-that-was-using-to-send-packets-being-opt-out" },"277": { "doc": "9. File Transfer Test Cases", "title": "Test Case ID: BLE/EP/API/FILETRANSFER/RECOVERY/BI/05: Recover transfer after GW that was using to send packets powered off for a while and back on", "content": "| Field | Value | . | Case ID | C103619302 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | BLE stack initialized | File transfer in progress | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Wait for the device to start receiving parts of the file, then turn off GW for 5 minutes, then turn it back on | File transfer recovered. Sidewalk Cloud resends remaining blocks.Device receives uncorrupted file.Expected Finalize Response:DEC: M:15 [3:8:1]ENC: M:15 [3:8:3]DEC: M:15 [3:D:2]Key check: File transfer completed successfully | . ", "url": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferrecoverybi05-recover-transfer-after-gw-that-was-using-to-send-packets-powered-off-for-a-while-and-back-on", "relUrl": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html#test-case-id-bleepapifiletransferrecoverybi05-recover-transfer-after-gw-that-was-using-to-send-packets-powered-off-for-a-while-and-back-on" },"278": { "doc": "9. File Transfer Test Cases", "title": "9. File Transfer Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/file-transfer-test-cases.html" },"279": { "doc": "4.8 Flex Layer messaging", "title": "4.8 Flex Layer messaging", "content": "4.8.1 Flex Layers . Flex Layer headers use a Type, Length Value (TLV) format. The Flex Layer header format is used for Network Layer header content and Link Layer header content in the Flex headers for Gateway to cloud communication and for cloud to Gateway communication. Flex headers are also used to achieve different security layers for communications. Single and Double flex headers are supported in Amazon Sidewalk communication. fig 4.22 Single Flex Layer . fig 4.23 Double Flex Layer . 4.8.2 Flex Layers message flow . It is assumed that the Gateway is registered in the Amazon Sidewalk network. See section 4.4.2.1. It is assumed that the Endpoint has successfully finished the Join procedure, and the Endpoint time is synchronized. A packet received from the Endpoint (with TXID) is encrypted with the Gateway’s GCM_KEY and encapsulated in an inner flex packet (inner flex headers are added). The whole inner flex packet is encapsulated in an outer flex frame (with header and security related metadata) and sent over a TCP/IP secured link towards the Network Server in the Sidewalk Cloud. The Network server, recovers the Device ID from the TXID, decrypts the flex data using the GCM_KEY key and routes the encrypted message to the Application server. The Application server decrypts the payload data and redirects the payload to the relevant Third party Application ID. Downlink sequence: A message with the destination Device ID is encrypted (using APP_CTR_KEY) and is sent to Network server. A TXID is generated from the Device ID, based on an internal map for device obfuscation. The Inner Flex headers are added and the payload is encrypted with the GCM_KEY. The message is encapsulated in an outer Flex message (headers and security related data are added) and the outer Flex message is sent over secured TCP/IP network to the Gateway. The Gateway decrypts the Flex payload using the GCM_KEY and places the packet with the TXID in a queue (the App message in the Flex payload is still encrypted with the APP_CTR_KEY). The packet is scheduled and sent over the air with preamble and PHY headers. If the Endpoint successfully receives the packet, the Endpoint decrypts the packet using the APP_CTR_KEY (and metadata). For flow diagrams see figure 4.24 and figure 4.25. fig 4.24 EN to Cloud . fig 4.25 Cloud to EN-- . ", "url": "/specifications/sidewalk-protocol-spec/security/flex-layer-messaging.html", "relUrl": "/specifications/sidewalk-protocol-spec/security/flex-layer-messaging.html" },"280": { "doc": "FSK Gateway Location (L2)", "title": "FSK Gateway Location (L2)", "content": " ", "url": "/app-notes/location-library/fsk-gateway-location-l2.html", "relUrl": "/app-notes/location-library/fsk-gateway-location-l2.html" },"281": { "doc": "FSK Gateway Location (L2)", "title": "Introduction", "content": "FSK gateway location works the same way as BLE gateway location (L1) but over an FSK link: the device signals Amazon Sidewalk, which resolves the device’s position from the receiving gateway’s known position. It is used when the device reaches a gateway over FSK rather than BLE. ", "url": "/app-notes/location-library/fsk-gateway-location-l2.html#introduction", "relUrl": "/app-notes/location-library/fsk-gateway-location-l2.html#introduction" },"282": { "doc": "FSK Gateway Location (L2)", "title": "How the Cloud Resolves the Fix", "content": "An FSK gateway fix is resolved from the receiving gateway’s known position, using the same gateway-location path described for BLE gateway location (L1): gateway position lookup and the same validation. The difference from L1 is the link the device used to reach the gateway, not the cloud resolution itself. There is no FSK-specific resolution path. A LoRa uplink is multilaterated and a device reported by several gateways is clustered, but any other single-gateway uplink, including an FSK gateway fix, is resolved from that one gateway’s position. FSK therefore shares L1’s cloud behavior. ", "url": "/app-notes/location-library/fsk-gateway-location-l2.html#how-the-cloud-resolves-the-fix", "relUrl": "/app-notes/location-library/fsk-gateway-location-l2.html#how-the-cloud-resolves-the-fix" },"283": { "doc": "FSK Gateway Location (L2)", "title": "Accuracy and Constraints", "content": ". | Requires an FSK link to a Sidewalk gateway. | Accuracy is gateway-granularity, as with L1: the fix is the gateway’s known position, not a measured device position. | . ", "url": "/app-notes/location-library/fsk-gateway-location-l2.html#accuracy-and-constraints", "relUrl": "/app-notes/location-library/fsk-gateway-location-l2.html#accuracy-and-constraints" },"284": { "doc": "2. FSK Power Optimization", "title": "2. FSK Power Optimization", "content": " ", "url": "/app-notes/power-optimization/fsk-power-optimization.html", "relUrl": "/app-notes/power-optimization/fsk-power-optimization.html" },"285": { "doc": "2. FSK Power Optimization", "title": "2.1 Introduction", "content": "FSK (Frequency Shift Keying) Sub-GHz communication in Amazon Sidewalk provides long-range connectivity with optimized power consumption. This chapter details power optimization techniques specific to FSK links. ", "url": "/app-notes/power-optimization/fsk-power-optimization.html#21-introduction", "relUrl": "/app-notes/power-optimization/fsk-power-optimization.html#21-introduction" },"286": { "doc": "2. FSK Power Optimization", "title": "2.2 Device Profile Optimization", "content": "2.2.1 Profile 1 vs Profile 2 . Choose the appropriate profile based on power requirements: . 2.2.1.1 Profile 1 (Fixed Configuration) . // Profile 1 - Fixed configuration with infinite RX windows struct sid_device_profile profile1 = { .unicast_params = { .device_profile_id = SID_LINK2_PROFILE_1, .rx_window_count = SID_RX_WINDOW_CNT_INFINITE, .beacon_interval_unit = SID_LINK2_BEACON_INTERVAL_UNIT_1, .wakeup_type = SID_TX_AND_RX_WAKEUP, .l2_rx_duration_sec = 0 // Infinite for Profile 1 } }; sid_error_t err = sid_option(handle, SID_OPTION_900MHZ_SET_DEVICE_PROFILE, &profile1, sizeof(profile1)); . Power Characteristics: . | Fixed configuration with infinite RX windows | Always reachable for downlink messages | Higher power consumption due to continuous listening | Limited configurability | . 2.2.1.2 Profile 2 (Configurable for Power Optimization) . // Profile 2 - All configurable parameters for power optimization struct sid_device_profile profile2 = { .unicast_params = { .device_profile_id = SID_LINK2_PROFILE_2, .rx_window_count = SID_RX_WINDOW_CNT_INFINITE, // Fixed for FSK .beacon_interval_unit = SID_LINK2_BEACON_INTERVAL_UNIT_2, // 1, 2, or 3 .unicast_window_interval.sync_rx_interval_ms = 315, // 63-5040ms .wakeup_type = SID_TX_AND_RX_WAKEUP, // TX_ONLY, RX_ONLY, TX_AND_RX .l2_rx_duration_sec = 3600 // 0 to 65535 seconds } }; sid_error_t err = sid_option(handle, SID_OPTION_900MHZ_SET_DEVICE_PROFILE, &profile2, sizeof(profile2)); . Profile 2 Configurable Parameters: . | : 1 (10.08s), 2 (20.16s), 3 (30.24s) | : 63, 315, 630, 945, 2520, 3150, 5040ms | : SID_TX_ONLY_WAKEUP, SID_RX_ONLY_WAKEUP, SID_TX_AND_RX_WAKEUP | : 0 (no downlink) to 65535 seconds | . ", "url": "/app-notes/power-optimization/fsk-power-optimization.html#22-device-profile-optimization", "relUrl": "/app-notes/power-optimization/fsk-power-optimization.html#22-device-profile-optimization" },"287": { "doc": "2. FSK Power Optimization", "title": "2.3 Beacon Synchronization Optimization", "content": "2.3.1 Beacon Interval Configuration . Configure beacon intervals for power efficiency: . | : 10.08s (shortest interval) | : 20.16s (balanced) | : 30.24s (least frequent) | . ", "url": "/app-notes/power-optimization/fsk-power-optimization.html#23-beacon-synchronization-optimization", "relUrl": "/app-notes/power-optimization/fsk-power-optimization.html#23-beacon-synchronization-optimization" },"288": { "doc": "2. FSK Power Optimization", "title": "2.4 RX Window Optimization", "content": "2.4.1 RX Duration Configuration . Profile 2 allows configurable L2 RX duration for power optimization: . // Profile 2 RX duration configuration for power optimization void configure_profile2_rx_duration(enum application_type app_type) { struct sid_device_profile profile = { .unicast_params = { .device_profile_id = SID_LINK2_PROFILE_2, .rx_window_count = SID_RX_WINDOW_CNT_INFINITE, // Fixed for FSK .wakeup_type = SID_TX_AND_RX_WAKEUP } }; switch(app_type) { case SENSOR_ONLY: profile.unicast_params.l2_rx_duration_sec = 0; // No downlink listening break; case STATUS_REPORTER: profile.unicast_params.l2_rx_duration_sec = 300; // 5 minutes break; case INTERACTIVE_DEVICE: profile.unicast_params.l2_rx_duration_sec = 3600; // 1 hour break; case ALWAYS_REACHABLE: profile.unicast_params.l2_rx_duration_sec = 0; // Infinite (same as Profile 1) break; } sid_option(handle, SID_OPTION_900MHZ_SET_DEVICE_PROFILE, &profile, sizeof(profile)); } . 2.4.2 RX Window Separation . Optimize RX window separation for Profile 2: . | : Highest responsiveness, highest power | : Balanced responsiveness and power | : Lower responsiveness, better power | : Lowest responsiveness, best power | . ", "url": "/app-notes/power-optimization/fsk-power-optimization.html#24-rx-window-optimization", "relUrl": "/app-notes/power-optimization/fsk-power-optimization.html#24-rx-window-optimization" },"289": { "doc": "2. FSK Power Optimization", "title": "2.5 FSK Transmit Power Control (TPC)", "content": "Amazon Sidewalk does include FSK TPC algorithm that dynamically manages transmit power between Gateway (GW) and End Point (EP) devices by utilizing RSSI and SNR measurements to optimize power consumption while maintaining reliable communication. How It Works: . | EP sends uplink message using current power level | Gateway measures RSSI/SNR and calculates optimal power adjustment | Gateway provides power adjustment feedback via ACK messages | EP maintains a Channel-Power Mapping Table for 69 channels and adjusts transmit power accordingly | . Key Features: . | Dynamic power adjustment range: -20 dBm to +20 dBm | Channel-specific power mapping for optimal performance | Quick response to changing link quality conditions | Configurable SNR thresholds based on data rates | . Benefits: . | Optimizes power consumption while maintaining reliable communication | Adapts to real-time RF conditions | Channel-specific power optimization | . Note: This feature requires enabling application layer acknowledgment (AWS IoT) for optimal operation. 2.5.1 FSK TPC Testing Results . The FSK TPC feature was evaluated under different environmental conditions to assess its power optimization performance. Testing scenarios included interference-free environments, weak interference (4 additional 0 dBm endpoints), strong interference (4 additional 20 dBm endpoints), and various attenuation levels. Test Environment Configurations: . | Interference-free: Single Endpoint (EN) communicating with single Gateway (GW) | Weak interference: Single EN with connected GW, plus 4 additional 0 dBm EN transmitting | Strong interference: Single EN with connected GW, plus 4 additional 20 dBm EN transmitting | Attenuation: Testing TPC performance with different attenuation levels between EN and GW | . TPC Performance Results: . FSK TPC Power Consumption Results . |   |   |   |   |   |   | . | Environment | EN TPC | GW TPC | TPC On | TPC Off | Power | . |   |   |   | Power (mA) | Power (mA) | Reduction | . | Interference-free | On | Off | 26.868 | 73.090 | 63.24% | . | Interference-free | Off | Off | 26.532 | 74.430 | 64.35% | . | Interference-free | On | On | 22.886 | 76.242 | 69.98% | . | Interference-free | Off | On | 21.726 | 75.978 | 71.40% | . | Weak Interference | On | Off | 37.929 | 41.465 | 8.53% | . | Weak Interference | Off | Off | 27.300 | 63.136 | 56.76% | . | Strong Interference | On | Off | 34.922 | 60.646 | 42.42% | . | Strong Interference | Off | Off | 26.777 | 46.355 | 42.23% | . Key Findings: . | : Up to 71.40% when both EN and GW support TPC in interference-free environments | : TPC maintains 42% power reduction even under strong interference conditions | : Best results achieved with EN TPC Off and GW TPC On in interference-free scenarios | : Weak interference significantly reduces TPC effectiveness (8.53% reduction with EN TPC On) | : TPC provides reliable power savings across different interference scenarios | . Implementation Recommendations: . | Consider EN TPC configuration based on expected interference levels | Monitor interference conditions to optimize TPC settings | Expect significant power savings (40-70%) in typical deployment scenarios | . ", "url": "/app-notes/power-optimization/fsk-power-optimization.html#25-fsk-transmit-power-control-tpc", "relUrl": "/app-notes/power-optimization/fsk-power-optimization.html#25-fsk-transmit-power-control-tpc" },"290": { "doc": "4. FSK (900MHz) Test Cases", "title": "4. FSK (900MHz) Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html" },"291": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.1 FSK/EP/BCN/DISCO/BV/01: FSK-WAN Endpoint discovers neighbor Gateway and synchronizes with it if roaming is allowed.", "content": "4.1.1 Test Purpose . DUT is able to discover and synchronize with neighbor Gateway if roam_opt flag is set to 1 in Beacon. 4.1.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | . 4.1.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Lower_Tester->>DUT: Beacon TX Note over Lower_Tester,Upper_Tester: Wait for end of Gateway Discovery Lower_Tester->>DUT: Beacon TX DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 2, FSK Connected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 4.1.4 Expected Results . 4.1.4.1 Pass Verdict . DUT is able to detect Beacon and synchronize with the neighbor Gateway that allows roaming. Detection of Beacon and synchronization with GW should take place within 40 seconds of starting the Sidewalk stack. In result the FSK stack goes connected state which means that synchronization on PHY layer has been achieved. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#41-fskepbcndiscobv01-fsk-wan-endpoint-discovers-neighbor-gateway-and-synchronizes-with-it-if-roaming-is-allowed", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#41-fskepbcndiscobv01-fsk-wan-endpoint-discovers-neighbor-gateway-and-synchronizes-with-it-if-roaming-is-allowed" },"292": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.2 FSK/EP/BCN/DISCO/BV/02: FSK-WAN Endpoint discovers home Gateway and synchronizes with it even if roaming is forbidden.", "content": "4.2.1 Test Purpose . DUT is able to discover and synchronize with home Gateway even if roam_opt flag is set to 0 in Beacon. 4.2.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is disabled on Lower Tester. | . 4.2.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Lower_Tester->>DUT: Beacon TX Note over Lower_Tester,Upper_Tester: Wait for end of Gateway Discovery Lower_Tester->>DUT: Beacon TX DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 2, FSK Connected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 4.2.4 Expected Results . 4.2.4.1 Pass Verdict . DUT is able to detect Beacon and synchronize with the home Gateway that does not allow roaming. Detection of Beacon and synchronization with Lower Tester should take place within 40 seconds of starting the Sidewalk stack. In result the FSK stack goes connected state which means that synchronization on PHY layer has been achieved. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#42-fskepbcndiscobv02-fsk-wan-endpoint-discovers-home-gateway-and-synchronizes-with-it-even-if-roaming-is-forbidden", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#42-fskepbcndiscobv02-fsk-wan-endpoint-discovers-home-gateway-and-synchronizes-with-it-even-if-roaming-is-forbidden" },"293": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.3 FSK/EP/BCN/DISCO/BV/03: FSK-WAN Endpoint detects a neighbor Gateway Beacon but continues with the Gateway discovery process if roaming is forbidden.", "content": "4.3.1 Test Purpose . DUT is able to detect Beacon frame but continues with the Gateway discovery process if roam_opt flag is set to 0 in Beacon. 4.3.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network using different user accounts. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is disabled on the Lower Tester. | . 4.3.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Lower_Tester->>DUT: Beacon TX Lower_Tester->>DUT: Beacon TX Note over Lower_Tester,Upper_Tester: Beacon frame rejected due to roam_opt=0 Lower_Tester->>DUT: Beacon TX Note over Lower_Tester,Upper_Tester: Beacon frame rejected due to roam_opt=0 Lower_Tester->>DUT: Beacon TX Note over Lower_Tester,Upper_Tester: Beacon frame rejected due to roam_opt=0 Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 4.3.4 Expected Results . 4.3.4.1 Pass Verdict . DUT is able to detect a Beacon, but the Gateway discovery procedure is continued and should not be successful due to disabled SidewalkNetworkFlag. DUT should reject three consecutive Beacon frames which were received after stack is started. In result change of SID application status should not be observed and FSK stack should remain in disconnected state all the time. No transmission of a UL packet should occur during the entire test as DUT is involved in a passive way in Beacon detection for most of time. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#43-fskepbcndiscobv03-fsk-wan-endpoint-detects-a-neighbor-gateway-beacon-but-continues-with-the-gateway-discovery-process-if-roaming-is-forbidden", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#43-fskepbcndiscobv03-fsk-wan-endpoint-detects-a-neighbor-gateway-beacon-but-continues-with-the-gateway-discovery-process-if-roaming-is-forbidden" },"294": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.4 FSK/EP/CONN/REG/BV/02: Endpoint can be deregistered from Sidewalk network.", "content": "4.4.1 Test Purpose . To verify that the DUT is able to be deregistered from the Amazon Sidewalk network. 4.4.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | The Sidewalk stack (FSK) is initialized and started on the DUT. | . 4.4.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 2, FSK Connected Upper_Tester->>DUT: sid_set_factory_reset() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: NOTIFY_RESET(RESET_HARD) DUT->>Upper_Tester: on_status_changed() \"Status: Not registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_get_time() DUT->>Upper_Tester: #35;SID_ERROR_INVALID_ARGS Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Not registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Not Registered, Link Mask 0, FSK Disconnected\" . 4.4.4 Expected Results . 4.4.4.1 Pass Verdict . Calling the sid_set_factory_reset method should force the DUT to send the packet NOTIFY_RESET (with RESET_HARD parameter) to the Lower Tester. Then the DUT should report to the Upper Tester the change in registration status to “Not registered”. After successful deregistration, the attempt to send the GET_TIME packet should fail with the SID_ERROR_INVALID_ARGS returned to the Upper Tester. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#44-fskepconnregbv02-endpoint-can-be-deregistered-from-sidewalk-network", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#44-fskepconnregbv02-endpoint-can-be-deregistered-from-sidewalk-network" },"295": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.5 FSK/EP/CONN/REG/BV/03: An unregistered Endpoint successfully completes Sidewalk device registration with use of FFN.", "content": "4.5.1 Test Purpose . An unregistered DUT configures the Sidewalk stack in FSK mode. DUT synchronizes with Lower Tester (by detecting a Beacon) and starts registration flow by sending “PROV_INIT_REQ” packet to Lower Tester. At the end of the registration flow, DUT receives SET_CONFIGURATION_COMPLETE packet from Lower Tester and responds with RESP_CONFIGURATION_COMPLETE packet, which is a sign of successful device registration. After that DUT continues to work using FSK radio for Amazon Sidewalk network activities. 4.5.2 Initial Conditions . | DUT is fully unregistered from Amazon Sidewalk network (both Cloud and DUT side) | . 4.5.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Not Registered, Link Mask 0, FSK Disconnected\" Lower_Tester->>DUT: Beacon TX DUT->>Upper_Tester: on_status_changed() \"Status: Not Registered, Link Mask 2, FSK Connected\" Note over Lower_Tester,Upper_Tester: Sidewalk Registration DUT->>Lower_Tester: PROV_INIT_REQ DUT->>Lower_Tester: PROV_INIT_REQ_SIG Lower_Tester->>DUT: RESP_PROV_INIT_REQ Lower_Tester->>DUT: PROV_INIT_SIG DUT->>Lower_Tester: RESP_PROV_INIT_SIG Lower_Tester->>DUT: GET_DEVICE_ECDH_SIG DUT->>Lower_Tester: RESP_DEVICE_ECDH_SIG Lower_Tester->>DUT: HAND_SHAKE_REQ DUT->>Lower_Tester: HAND_SHAKE_RESP Lower_Tester->>DUT: SET_PAN_ID DUT->>Lower_Tester: RESP_PAN_ID Lower_Tester->>DUT: SET_P2P_CHANNEL DUT->>Lower_Tester: RESP_P2P_CHANNEL Lower_Tester->>DUT: SET_P2P_BROADCAST_KEY DUT->>Lower_Tester: RESP_P2P_BROADCAST_KEY Lower_Tester->>DUT: SET_WAN_SEC_PARAMS DUT->>Lower_Tester: RESP_WAN_SEC_PARAMS Note over Lower_Tester,Upper_Tester: Continued on next page . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Application Registration Lower_Tester->>DUT: RESP_PROV_INIT_REQ Lower_Tester->>DUT: PROV_INIT_SIG DUT->>Lower_Tester: RESP_PROV_INIT_SIG Lower_Tester->>DUT: GET_DEVICE_ECDH_SIG DUT->>Lower_Tester: RESP_GET_DEVICE_ECDH_SIG Lower_Tester->>DUT: HAND_SHAKE_REQ DUT->>Lower_Tester: RESP_HAND_SHAKE_REQ Lower_Tester->>DUT: SET_CONFIGURATION_COMPLETE DUT->>Lower_Tester: RESP_CONFIGURATION_COMPLETE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 2, FSK Connected\" DUT->>Lower_Tester: GET_TIME Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 2, FSK Connected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, No Time, Link Mask 0, FSK Disconnected\" . 4.5.4 Expected Results . 4.5.4.1 Pass Verdict . Registration process is triggered by DUT, after detecting a Beacon and synchronizing with Lower Tester. DUT sends “PROV_INIT_REQ” packet to initiate the registration flow. Every registration related packet is successfully exchanged between Lower Tester and DUT. During the process of registration, DUT does not change Sidewalk stack. DUT receives “SET_CONFIGURATION_COMPLETE” packet from Lower Tester and responds with “RESP_CONFIGURATION_COMPLETE”. Those two packets signify that DUT is successfully registered with Amazon Sidewalk network with use of FFN. Afterwards, DUT completes time synchronization over FSK. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#45-fskepconnregbv03-an-unregistered-endpoint-successfully-completes-sidewalk-device-registration-with-use-of-ffn", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#45-fskepconnregbv03-an-unregistered-endpoint-successfully-completes-sidewalk-device-registration-with-use-of-ffn" },"296": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.6 FSK/EP/CONN/SEQ/BV/01: Uplink packets contain SEQ number.", "content": "4.6.1 Test Purpose . To verify that the uplink packets sent by the DUT contain the sequence number written in the seq_num field in the Link Layer. With each subsequent sent packet, the value of seq_num should be incremented by one. 4.6.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 4.6.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 2, FSK Connected Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with seq_num field in the Link Layer) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with seq_num field in the Link Layer) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with seq_num field in the Link Layer) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with seq_num field in the Link Layer) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 4.6.4 Expected Results . 4.6.4.1 Pass Verdict . The seq_num field is properly filled in the Link Layer of each CUSTOM_NOTIFY_CMD packet sent by DUT. Moreover, seq_num of each CUSTOM_NOTIFY_CMD packet should be incremented by one relative to the seq_num of the previous transmitted packet. As the packet sequence number is sent as plain text in the Link Layer, the above condition can be validated on the Lower Tester side. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#46-fskepconnseqbv01-uplink-packets-contain-seq-number", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#46-fskepconnseqbv01-uplink-packets-contain-seq-number" },"297": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.7 FSK/EP/CONN/SEQ/BV/02: Endpoint increments uplink SEQ number until UUID changes.", "content": "4.7.1 Test Purpose . To verify that the DUT increments the uplink packet sequence number until the UUID is changed. After the UUID is changed, the DUT should generate a new sequence number in the range between 0 and 16383. 4.7.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 4.7.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 2, FSK Connected Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with seq_num field in the Link Layer) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,DUT: ... Note over Lower_Tester,Upper_Tester: Repeat the uplink packet once per minute for up to 15 minutes Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with seq_num field in the Link Layer) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 4.7.4 Expected Results . 4.7.4.1 Pass Verdict . The seq_num field should be properly incremented by one for each subsequent packet sent by DUT within a maximum of 15 minutes from the previous UUID change, then a new sequence number should be generated in the range between 0 and 16383. As the packet sequence number is sent as plain text in the Link Layer, all CUSTOM_NOTIFY_CMD packets can be verified for seq_num field content on the Lower Tester side. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#47-fskepconnseqbv02-endpoint-increments-uplink-seq-number-until-uuid-changes", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#47-fskepconnseqbv02-endpoint-increments-uplink-seq-number-until-uuid-changes" },"298": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.8 FSK/EP/CONN/SEQ/BV/03: Endpoint accepts and decodes downlink packets with increased and decreased SEQ.", "content": "4.8.1 Test Purpose . To verify that the downlink packets with both increasing and decreasing sequence number can be decoded by the DUT. 4.8.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 4.8.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 2, FSK Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=2) DUT->>Upper_Tester: on_msg_received() \"seq_num=2\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=3) DUT->>Upper_Tester: on_msg_received() \"seq_num=3\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=6) DUT->>Upper_Tester: on_msg_received() \"seq_num=6\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=5) DUT->>Upper_Tester: on_msg_received() \"seq_num=5\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=4) DUT->>Upper_Tester: on_msg_received() \"seq_num=4\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 4.8.4 Expected Results . 4.8.4.1 Pass Verdict . The first three CUSTOM_NOTIFY_CMD packets sent by Lower Tester to the DUT contain an increasing sequence number ranging from 1 to 3. The next three CUSTOM_NOTIFY_CMD packets contain a decreasing sequence number ranging from 6 to 4. All sent packets should be accepted and properly decoded by the DUT which should manifested by reporting all six events to the Upper Tester. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#48-fskepconnseqbv03-endpoint-accepts-and-decodes-downlink-packets-with-increased-and-decreased-seq", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#48-fskepconnseqbv03-endpoint-accepts-and-decodes-downlink-packets-with-increased-and-decreased-seq" },"299": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.9 FSK/EP/CONN/SEQ/BV/05: Endpoint rejects downlink packet with duplicated SEQ.", "content": "4.9.1 Test Purpose . To verify that a downlink packet which contains a duplicated sequence number is rejected by the DUT. 4.9.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 4.9.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 2, FSK Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=2) DUT->>Upper_Tester: on_msg_received() \"seq_num=2\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=2) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 4.9.4 Expected Results . 4.9.4.1 Pass Verdict . The first CUSTOM_NOTIFY_CMD packet sent by the Lower Tester containing sequence number equal to 1 should be decoded correctly and information about this event should be visible on the Upper Tester side. However, another CUSTOM_NOTIFY_CMD packet sent by the Lower Tester also containing the same sequence number should be rejected by the DUT. The third CUSTOM_NOTIFY_CMD packet containing parameter seq_num increased by one should be decoded correctly and information about this event should again be visible on the Upper Tester side. The fourth CUSTOM_NOTIFY_CMD packet with a duplicated seq_num equal to 2 should be rejected by the DUT. In the case of duplicate packets, information about this event should not be visible on the Upper Tester side. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#49-fskepconnseqbv05-endpoint-rejects-downlink-packet-with-duplicated-seq", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#49-fskepconnseqbv05-endpoint-rejects-downlink-packet-with-duplicated-seq" },"300": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.10 FSK/EP/CONN/SEQ/BV/06: Endpoint rejects downlink packet with duplicated SEQ range.", "content": "4.10.1 Test Purpose . To verify that a group of five downlink packets which contain a duplicate sequence number are rejected by the DUT. 4.10.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 4.10.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 2, FSK Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=2) DUT->>Upper_Tester: on_msg_received() \"seq_num=2\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=3) DUT->>Upper_Tester: on_msg_received() \"seq_num=3\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=4) DUT->>Upper_Tester: on_msg_received() \"seq_num=4\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=5) DUT->>Upper_Tester: on_msg_received() \"seq_num=5\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=2) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=3) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=4) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=5) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 4.10.4 Expected Results . 4.10.4.1 Pass Verdict . The first five CUSTOM_NOTIFY_CMD packets with sequence numbers increasing sequentially from 1 to 5 should be sent from the Lower Tester and correctly decoded on the DUT side. Receipt of all five of these packets should be reported on the Upper Tester side. After re-sending from the Lower Tester the same packets containing sequence numbers from 1 to 5, all of them should be rejected by the DUT. Information on these five events should not be visible on the Upper Tester side. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#410-fskepconnseqbv06-endpoint-rejects-downlink-packet-with-duplicated-seq-range", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#410-fskepconnseqbv06-endpoint-rejects-downlink-packet-with-duplicated-seq-range" },"301": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.11 FSK/EP/CONN/SEQ/BV/07: SEQ number can be accepted again after getting 10 other messages.", "content": "4.11.1 Test Purpose . DUT is able to receive downlink packet with already used SEQ number, after receiving at least 10 additional packets with different, unique SEQ number. 4.11.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 4.11.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 2, FSK Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=2) DUT->>Upper_Tester: on_msg_received() \"seq_num=2\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=3) DUT->>Upper_Tester: on_msg_received() \"seq_num=3\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=4) DUT->>Upper_Tester: on_msg_received() \"seq_num=4\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=5) DUT->>Upper_Tester: on_msg_received() \"seq_num=5\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=6) DUT->>Upper_Tester: on_msg_received() \"seq_num=6\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=7) DUT->>Upper_Tester: on_msg_received() \"seq_num=7\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=8) DUT->>Upper_Tester: on_msg_received() \"seq_num=8\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=9) DUT->>Upper_Tester: on_msg_received() \"seq_num=9\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=10) DUT->>Upper_Tester: on_msg_received() \"seq_num=10\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=11) DUT->>Upper_Tester: on_msg_received() \"seq_num=11\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 4.11.4 Expected Results . 4.11.4.1 Pass Verdict . First, eleventh and thirteenth CUSTOM_NOTIFY_CMD packet contain the same SEQ number. All the other CUSTOM_NOTIFY_CMD packets contain different, unique SEQ number. Due to the fact that 10 additional packets have to be received by DUT before SEQ number can be reused: Eleventh CUSTOM_NOTIFY_CMD packet should be rejected by DUT (after 9 additional packets received). Thirteenth CUSTOM_NOTIFY_CMD packet should be received and decoded properly by DUT (after 10 additional packets received). ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#411-fskepconnseqbv07-seq-number-can-be-accepted-again-after-getting-10-other-messages", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#411-fskepconnseqbv07-seq-number-can-be-accepted-again-after-getting-10-other-messages" },"302": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.12 FSK/EP/CONN/SEQ/BV/08: SEQ number can be accepted again after Sidewalk stack reinitialization.", "content": "4.12.1 Test Purpose . DUT is able to receive downlink packet with already used SEQ number, after reinitialization of Sidewalk stack. 4.12.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 4.12.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 2, FSK Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Not Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Wait until DUT completes time sync and Join procedure DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 2, FSK Connected\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 4.12.4 Expected Results . 4.12.4.1 Pass Verdict . First and third CUSTOM_NOTIFY_CMD packets should be received and decoded properly by DUT, despite having the same SEQ number. Since there was no stack reinitialization before second CUSTOM_NOTIFY_CMD packet, it should be rejected by DUT because of repeating SEQ number. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#412-fskepconnseqbv08-seq-number-can-be-accepted-again-after-sidewalk-stack-reinitialization", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#412-fskepconnseqbv08-seq-number-can-be-accepted-again-after-sidewalk-stack-reinitialization" },"303": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.13 FSK/EP/CONN/SEQ/BV/09: Endpoint drops the packet with SEQ which is out of range.", "content": "4.13.1 Test Purpose . To verify that a downlink packet which contains an out of range sequence number is dropped by the DUT. 4.13.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 4.13.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 2, FSK Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=16383) DUT->>Upper_Tester: on_msg_received() \"seq_num=16383\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=16384) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 4.13.4 Expected Results . 4.13.4.1 Pass Verdict . The first CUSTOM_NOTIFY_CMD packet sent by the Lower Tester containing the maximum allowed sequence number (16383) should be decoded correctly and information about this event should be visible on the Upper Tester side. The second CUSTOM_NOTIFY_CMD packet sent by the Lower Tester should be dropped by the DUT due to the seq_num parameter being exceeded and therefore this event should not be reported to the Upper Tester. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#413-fskepconnseqbv09-endpoint-drops-the-packet-with-seq-which-is-out-of-range", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#413-fskepconnseqbv09-endpoint-drops-the-packet-with-seq-which-is-out-of-range" },"304": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.14 FSK/EP/DATA/DL/BV/01: Endpoint receives downlink packets with various sizes of Command data.", "content": "4.14.1 Test Purpose . DUT is able to receive downlink packets with various sizes of Command data (1B, 100B, 200B) sent from the Lower Tester. 4.14.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 4.14.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 2, FSK Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with 1B of Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: 1B\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with 100B of Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: 100B\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with 200B of Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: 200B\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 4.14.4 Expected Results . 4.14.4.1 Pass Verdict . Packets with various sizes of Command data sent by Lower Tester are able to reach the DUT. The Command data content must be verified for correctness on the Upper Tester side. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#414-fskepdatadlbv01-endpoint-receives-downlink-packets-with-various-sizes-of-command-data", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#414-fskepdatadlbv01-endpoint-receives-downlink-packets-with-various-sizes-of-command-data" },"305": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.15 FSK/EP/DATA/UL/BV/01: Gateway receives uplink packets with various sizes of Command data from Endpoint.", "content": "4.15.1 Test Purpose . Lower Tester is able to receive uplink packets with various sizes of Command data (1B, 100B, 200B) sent from the DUT. 4.15.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 4.15.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 2, FSK Connected Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data 1B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data 100B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 100B of Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data 200B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 200B of Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 4.15.4 Expected Results . 4.15.4.1 Pass Verdict . Packets with various sizes of Command data sent by DUT are able to reach the Lower Tester. The Command data content of each packet must be verified for correctness on the Lower Tester side. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#415-fskepdataulbv01-gateway-receives-uplink-packets-with-various-sizes-of-command-data-from-endpoint", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#415-fskepdataulbv01-gateway-receives-uplink-packets-with-various-sizes-of-command-data-from-endpoint" },"306": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.16 FSK/EP/NW/SYNC/TIME/BV/01: Endpoint completes the initial time sync procedure.", "content": "4.16.1 Test Purpose . DUT is able to pass the initial time synchronization procedure. 4.16.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | . 4.16.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, FSK Disconnected\" Lower_Tester->>DUT: Beacon TX Note over Lower_Tester,Upper_Tester: Wait for end of Gateway Discovery Lower_Tester->>DUT: Beacon TX DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 2, FSK Connected\" DUT->>Lower_Tester: GET_TIME Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Up, Time Synced, Link Mask 2, FSK Connected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, FSK Disconnected\" . 4.16.4 Expected Results . 4.16.4.1 Pass Verdict . DUT is able to acquire time from the network. Moreover, the GET_TIME packet must be the first UL transmission right after detecting the Beacon and synchronizing with the Lower Tester. The RESP_TIME packet will be sent to DUT within 30 seconds and no re-transmission of the GET_TIME packet should occur during this time. No other UL transmission should take place until the DUT receives a correct RESP_TIME packet which will be reported via Time Status: Synced. Completion of the time synchronization procedure should also change the Link Status to Up. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#416-fskepnwsynctimebv01-endpoint-completes-the-initial-time-sync-procedure", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#416-fskepnwsynctimebv01-endpoint-completes-the-initial-time-sync-procedure" },"307": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.17 FSK/EP/NW/SYNC/JOIN/BV/01: Endpoint completes the initial Join procedure.", "content": "4.17.1 Test Purpose . DUT is able to pass the initial Join procedure. 4.17.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile 1 (FSK-WAN ADHOC). | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | . 4.17.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_option(SET_DEVICE_PROFILE, SID_LINK2_PROFILE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, FSK Disconnected\" Lower_Tester->>DUT: Beacon TX Note over Lower_Tester,Upper_Tester: Wait for end of Gateway Discovery Lower_Tester->>DUT: Beacon TX DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 2, FSK Connected\" DUT->>Lower_Tester: GET_TIME Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Up, Time Synced, Link Mask 2, FSK Connected\" DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ Note over Lower_Tester,Upper_Tester: Wait 31 seconds Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, FSK Disconnected\" . 4.17.4 Expected Results . 4.17.4.1 Pass Verdict . DUT is able to acquire positive Join response from the network. Moreover, the GET_TIME packet must be the first UL transmission right after detecting the Beacon and synchronizing with the Lower Tester. The RESP_TIME packet will be sent to DUT within 30 seconds and no re-transmission of the GET_TIME packet should occur during this time. Also no other UL transmission is allowed before the DUT receives the RESP_TIME packet which will be reported via Time Status: Synced. Completion of the time synchronization procedure should also change the Link Status to Up. DUT should send the SET_JOIN_REQ packet right after the time synchronization procedure is complete. The RESP_JOIN_REQ packet will be sent back to DUT within 31 seconds and until then DUT should not repeat the transmission of the next SET_JOIN_REQ commands. This means the Join procedure completes as expected. As the SET_JOIN_REQ carries requested link characteristics for both UL and the DL messaging expected on the end device, its content must be verified against the declared capabilities of the DUT. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#417-fskepnwsyncjoinbv01-endpoint-completes-the-initial-join-procedure", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#417-fskepnwsyncjoinbv01-endpoint-completes-the-initial-join-procedure" },"308": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.18 FSK/EP/NW/SYNC/JOIN/BV/02: Endpoint keeps synchronization with the network by periodic transmission of Join request.", "content": "4.18.1 Test Purpose . DUT is able to keep synchronization with the network by periodic transmission of Join request. When the time sync and Join procedure is completed device is automatically synchronized with the network. Then after a period of 840 seconds of uplink inactivity (no data is transmitted), the DUT should send another Join request command to keep link with the network active/alive. 4.18.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile 1 (FSK-WAN ADHOC). | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | . 4.18.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_option(SET_DEVICE_PROFILE, SID_LINK2_PROFILE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, FSK Disconnected\" Lower_Tester->>DUT: Beacon TX Note over Lower_Tester,Upper_Tester: Wait for end of Gateway Discovery Lower_Tester->>DUT: Beacon TX DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 2, FSK Connected\" DUT->>Lower_Tester: GET_TIME Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Up, Time Synced, Link Mask 2, FSK Connected\" DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ Note over Lower_Tester,Upper_Tester: Wait 840 seconds for the end of 'in sync' state on DUT DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ Note over Lower_Tester,Upper_Tester: Wait 31 seconds Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, FSK Disconnected\" . 4.18.4 Expected Results . 4.18.4.1 Pass Verdict . DUT is able to acquire positive response from the network when Join request is sent during the active synchronization process. The GET_TIME packet must be the first uplink transmission right after detecting the Beacon and synchronizing with the Lower Tester. The RESP_TIME packet will be sent to DUT within 30 seconds and no re-transmission of the GET_TIME packet should occur during this time. Also no other uplink transmission is allowed before the DUT receives the RESP_TIME packet which will be reported via Time Status: Synced. Completion of the time synchronization procedure should also change the Link Status to Up. DUT should send the SET_JOIN_REQ packet right after the time synchronization procedure is complete. The RESP_JOIN_REQ packet should be sent back to DUT within 31 seconds and until then DUT should not repeat the transmission of the next SET_JOIN_REQ commands. After sending the first RESP_JOIN_REQ, wait 840 seconds after which DUT should send the second SET_JOIN_REQ packet to keep synchronization with the network. No uplink transmission should occur during this period. After sending the second RESP_JOIN_REQ, wait 31 seconds and verify that DUT has not resent SET_JOIN_REQ. This means that the DUT is able to maintain synchronization with the network by periodic transmission of Join request. As the initial SET_JOIN_REQ carries requested link characteristics for both uplink and the downlink messaging expected on the end device, its content must be verified against the declared capabilities of the DUT. In the case of the second SET_JOIN_REQ (Join request related to Network Synchronization), the only content that must be verified is the GWID field. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#418-fskepnwsyncjoinbv02-endpoint-keeps-synchronization-with-the-network-by-periodic-transmission-of-join-request", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#418-fskepnwsyncjoinbv02-endpoint-keeps-synchronization-with-the-network-by-periodic-transmission-of-join-request" },"309": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.19 FSK/EP/SEC/UUID/BV/01: Endpoint rotates UUID immediately after time sync.", "content": "4.19.1 Test Purpose . DUT is able to change the current UUID and use it right after the time synchronization procedure is completed. 4.19.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 4.19.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, FSK Disconnected\" Lower_Tester->>DUT: Beacon TX Note over Lower_Tester,Upper_Tester: Wait for end of Gateway Discovery Lower_Tester->>DUT: Beacon TX DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 2, FSK Connected\" DUT->>Lower_Tester: GET_TIME(TX-UUID-1) Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Up, Time Synced, Link Mask 2, FSK Connected\" DUT->>Lower_Tester: SET_JOIN_REQ(TX-UUID-2) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, FSK Disconnected\" . 4.19.4 Expected Results . 4.19.4.1 Pass Verdict . UUID of the Endpoint should change right after successful time synchronization procedure, therefore the value of TX-UUID sent as part of the GET_TIME packet should be different from the TX-UUID sent in the SET_JOIN_REQ packet. As the source device ID information is sent as plain text in the link layer, the above condition can be validated on the Lower Tester side. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#419-fskepsecuuidbv01-endpoint-rotates-uuid-immediately-after-time-sync", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#419-fskepsecuuidbv01-endpoint-rotates-uuid-immediately-after-time-sync" },"310": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.20 FSK/EP/SEC/UUID/BV/02: UUID rotates every 15 minutes after time sync.", "content": "4.20.1 Test Purpose . DUT is able to change the UUID every 15 minutes after the time synchronization procedure is completed. 4.20.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 4.20.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, FSK Disconnected\" Lower_Tester->>DUT: Beacon TX Note over Lower_Tester,Upper_Tester: Wait for end of Gateway Discovery Lower_Tester->>DUT: Beacon TX DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 2, FSK Connected\" DUT->>Lower_Tester: GET_TIME(TX-UUID-1) Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Up, Time Synced, Link Mask 2, FSK Connected\" DUT->>Lower_Tester: SET_JOIN_REQ(TX-UUID-2) Note over Lower_Tester,Upper_Tester: Wait up to 15 minutes for the DUT to change the UUID Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(TX-UUID-3) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,Upper_Tester: Wait 15 minutes for DUT to change the UUID Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(TX-UUID-4) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, FSK Disconnected\" . 4.20.4 Expected Results . 4.20.4.1 Pass Verdict . After successful time synchronization procedure, the UUID of the DUT should change every 15 minutes (the first change may occur earlier). Therefore, the TX-UUID value sent as part of the SET_JOIN_REQ packet should be different from the TX-UUID sent up to 15 minutes later in the CUSTOM_NOTIFY_CMD packet. The next CUSTOM_NOTIFY_CMD packet sent exactly 15 minutes after the previous UUID change should contain the new UUID. As the source device ID information is sent as plain text in the link layer, the above condition can be validated on the Lower Tester side. 4.20.5.2 Fail Verdict . A test failure will occur if the DUT re-uses an older TX-UUID at any point during the test. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#420-fskepsecuuidbv02-uuid-rotates-every-15-minutes-after-time-sync", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#420-fskepsecuuidbv02-uuid-rotates-every-15-minutes-after-time-sync" },"311": { "doc": "4. FSK (900MHz) Test Cases", "title": "4.21 FSK/EP/SEC/UUID/BV/03: Endpoint can exchange UL/DL during UUID rotation.", "content": "4.21.1 Test Purpose . DUT is able to exchange the uplink and downlink packets during UUID rotation. 4.21.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 4.21.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Lower_Tester->>DUT: Beacon TX Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, FSK Disconnected\" Lower_Tester->>DUT: Beacon TX Note over Lower_Tester,Upper_Tester: Wait for end of Gateway Discovery Lower_Tester->>DUT: Beacon TX DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 2, FSK Connected\" DUT->>Lower_Tester: GET_TIME(TX-UUID-1) Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Up, Time Synced, Link Mask 2, FSK Connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(TX-UUID-2) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(TX-UUID-2) DUT->>Upper_Tester: on_msg_received() Note over Lower_Tester,Upper_Tester: Continue sending the above uplink and downlink packets with 1 second interval until the UUID changes Note over Lower_Tester,DUT: ... Note over Lower_Tester,Upper_Tester: UUID rotation Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(TX-UUID-3) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(TX-UUID-3) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, FSK Disconnected\" . 4.21.4 Expected Results . 4.21.4.1 Pass Verdict . After successful time synchronization procedure, the UUID of the DUT should change every 15 minutes. All packets, both uplink and downlink, transmitted around the moment of UUID rotation should be handled correctly and reach the destination. ", "url": "/specifications/sidewalk-test-spec/fsk-test-cases.html#421-fskepsecuuidbv03-endpoint-can-exchange-uldl-during-uuid-rotation", "relUrl": "/specifications/sidewalk-test-spec/fsk-test-cases.html#421-fskepsecuuidbv03-endpoint-can-exchange-uldl-during-uuid-rotation" },"312": { "doc": "5. FSK Test Cases", "title": "FSK Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#fsk-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#fsk-test-cases" },"313": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/BCN/DISCO/BV-01: FSK-WAN Endpoint discovers neighbor Gateway beacon and synchronizes with it if roaming is allowed", "content": "| Field | Value | . | Case ID | C83932917 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start FSK stack: sid init 2 sid start | Each command returns: CMD: ERR: 0 EN detects beacon and synchronizes with GW within 40 seconds EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 1, BLE: 0 | . Key check: Time: 0 (time synced), FSK: 1 . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenbcndiscobv-01-fsk-wan-endpoint-discovers-neighbor-gateway-beacon-and-synchronizes-with-it-if-roaming-is-allowed", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenbcndiscobv-01-fsk-wan-endpoint-discovers-neighbor-gateway-beacon-and-synchronizes-with-it-if-roaming-is-allowed" },"314": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/BCN/DISCO/BV-02: FSK-WAN Endpoint discovers home Gateway and synchronizes with it even if roaming is forbidden", "content": "| Field | Value | . | Case ID | C83932918 | . | Executable by Customer | Yes | . Preconditions . | PAN device. | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start FSK stack: sid init 2 sid start | Each command returns: CMD: ERR: 0 | . | 2 | EN gets GW FSK beacon | [INFO]: Disco active [INFO]: GWD scan started | . | 3 | EN accepts beacon and completes time sync. Verify with: sid last_status | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 1, BLE: 0 | . Key check: Time: 0 (time synced), FSK: 1 . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenbcndiscobv-02-fsk-wan-endpoint-discovers-home-gateway-and-synchronizes-with-it-even-if-roaming-is-forbidden", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenbcndiscobv-02-fsk-wan-endpoint-discovers-home-gateway-and-synchronizes-with-it-even-if-roaming-is-forbidden" },"315": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/BCN/DISCO/BV-03: FSK-WAN Endpoint detects a neighbor Gateway beacon but continues with the GW discovery process if roaming is forbidden", "content": "| Field | Value | . | Case ID | C83932919 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Disable Sidewalk on GW via Amazon Alexa app: Amazon Alexa app -> More -> Account Settings -> Amazon Sidewalk -> Enabled -> Disable | Amazon Sidewalk set to OFF on Mobile. | . | 2 | Restart EN: sid init 2 sid start | Each command returns: CMD: ERR: 0 | . | 3 | Verify EN starts GW discovery (Disco active) | [INFO]: Disco active. LSC=<x>, symb=<x>, rx_to_ms=<x> | . | 4 | Wait for Disco stop sampling success | [INFO]: Disco stop sampling success. Time elapsed = 120002 ms (+-1000ms) | . Key check: EN continues GW discovery without synchronizing to neighbor GW . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenbcndiscobv-03-fsk-wan-endpoint-detects-a-neighbor-gateway-beacon-but-continues-with-the-gw-discovery-process-if-roaming-is-forbidden", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenbcndiscobv-03-fsk-wan-endpoint-detects-a-neighbor-gateway-beacon-but-continues-with-the-gw-discovery-process-if-roaming-is-forbidden" },"316": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/CONN/REG/BV-02: Endpoint can be deregistered from Sidewalk network", "content": "| Field | Value | . | Case ID | C83932921 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Run the following command to deregister the device: sid factory_reset | CMD: ERR: 0 EVENT SID STATUS: State: 1, Reg: 1, Time: 1, Link_Mask: 0 | . Key check: Reg: 1 (deregistered) . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnregbv-02-endpoint-can-be-deregistered-from-sidewalk-network", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnregbv-02-endpoint-can-be-deregistered-from-sidewalk-network" },"317": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/CONN/REG/BV-03: An unregistered Endpoint successfully completes Sidewalk device registration with use of FFN", "content": "| Field | Value | . | Case ID | C83932922 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Run the following commands on the EN device: sid init 2 sid start | Each command returns: CMD: ERR: 0 | . | 2 | Place EN next to a GW. Verify registration status with: sid last_status | EVENT SID STATUS: State: 1, Reg: 0, Time: 1, Link_Mask: 0 | . Key check: Reg: 0 (registered) . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnregbv-03-an-unregistered-endpoint-successfully-completes-sidewalk-device-registration-with-use-of-ffn", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnregbv-03-an-unregistered-endpoint-successfully-completes-sidewalk-device-registration-with-use-of-ffn" },"318": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/CONN/SEQ/BV-01: Uplink packets contain SEQ number", "content": "| Field | Value | . | Case ID | C83932923 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 5 UL packets from EN with 10 byte payload: sid send <10-byte-payload> | CMD: ERR: 0 TYPE: 2 ID: <id> EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 2 LINK_MODE: 0 ADDITIONAL ATTRS: 0 | . Key check: UL packets received on AWS . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-01-uplink-packets-contain-seq-number", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-01-uplink-packets-contain-seq-number" },"319": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/CONN/SEQ/BV-02: Endpoint increments uplink SEQ until UUID changes", "content": "| Field | Value | . | Case ID | C83932925 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 1 UL packet: sid send TEST | FskTx:EnqPkt sqn:<seq> src_frmt:1 src_id:0x<txid> dst_frmt:0 dst_id:0x<gw_id> msg_id:<id> | . | 2 | Wait for UUID rotation (~15 minutes after time sync) | UUID rotated (TX UUID changes) | . | 3 | Send 1 UL packet after UUID rotation: sid send TEST | FskTx:EnqPkt sqn:<new_seq> src_frmt:1 src_id:0x<new_txid> dst_frmt:0 dst_id:0x<gw_id> msg_id:<id> | . Key check: New SEQ number is different from Step 1 (reset after UUID change) . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-02-endpoint-increments-uplink-seq-until-uuid-changes", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-02-endpoint-increments-uplink-seq-until-uuid-changes" },"320": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/CONN/SEQ/BV-03: Endpoint accepts and decodes downlink packets with increased and decreased SEQ", "content": "| Field | Value | . | Case ID | C83932926 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 3 DL packets from AWS IoT with SEQ: 1, 2, 3 | All 3 DL packets received and accepted by EN: EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 2, ... | . | 2 | Send 3 DL packets from AWS IoT with SEQ: 6, 5, 4 | All 3 DL packets received and accepted by EN: EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 2, ... | . Key check: Delivery ratio 100% . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-03-endpoint-accepts-and-decodes-downlink-packets-with-increased-and-decreased-seq", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-03-endpoint-accepts-and-decodes-downlink-packets-with-increased-and-decreased-seq" },"321": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/CONN/SEQ/BV-05: Endpoint rejects downlink packet with duplicated SEQ", "content": "| Field | Value | . | Case ID | C83932927 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Send DL with SEQ=1. Then send DL with SEQ=1 again (duplicate) | First: EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 2, ... (accepted). Second: No EVENT SID RECEIVED within 20 seconds (duplicate rejected) | . | 2 | Send DL with SEQ=2. Then send DL with SEQ=2 again (duplicate) | First: EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 2, ... (accepted). Second: No EVENT SID RECEIVED within 20 seconds (duplicate rejected) | . Key check: Duplicate rejected . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-05-endpoint-rejects-downlink-packet-with-duplicated-seq", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-05-endpoint-rejects-downlink-packet-with-duplicated-seq" },"322": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/CONN/SEQ/BV-06: Endpoint rejects downlink packet with duplicated SEQ range", "content": "| Field | Value | . | Case ID | C83932928 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 5 DL packets with SEQ: 1, 2, 3, 4, 5 | EVENT SID RECEIVED: TYPE: 2, ID: <id>, LEN: <len>, LINK: 2, LINK_MODE: 1, ACK_REQUESTED: 0, ACK: 0, DUP: 0, RSSI: <rssi>, SNR: <snr> | . | 2 | Send 5 DL packets with SEQ: 1, 2, 3, 4, 5 again (all duplicates) | No EVENT SID RECEIVED for any packet | . Key check: All duplicates rejected . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-06-endpoint-rejects-downlink-packet-with-duplicated-seq-range", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-06-endpoint-rejects-downlink-packet-with-duplicated-seq-range" },"323": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK-EP-CONN-SEQ-BV-07: SEQ number can be accepted again after getting 10 other messages", "content": "| Field | Value | . | Case ID | C83932930 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 10 DL packets from AWS IoT with SEQ numbers: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 | Each DL packet received and accepted by EN: EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: - , ... Data: <payload> | . | 2 | Send 1 DL packet with SEQ=1 (duplicate of Step 1) | DL packet rejected by EN (duplicate) | . | 3 | Send 1 DL packet with SEQ=11 (new, non-duplicate) | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: - , ... Data: <payload> | . | 4 | Send 1 DL packet with SEQ=1 again (now outside the 10-SEQ window) | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: - , ... Data: <payload> | . Key check: SEQ=1 accepted again after 10 other messages, Delivery ratio 100% . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fsk-ep-conn-seq-bv-07-seq-number-can-be-accepted-again-after-getting-10-other-messages", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fsk-ep-conn-seq-bv-07-seq-number-can-be-accepted-again-after-getting-10-other-messages" },"324": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/CONN/SEQ/BV-08: SEQ number can be accepted again after End Node reinitialization", "content": "| Field | Value | . | Case ID | C83932933 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Send DL packet with SEQ=1 | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 2, ... | . | 2 | Send DL packet with SEQ=1 again (duplicate) | No EVENT SID RECEIVED within 20 seconds | . | 3 | Reinitialize Sidewalk stack: sid stop sid deinit sid init 2 sid start | Each command returns: CMD: ERR: 0 Wait for time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Wait for join: Nsync st ->2 | . | 4 | Send DL packet with SEQ=1 again (after reinit) | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 2, ... | . Key check: SEQ=1 accepted again after reinit . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-08-seq-number-can-be-accepted-again-after-end-node-reinitialization", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-08-seq-number-can-be-accepted-again-after-end-node-reinitialization" },"325": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/CONN/SEQ/BV-09: Endpoint drops the packet with SEQ which is out of range", "content": "| Field | Value | . | Case ID | C83932934 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Send DL packet with SEQ=0 (minimum valid) | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 2, ... | . | 2 | Send DL packet with SEQ=16383 (maximum valid) | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 2, ... | . | 3 | Send DL packet with SEQ=-1 (out of range) | No EVENT SID RECEIVED within 20 seconds | . | 4 | Send DL packet with SEQ=16384 (out of range) | No EVENT SID RECEIVED within 20 seconds | . Key check: Accepted (SEQ=0, SEQ=16383), Rejected (SEQ=-1, SEQ=16384) . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-09-endpoint-drops-the-packet-with-seq-which-is-out-of-range", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskenconnseqbv-09-endpoint-drops-the-packet-with-seq-which-is-out-of-range" },"326": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/DATA/DL/BV-01: Endpoint receives downlink packets with different payload size from Gateway", "content": "| Field | Value | . | Case ID | C83932935 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 1 DL packet from AWS IoT with 1 byte payload | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: 1, LINK: 2, LINK_MODE: <x>, ACK_REQUESTED: <x>, ACK: <x>, DUP: <x>, RSSI: <x>, SNR: <x> Data: <payload> | . | 2 | Send 1 DL packet from AWS IoT with 50 bytes payload | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: 50, LINK: 2, LINK_MODE: <x>, ACK_REQUESTED: <x>, ACK: <x>, DUP: <x>, RSSI: <x>, SNR: <x> Data: <payload> | . | 3 | Send 1 DL packet from AWS IoT with 200 bytes payload | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: 200, LINK: 2, LINK_MODE: <x>, ACK_REQUESTED: <x>, ACK: <x>, DUP: <x>, RSSI: <x>, SNR: <x> Data: <payload> | . Key check: Delivery ratio 100% . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskendatadlbv-01-endpoint-receives-downlink-packets-with-different-payload-size-from-gateway", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskendatadlbv-01-endpoint-receives-downlink-packets-with-different-payload-size-from-gateway" },"327": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/DATA/UL/BV-01: Gateway receives uplink packet with different payload sizes from Endpoint", "content": "| Field | Value | . | Case ID | C83932936 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 1 UL packet from EN with 1 byte payload: sid send <1-byte-payload> | CMD: ERR: 0 TYPE: 2 ID: <id> EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 2 LINK_MODE: 0 ADDITIONAL ATTRS: 0 | . | 2 | Send 1 UL packet from EN with 50 bytes payload: sid send <50-byte-payload> | CMD: ERR: 0 TYPE: 2 ID: <id> EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 2 LINK_MODE: 0 ADDITIONAL ATTRS: 0 | . | 3 | Send 1 UL packet from EN with 200 bytes payload: sid send <200-byte-payload> | CMD: ERR: 0 TYPE: 2 ID: <id> EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 2 LINK_MODE: 0 ADDITIONAL ATTRS: 0 | . Key check: Packet received on AWS . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskendataulbv-01-gateway-receives-uplink-packet-with-different-payload-sizes-from-endpoint", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskendataulbv-01-gateway-receives-uplink-packet-with-different-payload-sizes-from-endpoint" },"328": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/NW-SYNC/TIME/BV-01: Endpoint completes the initial time sync procedure", "content": "| Field | Value | . | Case ID | C83932937 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Reboot EN, then initialize and start FSK stack: reboot sid init 2 sid start Wait for time sync | Each command returns: CMD: ERR: 0 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 1, BLE: 0 | . Key check: Time: 0 (time synced) . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskennw-synctimebv-01-endpoint-completes-the-initial-time-sync-procedure", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskennw-synctimebv-01-endpoint-completes-the-initial-time-sync-procedure" },"329": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/NW-SYNC/JOIN/BV-01: Endpoint completes the initial join procedure", "content": "| Field | Value | . | Case ID | C83932938 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start FSK stack, then wait for time sync: sid init 2 sid start | Each command returns: CMD: ERR: 0 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 1, BLE: 0 | . | 2 | Wait for join response | Njoin(1, 2) st 2->6 | . Key check: Join response received . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskennw-syncjoinbv-01-endpoint-completes-the-initial-join-procedure", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskennw-syncjoinbv-01-endpoint-completes-the-initial-join-procedure" },"330": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/NW-SYNC/JOIN/BV-02: Endpoint keeps synchronization with the network by periodic transmission of Join request", "content": "| Field | Value | . | Case ID | C83932939 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Wait 14 minutes after time sync. Do not send any UL. | No UL packets sent during this period | . | 2 | Wait for join response | Njoin(1, 2) st 2->6 | . Key check: Join response received (periodic join request) . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskennw-syncjoinbv-02-endpoint-keeps-synchronization-with-the-network-by-periodic-transmission-of-join-request", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskennw-syncjoinbv-02-endpoint-keeps-synchronization-with-the-network-by-periodic-transmission-of-join-request" },"331": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/SEC/UUID/BV-01: Endpoint rotates UUID immediately after time sync", "content": "| Field | Value | . | Case ID | C83932941 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Get initial TX UUID: print txid | TXID: 0x<uuid> | . | 2 | Wait for time sync | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 1, BLE: 0 | . | 3 | Get TX UUID again: print txid | TXID: 0x<new_uuid> | . Key check: UUID is different from Step 1 (rotated after time sync) . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskensecuuidbv-01-endpoint-rotates-uuid-immediately-after-time-sync", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskensecuuidbv-01-endpoint-rotates-uuid-immediately-after-time-sync" },"332": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/SEC/UUID/BV-02: UUID rotates every 15 minutes after time sync", "content": "| Field | Value | . | Case ID | C83932942 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Get initial TX UUID: print txid | TXID: 0x<uuid> | . | 2 | Monitor UUID rotation for 2 rounds. Check UUID every 30 seconds: print txid | Round 1: UUID rotated after ~15 minutes. Round 2: UUID rotated after ~15 minutes | . | 3 | Verify all collected UUIDs are unique | All UUIDs are unique | . Key check: Each rotation within 14-16 minutes, no duplicate UUID detected . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskensecuuidbv-02-uuid-rotates-every-15-minutes-after-time-sync", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskensecuuidbv-02-uuid-rotates-every-15-minutes-after-time-sync" },"333": { "doc": "5. FSK Test Cases", "title": "Test Case ID: FSK/EN/SEC/UUID/BV-03: Endpoint can exchange UL/DL during UUID rotation", "content": "| Field | Value | . | Case ID | C83932943 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Get initial TX UUID: print txid | TXID: 0x<uuid> | . | 2 | Wait for 1st UUID rotation (check every 30s): print txid | TXID: 0x<new_uuid> | . | 3 | Wait ~14 minutes, then send UL/DL continuously until 2nd UUID rotation: sid send <5-byte-payload> (UL), Send DL from AWS IoT (DL). After 2nd rotation, send one more UL/DL to confirm | UL: EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 2 LINK_MODE: 0 DL: EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: 5, LINK: 2, ... 2nd UUID rotation detected. UL/DL still works after rotation | . Key check: UL/DL successful before and after UUID rotation . ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskensecuuidbv-03-endpoint-can-exchange-uldl-during-uuid-rotation", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html#test-case-id-fskensecuuidbv-03-endpoint-can-exchange-uldl-during-uuid-rotation" },"334": { "doc": "5. FSK Test Cases", "title": "5. FSK Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/fsk-test-cases.html" },"335": { "doc": "5.4 Gateway connection modes", "title": "5.4 Gateway connection modes", "content": "In the sub-GHz band, a Gateway operates in one of four modes: . | SubG-FSK-only mode (see figure 5.63) | SubG-CSS-only mode (see figure 5.64) | SubG-FSK+SubG-CSS mode, also called multirate mode (see figure 5.65) | Offline operation mode (see figure 5.66) | . The first three modes support different Endpoint types with communication to the Amazon Sidewalk Cloud. Gateways transfer Endpoints’ packets to the cloud through the direct communication link that may be handled by different communication technologies like Wi-Fi, LAN or cellular connectivity. These Gateways operation modes are described in detail in section 5.4.1, section 5.4.2, and section 5.4.3 . fig 5.63 SubG-FSK-only gateway . fig 5.64 SubG-CSS-only gateway . fig 5.65 Multirate gateway . Offline operation mode shall be used by the Gateway when a direct link to the Amazon Sidewalk Cloud is lost. The switch to this mode shall be done automatically and the Gateway behaves like a SubG-CSS Endpoint. The SubG-CSS connection is used in this case. The connectivity to the cloud is provided by a neighborhood Gateway that is called an assisting Gateway. Endpoints cannot connect to the network through the Gateway operating in this mode. fig 5.66 Offline mode gateway . 5.4.1 SubG-FSK-only operation mode . In this mode, the Gateway’s responsibility is to send the Beacon frequently and to handle SubG-FSK Endpoints’ traffic in uplink and downlink directions. The Gateway not transmitting data shall listen to the medium to detect uplink traffic. The Gateway shall start an uplink preamble detection in slots for hdr_listening_time duration (see figure 5.67). When a transmission of a preamble is detected in hdr_listening_time period, then reception of the uplink packet shall be started. The Gateway shall continue listening to the medium in the upcoming slot after the reception of an uplink packet is completed (see figure 5.68). The device not detecting traffic in hdr_listening_time shall switch the radio to the inactive state till upcoming selection activity. fig 5.67 Gateway timing - SubG-FSK-only . fig 5.68 SubG-FSK-only gateway - data reception . The downlink transmission is possible only during the instance of time when the Endpoint starts listening in the assigned downlink slots. The Gateway shall start the downlink transmission on the upcoming downlink slot. The Gateway does not check the medium availability but starts its transmission on the sub_slot_nb-1 detection sub-slot. This promotes the Gateway over Endpoints and gives higher priority to a downlink transmission. The mechanism is described in section 5.2.5. 5.4.2 SubG-CSS-only operation mode . In this mode, the Gateway responsibility is to handle SubG-CSS Endpoints’ traffic in the uplink and downlink directions. The Gateway not transmitting data shall listen to the medium to detect uplink traffic. Listening to the medium is done periodically each slot_int for ldr_listening_time duration. The radio shall be inactive for the remainder of the slot_int period (see figure 5.69). fig 5.69 Gateway timing - SubG-CSS-only . When an Endpoint transmission of a preamble is detected in ldr_listening_time period then reception of the uplink packet shall be started. The Gateway reception is spanned over a few slot_int (see 5.1.4.2.4). The Gateway shall continue listening to the medium in the upcoming slot after the reception of an uplink packet is completed (see figure 5.70). fig 5.70 SubG-CSS-only gateway - data reception . The SubG-CSS downlink transmission is scheduled in a synchronous way. The synchronization is based on each uplink Epoch frame (see section 5.3). The Amazon Sidewalk Cloud stores information when the SubG-CSS Endpoint can receive data and provides these parameters to the Gateway. This is based on the Join procedure and Connection Profile settings of the Endpoint. The start of a downlink transmission may not be aligned with the listening schedule (see figure 5.71 and section 5.5 when downlink transmission may happen). The Gateway is also responsible for applying the correct preamble size to the PHY level based on the possible time drift determined by the crystal quality. fig 5.71 SubG-CSS-only gateway - data transmission . 5.4.3 Multirate operation mode . In this mode, the Gateway’s responsibility is to send the Beacon frequently and to handle SubG-CSS and SubG-FSK Endpoints traffic in uplink and downlink directions. This Gateway mode is a combination of SubG-CSS-only and SubG-FSK-only modes. The Gateway listens to SubG-FSK and SubG-CSS uplink traffic sequentially. The listening schedule is determined in the same way as for the SubG-FSK-only Gateway. SubG-FSK traffic detection starts in each slot for hdr_listening_time duration. When SubG-FSK traffic is not detected, then SubG-CSS traffic detection is started for ldr_listening_time duration. When SubG-CSS traffic is not detected, then the cycle is repeated (see figure 5.72). fig 5.72 Gateway timing - SubG-CSS and SubG-FSK . The Gateway switches between modulations till the moment a transmission is detected in one of the modulations, which triggers reception of the uplink packet. The data reception may span a few slots. When the packet reception is completed, then the Gateway shall continue to listen to the medium starting from upcoming either SubG-FSK or SubG-CSS mode (see example on figure 5.73). fig 5.73 Multirate gateway - data reception . The SubG-FSK downlink transmission in case of multirate mode has the same scheduling and rules as described in section 5.4.1. The SubG-CSS downlink transmission rules are the same as described in section 5.4.2. In SubG-CSS-only mode, the start of a downlink transmission is not aligned with the listening schedule and may span a few slots (see example in figure 5.74). fig 5.74 Multirate gateway - data transmission . ", "url": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/gateway-connection-modes.html", "relUrl": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/gateway-connection-modes.html" },"336": { "doc": "3. Gateways", "title": "3 Gateways", "content": "A gateway establishes its own operating region. The gateway host determines the region from the gateway’s IP-based location and applies it to the sub-GHz radio. The application developer cannot configure or override it: no integration step selects the region on a gateway, and no application code needs to supply one. Because the region is determined by the gateway rather than provided by the application, the integration concern for a gateway is confirmation rather than configuration: confirm that your target market is a supported country (§2.2). A gateway that cannot establish a valid region, such as one in a country outside the supported regions, does not bring up its sub-GHz radio, so there is no sub-GHz coverage there. Auto-detection is bounded by the firmware: a gateway can only operate in a region its firmware supports. Gateways are built with REGION_LITE, which supports North America and Europe. A gateway operates on the radio parameters of the region it is in, so an end device can communicate only with gateways in the region it has been provisioned for. Because the gateway’s region comes from its network location and the end device’s region comes from the location given at setup, the two agree only if the end device is provisioned for the region where it is actually deployed (§4). ", "url": "/app-notes/internationalization/gateways.html#3-gateways", "relUrl": "/app-notes/internationalization/gateways.html#3-gateways" },"337": { "doc": "3. Gateways", "title": "3. Gateways", "content": " ", "url": "/app-notes/internationalization/gateways.html", "relUrl": "/app-notes/internationalization/gateways.html" },"338": { "doc": "8.2 Global Clock Synchronization", "title": "8.2 Global Clock Synchronization", "content": "8.2.1 Global clock synchronization - Bootup and maintenance . fig 8.2 Time sync maintenance . The flow chart specifies the commands sequence that shall be exchanged between the Endpoint and the Amazon Sidewalk Cloud to keep the Endpoint clock synchronization. Network clock synchronization is required for messaging features as described in section 4.7. The clock is synchronized during procedures described at boot-up time and maintained throughout the operation. The maintenance of the established clock synchronization shall be done by using GET_TIME and RESP_TIME commands, each clock_sync_int. The Endpoint shall not update its clock value in case the received value does not differ more than sec_clock_drift seconds. When there is no response for the GET_TIME command then the Endpoint shall perform a next try to synchronize the clock after the clock_sync_int period which is equal to two hours. When the response for the GET_TIME command is successfully received by the Endpoint, the clock_sync_int period dynamically adapts based on the time difference between the received time in RESP_TIME and the Endpoint’s current time. This is described in section 8.2.2. There is no special procedure to handle lack of RESP_TIME. 8.2.2 Global clock synchronization - maintenance interval . fig 8.3 Time sync maintenance Interval . The next time sync interval is updated dynamically based on the difference between the current time on the Endpoint and the time in RESP_TIME . I_next = next interval from adaptive_sync_intervals_h, If T_delta <= 1 minute . I_next = I_current, If 1 minute < T_delta <= 2 minute . I_next = I_min, If T_delta >= 2 minute . | I_next: Next time sync interval. | I_current: Current time sync interval. | I_max: Maximum time sync interval (720 hours(30 days)). | I_max: Minimum time sync interval (2 hours). | T_delta: Time difference between current time on Endpoint and received in RESP_TIME. | . The flow chart specifies the backoff procedure followed to determine the next clock_sync_int period only in the case of successfully receiving the time from RESP_TIME. The procedure for determining the next clock_sync_int period is as follows: . | The Endpoint starts the clock synchronization process. if there is sucessful response RESP_TIME then clock_sync_int period is set initially to first time sync interval vlue from adaptive_sync_intervals_h. | After adaptive_sync_intervals_h[0] hours clock synchronization process is attempted and if RESP_TIME is received and the difference between the current time and time in the RESP_TIME is less than one minute, clock_sync_int period is set to next sync interval i.e. adaptive_sync_intervals_h[1]. | successful RESP_TIME reception at subsequent clock_sync_int periods would result in update of clock_sync_int period as described below . | Initial clock_sync_int = adaptive_sync_intervals_h[0] | Next clock_sync_int = adaptive_sync_intervals_h[1] | Next clock_sync_int = adaptive_sync_intervals_h[2] | Next clock_sync_int = adaptive_sync_intervals_h[3] and so on until last index of adaptive_sync_intervals_h. | . | clock_sync_int period does not exceed last value of adaptive_sync_intervals_h hours and every adaptive_sync_intervals_h[last_idx] clock synchronization process is attempted in case of successful reception of RESP_TIME and the time difference between the received time in | At any step of the clock_sync_int period, the difference between the current time and time in the RESP_TIME is greater than 2 minute, the clock_sync_int period is reset to adaptive_sync_intervals_h[0] | Failure to receive RESP_TIME in response to GET_TIME command would start the Global Clock Synchronization section 8.2.3. | The SubG-CSS device shall continue from STEP 3 of section 8.1. | The SubG-FSK device shall complete section 8.1. | . | . 8.2.3 Global clock synchronization - retry . fig 8.4 Time sync - no response scenario . The flow chart specifies the commands sequence that shall be exchanged between the Endpoint and the Amazon Sidewalk Cloud to synchronize the Endpoint clock in case there is no response from the cloud for the first GET_TIME command. The procedure is included in STEP 2 and STEP 3 of section 8.1. The procedure for handling the clock synchronization failure is as follows: . | STEP 1 - The Endpoint initializes the clock synchronization process but it fails. There is no response RESP_TIME for the GET_TIME command for sync_resp_timeout equal to 3 min. | STEPs 2 - 4 - retry_count is initialized with 1 value and the next GET_TIME command is sent. When the response is not received for sync_resp_timeout then the activity is repeated in STEP 3 and STEP 4. The retry_count is increased by 1 up to its maximum value and sync_resp_timeout is equal to 3 min. When the retry_count reached its maximum value then go to STEP 5. | STEPs 5 - 8 - the sync_resp_timeout time interval is increased in the subsequent steps. The Endpoint waits a longer time for the possible response from the cloud. The value of the sync_resp_timeout is as follows in the next steps: . | STEP 5 - sync_resp_timeout = 5 min | STEP 6 - sync_resp_timeout = 8 min | STEP 7 - sync_resp_timeout = 10 min | STEP 8 - sync_resp_timeout = 15 min | . | STEP 9 - When there is still no response from the cloud then sync_resp_timeout is not increased. The Endpoint shall wait for a maximum value of sync_resp_timeout minutes for the response from the cloud for each subsequent GET_TIME command. The Endpoint shall send GET_TIME command each sync_resp_timeout till the moment the RESP_TIME command is received and the time is synchronized. | The SubG-CSS device shall continue from STEP 3 of section 8.1. | The SubG-FSK device shall complete section 8.1. | . | . ", "url": "/specifications/sidewalk-protocol-spec/procedures-and-flow-charts/global-clock-synchronization.html", "relUrl": "/specifications/sidewalk-protocol-spec/procedures-and-flow-charts/global-clock-synchronization.html" },"339": { "doc": "4.2 Global clock synchronization", "title": "4.2 Global clock synchronization", "content": "Global clock synchronization is a key component in Amazon Sidewalk security. Each device in the network shall have its clock synchronized with the Amazon Sidewalk Cloud. The synchronized clock is the base for encrypted messages between Endpoints and the cloud. Devices that do not have a valid time synchronization can only exchange time synchronization commands with the Amazon Sidewalk Cloud. The absolute time clock used in Amazon Sidewalk is Global Positioning System (GPS) Epoch time in seconds. The source of the correct time value is the Amazon Sidewalk Cloud. GCS time is verified by CMAC authentication between the Gateway and the Endpoint. For more information, see figure 4.4. The Gateway’s clock is synchronized by exchanging GET_TIME / RESP_TIME messages using an encrypted tunnel to the Network server. For more information, see section 8.1 and section 4.2. An Endpoint in synchronous mode that has successfully finished the Beacon discovery process uses an uplink slot to send a GET_TIME command with a counter-based CMAC. An Endpoint in asynchronous mode sends a GET_TIME command after initialization. The GET_TIME command is received by the Gateway and forwarded by the Gateway plugin to the Network Server. The Network Server decodes and verifies the GET_TIME command. If the Network Server successfully verified the GET_TIME command the Network server returns a Notify command to the Gateway. The Notify Command from the Network Server contains a flex counter-based CMAC. The Gateway builds a RESP_TIME response command with the Gateway’s GCS time. The data frame containing the RESP_TIME response command is encrypted with a counter-based CMAC and sent back to the Endpoint. If the Endpoint successfully received the RESP_TIME response command, the Endpoint synchronizes its own clock with the Gateway’s clock source. Further data exchange uses GCS time-based security procedures. fig 4.4 GCS WAN message sequence . Application commands used for the time synchronization are: GET_TIME, RESP_TIME. For more information on GET_TIME and RESP_TIME formats, see section 4.2. End-to-end communications that use time synchronization commands shall use keys that are generated as follows: . | If the Endpoint clock is not synchronized, the counter is used to generate keys. | If the Endpoint clock is synchronized, the Endpoint time is used to generate keys. | . For more information on key management and key rotation see: section 4.4. For more information on encrypted messaging see section 4.7. Configuration parameters of the time synchronization operations are: . | gcs_ret_num - the value indicates the number of subsequent GET_TIME commands that may be sent with the first gcs_resp_timeout interval value if the RESP_TIME command is not received. When gcs_ret_num is reached then gcs_resp_timeout is increased. gcs_ret_num = 3 . | gcs_resp_timeout - the time interval that an Endpoint shall wait for a RESP_TIME command. The gcs_resp_timeout value is constant until the count of transmitted GET_TIME commands is less than or equal to gcs_ret_num. When the count of transmitted GET_TIME commands reaches gcs_ret_num, then the interval between subsequent GET_TIME commands is increased up to a defined maximum value. If the RESP_TIME is not received and gcs_resp_timeout reaches the maximum value then a GET_TIME command shall be sent at the maximum defined interval until the RESP_TIME command is received. gcs_resp_timeout the first interval until gcs_ret_num is reached is 30 s, and then the timeout value is 3 min, then 5 min, then 8 min, then 10 min, then 15 min. | gcs_sync_int - the value indicates the frequency of sending GET_TIME command for the clock synchronization maintenance . gcs_sync_int = 2 h . | . The clock shall be synchronized with the Amazon Sidewalk Cloud in the following cases: . | The device is powered on or reset. Time synchronization shall be done as soon as possible. SubG-CSS, and SubG-FSK devices synchronize the clock at different points in time as follows: . | A SubG-CSS device shall synchronize the clock after the protocol stack is on so that transmit and receive are possible | A SubG-FSK device shall synchronize the clock after the protocol stack is on, and after Beacon synchronization is achieved. NOTE: Clock synchronization could happen on other PHYs prior to the SubG-FSK Beacon synchronization. | . For flow charts of all procedures from the Amazon Sidewalk application viewpoint, see Chapter 8. | Maintenance of the correct clock value on a device side. The device shall synchronize the clock frequently at an interval of gcs_sync_int. Frequent clock synchronization is required because oscillator drift can cause the device’s clock to float away from the Amazon Sidewalk network clock. The clock drift on the device side shall be less than +/- gcs_clock_drift seconds. When the time drift value received in RESP_TIME is greater than the time drift of the Endpoint then the Endpoint shall not update its clock value. gcs_clock_drift = 60 s . | . For values of gcs_ret_num, gcs_resp_timeout, gcs_sync_int and gcs_clock_drift see Appendix B.3. ", "url": "/specifications/sidewalk-protocol-spec/security/global-clock-synchronization.html", "relUrl": "/specifications/sidewalk-protocol-spec/security/global-clock-synchronization.html" },"340": { "doc": "Glossary", "title": "Glossary", "content": "| Term | Definition | . | GNSS | Global Navigation Satellite System used for satellite-based location determination. | . | Location Level | Hierarchical effort modes for location resolution, ordered by power consumption and time requirements. | . | LR1110 | Semtech transceiver with integrated GNSS and WiFi scanning capabilities. | . | MTU | Maximum Transmission Unit. | . | PAL | Platform Abstraction Layer. | . ", "url": "/app-notes/location-library/glossary.html", "relUrl": "/app-notes/location-library/glossary.html" },"341": { "doc": "Glossary", "title": "4. Glossary", "content": "| Term | Definition | . | Discovery | The procedure of discovering nearby gateways through their periodic Beacon transmissions. | . | Downlink | Data sent from a Gateway to an Endpoint. | . | EIRP | Equivalent isotropic radiated power. | . | Endpoint (EP) | A device that accesses services of Amazon Sidewalk to transport messages to and from the application services through AWS IoT. | . | FSK | 2-Gaussian Frequency Shift Keying modulation scheme. | . | Gateway (GW) | Connections between Endpoints and Amazon Sidewalk are established and maintained through these devices. Gateways are Amazon and Ring devices. Amazon Sidewalk messages are transported between Amazon Sidewalk and the AWS IoT service through these devices. | . | PAN | Personal Area Network. In PAN configuration, there is an association between the Endpoint and the Gateway belonging to the same user. | . | RSSI | Received Signal Strength Indicator. It’s a measurement of the power present in a received radio signal. | . | Sid API | Amazon Sidewalk Application Programming Interface. | . | Uplink | Data sent from an Endpoint to a Gateway. | . | WAN | Wide Area Network. In WAN configuration, also known as roaming, there is no association made between the Gateway and Endpoint. | . ", "url": "/app-notes/gateway-discovery-selection/glossary.html#4-glossary", "relUrl": "/app-notes/gateway-discovery-selection/glossary.html#4-glossary" },"342": { "doc": "Glossary", "title": "Glossary", "content": " ", "url": "/app-notes/gateway-discovery-selection/glossary.html", "relUrl": "/app-notes/gateway-discovery-selection/glossary.html" },"343": { "doc": "Glossary", "title": "Glossary", "content": "Region — the regulatory zone whose radio rules a device observes, expressed as a single enumerated value; detected by a gateway, provisioned on an end device. Conducted power — transmit power measured at the antenna port. Power figures in this note are given as conducted power, so they are directly comparable. Sub-GHz — the sub-gigahertz radio links (FSK 50kbps and LoRa) whose behaviour is region-specific, as distinct from Bluetooth Low Energy. ", "url": "/app-notes/internationalization/glossary.html", "relUrl": "/app-notes/internationalization/glossary.html" },"344": { "doc": "6. Glossary", "title": "6. Glossary", "content": "| Term | Definition | . | BLE | Bluetooth low energy. | . | CSS | Chirp Spread Spectrum. | . | DLRV | Downlink route validity: the time for which the Amazon Sidewalk cloud keeps a downlink route to an Endpoint on a Sub-GHz link (FSK or LoRa); the keep-alive (KA) refreshes it. | . | Downlink | Data sent from a Gateway to an Endpoint. | . | Endpoint | A device that accesses services of Amazon Sidewalk to transport messages to and from the application services through AWS IoT. | . | FFN | Frustration Free Networking. | . | FFS | Frustration Free Setup. | . | FSK | 2-Gaussian Frequency Shift Keying modulation scheme. | . | Gateway | Connections between Endpoints and Amazon Sidewalk are established and maintained through these devices. Gateways are Amazon and Ring devices. Amazon Sidewalk messages are transported between Amazon Sidewalk and the AWS IoT service through these devices. | . | ISR | Interrupt Service Routine. | . | KA | Keep-alive: an uplink the Amazon Sidewalk stack sends periodically on a Sub-GHz link (FSK, or LoRa in Profile B or Profile C) to keep the downlink route valid. | . | LoRa | Long Range proprietary protocol based on Chirp Spread Spectrum modulation scheme (CSS). | . | MTU | Maximum Transmission Unit. | . | PAL | Platform abstraction Layer. | . | SBDT | Sidewalk Bulk Data Transfer. | . | Sid API | Amazon Sidewalk Application Programming Interface. | . | Uplink | Data sent from an Endpoint to a Gateway. | . ", "url": "/sid-api-dg/glossary.html", "relUrl": "/sid-api-dg/glossary.html" },"345": { "doc": "GNSS Scan (L4)", "title": "GNSS Scan (L4)", "content": " ", "url": "/app-notes/location-library/gnss-scan-l4.html", "relUrl": "/app-notes/location-library/gnss-scan-l4.html" },"346": { "doc": "GNSS Scan (L4)", "title": "Introduction", "content": "GNSS scan location has the device capture satellite data and uplink it for cloud-side coordinate resolution. It is a higher-effort mechanism than WiFi scanning, trading more power and acquisition time for coverage where WiFi is unavailable. ", "url": "/app-notes/location-library/gnss-scan-l4.html#introduction", "relUrl": "/app-notes/location-library/gnss-scan-l4.html#introduction" },"347": { "doc": "GNSS Scan (L4)", "title": "How the Cloud Resolves the Fix", "content": "The scanned GNSS data is resolved through the AWS IoT Wireless position-estimate service, the same cloud path used for the WiFi scan (L3). As with WiFi, a scan that cannot be resolved produces no location. GNSS scan (L4) is distinct from GPS-assist (L6): L4 uplinks a scan for Amazon Sidewalk to resolve on its own, whereas L6 is an assisted exchange in which Amazon Sidewalk sends aiding first and the device then produces pseudoranges. ", "url": "/app-notes/location-library/gnss-scan-l4.html#how-the-cloud-resolves-the-fix", "relUrl": "/app-notes/location-library/gnss-scan-l4.html#how-the-cloud-resolves-the-fix" },"348": { "doc": "GNSS Scan (L4)", "title": "Accuracy and Constraints", "content": ". | Requires a GNSS-capable device. | Higher power and longer acquisition time than WiFi scanning. | Accuracy depends on the number and geometry of satellites the device captured and sky visibility at the time of the scan. | . ", "url": "/app-notes/location-library/gnss-scan-l4.html#accuracy-and-constraints", "relUrl": "/app-notes/location-library/gnss-scan-l4.html#accuracy-and-constraints" },"349": { "doc": "2. GSK Feature Overview", "title": "2. GSK feature overview", "content": "A GSK is a symmetric session key an Endpoint and a Gateway share on a sub-GHz link, established after the Endpoint is registered and network-synchronized. The stack owns the lifecycle: it establishes the session, keeps it in non-volatile memory, waits for an idle window because activating a GSK interrupts the SubG-CSS link, and stops using the key on any failure or expiry (§2.2). You control three things: how quiet the link must be first, how many consecutive unacknowledged ack-requested uplinks mean the session is unusable, and how long the Endpoint waits before retrying after a fallback (§3). ", "url": "/app-notes/gateway-session-key/gsk-feature-overview.html#2-gsk-feature-overview", "relUrl": "/app-notes/gateway-session-key/gsk-feature-overview.html#2-gsk-feature-overview" },"350": { "doc": "2. GSK Feature Overview", "title": "2.1 What a session gives you, per link", "content": "SubG-CSS (LoRa). A session runs only on the medium data rate (MDR), so activating one moves the link from the region’s low data rate (LDR) mode to MDR, changing it in three ways. An application may also select MDR itself at initialization, with sid_sub_ghz_links_config.link3_data_rate = SID_LINK3_DATA_RATE_MDR; it then gets the data-rate and RX-window-separation gains below without a session. | About 6× the nominal uplink data rate, and roughly 5× less airtime for the same payload. Budget airtime from the Amazon Sidewalk Specification, downlink included. The maximum application payload does not change: sid_get_mtu() returns the same fixed value per link type, whatever the data rate and whether or not a session is active. A faster PHY is not a larger traffic allowance: the network’s traffic limits are unchanged. | Link-layer acknowledgement and up to 3 link-layer retries per message. No public API exposes either: a live session turns them on, and without one the link runs with both off on either data rate. The retries are MAC retransmissions of one message: worst case 4 transmissions of the same message, not 4 messages. | The 500 ms and 1000 ms asynchronous RX-window separations become legal on Profile A/B (Table 2.1). Profile B holds rx_window_count at SID_RX_WINDOW_CNT_INFINITE, so windows keep opening at the separation and the worst-case wait for a downlink is about one separation. 500 ms is a tenth of the LDR worst case. On SID_LINK3_PROFILE_A the Endpoint opens rx_window_count windows after an application uplink, so the separation sets the span of that burst rather than the number of windows in it: 500 ms brings the first window forward but closes the downlink opportunity ten times sooner than 5000 ms. Raise rx_window_count (SID_RX_WINDOW_CNT_PROFILE_A_MAX is 60) to hold the opportunity open; the separation buys nothing at rx_window_count = SID_RX_WINDOW_CNT_ZERO — the same numeric 0 that Profile B reads as SID_RX_WINDOW_CNT_INFINITE. SID_LINK3_PROFILE_C listens continuously at either data rate and gets no latency benefit. | . To run a 500 ms or 1000 ms downlink separation, set sid_device_profile.unicast_params.l3_mdr_rx_window_interval_ms with SID_OPTION_900MHZ_SET_DEVICE_PROFILE (§4). It applies while the link runs MDR; at LDR the window is fixed, so this field is the only separation you choose: . | LoRa profile | LDR window | Accepted l3_mdr_rx_window_interval_ms | . | SID_LINK3_PROFILE_A, SID_LINK3_PROFILE_B | SID_LINK3_RX_WINDOW_SEPARATION_3 (5000 ms), fixed | 0 (no MDR preference), SID_LINK3_RX_WINDOW_SEPARATION_5 (500 ms), SID_LINK3_RX_WINDOW_SEPARATION_2 (1000 ms) or SID_LINK3_RX_WINDOW_SEPARATION_3 (5000 ms) | . | SID_LINK3_PROFILE_C | continuous | accepted, but has no effect | . Table 2.1: RX-window separation by profile and data rate. The call needs a registered device and an initialized LoRa link. With SubG-CSS in link_mask but no SubG-FSK, sid_init() initializes the link, so you may set the field before sid_start(); with both sub-GHz links the stack initializes LoRa only when it alternates onto it, so set it once SID_LINK_TYPE_3 appears in link_status_mask (§2.3). Before that, and on a started link that is not yet synchronized, the call returns SID_ERROR_INVALID_STATE (-40). Set it once: the stack re-applies the stored value on every entry to MDR, including at boot (§4), so no teardown loses it. Leave the field 0 to keep whatever the link is already using. Any other value returns SID_ERROR_INCOMPATIBLE_PARAMS (-12). You may set the field before the link has ever reached MDR, and a change made while already there applies without waiting for the next switch. MDR costs range, and receive time at 500 ms. No range figure in metres is published for either data rate: derive the LDR-versus-MDR link-budget delta from the per-region modulation and data-rate figures in the Amazon Sidewalk Specification and your radio’s sensitivity numbers. Size the RF budget at MDR; a device that closes the link there also closes it on the region’s more sensitive LDR. On Profile B, 500 ms also opens ten times as many receive windows as 5000 ms; on Profile A the count is rx_window_count either way and only the span changes. Each is cheaper at MDR, but the product is more receive time, so measure it on a battery product (Amazon Sidewalk Power Optimization Developer Guide). Any teardown withdraws MDR and returns the link to LDR, where the live window is 5000 ms again until the link next reaches MDR. An application that selected MDR keeps both the data rate and the window. A region that does not offer MDR fails every establishment attempt: the link stays on LDR and the Endpoint re-attempts each retry_interval_sec (§7), so settle MDR availability on the bench, not in a specification. MDR is not available in the EU region. The gate is in the SDK, not a per-fleet network decision: with the regulatory region set to the EU — or not yet established when the LoRa link initializes — the LoRa link runs LDR whatever sid_sub_ghz_links_config.link3_data_rate asks for, so an EU LoRa link never establishes a GSK session. LDR is not one waveform across regions: the EU variant is a narrower-band, lower-data-rate configuration with an asymmetric uplink and downlink. Size EU link budget and airtime against that variant, from the regional parameters in the Amazon Sidewalk Specification, never against the LDR-versus-MDR comparison above. The application owns the regulatory region: your porting layer supplies it through struct sid_device_info_callbacks.get_info with SID_DEVICE_INFO_TYPE_REGION (4) and an enum sid_device_region value. The move to MDR happens before any session exists. A device at the edge of MDR coverage therefore runs ordinary traffic on the weaker link, unacknowledged, until session material arrives or the attempt gives up, up to a couple of minutes later. If it gives up, and the application did not select MDR (above), the link returns to LDR on its own, with no reboot needed. Size MDR coverage for the fringe of your deployment, not its centre. SubG-FSK. A session moves uplink authentication into the Gateway on both SID_LINK2_PROFILE_1 and SID_LINK2_PROFILE_2. A session is bound to the Gateway that established it: a Gateway the Endpoint holds no session for uses the non-GSK path until a fresh establishment, while reconnecting to a Gateway it already holds one for resumes that session with no fresh establishment. GSK therefore suits a stationary Endpoint that holds one Gateway. A mobile product pays the most: each Gateway it holds no session for costs an idle window and an establishment (§2.2). Consent still governs forwarding, as in non-GSK mode. The steady state your application sees on SubG-FSK is otherwise unchanged: the same PHY, maximum payload, throughput and range, no new API, no GSK-specific branch, and nothing to configure beyond the three fields in §3. The one exception: on SID_LINK2_PROFILE_2 with a session active, an in-place synchronous RX-window interval change no longer takes the link out of network synchronization, so your application sees no bounce. ", "url": "/app-notes/gateway-session-key/gsk-feature-overview.html#21-what-a-session-gives-you-per-link", "relUrl": "/app-notes/gateway-session-key/gsk-feature-overview.html#21-what-a-session-gives-you-per-link" },"351": { "doc": "2. GSK Feature Overview", "title": "2.2 Session lifecycle", "content": "flowchart TD N[\"Non-GSK mode\"] R[\"Establishment requested\"] P[\"Establishment in progress\"] A[\"Session active, SID_STATE_READY\"] N -->|\"registered, link network-synced, network enabled GSK for this PHY\"| R R -->|\"link quiet both ways for idle_timeout_sec\"| P R -.->|\"link busy resets the quiet window\"| R P -->|\"establishment succeeds\"| A P -->|\"establishment fails\"| N A -->|\"expiry, missed acks, or PHY cannot carry GSK\"| N N -.->|\"reboot in coverage with a stored session, no link bounce\"| A . Figure 2.1: GSK session establishment. The application cannot read these states; the only visible effects are the status changes described below. Network synchronization means joined, not merely connected; the enabled PHY is SubG-FSK or the SubG-CSS MDR data rate. Only SubG-CSS bounces: it moves the PHY to MDR, so the link leaves link_status_mask and returns (not if the application already selected MDR, §2.1); on SubG-FSK a successful establishment changes nothing in the reported status. The idle window. Establishment is requested when a GSK-capable link connects and when it reaches network synchronization, but starts only once the link has been quiet for idle_timeout_sec. The window counts sub-GHz message traffic in both directions, not raw radio activity: an application uplink or downlink restarts it, as do the keep-alive and its acknowledgement and any join, registration or time-synchronization exchange; FSK beacon and synchronization reception, link-layer acknowledgements and MAC retransmissions do not. The keep-alive interval is therefore a hard ceiling on a usable idle_timeout_sec (§4). One exception: when a join or time-synchronization exchange fails under the key, the re-request starts immediately, mid-traffic. A successful one restarts the quiet window like any other traffic. Reboot. A stored session survives a reboot: in coverage it costs no link bounce. Out of coverage the session is discarded and re-established when coverage returns, which costs one bounce on SubG-CSS and none on SubG-FSK (§7). When a session ends. A session ends when its lifetime expires, a run of ack-requested uplinks goes unacknowledged, an establishment fails, the link moves to a PHY that cannot carry GSK, or the Gateway serving the Endpoint stops using the session. Whatever ends it, the ending is the same: the Endpoint stops using the key and continues in non-GSK mode; on SubG-CSS the link bounces on the way, unless the application selected MDR (§2.1), while on SubG-FSK nothing changes in the reported status. Connectivity never depends on a session — a link in non-GSK mode carries your traffic as it always did. The desync fallback is the one ending you configure. The stack counts consecutive ack-requested uplinks it transmitted on a link in GSK mode whose end-to-end acknowledgement never arrived; at app_ack_miss_threshold it discards the key. Any ack-requested uplink feeds the counter, not only yours — Table 6.1 lists the sources (§6). The keep-alive is independent of GSK: it counts its own consecutive missed acknowledgements against its own default of 3, and tears down and rejoins the link on that count alone, whether or not GSK is enabled, active, or even compiled in (§6). A GSK-authenticated downlink resets the count; a downlink the Endpoint accepts on the network key alone does not. Counted uplinks are lost. Each exhausted either its own num_retries or its ttl_in_seconds and was released, and none is retransmitted after the fallback. Your own messages among them normally surface through on_send_error with SID_ERROR_TIMEOUT (-2), but do not expect that callback to account for every counted uplink — the stack’s own ack-requested uplinks are counted too (above). A message that never reached the air — -38 or -40 — is not counted, and a re-send is a new message that can be counted again. Recovery is not immediate (§3, §7). A factory reset discards all GSK state and notifies on_factory_reset; after re-registration expect one establishment and one link bounce. Not supported: the application cannot force an establishment, discard a session, read the session state or the remaining lifetime, choose the lifetime, or choose which links carry a session (§7). ", "url": "/app-notes/gateway-session-key/gsk-feature-overview.html#22-session-lifecycle", "relUrl": "/app-notes/gateway-session-key/gsk-feature-overview.html#22-session-lifecycle" },"352": { "doc": "2. GSK Feature Overview", "title": "2.3 Multi-link devices", "content": "Only one sub-GHz link is on air at a time. The stack de-initializes one to start the other, so SubG-FSK and SubG-CSS are never network-synchronized at once, and establishment runs on whichever is active. Bluetooth LE runs independently and never carries a session. The Amazon Sidewalk Multi-link Application Note covers the alternation and SID_OPTION_SET_LINK_POLICY_MULTI_LINK_POLICY (9). | A session belongs to the device, not to a link, and is used on whichever GSK-enabled sub-GHz link is active. A link whose PHY the network has not enabled runs in non-GSK mode, so one sub-GHz link in GSK mode and the other in non-GSK mode as the links alternate is normal. | The tunables are single device-wide values, and a switch between sub-GHz links does not postpone the fallback. Size idle_timeout_sec against the smallest keep-alive interval of any enabled sub-GHz link, and read detection latency for your slowest link (§6). | Teardown is device-wide, even though only SubG-CSS shows it: there you see the link’s bit clear and set again in link_status_mask (§2.2). Do not design a failover state machine that treats either link as unaffected. | . ", "url": "/app-notes/gateway-session-key/gsk-feature-overview.html#23-multi-link-devices", "relUrl": "/app-notes/gateway-session-key/gsk-feature-overview.html#23-multi-link-devices" },"353": { "doc": "2. GSK Feature Overview", "title": "2. GSK Feature Overview", "content": " ", "url": "/app-notes/gateway-session-key/gsk-feature-overview.html", "relUrl": "/app-notes/gateway-session-key/gsk-feature-overview.html" },"354": { "doc": "2. How Region Shapes a Device", "title": "2 How region shapes a device", "content": " ", "url": "/app-notes/internationalization/how-region-shapes-a-device.html#2-how-region-shapes-a-device", "relUrl": "/app-notes/internationalization/how-region-shapes-a-device.html#2-how-region-shapes-a-device" },"355": { "doc": "2. How Region Shapes a Device", "title": "2.1 What differs by region", "content": "Region changes more than a frequency. Two regulatory differences between North America and Europe account for nearly everything that changes for an application. Transmit power. North America permits 30 dBm. European limits are lower, which reduces link budget, and the effect differs by link: . | FSK 50kbps is limited to 14 dBm in Europe. Receiver sensitivity is the same in both regions, so the full 16 dB reduction carries into the link budget. | LoRa uplink is also limited to 14 dBm. The European uplink uses SF9 at 125 kHz, which is more sensitive than North America’s SF11 at 500 kHz and recovers about 3 dB, so the link budget is about 13 dB below North America. | LoRa downlink is permitted 27 dBm in its dedicated European band, only 3 dB below North America. The SF7 downlink receiver is slightly less sensitive, so the link budget ends up about 6 dB below. | . Plan coverage against the European link budget if you deploy in both regions. Airtime limits. North America places no limit on airtime. Each European band caps how long a device may transmit per hour, and this, rather than the radio, is what limits European capacity. The effect differs by link: . | FSK 50kbps is limited by listen-before-talk, with a cap of 100 seconds of transmission per channel per hour across 15 channels. End-device uplink traffic does not reach that cap, so FSK 50kbps uplink capacity is the same as in North America. The cap does bind on gateway downlink, which falls to a little under half the North American ceiling. | LoRa uplink is limited by a 1% duty cycle. Under ideal conditions a LoRa end device can send about 110 uplinks an hour in Europe, against about 720 in North America. | LoRa downlink is limited by a 10% duty cycle. Under ideal conditions a gateway can send about 2,400 LoRa downlinks an hour in Europe, against about 11,700 in North America. | . The figures above assume the default LoRa data rate. The higher LoRa data rate is available only in North America; Europe has no equivalent, so an application that relies on it in North America runs at the default data rate in Europe. An application whose traffic is validated in North America may exceed the European budget, particularly on LoRa, so size traffic against the European limits. ", "url": "/app-notes/internationalization/how-region-shapes-a-device.html#21-what-differs-by-region", "relUrl": "/app-notes/internationalization/how-region-shapes-a-device.html#21-what-differs-by-region" },"356": { "doc": "2. How Region Shapes a Device", "title": "2.2 Regions and countries", "content": "A region covers many countries. A device operates on its region’s radio rules and has no knowledge of the individual country it is in. Each region is supported in the following countries: . | Region | Countries | . | North America | Canada, Mexico, United States | . | Europe | Austria, Belgium, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy, Netherlands, Norway, Poland, Portugal, Spain, Sweden, United Kingdom | . Table 2.1: Regions and the countries they support. The Europe region follows the European radio rules for short-range devices, which also apply in some countries outside the European Union, such as Iceland, Norway and the United Kingdom. Certification is still required per country (see §5). A region is not the same as product availability. A country falling within a supported region does not by itself mean a product may be offered there; availability is decided per product and per country. Your setup flow should derive the region from the country of the device’s location, and should not complete setup if that country falls outside every supported region or the product is not offered there. Confirm availability for each target country before launch. ", "url": "/app-notes/internationalization/how-region-shapes-a-device.html#22-regions-and-countries", "relUrl": "/app-notes/internationalization/how-region-shapes-a-device.html#22-regions-and-countries" },"357": { "doc": "2. How Region Shapes a Device", "title": "2. How Region Shapes a Device", "content": " ", "url": "/app-notes/internationalization/how-region-shapes-a-device.html", "relUrl": "/app-notes/internationalization/how-region-shapes-a-device.html" },"358": { "doc": "Registration over Wire Application Note", "title": "Amazon Sidewalk - Registration over Wire Application Note", "content": "This application note explains Registration over Wire (ROW): a factory-line flow that provisions and registers Amazon Sidewalk endpoints over UART, with no mobile app, gateway, or in-field registration step. It covers the one-time account onboarding, workstation setup, the per-device flow, the firmware integration contract, and the security-level and factory-reset behavior that must stay consistent across images. ", "url": "/app-notes/registration-over-wire/#amazon-sidewalk---registration-over-wire-application-note", "relUrl": "/app-notes/registration-over-wire/#amazon-sidewalk---registration-over-wire-application-note" },"359": { "doc": "Registration over Wire Application Note", "title": "Legal", "content": "Use of these Amazon Sidewalk specifications (the “Specifications”) is subject to your compliance with the AWS Customer Agreement and the Service Terms (collectively, the “Agreement”), including all disclaimers and limitations as to such use contained therein. All statements, information, and data contained herein is subject to change without further notice to improve reliability, function, or design. Certain parameters may vary in different applications and performance may vary over time. It is your responsibility to validate that Amazon Sidewalk is suitable for your particular device or application. No license, express or implied, by estoppel or otherwise, to any intellectual property rights are granted by this document. Amazon Sidewalk is not intended for use in, or in association with, the operation of any hazardous environments or critical systems that may lead to serious bodily injury or death or cause environmental or property damage, and you are solely responsible for all liability that may arise in connection with any such use. This document is Non-Confidential. © 2026 Amazon Technologies, Inc. Amazon and all related marks are trademarks of Amazon.com, Inc. or its affiliates. ", "url": "/app-notes/registration-over-wire/#legal", "relUrl": "/app-notes/registration-over-wire/#legal" },"360": { "doc": "Registration over Wire Application Note", "title": "Registration over Wire Application Note", "content": " ", "url": "/app-notes/registration-over-wire/", "relUrl": "/app-notes/registration-over-wire/" },"361": { "doc": "Location Library Developer Guide", "title": "Amazon Sidewalk Location Library Developer Guide", "content": "The Amazon Sidewalk Location Library enables Sidewalk customers to use a range of cloud-based location solvers. Available in SDK >= 1.19, this library provides an API that automatically selects the most power- and time-efficient location mechanism based on available hardware and network conditions, while also giving developers finer-grained control to configure and override the mechanism used to determine location. This developer guide covers the supported location methods and levels, the library architecture, a usage guide with worked examples for WiFi/GNSS (LR1110), BLE-only, and LoRa location, Platform Abstraction Layers, best practices, and requesting location resolution as part of a user message via sid_put_msg(). ", "url": "/app-notes/location-library/#amazon-sidewalk-location-library-developer-guide", "relUrl": "/app-notes/location-library/#amazon-sidewalk-location-library-developer-guide" },"362": { "doc": "Location Library Developer Guide", "title": "Contents", "content": ". | Overview — introduction, supported location methods, location levels, and architecture (Chapter 1). | Usage Guide — getting started, the two-phase programming model, WiFi/GNSS, BLE-only and LoRa examples, PALs, best practices, and location resolve via sid_put_msg() (Chapter 2). | Change History (Chapter 3). | Glossary. | . ", "url": "/app-notes/location-library/#contents", "relUrl": "/app-notes/location-library/#contents" },"363": { "doc": "Location Library Developer Guide", "title": "Location Library Developer Guide", "content": " ", "url": "/app-notes/location-library/", "relUrl": "/app-notes/location-library/" },"364": { "doc": "Gateway Discovery and Selection Application Note", "title": "Amazon Sidewalk - Gateway Discovery and Selection Application Note", "content": "This application note explains the implementation of the Gateway Discovery and Selection feature in the Amazon Sidewalk endpoint stack for the SubG-FSK link. It covers the three phases of the feature — Gateway Discovery, Gateway Selection, and Connection Health Monitoring — the parameters and algorithms behind each, the predefined and custom discovery policies exposed through the sid_option API, and the control events the stack uses to notify your application. ", "url": "/app-notes/gateway-discovery-selection/#amazon-sidewalk---gateway-discovery-and-selection-application-note", "relUrl": "/app-notes/gateway-discovery-selection/#amazon-sidewalk---gateway-discovery-and-selection-application-note" },"365": { "doc": "Gateway Discovery and Selection Application Note", "title": "Gateway Discovery and Selection Application Note", "content": " ", "url": "/app-notes/gateway-discovery-selection/", "relUrl": "/app-notes/gateway-discovery-selection/" },"366": { "doc": "Sub-GHz Device Profiles Application Note", "title": "Amazon Sidewalk - Sub-GHz Device Profiles Application Note", "content": "This application note is intended for application developers who want to build their IoT solution using Amazon Sidewalk. ", "url": "/app-notes/sub-ghz-device-profile/#amazon-sidewalk---sub-ghz-device-profiles-application-note", "relUrl": "/app-notes/sub-ghz-device-profile/#amazon-sidewalk---sub-ghz-device-profiles-application-note" },"367": { "doc": "Sub-GHz Device Profiles Application Note", "title": "Sub-GHz Device Profiles Application Note", "content": " ", "url": "/app-notes/sub-ghz-device-profile/", "relUrl": "/app-notes/sub-ghz-device-profile/" },"368": { "doc": "Multi-link Application Note", "title": "Amazon Sidewalk - Multi-link Application Note", "content": "This document covers the implementation of Amazon Sidewalk’s multi-link feature in the endpoint stack and how different multi-link policy settings behave via the SID API. It does not cover broader Sidewalk features, which are documented elsewhere. ", "url": "/app-notes/multi-link/#amazon-sidewalk---multi-link-application-note", "relUrl": "/app-notes/multi-link/#amazon-sidewalk---multi-link-application-note" },"369": { "doc": "Multi-link Application Note", "title": "Multi-link Application Note", "content": " ", "url": "/app-notes/multi-link/", "relUrl": "/app-notes/multi-link/" },"370": { "doc": "Internationalization Application Note", "title": "Amazon Sidewalk - Internationalization Application Note", "content": "This application note is intended for application developers building an IoT solution on Amazon Sidewalk for North America, Europe, or both. It describes how a device’s operating region reaches each class of device, what the application developer is responsible for in each case, and how a device behaves when a region has not yet been set or is not supported. ", "url": "/app-notes/internationalization/#amazon-sidewalk---internationalization-application-note", "relUrl": "/app-notes/internationalization/#amazon-sidewalk---internationalization-application-note" },"371": { "doc": "Internationalization Application Note", "title": "Legal", "content": "Use of these Amazon Sidewalk specifications (the “Specifications”) is subject to your compliance with the AWS Customer Agreement and the Service Terms (collectively, the “Agreement”), including all disclaimers and limitations as to such use contained therein. All statements, information, and data contained herein is subject to change without further notice to improve reliability, function, or design. Certain parameters may vary in different applications and performance may vary over time. It is your responsibility to validate that Amazon Sidewalk is suitable for your particular device or application. No license, express or implied, by estoppel or otherwise, to any intellectual property rights are granted by this document. Amazon Sidewalk is not intended for use in, or in association with, the operation of any hazardous environments or critical systems that may lead to serious bodily injury or death or cause environmental or property damage, and you are solely responsible for all liability that may arise in connection with any such use. This document is Non-Confidential. ©2026 Amazon Technologies, Inc. Amazon and all related marks are trademarks of Amazon.com, Inc. or its affiliates. ", "url": "/app-notes/internationalization/#legal", "relUrl": "/app-notes/internationalization/#legal" },"372": { "doc": "Internationalization Application Note", "title": "Internationalization Application Note", "content": " ", "url": "/app-notes/internationalization/", "relUrl": "/app-notes/internationalization/" },"373": { "doc": "Power Optimization Developer Guide", "title": "Power Optimization Developer Guide", "content": "This guide provides power optimization techniques for Amazon Sidewalk endpoint devices across all supported radio links: BLE, FSK, and LoRa. It covers configurable parameters such as advertisement intervals, connection policies, device profiles, RX window management, and Transmit Power Control (TPC) algorithms. Developers can leverage pre-configured policies or fine-tune custom settings through the SID API to balance power consumption against responsiveness and connectivity requirements. Test results demonstrate significant power savings—up to 71% for FSK and 46% for LoRa—when TPC and optimized profiles are properly configured. ", "url": "/app-notes/power-optimization/", "relUrl": "/app-notes/power-optimization/" },"374": { "doc": "Gateway Session Key (GSK) Application Note", "title": "Amazon Sidewalk - Gateway Session Key (GSK) Application Note", "content": "This application note is intended for application developers building an IoT solution on Amazon Sidewalk. It explains what a Gateway Session Key (GSK) session unlocks and costs on each sub-GHz link, the lifecycle your application observes, the three settings you own and how to size them, plus troubleshooting and bring-up. ", "url": "/app-notes/gateway-session-key/#amazon-sidewalk---gateway-session-key-gsk-application-note", "relUrl": "/app-notes/gateway-session-key/#amazon-sidewalk---gateway-session-key-gsk-application-note" },"375": { "doc": "Gateway Session Key (GSK) Application Note", "title": "Gateway Session Key (GSK) Application Note", "content": " ", "url": "/app-notes/gateway-session-key/", "relUrl": "/app-notes/gateway-session-key/" },"376": { "doc": "Application Notes", "title": "Application Notes", "content": ". | Amazon Sidewalk Sub-GHz Device Profiles Application Note | Amazon Sidewalk Multi-link Application Note | Amazon Sidewalk Power Optimization Developer Guide | Amazon Sidewalk Location Library Developer Guide | Amazon Sidewalk Registration over Wire Application Note | Amazon Sidewalk Gateway Session Key (GSK) Application Note | Amazon Sidewalk Gateway Discovery and Selection Application Note | Amazon Sidewalk Internationalization Application Note | . ", "url": "/app-notes/", "relUrl": "/app-notes/" },"377": { "doc": "Terms and Agreements", "title": "Terms and Agreements", "content": "Topics . | AWS Service Terms | Amazon Sidewalk Program Requirements | On Amazon Sidewalk Qualification Guidelines | On Amazon Sidewalk Badge Guidelines | Amazon Sidewalk Program Security Requirements | . ", "url": "/sidewalk-terms-and-agreements/", "relUrl": "/sidewalk-terms-and-agreements/" },"378": { "doc": "Privacy & Security", "title": "Sidewalk privacy and security", "content": "Amazon Sidewalk preserves customer privacy and security. Sidewalk is designed with multiple layers of encryption to secure data traveling on Sidewalk and to keep you safe and in control. For example, Sidewalk gateway owners do not receive any information about devices owned by others connected to Sidewalk. For more information, see this Amazon Security and Privacy White Paper. ", "url": "/privacy-security/#sidewalk-privacy-and-security", "relUrl": "/privacy-security/#sidewalk-privacy-and-security" },"379": { "doc": "Privacy & Security", "title": "Privacy & Security", "content": " ", "url": "/privacy-security/", "relUrl": "/privacy-security/" },"380": { "doc": "Getting Started With Amazon Sidewalk Mobile Android SDK", "title": "Getting started with Amazon Sidewalk Mobile Android SDK", "content": "Use this document to get started with Amazon Sidewalk Mobile Android SDK. This document walks you through how to integrate Amazon Sidewalk Mobile Android SDK into your Android apps. Topics . | Prerequisites | Set up your app | Run the sample app | . Related . | Amazon Sidewalk Mobile Android SDK Release Notes | . ", "url": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-android-sdk/#getting-started-with-amazon-sidewalk-mobile-android-sdk", "relUrl": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-android-sdk/#getting-started-with-amazon-sidewalk-mobile-android-sdk" },"381": { "doc": "Getting Started With Amazon Sidewalk Mobile Android SDK", "title": "Prerequisites", "content": "To complete this getting started tutorial, you first need the following: . | Minimum API level 23 (Android 6.0) or higher | Amazon Sidewalk MCU SDK version 1.14 | . ", "url": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-android-sdk/#prerequisites", "relUrl": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-android-sdk/#prerequisites" },"382": { "doc": "Getting Started With Amazon Sidewalk Mobile Android SDK", "title": "Set up your app", "content": "The Amazon Sidewalk Mobile Android SDK provides APIs for Android apps. Using the SDK, you can build Android apps that interact with the Amazon Sidewalk network.This document shows you how to set up the dependency of Amazon Sidewalk Mobile Android SDK in your app. Once you set up your app, you write your own code with Amazon Sidewalk Mobile Android SDK to scan and register devices onto on the Amazon Sidewalk network. Follow the instructions to complete the setup: . Step 1: Integrate Login with Amazon into your app . Sidewalk devices can be attached to an Amazon account. In order to protect user data integrity and to provide a consistent user experience, interactions with the Amazon Sidewalk network requires a user access token from Login with Amazon (LWA). Before you begin adding the Amazon Sidewalk Mobile SDK to your app, follow the steps to integrate LWA into your app: . Obtain your Android API key . Follow all the instructions here to set up a security profile and get your Android API key. The Consent Privacy Notice URL field you set in the security profile will be shown at the bottom of the consent screen on your mobile app, with the link being “[Security Profile Name] Privacy”. The Consent Logo Image is optional. If provided, it will be shown at the top of the consent screen. You will also be able to see these in https://www.amazon.com/ap/adam?ref_=ya_d_l_iba . Integrate LWA into your app . | Follow the instructions here to download the LWA SDK for Android. | Follow the instructions here to set up LWA for your app. You can skip the “Create a New Project in Android Studio” section if you already have a project. | . Use LWA to login and logout a user . Follow the instructions here to implement user login and logout. You can skip the “Fetch User Profile Data” section. When calling AuthorizationManager.authorize(), use the sidewalk::manage_endpoint scope. AuthorizationManager.authorize( AuthorizeRequest.Builder(requestContext) .addScopes(ScopeFactory.scopeNamed(\"sidewalk::manage_endpoint\")) .shouldReturnUserData(false) .build() ) . Remember to call Sidewalk.clearAccountCache() when the user logs out. This document shows you how to integrate Amazon Sidewalk Mobile Android SDK into your app. Amazon Sidewalk only requires a LWA user access token and does not require you to integrate your existing account system with LWA. You can skip the “Integrating with Your Account System” section in the LWA documentation. Note Amazon Sidewalk only requires a LWA user access token and does not require you to integrate your existing account system with LWA. You can skip the “Integrating with Your Account System” section in the LWA documentation. Step 2: Add Sidewalk Mobile Android SDK to your app . Amazon Sidewalk Mobile Android SDK is distributed as an Apache Maven package under maven central. With mavenCentral() config in project level Gradle file, we can add the dependency for Amazon Sidewalk Mobile Android SDK In your app-level Gradle file directly. You can find all released versions in Release Notes. build.gradle.kts . // project-level build.gradle.kts allprojects { repositories { ... mavenCentral() } } // app-level build.gradle.kts dependencies { // ... // Add the dependency for the Amazon Sidewalk Mobile Android SDK implementation(\"com.amazon.sidewalk:mobile-sdk:[Sidewalk Mobile SDK Version]\") } . build.gradle.kts . // project-level build.gradle.kts allprojects { repositories { ... mavenCentral() } } // app-level build.gradle.kts dependencies { // ... // Add the dependency for the Amazon Sidewalk Mobile Android SDK implementation(\"com.amazon.sidewalk:mobile-sdk:[Sidewalk Mobile SDK Version]\") } . After adding the dependency, sync your Android project. Development Environment Ensure that you are using the Android Gradle plugin version 7.0 or later in Android Studio and set minimum API level to 23 or higher. Add permissions . Amazon Sidewalk Mobile Android SDK uses Bluetooth to interact with devices. Follow the code snippet below to add user permission for Bluetooth. For more information, visit Android developers guides for Bluetooth permissions. <manifest ... > ... <uses-permission android:name=\"android.permission.BLUETOOTH\" android:maxSdkVersion=\"30\" /> <uses-permission android:name=\"android.permission.BLUETOOTH_ADMIN\" android:maxSdkVersion=\"30\" /> <uses-permission android:name=\"android.permission.BLUETOOTH_SCAN\" /> <uses-permission android:name=\"android.permission.BLUETOOTH_CONNECT\" /> <uses-permission android:name=\"android.permission.ACCESS_FINE_LOCATION\" /> <uses-permission android:name=\"android.permission.ACCESS_COARSE_LOCATION\" /> ... </manifest> . Request permissions . Before calling Amazon Sidewalk APIs, you will have to request necessary permissions from the user. The following code snippets show you how to use Activity Result APIs to request permissions. First, create a ActivityResultLauncher for requesting location permission on Android 11 and lower. private val locationPermissionsLauncher = registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions -> if (permissions.values.any { !it }) { // Location permission denied. } } private fun requestLocationPermissionIfNeeded() { if (Build.VERSION.SDK_INT < Build.VERSION_CODES.S) { locationPermissionsLauncher.launch( arrayOf( Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION ) ) } } . Second, create another two ActivityResultLauncher for handling a set of Bluetooth permissions according to the Android version. private val bleRuntimePermissionsLauncher = registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions -> if (permissions.values.all { it }) { requestLocationPermissionIfNeeded() } else { // BLE permission denied. } } private val bluetoothEnableLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result -> if (result.resultCode == AppCompatActivity.RESULT_OK) { requestLocationPermissionIfNeeded() } else { // BLE permission denied. } } private fun requestBlePermissions() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) { bleRuntimePermissionsLauncher.launch( arrayOf( Manifest.permission.BLUETOOTH_SCAN, Manifest.permission.BLUETOOTH_CONNECT ) ) } else { val enableBtIntent = Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE) bluetoothEnableLauncher.launch(enableBtIntent) } } . Finally, request for permissions before calling Amazon Sidewalk API. For more information and best practices, see Android developers guides for requesting permissions. class MyFragment : Fragment() { override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) requestBlePermissions() } } . The full permission handling flow can be found in the sample app. Step 3: Write your Amazon Sidewalk project . Write your Amazon Sidewalk project using Amazon Sidewalk Mobile Android SDK. This document shows you how to use Amazon Sidewalk Mobile Android SDK to register a device after user login. Implement the SidewalkAuthProvider . First, implement SidewalkAuthProvider to provide a LWA user access token to the Amazon Sidewalk Mobile Android SDK. When asking for a user access token from LWA, use the sidewalk::manage_endpoint scope, it is the same scope you use when user logs in. val sidewalkAuthProvider = object : SidewalkAuthProvider { override suspend fun getToken(): SidewalkResult<String> = suspendCoroutine { continuation -> val scopes = arrayOf(ScopeFactory.scopeNamed(\"sidewalk::manage_endpoint\")) AuthorizationManager.getToken( context, scopes, object : Listener<AuthorizeResult, AuthError> { override fun onSuccess(result: AuthorizeResult) { result.accessToken?.let { // Success continuation.resume(SidewalkResult.Success(it)) } ?: run { // User is not logged in. continuation.resume(SidewalkResult.Failure()) } } override fun onError(ae: AuthError) { // Error continuation.resume(SidewalkResult.Failure(ae)) } } ) } } . Amazon Sidewalk Mobile Android SDK API will internally call SidewalkAuthProvider.getToken() anytime when needed. Create a Sidewalk . Create a Sidewalk with a SidewalkAuthProvider instance. val sidewalk = Sidewalk(context, sidewalkAuthProvider) . Note Use the same Sidewalk instance during the lifecycle of Application. You can use dependency injection (DI) to reuse the same Sidewalk instance across your app. The sample app uses Hilt for dependency injection. See Dependency injection in Android for more information. Scan and get a SidewalkDevice . Call Sidewalk.scan() to scan for nearby devices. The method returns a flow of SidewalkDevice. class MyViewModel : ViewModel() { private val scanList = mutableListOf<SidewalkDevice>() fun scan () { viewModelScope.launch { scanList.clear() sidewalk.scan().collect { result -> when (result) { is SidewalkResult.Success -> { // A `SidewalkDevice` is discovered. scanList.add(result.value) } is SidewalkResult.Failure -> { // Error } } } } } } . Register Amazon Sidewalk Device . Call Sidewalk.registerDevice() with a Sidewalk Manufacturing Serial Number(SMSN) string to register a device to the user. Sidewalk.registerDevice() internally calls SidewalkAuthProvider.getToken() to get the user access token. class MyViewModel : ViewModel() { fun registerDevice(smsn: String) { viewModelScope.launch { val result = sidewalk.registerDevice(smsn) when (result) { is SidewalkResult.Success -> { // Device registered! } is SidewalkResult.Failure -> { // Error } } } } } . Get logs from Amazon Sidewalk Mobile SDK . Set Sidewalk.logger to an object that implements SidewalkLogging with the log(sidewalkLogLevel: SidewalkLogLevel, message: String) function. Sidewalk.logger = SidewalkLogging { sidewalkLogLevel, message -> // Save message to a file accoring to log level for further troubleshooting. } . Note Amazon Sidewalk Mobile Android SDK also logs the message with “SidewalkSDKAndroid” tag, so you might need to integrate logger only for additional purpose such as saving logs to a file. Step 4: Build and run the app . Now you can build and run your app to login and logout a user, scan and register devices. Before running the app, remember to turn on bluetooth on the phone. Also, do not forget to call Sidewalk.clearAccountCache() when the user logs out. Congratulations! Now that you have the basics down, you can start your own journey or check out the sample app. Please check the Amazon and Ring account linking limitation from here before you start registering device with Amazon Sidewalk Mobile SDK. Make sure to inform your customer about the action required. ", "url": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-android-sdk/#set-up-your-app", "relUrl": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-android-sdk/#set-up-your-app" },"383": { "doc": "Getting Started With Amazon Sidewalk Mobile Android SDK", "title": "Run the sample app", "content": "Step 1: Download the sample app . Clone Android sample app from GitHub https://github.com/amzn/amazon-sidewalk-android-samples to a directory on your hard drive. Step 2: Set up Login with Amazon . Follow the steps in Integrate Login with Amazon into your app to obtain your Android API key and integrate LWA into the sample app. Step 3: Run the sample app . You can now compile and run the sample app. The sample app demonstrates the following features: . | Login and logout users with LWA SDK. | Scan nearby Amazon Sidewalk devices. | Register and unregister Amazon Sidewalk devices. | Establish a secure connection with a device. | . ", "url": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-android-sdk/#run-the-sample-app", "relUrl": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-android-sdk/#run-the-sample-app" },"384": { "doc": "Getting Started With Amazon Sidewalk Mobile Android SDK", "title": "Getting Started With Amazon Sidewalk Mobile Android SDK", "content": " ", "url": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-android-sdk/", "relUrl": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-android-sdk/" },"385": { "doc": "Overview", "title": "Amazon Sidewalk Mobile SDK Overview", "content": "The Amazon Sidewalk Mobile SDK includes the library, supporting documentation, and a sample app to teach you how to use Amazon Sidewalk functionalities. Amazon Sidewalk Mobile SDK library . Amazon Sidewalk Mobile SDK is for mobile developers who want to build customized Amazon Sidewalk applications. To integrate Amazon Sidewalk Mobile SDK with your app, follow the step-by-step guide given in the link below to set up your app. | Set up your app with Amazon Sidewalk Mobile Android SDK | Set up your app with Amazon Sidewalk Mobile iOS SDK | . Amazon Sidewalk Mobile SDK sample app . Amazon Sidewalk Mobile SDK Sample App demonstrates how to integrate Amazon Sidewalk Mobile SDK into your app with basic API call flows. To try out the Amazon Sidewalk Mobile SDK functionalities and to run the sample app, follow the step-by-step guide given in the link below. | Run the Android sample app | Run the iOS sample app | . Topics . | What is Amazon Sidewalk Mobile SDK? | Common Amazon Sidewalk User Activities and High Level API Call Flow | Amazon Sidewalk Mobile SDK API Overview | . ", "url": "/mobile-sdk/developer-guide/sidewalk-mobile-sdk-overview/#amazon-sidewalk-mobile-sdk-overview", "relUrl": "/mobile-sdk/developer-guide/sidewalk-mobile-sdk-overview/#amazon-sidewalk-mobile-sdk-overview" },"386": { "doc": "Overview", "title": "What is Amazon Sidewalk Mobile SDK?", "content": "Amazon Sidewalk Mobile SDK provides a one-stop solution for everything related to Amazon Sidewalk on mobiles. Amazon Sidewalk Mobile SDK has its own Bluetooth and network stack, and is able to communicate to both the edge device (over BLE) and the Amazon Sidewalk cloud. Currently, the Amazon Sidewalk Mobile SDK exports the underlying Alexa Mobile Accessory (AMA) BLE stack, and allows apps to scan for AMA beaconing devices and then provision these devices over AMA to use the Amazon Sidewalk network. The Amazon Sidewalk Mobile SDK handles the interaction between the Amazon Sidewalk cloud, edge device, exchanging keys and registering the edge device, so that the edge device can connect to the Amazon Sidewalk network via Amazon Sidewalk Gateways. Authentication is provided via integration with Login with Amazon (LWA). The Amazon Sidewalk Mobile SDK is designed to assist developers in integrating common Amazon Sidewalk user controls into developers’ own mobile apps for controls such as the endpoint registration and de-registration. Amazon Sidewalk Mobile SDK is able to communicate to both the endpoint (over BLE) and the Amazon Sidewalk cloud. Amazon Sidewalk Mobile SDK apps are required to integrate with Login with Amazon (LWA) SDK to collect a user Auth Token for issuing Amazon Sidewalk controls. The iOS Mobile SDK also requires OpenSSL. More details can also be found in Getting Started with Amazon Sidewalk Mobile SDK Android and iOS sections. NOTE . For customers interacting with Amazon Sidewalk devices through Amazon Sidewalk Mobile SDK, there is a prerequisite to link their Amazon account to a Ring account, where the Amazon account is the one customer logs in to LWA and provides Auth Token for Amazon Sidewalk Mobile SDK. If the Amazon account is not linked with a Ring account, the Amazon Sidewalk cloud does not return registered devices. To link an Amazon account with a Ring account, please visit url: https://account.ring.com/account/control-center/account-linking. Follow below steps: . | Create / Signin to a Ring account | Go to ‘Amazon Account Linking’ | Click ‘Link’ inside Amazon Account Linking | Enter Ring account credentials and click on ‘LINK ACCOUNT’ | Enter Amazon account credentials. | . The Amazon Account will be successfully linked to the Ring account. Please check your account linking before testing with Mobile SDK, and inform your customer about the action required while releasing your app integrated with Sidewalk Mobile SDK. ", "url": "/mobile-sdk/developer-guide/sidewalk-mobile-sdk-overview/#what-is-amazon-sidewalk-mobile-sdk", "relUrl": "/mobile-sdk/developer-guide/sidewalk-mobile-sdk-overview/#what-is-amazon-sidewalk-mobile-sdk" },"387": { "doc": "Overview", "title": "Common Amazon Sidewalk User Activities and High Level API Call Flow", "content": "| End User Activity | Short Description | High Level API Call Flow | . | Endpoint registration | User registers the endpoint to the Amazon Sidewalk network through a mobile app. | . | Start scan(). | Select a device from scan() result array. | Call registerDevice() with the Sidewalk Manufacturing Serial Number(SMSN) string of the endpoint to the Amazon Sidewalk network. | . | Connecting directly to an endpoint | User connects directly to an endpoint to write/receive packets directly. | . | Start scan(). | Select a device from scan() result array. | Call secureConnectDevice() with the Sidewalk Manufacturing Serial Number(SMSN) string of the endpoint, which returns a SidewalkConnection. | subscribe() to listen to device messages on SidewalkConnection. | write() payload as required. | . | Endpoint deregistration | User deregisters the endpoint from the Amazon Sidewalk network through a mobile app. | Call deregisterDevice() with the Sidewalk Manufacturing Serial Number(SMSN) string of the endpoint. | . | Upload device metrics to the Amazon Sidewalk cloud | Deprecation Notice: This API is deprecated as it relies on the Sidewalk SDK for endpoint devices. Starting with the Sidewalk endpoint SDK 1.17 release, this feature is no longer supported. User connects directly to an endpoint to collect device metrics and upload them to the Amazon Sidewalk cloud. These metrics can help the Amazon Sidewalk team in diagnosing endpoint device connectivity issues, providing supplementary support alongside endpoint logs. NOTE: It’s recommended to notify customer before calling this API. | . | Start scan(). | Select a device from scan() result array. | Call secureConnectDevice() with the Sidewalk Manufacturing Serial Number(SMSN) string of the endpoint, which returns a SidewalkConnection. | uploadDeviceMetrics() to collect device metrics and upload them to the Amazon Sidewalk cloud. | . ", "url": "/mobile-sdk/developer-guide/sidewalk-mobile-sdk-overview/#common-amazon-sidewalk-user-activities-and-high-level-api-call-flow", "relUrl": "/mobile-sdk/developer-guide/sidewalk-mobile-sdk-overview/#common-amazon-sidewalk-user-activities-and-high-level-api-call-flow" },"388": { "doc": "Overview", "title": "Amazon Sidewalk Mobile SDK API Overview", "content": "| API Call | Description | . | Sidewalk | - main entry point for interactions | . | scan() | API scans for available Amazon Sidewalk devices within the mobile BLE range. This function call puts the smartphone into scanning mode, and the operation must be cancelled for the API to stop scanning. | . | secureConnectDevice() | Creates a secure connection with the given Sidewalk Manufacturing Serial Number(SMSN) string of an Amazon Sidewalk device via BLE, and exchanges encryption keys to create a secure connection. This connection allows write and subscribe for communication. | . | registerDevice() | API registers the endpoint to Amazon Sidewalk network. By providing different parameters, you can register an endpoint by given device Id, name, or SidewalkConnection. | . | deregisterDevice() | API deregisters the endpoint from Amazon Sidewalk network. | . | clearAccountCache() | Clears user related data. You should call clearAccountCache() explicitly when the account credential is no longer available, e.g. user logged out. | . | SidewalkConnection | - handling a secure connection | . | subscribe() | Subscribes to BLE payloads sent by the device. | . | write() | Writes a BLE payload to the device. | . | isAvailable() | Checks whether the connection is available to write and subscribe messages. | . | startCoverageTest() | Starts coverage test on the connected Amazon Sidewalk device to get Amazon Sidewalk coverage information near the Amazon Sidewalk device. | . | uploadDeviceMetrics() | Uploads device metrics to the Amazon Sidewalk cloud. | . | SidewalkAuthProviding | - authentication provider for Sidewalk | . | getToken() | API retrieves and refreshes the Auth Token via Login with Amazon for communication with Amazon Sidewalk cloud. | . | SidewalkLogging | - log output for Sidewalk | . | log() | Setup Sidewalk.logger with your implementation of SidewalkLogging interface and the log() method to get logs from Amazon Sidewalk Mobile SDK. | . ", "url": "/mobile-sdk/developer-guide/sidewalk-mobile-sdk-overview/#amazon-sidewalk-mobile-sdk-api-overview", "relUrl": "/mobile-sdk/developer-guide/sidewalk-mobile-sdk-overview/#amazon-sidewalk-mobile-sdk-api-overview" },"389": { "doc": "Overview", "title": "Overview", "content": " ", "url": "/mobile-sdk/developer-guide/sidewalk-mobile-sdk-overview/", "relUrl": "/mobile-sdk/developer-guide/sidewalk-mobile-sdk-overview/" },"390": { "doc": "Getting Started With Amazon Sidewalk Mobile iOS SDK", "title": "Getting started with Amazon Sidewalk Mobile iOS SDK", "content": "Use this document to get started with Amazon Sidewalk Mobile iOS SDK. This document walks you through how to integrate Amazon Sidewalk Mobile iOS SDK into your iOS apps. Topics . | Prerequisites | Set up your app | Run the sample app | . Related . | Amazon Sidewalk Mobile iOS SDK Release Notes | . ", "url": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-ios-sdk/#getting-started-with-amazon-sidewalk-mobile-ios-sdk", "relUrl": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-ios-sdk/#getting-started-with-amazon-sidewalk-mobile-ios-sdk" },"391": { "doc": "Getting Started With Amazon Sidewalk Mobile iOS SDK", "title": "Prerequisites", "content": "The Amazon Sidewalk Mobile iOS SDK has a dependency on OpenSSL. Before starting the set up flow, confirm that you have added an OpenSSL library into your app. This is also required when running the Sample App. To complete this getting started tutorial, you first need the following: . | A deployment target iOS 12.1 or later. | Amazon Sidewalk MCU SDK version 1.14. | OpenSSL | . ", "url": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-ios-sdk/#prerequisites", "relUrl": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-ios-sdk/#prerequisites" },"392": { "doc": "Getting Started With Amazon Sidewalk Mobile iOS SDK", "title": "Set up your app", "content": "The Amazon Sidewalk Mobile iOS SDK provides APIs for iOS apps. Using the SDK, you can build iOS apps that interact with the Amazon Sidewalk network. This document shows you how to set up the dependency of Amazon Sidewalk Mobile iOS SDK in your app. After you set up your app, you can write your own code with the Amazon Sidewalk Mobile iOS SDK to scan and register devices on the Amazon Sidewalk network. Complete the following steps to set up your app. Step 1: Integrate Login with Amazon into your app . Amazon Sidewalk devices can be attached to an Amazon account. In order to protect user data integrity and to provide a consistent user experience, interactions with the Amazon Sidewalk network requires a user access token from Login with Amazon (LWA). Before you begin adding Amazon Sidewalk Mobile iOS SDK to your app, follow these steps to integrate LWA into your app. Obtain your iOS API Key . Follow the instructions here to set up a security profile and get your iOS API key. The Consent Privacy Notice URL field you set in the security profile will be shown at the bottom of the consent screen on your mobile app, with the link being “[Security Profile Name] Privacy”. The Consent Logo Image is optional. If provided, it will be shown at the top of the consent screen. You will also be able to see these in https://www.amazon.com/ap/adam?ref_=ya_d_l_iba . Integrate LWA into your app . | Follow the instructions here to download the LWA SDK for iOS. | Follow the instructions here to set up LWA for your app. You can skip the “Create a New Project in Xcode” section if you already have a project. | . Use LWA to login and logout a user . Follow the instructions here to implement user login and logout. You can skip the “Fetch User Profile Data” section. When calling AMZNAuthorizationManager.authorize(), you need to use the sidewalk::manage_endpoint scope and make sure you are calling from the main queue. let request: AMZNAuthorizeRequest = AMZNAuthorizeRequest() request.scopes = [AMZNScopeFactory.scope(withName: \"sidewalk::manage_endpoint\")] DispatchQueue.main.async { // This should run in the main queue. AMZNAuthorizationManager.shared().authorize(request) { (result, _, error) in if let accessToken = result?.token { // Authentication was successful. } else { // Handle errors. } } } . Remember to call Sidewalk.clearAccountCache() when the user logs out. The following tutorials document will help how to integrate Amazon Sidewalk Mobile iOS SDK into your app. Note Amazon Sidewalk only requires a LWA user access token and does not require you to integrate your existing account system with LWA. You can skip “Integrating with Your Account System” section in the LWA documentation. Step 2: Add OpenSSL to your app . The Amazon Sidewalk Mobile iOS SDK has a dependency on OpenSSL. You must add an OpenSSL library into your app. Step 3: Add Amazon Sidewalk Mobile iOS SDK to your app . Add Amazon Sidewalk Mobile iOS SDK dependency . Amazon Sidewalk Mobile iOS SDK is distributed through CocoaPods or binary zip files, chose the one that better fits your needs. You can find all released versions in Release Notes. CocoaPods . | If you do not have a Podfile, run the following command in the root of your project directory. pod init . | Add Amazon Sidewalk pod in your Podfile. # Add the Amazon Sidewalk pod pod 'SidewalkSDK', '~> [Amazon Sidewalk Mobile SDK Version]' . | Install the pods. pod install --repo-update . | . Download Amazon Sidewalk Mobile iOS SDK Binary . Download the latest version SidewalkMobile iOS SDK from the Release Notes and extract the files to a directory on your hard drive. You should see a SidewalkSDK.xcframework directory in the Sidewalk_iOS/Frameworks parent directory. This contains the Amazon Sidewalk Mobile SDK library. Next, install Amazon Sidewalk Mobile iOS SDK framework to an iOS project with the following steps. | If your project doesn’t have a Frameworks folder, right-select the project name in the Navigator pane in Xcode, then select New Group. | Name the new group Frameworks. | Select the Frameworks folder and select File from the Main menu. | Select Add Files to Project. | In the dialog box, select SidewalkSDK.xcframework and select Add. | Select the name of your project in the Project Navigator. The Project Editor will appear in the editor area of the Xcode workspace. | Select your project name under Targets, and select Build Phases. Expand Link Binary with Libraries and select the plus sign to add a library. | Select Build Settings. select All to view all settings. | Under Search Paths, ensure that the SidewalkSDK.xcframework directory is in the Framework Search Paths. | From the Main menu, select Product and then select Build. The build should complete successfully. | . Provide a purpose string for access to Bluetooth . Amazon Sidewalk Mobile iOS SDK uses Bluetooth to interact with devices. You must provide a purpose string by setting a string value for the NSBluetoothAlwaysUsageDescription key in your apps Info.plist file. If your app has a deployment target earlier than iOS 13, you also need to add the NSBluetoothPeripheralUsageDescription key. For more information, see Requesting access to protected resources. <key>NSBluetoothAlwaysUsageDescription</key> <string>Your purpose string.</string> . Step 4: Write your Amazon Sidewalk project . Write your code using Amazon Sidewalk Mobile iOS SDK. In this document, we show you how to use Amazon Sidewalk Mobile iOS SDK to register a device after user login. Implement the SidewalkAuthProviding . Implement the SidewalkAuthProviding to provide a LWA user access token to the Amazon Sidewalk Mobile iOS SDK. When calling AMZNAuthorizationManager.authorize(), make sure you are calling from the main queue. final class MySidewalkAuthProviding: SidewalkAuthProviding { struct AuthError: Error {} func getToken(completion: @escaping (Result<String, Error>) -> Void) { let request: AMZNAuthorizeRequest = AMZNAuthorizeRequest() request.interactiveStrategy = .never DispatchQueue.main.async { // This should run in the main queue. AMZNAuthorizationManager.shared().authorize(request) { (result, _, error) in if let accessToken = result?.token { // Success completion(.success(accessToken)) } else { // Error completion(.failure(error ?? AuthError())) } } } } } . Amazon Sidewalk Mobile iOS SDK API will internally call SidewalkAuthProviding.getToken() anytime when needed. Create a Sidewalk . Create a Sidewalk with a SidewalkAuthProviding instance. let authProviding = MySidewalkAuthProviding() let sidewalk = Sidewalk(authProvider: authProviding) . Note Use the same Sidewalk instance during the lifecycle of your app. You can use dependency injection (DI) to reuse the same Sidewalk instance across your app. Scan and get a SidewalkDevice . Call Sidewalk.scan() to scan for nearby devices. The method returns a SidewalkCancellable. final class MyViewModel { private var devices: [SidewalkDevice] = [] private var operation: SidewalkCancellable? = nil func scan () { devices = [] operation?.cancel() operation = sidewalk.scan(onDeviceFound: didDetectDeviceDuringScan, completion: { (result) in DispatchQueue.main.async { switch result { case .success: // Scan completed. case .failure(let error): // Scan failed. } } }) } private func didDetectDeviceDuringScan(device: SidewalkDevice) { DispatchQueue.main.async { // A `SidewalkDevice` is discovered. self.devices.append(device) } } } . Register Amazon Sidewalk Device . Call Sidewalk.registerDevice() with a Sidewalk Manufacturing Serial Number(SMSN) string to register a device to the user. Sidewalk.registerDevice() internally calls SidewalkAuthProviding.getToken() to get the user access token. final class MyViewModel { private var operation: SidewalkCancellable? = nil func registerDevice(smsn: String) { operation?.cancel() operation = sidewalk.registerDevice(smsn: smsn) { result in DispatchQueue.main.async { switch result { case .success(let detail): // Device registered! case .failure(let error): // Error } } } } } . Get logs from Amazon Sidewalk Mobile SDK . Define an object that implements SidewalkLogging with the log(type:, message:) function. final class MyLogger: SidewalkLogging { func log(type: OSLogType, message: @autoclosure () -> String) { // Capture the logs from Amazon Sidewalk Mobile SDK here in message() os_log(type, \"%@\", message()) } } . Set Sidewalk.logger to the object that implements SidewalkLogging. Sidewalk.logger = MyLogger() . Step 5: Build and run the app . Now you can build and run your app to login / logout a user, and scan and register devices. Before running the app, remember to turn on your phone’s Bluetooth. Do not forget to call Sidewalk.clearAccountCache() when the user logs out. Congratulations! Now that you have the basics down, you can start your own journey or check out the sample app. Please check the Amazon and Ring account linking limitation from here before you start registering device with Amazon Sidewalk Mobile SDK. Make sure to inform your customer about the action required. ", "url": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-ios-sdk/#set-up-your-app", "relUrl": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-ios-sdk/#set-up-your-app" },"393": { "doc": "Getting Started With Amazon Sidewalk Mobile iOS SDK", "title": "Run the sample app", "content": "Step 1: Download the sample app . Clone iOS sample app from GitHub https://github.com/amzn/amazon-sidewalk-ios-samples to a directory on your hard drive. Step 2: Set up Amazon Sidewalk Mobile SDK . CocoaPods . Run the command below to install the pods for Amazon Sidewalk Mobile iOS SDK . pod install --repo-update . Local xcframework . Please refer to Install Amazon Sidewalk Mobile iOS SDK framework to an iOS project above to add your local Amazon Sidewalk Mobile SDK xcframework to your Sample App. Step 3: Set up Login with Amazon . Follow the steps in Integrate Login with Amazon into your app to obtain your iOS API key and integrate LWA into the sample app. Step 4: Add OpenSSL to the sample app . The Amazon Sidewalk Mobile iOS SDK has a dependency on OpenSSL. Add an OpenSSL library into the sample app. Step 5: Run the sample app . You can now compile and run the sample app. The sample app demonstrates the following features: . | Login and logout users with LWA SDK. | Scan nearby Amazon Sidewalk devices. | Register and unregister Amazon Sidewalk devices. | Establish a secure connection with a device. | . Troubleshooting . Errors were encountered while preparing your device for development. Rebooting your iPhone. XCode shows that the device is locked when the iPhone is unlocked. Add your computer as a trusted device. See Apple Support article for more information. Profile has not been trusted. Establish trust for your app developer in your iPhone under Settings → General → Device Management. See Apple Support article for more information. ", "url": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-ios-sdk/#run-the-sample-app", "relUrl": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-ios-sdk/#run-the-sample-app" },"394": { "doc": "Getting Started With Amazon Sidewalk Mobile iOS SDK", "title": "Getting Started With Amazon Sidewalk Mobile iOS SDK", "content": " ", "url": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-ios-sdk/", "relUrl": "/mobile-sdk/developer-guide/getting-started-sidewalk-mobile-ios-sdk/" },"395": { "doc": "Developer Guide", "title": "Amazon Sidewalk Mobile SDK Developer Guide", "content": "Amazon Sidewalk Mobile SDK Developer Guide provides an overview of the Amazon Sidewalk Mobile SDK and the instructions on how to integrate Amazon Sidewalk Mobile SDK into your app. For more information, including step-by-step walkthoughs, check the following topics. Topics . | Amazon Sidewalk Mobile SDK Overview | Getting started with Amazon Sidewalk Mobile Android SDK | Getting started with Amazon Sidewalk Mobile iOS SDK | . ", "url": "/mobile-sdk/developer-guide/#amazon-sidewalk-mobile-sdk-developer-guide", "relUrl": "/mobile-sdk/developer-guide/#amazon-sidewalk-mobile-sdk-developer-guide" },"396": { "doc": "Developer Guide", "title": "Developer Guide", "content": " ", "url": "/mobile-sdk/developer-guide/", "relUrl": "/mobile-sdk/developer-guide/" },"397": { "doc": "Amazon Sidewalk Mobile SDK", "title": "Amazon Sidewalk Mobile SDK", "content": "In this section, you’ll learn about the Amazon Sidewalk Mobile SDK. The section provides an overview of the Amazon Sidewalk Mobile SDK, how to use it, and instructions for integrating the Amazon Sidewalk Mobile SDK into your application. Topics . | Amazon Sidewalk Mobile SDK Developer Guide | Amazon Sidewalk Mobile SDK API Reference | Amazon Sidewalk Mobile SDK Sample App | Amazon Sidewalk Mobile SDK Release Notes | . ", "url": "/mobile-sdk/", "relUrl": "/mobile-sdk/" },"398": { "doc": "Sidewalk Test Specification", "title": "Amazon Sidewalk Test Specification", "content": "This document outlines the Amazon Sidewalk reference test cases used to qualify an endpoint device for compliance with the Amazon Sidewalk protocol specification. Select a chapter from the navigation menu to view the test specification content. ", "url": "/specifications/sidewalk-test-spec/#amazon-sidewalk-test-specification", "relUrl": "/specifications/sidewalk-test-spec/#amazon-sidewalk-test-specification" },"399": { "doc": "Sidewalk Test Specification", "title": "Sidewalk Test Specification", "content": " ", "url": "/specifications/sidewalk-test-spec/", "relUrl": "/specifications/sidewalk-test-spec/" },"400": { "doc": "Sidewalk Compliance Test Implementation Guide", "title": "Sidewalk Compliance Test Implementation Guide", "content": "This document provides detailed implementation guidance for the Amazon Sidewalk compliance test cases. Each test case includes step-by-step instructions, expected results, and key checks to verify correct device behavior. Version 1.0 — 2026-04-22 . Select a chapter from the navigation menu to view the test implementation guide content. ", "url": "/specifications/sidewalk-compliance-test-guide/", "relUrl": "/specifications/sidewalk-compliance-test-guide/" },"401": { "doc": "8. Procedures and flow charts", "title": "8. Procedures and Flow Charts", "content": "This chapter provides procedures and flow charts for common Amazon Sidewalk operations, including device power-up, join and network synchronization, and global clock synchronization. ", "url": "/specifications/sidewalk-protocol-spec/procedures-and-flow-charts/#8-procedures-and-flow-charts", "relUrl": "/specifications/sidewalk-protocol-spec/procedures-and-flow-charts/#8-procedures-and-flow-charts" },"402": { "doc": "8. Procedures and flow charts", "title": "8. Procedures and flow charts", "content": " ", "url": "/specifications/sidewalk-protocol-spec/procedures-and-flow-charts/", "relUrl": "/specifications/sidewalk-protocol-spec/procedures-and-flow-charts/" },"403": { "doc": "3. Application", "title": "3. Application", "content": "This chapter describes the Application layer role in the Amazon Sidewalk protocol stack. 3.1 Application layer characterizes the role of this layer and frame format. 3.2 Application commands describe application commands that are collected in separate groups. ", "url": "/specifications/sidewalk-protocol-spec/application/", "relUrl": "/specifications/sidewalk-protocol-spec/application/" },"404": { "doc": "Glossary", "title": "Glossary", "content": "| Acronym | Definition | . | ACK | Acknowledgement | . | AES-GCM | Advanced Encryption Standard Galois/Counter Mode | . | AES-CTR | Advanced Encryption Standard Counter Mode | . | AES-CMAC | Advanced Encryption Standard Cipher Message Authentication Code | . | AMA | Alexa Mobile Accessory | . | APID/API | Advertised Product ID | . | ASL | Application Support Layer | . | BB | Baseband | . | BLE | Bluetooth Low Energy | . | BoardID | Type of device build | . | BT | Bandwidth-time product | . | CA | Certificate Authority | . | Chunk MTU Size | Data Payload Transported over a Link | . | CMAC | Cipher-based Message Authentication Code | . | CR | Coding Rate | . | CRC | Cyclic Redundancy Check | . | CS-UL | Cloud Server Uplink | . | CS-DL | Cloud Server Downlink | . | CTRREF | Counter-based reference symmetric key | . | D2D | Device to Device | . | DAK | Device Attestation Key | . | DHAv2 | Device Hardware Authentication - Version 2 | . | DL | Downlink | . | DMS | Device Management Service | . | DSN | Device Serial Number | . | DUT | Device Under Test | . | EC | Elliptic Curve | . | ECDH | Elliptic Curve Diffie-Hellman | . | FCS | Frame Check Sequence | . | FEC | Forward Error Correction | . | FFN | Frustration-Free Network | . | FIFO | First In, First Out | . | Fragments | Smaller Blocks of a File | . | FSK | Frequency Shift Keying | . | FW | Firmware | . | GATT | Generic Attribute Profile | . | GFSK | Gaussian Frequency-Shift Keying | . | GPS | Global Positioning System | . | HDR | High Data Rate | . | HDX | Half-Duplex | . | HSM | Hardware Security Module | . | ID | Identifier | . | IoT | Internet of Things | . | ISM | Radio bands reserved for Industrial, Scientific and Medical purposes | . | KEX | Key Exchange Flow | . | LAN | Local Area Network | . | LDR | Low Data Rate | . | LFSR | Linear Feedback Shift Register | . | LoRa | LoRa (derived from Long Range) is a proprietary chirp spread spectrum radio modulation technique owned by Semtech | . | MAC | Media Access Control | . | MCU-SDK | Micro Controller Unit Software Development Kit | . | MTU | Maximum Transmission Unit | . | OpenSSL | Open Secure Sockets Layer, an open source software library | . | PAN | Personal Area Network | . | PHDR | Physical layer Header | . | PHY | Physical layer | . | PKI | Public Key Infrastructure | . | Rb | Bit rate | . | RF | Radio Frequency | . | RNG | Random Number Generator | . | RSVD | Reserved | . | RX | Receive operation | . | SBDT | Sidewalk Bulk Data Transfer | . | SDK | Software Development Kit | . | SF | Spreading Factor | . | SFD | Start of Frame Delimiter | . | SMSN | Sidewalk Manufacturing Serial Number | . | SR | Symbol Rate | . | SubG-CSS | Amazon Sidewalk asynchronous transport using Semtech’s LoRa chirp spread spectrum (CSS) modulation in the sub-GHz ISM band. Also referred to as Low Data Rate (LDR), CSS, LoRa, and asynchronous. | . | SubG-FSK | Amazon Sidewalk synchronous transport using GFSK modulation in the sub-GHz ISM band. Also referred to as High Data Rate(HDR), 900MHz, FSK, GFSK and synchronous. | . | TLV | Tag Length Value | . | TX | Transmit operation | . | TXID | Transmitter/Transmission Identifier | . | UL | Uplink | . | Wi-Fi | High speed wireless data transmission | . ", "url": "/specifications/sidewalk-protocol-spec/glossary/", "relUrl": "/specifications/sidewalk-protocol-spec/glossary/" },"405": { "doc": "5. Sub-GHz Protocol Stack", "title": "5. Sub-GHz Protocol Stack", "content": "This chapter describes the Amazon Sidewalk sub-GHz protocol stack, covering the protocol stack layers and structure, the sub-GHz physical-layer modulations, endpoint and gateway connection modes, connection maintenance with network synchronization, and the SubG-FSK and SubG-CSS connection procedures. ", "url": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/", "relUrl": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/" },"406": { "doc": "4. Security", "title": "4. Security", "content": "This chapter describes the Amazon Sidewalk security architecture, including entity identification, key establishment and management, encrypted and flex-layer messaging, obfuscated transmission IDs, and global clock synchronization. Use the sections in this chapter to understand how endpoints, gateways, and the Amazon Sidewalk cloud authenticate one another and protect data in transit. ", "url": "/specifications/sidewalk-protocol-spec/security/", "relUrl": "/specifications/sidewalk-protocol-spec/security/" },"407": { "doc": "7. Sidewalk Bulk Data Transfer", "title": "7. Sidewalk Bulk Data Transfer", "content": "This chapter describes the Amazon Sidewalk Bulk Data Transfer (SBDT) feature, covering its overview, design architecture, end-device behavior, protocol specification, and security and privacy considerations. ", "url": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/", "relUrl": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/" },"408": { "doc": "6. BLE Protocol Stack", "title": "6. BLE Protocol Stack", "content": "BLE is used as a transport medium to provide connectivity for an Endpoint to exchange encrypted messages with the Amazon Sidewalk Cloud via compatible BLE-enabled Amazon Sidewalk Gateways. This chapter provides details of the BLE protocol stack and use cases that are specific to Amazon Sidewalk. This chapter covers selected security aspects that are specific to BLE and are not covered by Chapter 4. BLE usage in Amazon Sidewalk emphasizes power efficiency and low latency for Endpoint communication. BLE gives the most efficient and highest data rate but has a shorter range than the SubG-FSK and SubG-CSS links. BLE devices may play central or peripheral roles. A peripheral device (Endpoint) advertises its presence by broadcasting an advertisement packet. A central device scans for advertisements and may choose to allow connection with a peripheral device based on the advertisement data. A central device may connect with multiple peripheral devices simultaneously. Smartphones with a mobile application installed and Gateways act as central devices while devices like sensors act as peripheral devices. Amazon Sidewalk BLE devices use the Generic Attribute Profile (GATT) defined in Bluetooth Low Energy Specification v 4.2 with the following GATT concepts: . | Client: A device that initiates connection. Typically, the central device (smartphone/Gateway) is a GATT client. | Server: A device that receives connection. Typically, a BLE peripheral is also the GATT server. | Service: A collection of related characteristics is a BLE GATT service. | Characteristic: Contains data to be exchanged between the client and server. Each characteristic can support one or more operations like read, write, notify or indicate. A client can subscribe to notifications when connecting with a GATT server. | Descriptor: GATT Descriptors are defined attributes that describe a characteristic value. “Client Characteristic Configuration Descriptor 0x2902” is used as a descriptor value. | . ", "url": "/specifications/sidewalk-protocol-spec/ble-protocol-stack/", "relUrl": "/specifications/sidewalk-protocol-spec/ble-protocol-stack/" },"409": { "doc": "Sidewalk Protocol Specification", "title": "Amazon Sidewalk Protocol Specification", "content": "This document defines the wireless protocol used by Endpoint devices in the Amazon Sidewalk network. Select a chapter from the navigation menu to view the specification content. ", "url": "/specifications/sidewalk-protocol-spec/#amazon-sidewalk-protocol-specification", "relUrl": "/specifications/sidewalk-protocol-spec/#amazon-sidewalk-protocol-specification" },"410": { "doc": "Sidewalk Protocol Specification", "title": "Sidewalk Protocol Specification", "content": " ", "url": "/specifications/sidewalk-protocol-spec/", "relUrl": "/specifications/sidewalk-protocol-spec/" },"411": { "doc": "Specifications", "title": "Amazon Sidewalk specification", "content": "The Amazon Sidewalk specifications consists of the following documents. ", "url": "/specifications/#amazon-sidewalk-specification", "relUrl": "/specifications/#amazon-sidewalk-specification" },"412": { "doc": "Specifications", "title": "Amazon Sidewalk protocol specification", "content": "This document defines the wireless protocol used by Endpoint devices in the Amazon Sidewalk network. It covers information about: . | Protocol stack layers | The Amazon Sidewalk sub-1 GHz radio | Interactions between endpoints and other elements of the system, such as commands and procedures. | Power profiles | Security and architecture | Frame formats and detailed descriptions of frame fields. | . The document does not include the detailed specification of gateways and the Amazon Sidewalk Cloud, or the interactions between the gateways and the Amazon Sidewalk Cloud. Browse the Sidewalk Protocol Specification chapters in the navigation menu, or download the PDF version. ", "url": "/specifications/#amazon-sidewalk-protocol-specification", "relUrl": "/specifications/#amazon-sidewalk-protocol-specification" },"413": { "doc": "Specifications", "title": "Amazon Sidewalk test specification", "content": "This document outlines the Amazon Sidewalk reference test cases used to qualify an endpoint device for compliance with the Amazon Sidewalk protocol specification. The document also includes the Amazon Sidewalk Protocol Implementation Conformance Statement (PICS) in the appendix, which details the mandatory and optional Sidewalk features that must be implemented in the device. The purpose of this document is to verify the device’s compatibility with the specified Sidewalk implementation, and its alignment with the developer’s requirements. Developers must submit a PICS statement for their device when applying for Sidewalk qualification, confirming that the device’s Sidewalk implementation meets the specified criteria. The Sidewalk endpoint device is referred to as a Design Under Test (DUT) in the document. For more information, see Amazon Sidewalk test specification document. Browse the Sidewalk Test Specification chapters in the navigation menu, or download the PDF above. ", "url": "/specifications/#amazon-sidewalk-test-specification", "relUrl": "/specifications/#amazon-sidewalk-test-specification" },"414": { "doc": "Specifications", "title": "Sidewalk Compliance Test Implementation Guide", "content": "This document provides detailed implementation guidance for the Amazon Sidewalk compliance test cases. Each test case includes step-by-step instructions, expected results, and key checks to verify correct device behavior during qualification testing. Browse the Sidewalk Compliance Test Implementation Guide chapters in the navigation menu, or download the PDF version. ", "url": "/specifications/#sidewalk-compliance-test-implementation-guide", "relUrl": "/specifications/#sidewalk-compliance-test-implementation-guide" },"415": { "doc": "Specifications", "title": "Specifications", "content": " ", "url": "/specifications/", "relUrl": "/specifications/" },"416": { "doc": "SID API Developer Guide", "title": "Amazon Sidewalk SID API Developer Guide", "content": "Amazon Sidewalk provides an Application Programming Interface API (the “SID API”) that allows Sidewalk device creators to onboard their devices to Amazon Sidewalk, and to manage an encrypted data pipe over BLE and sub-GHz radio interfaces. A developer’s application interacts with the Amazon Sidewalk stack through the SID API. The SID API supports the following operations for Amazon Sidewalk links: . | Initialize and de-initialize links. | Start and stop links. | Send and receive messages. | Set and get configuration through IOCTLs | . ", "url": "/sid-api-dg/#amazon-sidewalk-sid-api-developer-guide", "relUrl": "/sid-api-dg/#amazon-sidewalk-sid-api-developer-guide" },"417": { "doc": "SID API Developer Guide", "title": "SID API Developer Guide", "content": " ", "url": "/sid-api-dg/", "relUrl": "/sid-api-dg/" },"418": { "doc": "How To Manufacture & Produce Devices", "title": "How to manufacture and bulk produce Sidewalk devices", "content": "This section describes how to mass manufacture your Sidewalk-enabled products for production. You’ll learn about the pre-requisites and tools that are used, and the steps that are performed in manufacturing your devices. It also contains information about the steps that you must perform and the steps that must be performed by the CM. Topics . | Required toolkit | HSMs for Sidewalk signing tool | Pre-requisites | Manufacturing workflow overview . | Step 1: Setting up the host | Step 2: Provisioning with CSR and Sidewalk Signing tool | Step 3: Constructing and uploading Sidewalk control logs | . | . ", "url": "/manufacturing/manufacture-provision/#how-to-manufacture-and-bulk-produce-sidewalk-devices", "relUrl": "/manufacturing/manufacture-provision/#how-to-manufacture-and-bulk-produce-sidewalk-devices" },"419": { "doc": "How To Manufacture & Produce Devices", "title": "Required toolkit", "content": "To manufacture your Sidewalk devices with AWS IoT Core for Amazon Sidewalk, a collection of tools run on one or more Ubuntu or Windows-based machines. The following tools are required for mass manufacturing: . | OpenSSL OpenSSL version 1.1.1 or greater. OpenSSL with Ed25519 support is required. | Sidewalk signing tool The Sidewalk signing tool takes a Sidewalk CSR as input for each of the required elliptic curves, and returns a signed certificate chain for the specified EC. To get access to the latest version of the tool, contact Amazon Sidewalk support. The signing tool can run on a single machine or distributed in a client-server setup. Running the tool on a single machine can be useful when testing a single line of manufacturing. When you want multiple clients to use a single HSM, you distribute the tool in a client-server setup. | YubiHSM connector The YubiHSM connector, yubihsm-connector, is a back-end application that’s required to communicate with the HSM token. | Nginx Nginx is a web server that’s required when you’re using the client-server setup. This tool serves as a reverse proxy for the YubiHSM connector. It controls access to the yubihsm-connector, such as mutually authenticated TLS providing a secure connection between the components. | . ", "url": "/manufacturing/manufacture-provision/#required-toolkit", "relUrl": "/manufacturing/manufacture-provision/#required-toolkit" },"420": { "doc": "How To Manufacture & Produce Devices", "title": "HSMs for Sidewalk signing tool", "content": "When manufacturing your Sidewalk devices, each Sidewalk-enabled device that joins the Sidewalk network must be provisioned with a Sidewalk device certificate. The HSM that’s issued for use with the Sidewalk signing tool has these two major components. | The public portions of the device certificates, or the Sidewalk certificate chain. It consists of four certificates up to the Amazon root, and provides a path of valid certificates, or chain of trust, to the Amazon Root CA. After the device certificates have been generated, the public device information must be uploaded to Amazon using control log ingestion. | The private key (DAK), that will be stored in the device. | . For more information, see Device attestation key (DAK). ", "url": "/manufacturing/manufacture-provision/#hsms-for-sidewalk-signing-tool", "relUrl": "/manufacturing/manufacture-provision/#hsms-for-sidewalk-signing-tool" },"421": { "doc": "How To Manufacture & Produce Devices", "title": "Pre-requisites", "content": ". | Printed circuit board assembly (PCBA) with a supported chipset. When testing HSM-based provisioning, you can use a Sidewalk hardware development kit (HDK). | HSM specifically created for your Sidewalk product by Amazon. Amazon can provide multiple HSMs per product, if needed. Each HSM is identified by a unique serial number, YubiHSM SN, that is printed on the side that does not have the USB contacts. For information about purchasing a YubiHSM, see YubiHSM. The number of YubiHSM needed is based on the mode of operation, as described in Step 1: Setting up the host. For more information, see the HSM section. | HSM vendor-provided SDK. For more information, see YubiHSM2 releases. | Sidewalk device profile that’s factory supported and qualified for production. The Sidewalk signing tool requires the APID information from the created profile. | Computer or native machine running Ubuntu 20.04 or Windows 10. | Sidewalk signing tool, which corresponds to the Python script sidewalk-signing-tool.py. To get access to the latest version of the tool, contact Amazon Sidewalk support. | Python interpreter (version 3.8 or above), which is required by the signing tool. | . ", "url": "/manufacturing/manufacture-provision/#pre-requisites", "relUrl": "/manufacturing/manufacture-provision/#pre-requisites" },"422": { "doc": "How To Manufacture & Produce Devices", "title": "Manufacturing workflow overview", "content": "The following describes the steps that are involved in mass manufacturing your Sidewalk devices. You’ll also learn more about the steps that you need to perform and the steps performed by the contract manufacturer (CM) in the manufacturing workflow. You need to create a Sidewalk device profile and obtain factory support so that it’s qualified for production use. The CM then sets up the required tools on the host machines, and runs the Sidewalk signing tool to obtain the certificates and generate the control logs. The CM also uploads these logs to Amazon Sidewalk using EDI or an SFTP endpoint, after which you receive a CSV file. You’ll then upload this CSV file to an S3 bucket and use AWS IoT Core for Amazon Sidewalk to bulk provision your Sidewalk devices. For more information, see How Amazon Sidewalk manufacturing works. | Step 1: Setting up the host . The contract manufacturer (CM) sets up the required tools on the host machines for manufacturing your Sidewalk devices. You don’t need to take any action. | Step 2: Provisioning with CSR and Sidewalk Signing tool . You create a prototype device profile and request the Amazon Sidewalk team to provide factory support. The CM then generates the CSRs, runs the YubiHSM connector in the background, and uses the Sidewalk signing tool to return the encoded and signed Sidewalk certificate chains. | Step 3: Constructing and uploading Sidewalk control logs . The CM then uses the signing tools to generate and consolidate the control logs, which is then uploaded to Amazon Sidewalk using EDI or an SFTP point. You’ll then receive an email with a CSV file attached that contains the status information. | . You can now upload the CSV file received to an S3 bucket and provide the information to AWS IoT Core for Amazon Sidewalk for bulk provisioning. If AWS IoT Core for Amazon Sidewalk finds a match in the serial numbers between the CSV file and the control logs that it receives from Amazon Sidewalk, the corresponding devices are then provisioned. The following sections describe each of these steps in additional detail. ", "url": "/manufacturing/manufacture-provision/#manufacturing-workflow-overview", "relUrl": "/manufacturing/manufacture-provision/#manufacturing-workflow-overview" },"423": { "doc": "How To Manufacture & Produce Devices", "title": "How To Manufacture & Produce Devices", "content": " ", "url": "/manufacturing/manufacture-provision/", "relUrl": "/manufacturing/manufacture-provision/" },"424": { "doc": "Manufacturing", "title": "Manufacturing Amazon Sidewalk devices for mass production", "content": "This section describes how contract manufacturers (CM) can mass manufacture Sidewalk-enabled products. This flow is used when you want to manufacture a large number of devices, such as for bulk production applications. After you manufacture these devices, the control log info can be provided to AWS IoT Core for Amazon Sidewalk for bulk provisioning these devices and onboarding them to AWS IoT. For more information, see Bulk provisioning devices with AWS IoT Core for Amazon Sidewalk in the AWS IoT Core developer guide. This section provides an overview of the different types of provisioning flows, and the onboarding experience for your Sidewalk devices. It details: . | The criteria that a Sidewalk device must meet so that it can be authenticated to join Amazon Sidewalk. | The process that must be followed by developers and contract manufacturers (CM) for provisioning a device to use Amazon Sidewalk, including how to bulk provision Sidewalk-enabled products for manufacturing. | The life cycle of a Sidewalk device or endpoint in the prototyping and manufacturing process. | . If you are using Amazon Sidewalk SDK 1.15 or older, please see here for the legacy manufacturing flow . ", "url": "/manufacturing/#manufacturing-amazon-sidewalk-devices-for-mass-production", "relUrl": "/manufacturing/#manufacturing-amazon-sidewalk-devices-for-mass-production" },"425": { "doc": "Manufacturing", "title": "Sidewalk device provisioning flows", "content": "The following shows the type of flows that can be performed for Amazon Sidewalk devices. This section describes the manufacturing or the mass production flow. For information about the prototyping flow, see Provisioning and registering Sidewalk endpoint for device prototyping. Prototyping flow . The prototyping flow is used to create a Sidewalk prototype device, and is primarily used for testing purposes. When you use this flow with AWS IoT Core for Amazon Sidewalk, you provision devices one at a time, which will help you learn about the workflow and how to prototype your application. To use this flow, you only need to download the certificate JSON and flash them onto your device. Mass production flow . The mass production flow, also known as the manufacturing flow, uses a number of factory tools and is designed for manufacturing in large volumes. This flow is performed by contract manufacturers (CMs) where your devices are manufactured. It combines Factory Diagnostic Firmware, Sidewalk Signing Tool, and Amazon’s Provisioning System to securely issue Sidewalk certificates to devices and register them with Sidewalk cloud services. For more information about accessing the tools, contact Amazon Sidewalk support. The mass production flow can accommodate your operation if you have a large number of Sidewalk devices to onboard. After the devices are manufactured, the control logs are uploaded to Amazon via SFTP or Electronic Data Interchange (EDI) system, and a CSV file containing the Sidewalk manufacturing serial numbers (SMSN) is uploaded to AWS IoT Core for Sidewalk. The CSV file is used to onboard the devices to the AWS Cloud. After this, your devices are provisioned in the Sidewalk network and they can send or receive data. For more information about onboarding the devices in AWS IoT Core for Amazon Sidewalk, see Bulk provisioning devices with AWS IoT Core for Amazon Sidewalk in the AWS IoT Core Developer Guide. ", "url": "/manufacturing/#sidewalk-device-provisioning-flows", "relUrl": "/manufacturing/#sidewalk-device-provisioning-flows" },"426": { "doc": "Manufacturing", "title": "Manufacturing", "content": " ", "url": "/manufacturing/", "relUrl": "/manufacturing/" },"427": { "doc": "Getting Started", "title": "Setting up for connecting Amazon Sidewalk devices", "content": "Before you connect your Sidewalk device, perform the following steps to set up your Sidewalk gateway and the hardware development kit (HDK) for connecting your Sidewalk device. For performing the end-to-end prototyping flow, you must also set up your AWS account and AWS CLI. For more information, see Setting up your account and AWS CLI in the AWS IoT Core Developer Guide. ", "url": "/getting-started/#setting-up-for-connecting-amazon-sidewalk-devices", "relUrl": "/getting-started/#setting-up-for-connecting-amazon-sidewalk-devices" },"428": { "doc": "Getting Started", "title": "Getting Started", "content": " ", "url": "/getting-started/", "relUrl": "/getting-started/" },"429": { "doc": "Events", "title": "Sidewalk Events", "content": " ", "url": "/events/#sidewalk-events", "relUrl": "/events/#sidewalk-events" },"430": { "doc": "Events", "title": "Events", "content": " ", "url": "/events/", "relUrl": "/events/" },"431": { "doc": "On Amazon Sidewalk", "title": "On Amazon Sidewalk qualification", "content": "Amazon requires every Endpoint product that connects to Amazon Sidewalk to comply with the On Amazon Sidewalk Qualification Guidelines. To get the On Amazon Sidewalk badge, the design of the product must pass On Amazon Sidewalk qualification. Test evidence and the qualification fee are submitted to Amazon. For the first year of operation Amazon is waiving qualification fees, although where testing is conducted by an external test facility that facility may charge a fee for test services. If the test evidence passes On Amazon Sidewalk qualification requirements, the product design is granted the On Amazon Sidewalk badge. In case of issues with qualification testing or with the qualification process that may impact the evaluation of an end product’s qualification, Amazon may grant qualification waivers for tests that are affected by the issues in accordance with its qualification waiver policy. The purpose of On Amazon Sidewalk qualification is to test that a certain device or component reference design complies with the Amazon Sidewalk network requirements. On Amazon Sidewalk qualification only tests the Amazon Sidewalk functionality of reference designs. Qualified end products then must be built using the same Amazon Sidewalk functionality as the qualified reference design. Important Please note that you are still responsible for ongoing compliance with the Qualification Guidelines and any other applicable Amazon terms after receiving qualification. The following shows some qualification concepts and the On Amazon Sidewalk qualification process. Topics . | Amazon Sidewalk qualification concepts | On Amazon Sidewalk qualification process | . ", "url": "/qualification/on-amazon-sidewalk/#on-amazon-sidewalk-qualification", "relUrl": "/qualification/on-amazon-sidewalk/#on-amazon-sidewalk-qualification" },"432": { "doc": "On Amazon Sidewalk", "title": "On Amazon Sidewalk", "content": " ", "url": "/qualification/on-amazon-sidewalk/", "relUrl": "/qualification/on-amazon-sidewalk/" },"433": { "doc": "Qualification", "title": "On Amazon Sidewalk qualification", "content": "The On Amazon Sidewalk qualification process checks that product designs comply with Amazon Sidewalk protocol requirements. The On Amazon Sidewalk qualification process helps builders create fit for purpose products reinforcing correct operation of Amazon Sidewalk Endpoints, and the Amazon Sidewalk network as a whole. This builds value for both builders and end users alike. Every Amazon Sidewalk product must be qualified under the On Amazon Sidewalk qualification program, but not every product must go through the testing process. The On Amazon Sidewalk qualification process tests designs. When a reference design passes the On Amazon Sidewalk qualification tests, end products can be built using that design. End products can then be qualified without retest if they meet all the following requirements: . | The Amazon Sidewalk features of the design are not changed. | Any critical security updates are implemented. | The product is registered with the Amazon Sidewalk qualification team. | The company responsible for the product complies with the On Amazon Sidewalk Qualification Guidelines. | The SDK and hardware for the end product have maintained their qualified status. | . Amazon Sidewalk, in its sole discretion, reserves the right to amend the reasons for granting or denying qualification to an end product. Topics . | Amazon Sidewalk qualification FAQs | On Amazon Sidewalk qualification . | Amazon Sidewalk qualification concepts | On Amazon Sidewalk qualification process | . | On Amazon Sidewalk qualification waiver policy | . ", "url": "/qualification/#on-amazon-sidewalk-qualification", "relUrl": "/qualification/#on-amazon-sidewalk-qualification" },"434": { "doc": "Qualification", "title": "Qualification", "content": " ", "url": "/qualification/", "relUrl": "/qualification/" },"435": { "doc": "Introduction", "title": "Introduction to Amazon Sidewalk", "content": "Amazon Sidewalk is a secure community network that uses Amazon Sidewalk Gateways (also called Sidewalk Bridges), such as compatible Amazon Echo and Ring devices, to provide cloud connectivity for IoT endpoint devices. Amazon Sidewalk enables low-bandwidth and long-range connectivity at home and beyond using Bluetooth Low Energy for short-distance communication and LoRa and FSK radio protocols at 900MHz frequencies to cover longer distances. When Amazon Sidewalk Gateway owners opt to participate in the Sidewalk Network, Sidewalk endpoint devices located within the wireless range of this network can be used for applications such as sensing the environment or alerting when a specific condition or event occurs. Amazon Sidewalk supports a diversity of use cases, from connected sensors, utility meters or appliances in and around the home to trackers, tools, toys and monitoring devices that are used in and around neighborhoods and on the go. Amazon Sidewalk transfers data between Sidewalk endpoints and Sidewalk Gateways, and between Sidewalk Gateways and the AWS cloud. The following are features of Amazon Sidewalk: . | Amazon Sidewalk creates a low-bandwidth network using Sidewalk Gateways that include select Ring and Echo devices. The Sidewalk Gateways share a small portion of the user’s internet bandwidth, which is then used to connect endpoints to the network. The strength of Amazon Sidewalk network increases with an increase in the number of gateways. | Amazon Sidewalk offers a secure networking mechanism with multiple layers of encryption. It can be used to connect endpoint devices and objects, even if they are outside the normal range of Wi-Fi communication. | Amazon Sidewalk offers a simple mechanism to enable or disable participation in Sidewalk at any time, from Alexa account settings or Ring Control Center. | . ", "url": "/introduction/#introduction-to-amazon-sidewalk", "relUrl": "/introduction/#introduction-to-amazon-sidewalk" },"436": { "doc": "Introduction", "title": "Introduction", "content": " ", "url": "/introduction/", "relUrl": "/introduction/" },"437": { "doc": "Provisioning and Registration", "title": "Provisioning and registering Sidewalk endpoint for device prototyping", "content": "Sidewalk endpoint devices can be provisioned and registered using either of two flows, the prototyping flow or the manufacturing flow. The prototyping flow is used to create a Sidewalk prototype device, and is primarily used for experimental and testing purposes. The mass production flow, also known as the manufacturing flow, uses a number of factory tools and is designed for manufacturing in large volumes. For more information, see Sidewalk device provisioning flows. The prototyping flow is explained in this section, while the manufacturing flow is described in Manufacturing flow. This section walks through the steps that are part of the prototyping flow for onboarding your Sidewalk devices. In this flow, you provision devices one at a time, which will help you learn more about the flow and prototyping your application. This section focuses on how to connect your device and programmatically run the application on your hardware development kit. You’ll use Python and Python-pip3 to run the scripts that provision the Sidewalk endpoint and connect to the hardware board. After you’ve added your Sidewalk credentials using AWS IoT Core for Amazon Sidewalk, you can provision your Sidewalk endpoints and connect your device. To see messages that are exchanged between your device and the cloud, you register the endpoint and connect your Sidewalk device to the AWS Cloud. The following steps provide information about the prototyping flow and how to provision and register your Sidewalk endpoint. Topics . | Pre-requisites | Step 1: Add your device to AWS IoT Core for Amazon Sidewalk | Step 2: Provision Sidewalk endpoint and flash the binary image | Step 3: Register and test Sidewalk endpoint | . ", "url": "/provisioning/#provisioning-and-registering-sidewalk-endpoint-for-device-prototyping", "relUrl": "/provisioning/#provisioning-and-registering-sidewalk-endpoint-for-device-prototyping" },"438": { "doc": "Provisioning and Registration", "title": "Pre-requisites", "content": "To add your Sidewalk device and destination, and to provision and register your device, perform the following steps. For more information about setting up your account and AWS CLI, see Setting up your account and AWS CLI in the AWS IoT Core Developer Guide. | Set up an AWS account. | Install and configure the AWS CLI to programmatically onboard your devices. | Use a native Ubuntu machine running version 18.04 or higher, or a Windows or Mac machine. You’ll use common Linux commands and software packages, and you’ll need Python3 and pip to run the Sidewalk tools. (Optional) If you want to register your device manually, you’ll also need a Bluetooth wireless interface on your Ubuntu machine or a USB bluetooth adapter. Using a virtual machine is not recommended as there are known compatibility issues. | Use a hardware development kit (HDK) from a third-party vendor, which can be Nordic Semiconductor, Texas Instruments, or Silicon Laboratories. | . ", "url": "/provisioning/#pre-requisites", "relUrl": "/provisioning/#pre-requisites" },"439": { "doc": "Provisioning and Registration", "title": "Step 1: Add your device to AWS IoT Core for Amazon Sidewalk", "content": "Before you can provision your device as a Sidewalk endpoint, you must obtain the device JSON data that’s used by the provisioning script. You obtain this information when adding your device to AWS IoT Core for Amazon Sidewalk. The device JSON contains the following information: . | The device certificates and private keys | The application server public key | The Sidewalk manufacturing serial number (SMSN), which is a unique serial number for each Sidewalk device. | The DeviceTypeID, which is a unique ID to identify the profile that a Sidewalk device is associated with. | . For more information, see Add your device to AWS IoT Core for Amazon Sidewalk in the AWS IoT Core Developer Guide. Next Step: Step 2 - Provision Sidewalk endpoint and flash the binary image . ", "url": "/provisioning/#step-1-add-your-device-to-aws-iot-core-for-amazon-sidewalk", "relUrl": "/provisioning/#step-1-add-your-device-to-aws-iot-core-for-amazon-sidewalk" },"440": { "doc": "Provisioning and Registration", "title": "Provisioning and Registration", "content": " ", "url": "/provisioning/", "relUrl": "/provisioning/" },"441": { "doc": "1. Introduction", "title": "1. Introduction", "content": " ", "url": "/specifications/sidewalk-test-spec/introduction.html", "relUrl": "/specifications/sidewalk-test-spec/introduction.html" },"442": { "doc": "1. Introduction", "title": "1.1 Scope", "content": "This document provides the Amazon Sidewalk reference test cases for certification of compliance with the Amazon Sidewalk specification. 1.1.1 Application . The specification includes test cases for Endpoint products, referred to as the Device Under Test (DUT). At this time there is no requirement for gateway certification, as all gateways on the Amazon Sidewalk network are Amazon devices, such as Echo and Ring products. 1.1.2 Naming Convention . Each test case has a short, unique identifier, and a title. The general format of a test case identifier is: . <AREA>/<ROLE>/<FEATURE>/<FUNCTION>/<CLASS>-<ID> . | <AREA> can be: CMN (Common), BLE, FSK, LORA, or MULTI (multi-radio) | <ROLE> can be: EP (Endpoint), or GW (Gateway, reserved for future use) | <FEATURE> can be: BCN, CONN, DATA, API | <FUNCTION> is <FEATURE> dependent | <CLASS> can be: BV (Behaviour Valid), or BI (Behaviour Invalid) | <ID> is a unique integer to differentiate multiple test cases under the preceding fields | . For example FSK/EP/BCN/JOIN/BV-01 - an FSK Endpoint test case for discovering a beacon, with valid behavior. 1.1.2.1 Behaviour Valid (BV) Tests . These tests verify that the DUT reacts in conformity with the specification when receiving valid message sequences. 1.1.2.2 Behaviour Invalid (BI) Tests . These tests verify that the DUT reacts in conformity with the specification when receiving sequences containing invalid messages, missing messages, messages of incorrect type or content, and is expected to recover and resume the protocol function. ", "url": "/specifications/sidewalk-test-spec/introduction.html#11-scope", "relUrl": "/specifications/sidewalk-test-spec/introduction.html#11-scope" },"443": { "doc": "1. Introduction", "title": "1.2 General Test Requirements", "content": "Each test case has an Expected Results section. In all cases this will describe the criteria for a Pass Verdict. In some cases it may also describe criteria that could lead to an Inconclusive Verdict - this refers to a result that is not recorded as a fail but may indicate an undetected or undesirable condition and should be reviewed. If a DUT cannot achieve a Pass Verdict or Inconclusive Verdict then it is automatically classified as a test failure, however in some cases additional specific details may be provided under Fail Verdict indicating why a test could fail. For example a test that attempts to send 10 data packets may explicitly state that a Fail Verdict is recorded if the Tester receives 9 or fewer packets. ", "url": "/specifications/sidewalk-test-spec/introduction.html#12-general-test-requirements", "relUrl": "/specifications/sidewalk-test-spec/introduction.html#12-general-test-requirements" },"444": { "doc": "1. Introduction", "title": "1.3 Test Environment", "content": "The test specification requires one or two tester “roles” - the Upper Tester and the Lower Tester. These refer to the roles undertaken by the test equipment to drive the upper (top of stack) and lower (bottom of stack) interfaces to the Device Under Test. The roles do not mandate a particular physical implementation of the test equipment. Typically a single piece of test equipment would implement both roles, however for some test cases it may be possible to separate the roles across two independent entities. The DUT lower interface is the radio, therefore the Lower Tester will reproduce the functionality and required behavior of a standard Amazon Sidewalk Gateway. The DUT upper interface is the on-chip Amazon Sidewalk application API (e.g. the sid_init, sid_start etc. API calls). It is the responsibility of the test equipment provider to specify how the Upper Tester role within the test equipment will communicate with the on-chip API (e.g. via command-line interface, binary transport, or some other mechanism). ", "url": "/specifications/sidewalk-test-spec/introduction.html#13-test-environment", "relUrl": "/specifications/sidewalk-test-spec/introduction.html#13-test-environment" },"445": { "doc": "1. Introduction", "title": "1.4 References", "content": "TBD . ", "url": "/specifications/sidewalk-test-spec/introduction.html#14-references", "relUrl": "/specifications/sidewalk-test-spec/introduction.html#14-references" },"446": { "doc": "Provision your Sidewalk endpoint", "title": "Step 2: Provision your Sidewalk endpoint and flash the binary image", "content": "After you’ve added your Sidewalk credentials, you can provision your Sidewalk endpoints and connect your device. Provision your device as a Sidewalk endpoint by using the device profile and wireless device JSON files, wireless_device.json and device_profile.json. For information about how you create these files, see Add your device to AWS IoT Core for Amazon Sidewalk in the AWS IoT Core Developer Guide. This tutorial focuses on how to connect your device and programmatically run the application on your hardware development kit. You’ll use Python and Python-pip3 to run the scripts that provision the Sidewalk endpoint and connect to the hardware board. After you’ve provisioned the endpoint, to see messages that are exchanged between your device and the cloud, you register the endpoint and create a destination for your Sidewalk device. ", "url": "/provisioning/iot-sidewalk-provision-endpoint.html#step-2-provision-your-sidewalk-endpoint-and-flash-the-binary-image", "relUrl": "/provisioning/iot-sidewalk-provision-endpoint.html#step-2-provision-your-sidewalk-endpoint-and-flash-the-binary-image" },"447": { "doc": "Provision your Sidewalk endpoint", "title": "Generate binary image", "content": "The following steps show how to generate the binary image that will be flashed on the hardware. Install the requirements file . Use Python-pip3 to install the requirements file from the provision folder in your Sidewalk SDK. You’ll require this file to be installed to be able to run the provision.py script in the next step to generate the image. Go to the Sidewalk SDK folder $[Amazon Sidewalk repository]/tools/scripts/public/provision/, and then run the following command to install the requirements file. pip3 install -r requirements.txt . Generate the manufacturing binary image . Run the provision.py script to generate the manufacturing binary image file that will be used to provision the development board that you are using as a Sidewalk endpoint. How you generate the image can vary depending on the hardware development kit (HDK) that you’re using. Nordic Semiconductor HDK . If you’re using a HDK from Nordic Semiconductor, run the provisioning script using the device JSON files obtained from the previous steps and the configuration file for your HDK. The output of running the script is the manufacturing binary image, which you can name as mfg.bin. The following shows examples of generate the manufacturing binary image, mfg.bin. | If you’re using the combined device JSON file that you obtained from the AWS IoT console, use the certificate_json parameter to specify this file as input when running the provisioning script. python3 provision.py nordic aws --output_bin mfg.bin \\ --certificate_json certificate.json \\ --addr 0xFF000 . | If you’re using the separate device JSON files that you obtained as responses from the GetDeviceProfile and GetWirelessDevice API operations, use the wireless_device_json and device_profile_json parameters to specify these files as input when running the provisioning script. python3 provision.py aws --output_bin mfg.bin \\ --wireless_device_json wireless_device.json \\ --device_profile_json device_profile.json \\ --addr 0xFF000 . | . Silicon Laboratories HDK . If you’re using an HDK from Silicon Laboratories, first export the path to the binary file for the Simplicity Commander tool, [Path to commander bin file]. You must then specify the MCU series chip, [Silabs mcu series], that you’re using. Specify the value xg21 for bg21 and xg24 for the bg24 MCU series chip. The output of running the provisioning script is the file, mfg.s37. The following examples show how to generate this file. | If you’re using the combined device JSON file that you obtained from the AWS IoT console, specify the certificate.json file. export COMMANDER_BIN_PATH=[Path to commander bin file] ./script/provision_silabs_aws.sh [Silabs mcu series] certificate.json . | If you’re using the separate device JSON files that you obtained using the GetDeviceProfile and GetWirelessDevice API operations, specify the device_profile.json and wireless_device.json files. export COMMANDER_BIN_PATH=[Path to commander bin file] ./script/provision_silabs_aws.sh [Silabs mcu series] device_profile.json wireless_device.json . | . STMicroelectronics HDK . If you’re using a HDK from STMicroelectronics, run the provisioning script using the device JSON files obtained from the previous steps and the configuration file for your HDK. The output of running the script is the manufacturing binary image, which you can name as mfg.bin. The following shows examples of generate the manufacturing binary image, mfg.bin. | If you’re using the combined device JSON file that you obtained from the AWS IoT console, use the certificate_json parameter to specify this file as input when running the provisioning script. python3 provision.py st aws --output_bin mfg.bin \\ --certificate_json certificate.json \\ --chip <target chip name> . with either WBA65xI or WBA55xG . | If you’re using the separate device JSON files that you obtained as responses from the GetDeviceProfile and GetWirelessDevice API operations, use the wireless_device_json and device_profile_json parameters to specify these files as input when running the provisioning script. | . python3 provision.py st aws --output_bin mfg.bin \\ --wireless_device_json wireless_device.json \\ --device_profile_json device_profile.json \\ --chip <target chip name> . with either WBA65xI or WBA55xG . Texas Instruments HDK . If you’re using a HDK from Texas Instruments, run the provisioning script using the device JSON files obtained from the previous steps and the configuration file for your HDK. The output of running the script is the manufacturing binary image, which you can name as mfg.bin. The following shows examples of generate the manufacturing binary image, mfg.bin, for P7 board: . | If you’re using the combined device JSON file that you obtained from the AWS IoT console, use the certificate_json parameter to specify this file as input when running the provisioning script. python3 provision.py ti aws --output_bin mfg.bin \\ --certificate_json certificate.json \\ --chip P7 . | If you’re using the separate device JSON files that you obtained as responses from the GetDeviceProfile and GetWirelessDevice API operations, use the wireless_device_json and device_profile_json parameters to specify these files as input when running the provisioning script. python3 provision.py ti aws --output_bin mfg.bin \\ --wireless_device_json wireless_device.json \\ --device_profile_json device_profile.json \\ --chip P7 . | . ", "url": "/provisioning/iot-sidewalk-provision-endpoint.html#generate-binary-image", "relUrl": "/provisioning/iot-sidewalk-provision-endpoint.html#generate-binary-image" },"448": { "doc": "Provision your Sidewalk endpoint", "title": "Flash binary image", "content": "To flash the manufacturing binary image onto your HDK, which is the Sidewalk endpoint, use the provision.py script and the device certificates in the working directory that contains the keys. For information about how to flash the image on your hardware development kit, see the vendor documentation as described below. To make flashing easier using JLINK, you might want use the .hex file that provision.py generates as well instead of using binary. Nordic Semiconductor Login to the Nordic Semiconductor website, or create your account, and request permission to download the Amazon Sidewalk documentation and hardware and software development resources. The download instructions will be sent to your email address when approved. To flash the binary image, use the address 0xFF000 for loading the binary image on the Nordic Semiconductor HDK. For information about flashing the binary image, see the Nordic Semiconductor documentation. Silicon Laboratories Login to the Silicon Laboratories website, or create your account, and open a support case that requests for GitHub access permission to download the Amazon Sidewalk documentation and hardware and software development resources. When requesting access, specify your GitHub account that links to your corporate email address. Information about the address for loading the binary file for Silicon Laboratories is already in provision/scripts/*.sh. For information about flashing the binary file, see the Silicon Laboratories documentation. STMicroelectronics . Go to the STMicroelectronics’s Amazon Sidewalk GitHub repository and download the Amazon Sidewalk documentation and hardware and software development resources. For information about flashing the binary files, see the documentation in the README.md . Texas Instruments Login to the Texas Instruments website, or register, and request for access permission to download the Amazon Sidewalk documentation and hardware and software development resources. The download instructions will be sent to your email address when approved. To flash the binary image, use the following address information for loading the binary image on the Nordic Semiconductor HDK. | Texas Instruments P1 board: 0x56000 | Texas Instruments P7 board: 0xAE000 | . For information about flashing the binary image, see the Texas Instruments documentation. After you’ve flashed the image onto the hardware, you register your device as a Sidewalk endpoint and add a Sidewalk destination. You then test the connectivity, exchange messages, and prototype your application on the hardware board. Next Step: Step 3 - Register and test Sidewalk endpoint . ", "url": "/provisioning/iot-sidewalk-provision-endpoint.html#flash-binary-image", "relUrl": "/provisioning/iot-sidewalk-provision-endpoint.html#flash-binary-image" },"449": { "doc": "Provision your Sidewalk endpoint", "title": "Provision your Sidewalk endpoint", "content": " ", "url": "/provisioning/iot-sidewalk-provision-endpoint.html", "relUrl": "/provisioning/iot-sidewalk-provision-endpoint.html" },"450": { "doc": "Quick Start Guide", "title": "Try the sensor monitoring tutorial", "content": "The sensor monitoring application demonstrates a set of simple Sidewalk-based IoT use-cases: sensor monitoring, command-control and alarms/alerts. The sample application communicates with the cloud backend over the secure Sidewalk network. The Amazon Sidewalk Sample IoT application consists of an edge device (A qualified hardware development kit) running the embedded application and application server (cloud backend with web UI). The Edge device, after initial setup and registration in Sidewalk network, sends the temperature measurement periodically to the backend. The backend visualizes the data on graphical UI in a form of chart. For detailed instructions including pre-requisites and configurations, see Amazon Sidewalk Sample IoT Application Tutorial. In this tutorial, scripts are used to programmatically add a Sidewalk destination, launch the application, create the required wireless resources, and then connect the edge device to the application after flashing the binary images on the HDK. ", "url": "/getting-started/iot-sidewalk-qsg-tutorial.html#try-the-sensor-monitoring-tutorial", "relUrl": "/getting-started/iot-sidewalk-qsg-tutorial.html#try-the-sensor-monitoring-tutorial" },"451": { "doc": "Quick Start Guide", "title": "Quick Start Guide", "content": " ", "url": "/getting-started/iot-sidewalk-qsg-tutorial.html", "relUrl": "/getting-started/iot-sidewalk-qsg-tutorial.html" },"452": { "doc": "Register and test your Sidewalk endpoint", "title": "Step 3: Register and test your Sidewalk endpoint", "content": "After you’ve provisioned the Sidewalk endpoint, the endpoint must be registered so that it can communicate over the Sidewalk network. In this tutorial, you’ll learn about registering the endpoint. ", "url": "/provisioning/iot-sidewalk-register-endpoint.html#step-3-register-and-test-your-sidewalk-endpoint", "relUrl": "/provisioning/iot-sidewalk-register-endpoint.html#step-3-register-and-test-your-sidewalk-endpoint" },"453": { "doc": "Register and test your Sidewalk endpoint", "title": "Sidewalk registration methods", "content": "To register your Sidewalk endpoint, use automatic touchless registration with Sidewalk Frustration Free Networking (FFN). The following table describes the attributes of automatic touchless registration. FFN registration . | Criteria | Automatic registration (using Sidewalk FFN) | . | User and endpoint association | This registration method doesn’t require any association between the Sidewalk endpoint and a user. The endpoint can join the Sidewalk network without being associated with any user. | . | Links Supported | BLE and FSK | . | LWA (Login with Amazon) | LWA is not required. | . ", "url": "/provisioning/iot-sidewalk-register-endpoint.html#sidewalk-registration-methods", "relUrl": "/provisioning/iot-sidewalk-register-endpoint.html#sidewalk-registration-methods" },"454": { "doc": "Register and test your Sidewalk endpoint", "title": "Automatic touchless registration using Sidewalk FFN", "content": "Automatic touchless registration using Sidewalk frustration-free networking (FFN) is a registration process that automatically registers your Sidewalk endpoint, either over BLE or FSK. The registration process starts automatically when your Sidewalk gateway and your unregistered endpoint are in range of each other using the specific link. Set up to view FFN logs To view the logs for the FFN registration process, follow these steps. For more information, see Set up for testing your Sidewalk device. | Connect the hardware development kit (HDK) to your computer using USB. | Power cycle the hardware by toggling the USB switch, and then power it on. | Connect to your hardware by following the instructions in the vendor documentation. | . How FFN works To perform registration using Sidewalk FFN: . | Your Sidewalk gateway and endpoint must be powered on. | Your gateway must be opted into Sidewalk, and in close range to your endpoint. We recommend that you keep the devices within the range of link chosen (either BLE or FSK) between each other. | . The registration process will start automatically, and a successful registration is indicated with Registration Status of zero, as seen in this log output. The Time Sync Status of zero indicates a successful time sync. ≪info> app: Registration Status = 0, Time Sync Status = 0 and Link Status = 0 . If you don’t see this output, try either of the following steps: . | Confirm that your Sidewalk endpoint is powered on. If needed, reboot your Sidewalk endpoint. | Confirm that your Sidewalk gateway is powered on, has internet connection, and is registered to a user with Sidewalk consent enabled. If needed, reboot your Sidewalk gateway and wait for 10 minutes for the gateway to be ready to retry the registration process. | . De-register your Sidewalk endpoint In certain cases, you might want to de-register your Sidewalk endpoint. For example, when testing the registration process multiple times, you must de-register your Sidewalk endpoint before attempting to re-register it. De-registering your Sidewalk endpoint requires a two-way message exchange between the endpoint, gateway, and the cloud. To avoid any out-of-sync issues between your endpoint and the cloud, your Sidewalk gateway must be powered on, and in range of the registered endpoint. You use the AWS API to de-register the endpoint. To de-register, run the following curl command. Replace: . | AWS_ACCESS_KEY and AWS_SECRET_KEY with the credentials you obtained when setting up your account and configuring the AWS CLI. | WIRELESS_DEVICE_ID with the ID of your Sidewalk device. | . curl -X PATCH \"https://api.iotwireless.us-east-1.amazonaws.com/wireless-devices/WIRELESS_DEVICE_ID/deregister?WirelessDeviceType=Sidewalk\" --user <AWS_ACCESS_KEY>:<AWS_SECRET_KEY> --aws-sigv4 \"aws:amz:us-east-1:iotwireless\" . A successful de-registration is indicated by a status of 200 or 202, and will have the following log output: . <info> app: Registration Status = 1, Time Sync Status = 1 and Link Status = 1 . ", "url": "/provisioning/iot-sidewalk-register-endpoint.html#automatic-touchless-registration-using-sidewalk-ffn", "relUrl": "/provisioning/iot-sidewalk-register-endpoint.html#automatic-touchless-registration-using-sidewalk-ffn" },"455": { "doc": "Register and test your Sidewalk endpoint", "title": "Set up for testing your Sidewalk device", "content": "To view the logs for testing your Sidewalk device, perform the following steps to connect to your HDK, and to connect your Sidewalk device. | Connect the HDK to your computer using a USB cable. | Power cycle the hardware by toggling the switch that’s situtated beside the USB port on the HDK, and then set it to the ON position. | Connect to your hardware by following the instructions in the documentation for your HDK. One way to connect to the device and view log messages is using telnet. | For Nordic Semiconductor’s HDK, see the Nordic Semiconductor documentation. | For Silicon Laboratories’ HDK, see the Silicon Laboratories documentation. | For STMicroelectronics’s HDK, see the STMicroelectronics documentation. | For Texas Instruments’ HDK, see the Texas Instruments documentation. | . | To connect your device to the AWS Cloud and view messages that are exhanged between your device and the cloud, you must create a Sidewalk destination. A destination describes the AWS IoT rules that process and route messages between your devices and other AWS services and other applications. For more information about adding a destination, see Add a destination to AWS IoT Core for Amazon Sidewalk in the AWS IoT Core Developer Guide. | . ", "url": "/provisioning/iot-sidewalk-register-endpoint.html#set-up-for-testing-your-sidewalk-device", "relUrl": "/provisioning/iot-sidewalk-register-endpoint.html#set-up-for-testing-your-sidewalk-device" },"456": { "doc": "Register and test your Sidewalk endpoint", "title": "Register and test your Sidewalk endpoint", "content": " ", "url": "/provisioning/iot-sidewalk-register-endpoint.html", "relUrl": "/provisioning/iot-sidewalk-register-endpoint.html" },"457": { "doc": "8.3 Join and Network Sync Procedures", "title": "8.3 Join and Network Sync Procedures", "content": "Join process establishes a connection with the Amazon Sidewalk Cloud through the Sidewalk Relay. This process involves a secure command exchange, namely Join-Req Message on the uplink and Join-Resp Message on the downlink, following Network Encryption Model. Via this packet exchange, the Endpoint: . | notifies the Amazon Sidewalk Cloud that the Endpoint is active and connected through Sidewalk Relay or Sidewalk Relays; | notifies the Amazon Sidewalk Cloud that it is using a chosen communication mode, profile and parameters indicated through the payload of Join-Req Message; | checks the existence of a bidirectional communication path between the cloud and the Endpoint. | . The Join-Req Message and Join-Resp Message exchange is performed not only the first time the Endpoints joins Amazon Sidewalk but also periodically thereafter. The initial exchange is called a Network Join and the periodical exchanges are referred to as Network Sync. The information carried in the command payload varies depending on the use case, i.e. Network Join or Network Sync, as well as the Amazon Sidewalk communication mode and profile configuration of the Endpoint. The contents of Join-Req Message and Join-Resp Message are listed in Table 3.1 and Table 3.2, respectively. The command payloads are encoded using a TLV(type-length-value) format. The type field indicates the type of information content, the length field indicates the size of the information content, and the value is the payload. 8.3.1 Join Request . 8.3.2 Join Request and retries . fig 8.5 Join Request no response . The Endpoint needs to complete the join process before reporting a connected status to the application. After sending a Join-Req Message, the Endpoint waits for a Join-Resp Message and if not received within a timeout interval, repeats the process. The timeout interval is 20 s for SubG-CSS connection mode and a random value [between 20 s and 30 s] for SubG-FSK connection mode. The flow chart specifies the commands sequence that shall be exchanged between the Endpoint and the Amazon Sidewalk Cloud to handle the lack of RESP_JOIN_REQUEST for the SET_JOIN_REQ on the Endpoint side. The procedure is as follows: . | The Endpoint transmits the SET_JOIN_REQ command. | The Endpoint waits for the RESP_JOIN_REQ: . | if the response from the cloud is received by the Endpoint then it finishes the commands exchange successfully | if the response from the cloud is not received by the Endpoint then . | if the number of SET_JOIN_REQ commands sent subsequently is less than three then wait for join_req_timeout time and continue from bullet 1 | if the number of SET_JOIN_REQ commands sent subsequently is equal to three then go to bullet 3 | . | . | There is no response for three subsequent SET_JOIN_REQ commands so the procedure is stopped with failure. | . A maximum of three consecutive failures or receiving a Join-Resp Message with a failure code leads to a failure to join indication. Handling of this failure varies depending on the connection mode: . | in the case of SubG-FSK connection mode, the device returns to the Link Connection Establishment Phase by triggering a new Gateway Discovery for finding a new Sidewalk Relay; and | in the case of SubG-CSS connection mode, the device stays in a disconnected state until a new join procedure is triggered by the user application via sid_start API. | . fig 8.6 Power profile parameter change . 8.3.3 Connection Profile parameters change . Commands SET_JOIN_REQ and RESP_JOIN_REQ are not only used in section 8.1. This set of commands shall be used every time the Power Profile configuration is changed on the Endpoint side. It shall also be used in case when the Power Profile is changed - e.g. the Endpoint switches from Profile A to Profile B. ", "url": "/specifications/sidewalk-protocol-spec/procedures-and-flow-charts/join-and-network-sync-procedures.html", "relUrl": "/specifications/sidewalk-protocol-spec/procedures-and-flow-charts/join-and-network-sync-procedures.html" },"458": { "doc": "4.4 Key establishment", "title": "4.4 Key establishment", "content": "The key establishment process contains two stages: factory provisioning and registration. During the factory provisioning stage, hardware devices (Gateways and Endpoints) are provisioned with Amazon Sidewalk certificates and initial credentials. During the registration stage, hardware devices (Gateways and Endpoints) are associated and registered to a user. 4.4.1 Key assignment stages (initiating, storing discarding) . During obligatory device provisioning in the factory, initial credentials are stored on the device and the device is logged in manufacturing control logs. AWS consumes the control logs to allow devices to register with the network. The next mandatory stage for each device is owner provisioning. During owner provisioning the device is authenticated and its status is updated in AWS Cloud Services. During the device’s lifetime its ownership can be changed, device software can be updated, and the device can be deregistered, or blocked. If any of the above changes are made to the device, the relevant credentials are updated or removed. Separate security procedures are implemented for each of the following cases: . | Factory (Gateway, Endpoint) provisioning: During this stage all credentials are flashed on the device. | Gateway owner provisioning: During this stage the device is authenticated in the network and network credentials are updated. | Endpoint owner provisioning: During this stage device is authenticated in the network. | Endpoint changing ownership (this is beyond the scope of this specification). | Device deregistration, blocklist (this is beyond the scope of this specification). | Application software upgrade. (This is beyond the scope of this specification.) | Firmware upgrade (This is beyond the scope of this specification.) | . 4.4.1.1 Factory provisioning . A provisioning process in the mass production flow is triggered by the Contract Manufacturer that manufactures devices. This flow is driven by a number of factory tools and is designed for high volume manufacturing scenarios. This flow combines Factory Diagnostic Firmware, Amazon Sidewalk Signing Tool, Amazon Sidewalk Provisioning Tool, and Amazon Sidewalk Control Logs to issue Amazon Sidewalk certificates to devices and register them with Amazon Sidewalk Cloud Services. A device being provisioned is connected to the Contract Manufacturer’s configuration system (hardware and software for data load, inventory management and unit calibration) and is also connected by an encrypted link to the Amazon Sidewalk Cloud. Device keys are signed by the Amazon Sidewalk signing tool using the HSM. Depending on the manufacturing needs, signing device keys can be done directly from the line PC, or by establishing a signing server on the local area network. The Amazon Sidewalk provisioning signing tool requests certificates after reading the Device Serial Number. Device certificates and signatures are generated based on received data EC key pairs (Ed25519 and p256r1). Device certificates and signatures are stored in device-persistent memory (flash). After certificates and signatures have been stored in the device, the Amazon Sidewalk Manufacturing Serial Number (SMSN), public keys and signatures are registered in the cloud by Amazon Sidewalk Cloud Services. Each of the keys are signed by the Amazon Sidewalk Provisioning Tool during provisioning and flashed to the device by J-Link along with the rest of the certificate chain.Figure 4.7 shows the process flow. fig 4.7 Factory provisioning . The manufacturing page is a region in the internal memory that is reserved for various values to be written during the manufacturing of a device. Fields may be written to the manufacturing page either using a diagnostic version of the firmware or using the J-Link interface. Command line tools provided by the silicon vendor are used to write on the J-Link interface. The following table summarizes the list of security items that need to be present on the device manufacturing page: . Table 4.6 Security items in hardware device . | Required Field | Description | . | SID_MFG_STORE_VERSION | Version of the manufacturing storage block format. | . | SID_MFG_STORE_DEV_ID | Sidewalk ID. The Sidewalk ID includes a size field in the first 3 most significant bits, so the unique Device IDs should be no larger than (2^37 - 1) and the first 3 most significant bits should be hard coded to 0b101. | . | SID_MFG_STORE_HW_MODEL_AND_VERSION | Hardware model and version number. This is a silicon vendor-specific value that is used by the boot loader to determine if a firmware package that is about to be loaded is compatible with the device. Each model of hardware shall use a different value. If a new hardware revision of the same model needs to run a different version of firmware, the hardware version byte shall be increased. 3B hardware model 1B hardware version | . | SID_MFG_STORE_BOARD_ID | Board ID | . | SID_MFG_STORE_SERIAL_NUM | Serial number of device. | . | SID_DEVCFG_DEVICE_PRIV_ED25519SID_DEVCFG_DEVICE_PUB_ED25519SID_DEVCFG_DEVICE_PUB_ED25519_SIGNATURE | Unique per device curve Ed25519 key pair, and signature (see: SID device authentication, SID key and signature generation) | . | SID_DEVCFG_DEVICE_PRIV_P256R1SID_DEVCFG_DEVICE_PUB_P256R1SID_DEVCFG_DEVICE_PUB_P256R1_SIGNATURE | Unique per device curve p256r1 key pair, and signature (see: SID device authentication, SID key and signature generation) | . | SID_DEVCFG_MODEL_PUB_ED25519SID_DEVCFG_MODEL_PUB_ED25519_SIGNATURESID_DEVCFG_MODEL_ED25519_SERIAL | Model device curve Ed25519 key pair, and signature (see: SID device authentication, SID key and signature generation) | . | SID_DEVCFG_MODEL_PUB_P256R1SID_DEVCFG_MODEL_PUB_P256R1_SIGNATURESID_DEVCFG_MODEL_P256R1_SERIAL | Model curve p256r1 key pair and signature (see: SID device authentication, SID key, and signature generation) | . | SID_DEVCFG_MAN_PUB_ED25519SID_DEVCFG_MAN_PUB_ED25519_SIGNATURESID_DEVCFG_MAN_ED25519_SERIAL | Product Manufacturer curve Ed25519 key pair and signature (see: SID device authentication, SID key and signature generation) | . | SID_DEVCFG_MAN_PUB_P256R1SID_DEVCFG_MAN_PUB_P256R1_SIGNATURESID_DEVCFG_MAN_P256R1_SERIAL | Product Manufacturer curve p256r1 key pair, and signature (see: SID device authentication, SID key and signature generation) | . | SID_AMZN_PUB_ED25519 | Amazon Ed25519 public key | . | SID_AMZN_PUB_P256R1 | Amazon p256r1 public key | . | SID_MFG_STORE_FW_KEY1SID_MFG_STORE_FW_KEY1_Signature | Production Public Key #1 and signature used to check FW signatures. This key must be the same for every device that runs the same firmware. see: SID key and signature generation | . | SID_MFG_STORE_FW_KEY2SID_MFG_STORE_FW_KEY2_SIGNATURE | Production Public Key #2 and signature used to check FW signatures. This key must be the same for every device that runs the same firmware. see: SID key and signature generation | . | SID_MFG_STORE_FW_DEV_KEYSID_MFG_STORE_FW_DEV_SIGNATURE | Development Public Key and signature used to check FW signatures. This key must be the same for every device that runs the same firmware. see: SID key and signature generation | . | SID_DHAv2_REGION_ADDRESS | DHAv2 region start address. The address should be at the beginning of the page | . | SID_DHAv2_REGION_SIZE | DHAv2 Region Size | . | SID_DHAv2_PID | Defined by Amazon and assigned to a product during product onboarding. SID_DHAv2_PID is unique to every product even for multiple products from the same manufacturer. This is alphanumeric and 4 characters in length. ASCII encoded. This location is used for devices that do not have the DHAv2 page extension. | . | SID_DHAV2_PIN | ASCII encoded secret PIN used for DHAv2 Registration. This location is used for devices that do not have the DHAv2 page extension. | . | SID_MFG_STORE_TEST_MASTER_HW_ID | Lower 32 bits of Bluetooth MAC of master device that controlled the RF testing of this device. | . | SID_MFG_STORE_REG_ISO_COUNTRY | String containing two characters that determines the default country where the device is certified to operate. In ISO 3166-2 | . | APP_MFG_STORE | Device-specific manufacturing value storage not specified by Sidewalk. (ie calibration values for sensors, etc.) | . | SID_MFG_STORE_CRC | Calculated over Amazon Sidewalk manufacturing storage. (words 0-1022) | . 4.4.2 Device registration . Devices are required to register before using Amazon Sidewalk. During registration the device is authenticated. 4.4.2.1 Gateway registration . As Amazon Sidewalk Gateways are based on Amazon and Ring product devices, an Amazon or Ring user account is required to register the product. To use an Amazon or Ring account requires configuring local Internet access. Amazon Sidewalk registration happens automatically once the user has signed in and registered the Gateway product. As part of Amazon Sidewalk registration, the Gateway establishes an encrypted connection with the Amazon Sidewalk Cloud, providing an authenticated connection. 4.4.2.2 Endpoint registration . The release described in this specification supports Endpoint registration via BLE and FSK can also be used. An Endpoint can be registered using a mobile application leveraging the Amazon Sidewalk mobile SDK. An Amazon registered user with a dedicated mobile application connects to Sidewalk Cloud Services and to the device while it is in Out Of the Box Experience (OOBE) mode and provides the device ID to register. During this stage security is set up and a connection with the Client’s API is established. The Endpoint connects to the Mobile Application with default settings and further configuration proceeds. Then the authenticated link between AWS Cloud Services and the Endpoint is associated, the Endpoint is bound to the user Gateway and necessary credentials are established. The following diagram summarizes the sequence flow: . fig 4.8 EN registration part 1 . fig 4.9 EN registration part 2 . ", "url": "/specifications/sidewalk-protocol-spec/security/key-establishment.html", "relUrl": "/specifications/sidewalk-protocol-spec/security/key-establishment.html" },"459": { "doc": "4.5 Key management", "title": "4.5 Key management", "content": "Each of the links is protected by an ECDH key exchange process. Initially key pairs and certificates are built and stored in the device and in the relevant link termination point during the manufacturing provisioning process. For more information, see section 4.4.1.1. For the application link, the Application Server initiates key exchange. For the Flex Layer link and the Network Layer link that terminate in the Network Server, the Network Server initiates key exchange. 4.5.1 Session Key exchange . The Network Server generates the ephemeral key pair and exchanges its public key with the Endpoint. The Endpoint generates the ephemeral key pair and exchanges its public key with the Network Server. the Network Server and the Endpoint generate the shared secret key using ECDH. The Network Server and the Endpoint use a predefined formula to generate the symmetric secret key from the shared secret. This symmetric secret key is the NETWORK_PRIMARY_KEY. The Network Server generates a temporary key from the NETWORK_PRIMARY_KEY. The Network Server uses the temporary key to encrypt a payload, then the payload is sent to the Endpoint for validation. The Endpoint decrypts the encrypted packet and verifies the content. If the Endpoint successfully decrypts and verifies the content, the Endpoint sends an uplink message to the Network Server with an encrypted packet indicating successful verification. If the Network Server receives the uplink packet, the Network Server decrypts the encrypted portion and validates it against the payload content sent on the downlink. If verification is successful, both the Network Server and the Endpoint save the NETWORK_PRIMARY_KEY to a database record. 4.5.2 Gateway Primary Key Negotiation . For SubG-FSK and SubG-CSS, the Gateway primary key is derived during Gateway registration. The Gateway primary key is used to encrypt the exchange between a Gateway and the Amazon Sidewalk Network Server. The Gateway primary key is used to encrypt the inner Flex Layer. The outer Flex Layer is not encrypted. For BLE-enabled Gateways, a TLS session is used instead of the outer Flex Layer. The following diagram describes the key exchange flow between a Gateway and the Amazon Sidewalk Network Server: . fig 4.10 Key exchange (KEX) flow . ", "url": "/specifications/sidewalk-protocol-spec/security/key-management.html", "relUrl": "/specifications/sidewalk-protocol-spec/security/key-management.html" },"460": { "doc": "Location Resolution", "title": "Amazon Sidewalk Location Resolution", "content": "This application note describes how each Amazon Sidewalk location resolution mechanism works: what the device contributes, how Amazon Sidewalk resolves it into a position, and what drives accuracy and failure. For the device-side API and how a device selects and sequences mechanisms, see the Amazon Sidewalk API User Guide. Amazon Sidewalk resolves location through the following mechanisms: . | Level | Mechanism | Resolved by | . | L1 | BLE gateway location | Amazon Sidewalk, from the gateway’s known position | . | L2 | FSK gateway location | Amazon Sidewalk, from the gateway’s known position | . | L3 | WiFi scan | AWS IoT Wireless, from an access-point database | . | L4 | GNSS scan | AWS IoT Wireless, from satellite data | . | L5 | LoRa MLAT | Amazon Sidewalk, by multilateration across gateways | . The L-number identifies the mechanism; it is not a ranking of power cost (LoRa MLAT at L5, for instance, is lower power than the GNSS scan at L4). ", "url": "/app-notes/location-library/location-resolution.html#amazon-sidewalk-location-resolution", "relUrl": "/app-notes/location-library/location-resolution.html#amazon-sidewalk-location-resolution" },"461": { "doc": "Location Resolution", "title": "Where Resolution Happens", "content": "For every mechanism the device contributes a signal or a measurement and the position is resolved off-device. Mechanisms fall into two families, by where that resolution happens. Resolved by AWS IoT Wireless (L3, L4). For a WiFi or GNSS scan, Amazon Sidewalk forwards the scan to the AWS IoT Wireless position-estimate service, which returns the coordinates. Resolved within Amazon Sidewalk (L1, L2, L5). For all other mechanisms Amazon Sidewalk computes the position itself: . | A BLE or FSK uplink is resolved from the receiving gateway’s known position. | A LoRa uplink is multilaterated across the gateways that heard it. | . When resolution fails, no location is produced for that attempt. Each of the following pages covers one mechanism. ", "url": "/app-notes/location-library/location-resolution.html#where-resolution-happens", "relUrl": "/app-notes/location-library/location-resolution.html#where-resolution-happens" },"462": { "doc": "Location Resolution", "title": "Location Resolution", "content": " ", "url": "/app-notes/location-library/location-resolution.html", "relUrl": "/app-notes/location-library/location-resolution.html" },"463": { "doc": "13. Location Service MCU Test Cases", "title": "13. Location Service MCU Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html" },"464": { "doc": "13. Location Service MCU Test Cases", "title": "13.1 CMN-EP-LOCATIONSERVICE-BLELOCATION-BV-01: Send location when there is BLE gateway.", "content": "13.1.1 Test Purpose . Verify EN send a location uplink at level 1. 13.1.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE or BLE+LoRa mode. | The Sidewalk stack (BLE or BLE+LoRa) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 13.1.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 1(on BLE stack) or Link Mask 5(on BLE+LoRa stack), BLE connected Upper_Tester->>DUT: location init Upper_Tester->>DUT: location send 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: BLE_LOCATION_RESOLUTION_CMD Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 13.1.4 Expected Results . 13.1.4.1 Pass Verdict . Device can send location via BLE uplink using Sidewalk Network location. ", "url": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#131-cmn-ep-locationservice-blelocation-bv-01-send-location-when-there-is-ble-gateway", "relUrl": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#131-cmn-ep-locationservice-blelocation-bv-01-send-location-when-there-is-ble-gateway" },"465": { "doc": "13. Location Service MCU Test Cases", "title": "13.2 CMN-EP-LOCATIONSERVICE-BLELOCATION-BV-02: Send location with piggybacking.", "content": "13.2.1 Test Purpose . Verify EN send a location uplink at level 1 via piggybacking. 13.2.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE or BLE+LoRa mode. | The Sidewalk stack (BLE or BLE+LoRa) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 13.2.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 1(on BLE stack) or Link Mask 5(on BLE+LoRa stack), BLE connected Upper_Tester->>DUT: location init Upper_Tester->>DUT: location send 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: 1B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (1B of Command data with location data) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 13.2.4 Expected Results . 13.2.4.1 Pass Verdict . Device can send location via BLE uplink using Sidewalk Network location via piggybacking. ", "url": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#132-cmn-ep-locationservice-blelocation-bv-02-send-location-with-piggybacking", "relUrl": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#132-cmn-ep-locationservice-blelocation-bv-02-send-location-with-piggybacking" },"466": { "doc": "13. Location Service MCU Test Cases", "title": "13.3 CMN-EP-LOCATIONSERVICE-WIFILOCATION-BV-01: Send location when there are enough Wi-Fi Access points.", "content": "13.3.1 Test Purpose . Verify EN send a location uplink at level 3. 13.3.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE, LoRa or BLE+LoRa mode. | The Sidewalk stack (BLE, LoRa or BLE+LoRa) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | SidewalkNetworkFlag is enabled on the Lower Tester. | There is one Wi-Fi Access point nearby at least. | . 13.3.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 1(on BLE stack) or Link Mask 3(on LoRa stack) or Link Mask 5(on BLE+LoRa stack) Upper_Tester->>DUT: location init Upper_Tester->>DUT: location send 3 DUT->>Upper_Tester: WIFI_LOCATION_RESOLUTION_RESULT DUT->>Lower_Tester: WIFI_LOCATION_RESOLUTION_SEND_COMPLETE Lower_Tester->>DUT: WIFI_LOCATION_RESOLUTION_COMPLETE_ACK(if EN is linked on LoRa link only) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 13.3.4 Expected Results . 13.3.4.1 Pass Verdict . Device can resolve and send location using Wi-Fi Access points location. ", "url": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#133-cmn-ep-locationservice-wifilocation-bv-01-send-location-when-there-are-enough-wi-fi-access-points", "relUrl": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#133-cmn-ep-locationservice-wifilocation-bv-01-send-location-when-there-are-enough-wi-fi-access-points" },"467": { "doc": "13. Location Service MCU Test Cases", "title": "13.4 CMN-EP-LOCATIONSERVICE-WIFILOCATION-BV-02: Scan location when there are enough Wi-Fi Access points.", "content": "13.4.1 Test Purpose . Verify EN scan location at level 3. 13.4.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE, LoRa or BLE+LoRa mode. | The Sidewalk stack (BLE, LoRa or BLE+LoRa) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | SidewalkNetworkFlag is enabled on the Lower Tester. | There is one Wi-Fi Access point nearby at least. | . 13.4.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 1(on BLE stack) or Link Mask 3(on LoRa stack) or Link Mask 5(on BLE+LoRa stack) Upper_Tester->>DUT: location init Upper_Tester->>DUT: location scan 3 DUT->>Upper_Tester: WIFI_LOCATION_RESOLUTION_RESULT Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 13.4.4 Expected Results . 13.4.4.1 Pass Verdict . Device can resolve without sending UL using Wi-Fi Access points location. ", "url": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#134-cmn-ep-locationservice-wifilocation-bv-02-scan-location-when-there-are-enough-wi-fi-access-points", "relUrl": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#134-cmn-ep-locationservice-wifilocation-bv-02-scan-location-when-there-are-enough-wi-fi-access-points" },"468": { "doc": "13. Location Service MCU Test Cases", "title": "13.5 CMN-EP-LOCATIONSERVICE-GNSSLOCATION-BV-01: Send location when there are enough satellites.", "content": "13.5.1 Test Purpose . Verify EN send a location uplink at level 4. 13.5.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE, LoRa or BLE+LoRa mode. | The Sidewalk stack (BLE, LoRa or BLE+LoRa) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 13.5.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 1(on BLE stack) or Link Mask 3(on LoRa stack) or Link Mask 5(on BLE+LoRa stack) Upper_Tester->>DUT: location init Upper_Tester->>DUT: location send 4 DUT->>Upper_Tester: GNSS_LOCATION_RESOLUTION_RESULT DUT->>Lower_Tester: GNSS_LOCATION_RESOLUTION_SEND_COMPLETE Lower_Tester->>DUT: GNSS_LOCATION_RESOLUTION_COMPLETE_ACK(if EN is linked on LoRa link only) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 13.5.4 Expected Results . 13.5.4.1 Pass Verdict . Device can resolve and send location using GNSS location. ", "url": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#135-cmn-ep-locationservice-gnsslocation-bv-01-send-location-when-there-are-enough-satellites", "relUrl": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#135-cmn-ep-locationservice-gnsslocation-bv-01-send-location-when-there-are-enough-satellites" },"469": { "doc": "13. Location Service MCU Test Cases", "title": "13.6 CMN-EP-LOCATIONSERVICE-GNSSLOCATION-BV-02: Scan location when there are enough satellites.", "content": "13.6.1 Test Purpose . Verify EN scan location at level 4. 13.6.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE, LoRa or BLE+LoRa mode. | The Sidewalk stack (BLE, LoRa or BLE+LoRa) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 13.6.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 1(on BLE stack) or Link Mask 3(on LoRa stack) or Link Mask 5(on BLE+LoRa stack) Upper_Tester->>DUT: location init Upper_Tester->>DUT: location scan 4 DUT->>Upper_Tester: GNSS_LOCATION_RESOLUTION_RESULT Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 13.6.4 Expected Results . 13.6.4.1 Pass Verdict . Device can resolve without sending UL using GNSS location. ", "url": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#136-cmn-ep-locationservice-gnsslocation-bv-02-scan-location-when-there-are-enough-satellites", "relUrl": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#136-cmn-ep-locationservice-gnsslocation-bv-02-scan-location-when-there-are-enough-satellites" },"470": { "doc": "13. Location Service MCU Test Cases", "title": "13.7 CMN-EP-LOCATIONSERVICE-FRAGMENT-BV-01: Re-transmit all missed fragments for Wi-Fi on LoRa.", "content": "13.7.1 Test Purpose . Verify some of location fragments are missed when specify location resolution via Wi-Fi and send via LoRa link. 13.7.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in LoRa or BLE+LoRa mode. | The Sidewalk stack (LoRa or BLE+LoRa) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | SidewalkNetworkFlag is enabled on the Lower Tester. | There is one AP nearby at least. | . 13.7.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 3(on LoRa stack) or Link Mask 5(on BLE+LoRa stack) Note over Lower_Tester,Upper_Tester: Wait until BLE disconnected if operate in BLE+LoRa mode Upper_Tester->>DUT: location init Upper_Tester->>DUT: location send 3 DUT->>Upper_Tester: WIFI_LOCATION_RESOLUTION_RESULT Upper_Tester->>DUT: mac scfg R <channel_different_from_gw> DUT->>Lower_Tester: FIRST_FRAGMENT_SENT Upper_Tester->>DUT: mac scfg R <channel_same_as_gw> DUT->>Lower_Tester: REMAINING_WIFI_LOCATION_RESOLUTION_FRAGMENTS_SENT Lower_Tester->>DUT: WIFI_LOCATION_RESOLUTION_RESULT_ACK DUT->>Lower_Tester: SENDING_LOST_WIFI_LOCATION_RESOLUTION_FRAGMENTS Lower_Tester->>DUT: WIFI_LOCATION_RESOLUTION_COMPLETE_ACK Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 13.7.4 Expected Results . 13.7.4.1 Pass Verdict . when some fragments fail to be received by the cloud, device will re-transmit lost fragments. ", "url": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#137-cmn-ep-locationservice-fragment-bv-01-re-transmit-all-missed-fragments-for-wi-fi-on-lora", "relUrl": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#137-cmn-ep-locationservice-fragment-bv-01-re-transmit-all-missed-fragments-for-wi-fi-on-lora" },"471": { "doc": "13. Location Service MCU Test Cases", "title": "13.8 CMN-EP-LOCATIONSERVICE-FRAGMENT-BV-02: Re-transmit all missed fragments for GNSS on LoRa.", "content": "13.8.1 Test Purpose . Verify some of location fragments are missed when specify location resolution via GNSS and send via LoRa link. 13.8.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in LoRa or BLE+LoRa mode. | The Sidewalk stack (LoRa or BLE+LoRa) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | SidewalkNetworkFlag is enabled on the Lower Tester. | . 13.8.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 3(on LoRa stack) or Link Mask 5(on BLE+LoRa stack) Note over Lower_Tester,Upper_Tester: Wait until BLE disconnected if operate in BLE+LoRa mode Upper_Tester->>DUT: location init Upper_Tester->>DUT: location send 4 DUT->>Upper_Tester: GNSS_LOCATION_RESOLUTION_RESULT Upper_Tester->>DUT: mac scfg R <channel_different_from_gw> DUT->>Lower_Tester: FIRST_FRAGMENT_SENT Upper_Tester->>DUT: mac scfg R <channel_same_as_gw> DUT->>Lower_Tester: REMAINING_GNSS_LOCATION_RESOLUTION_FRAGMENTS_SENT Lower_Tester->>DUT: GNSS_LOCATION_RESOLUTION_RESULT_ACK DUT->>Lower_Tester: SENDING_LOST_GNSS_LOCATION_RESOLUTION_FRAGMENTS Lower_Tester->>DUT: GNSS_LOCATION_RESOLUTION_COMPLETE_ACK Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 13.8.4 Expected Results . 13.8.4.1 Pass Verdict . when some fragments fail to be received by the cloud, device will re-transmit lost fragments. ", "url": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#138-cmn-ep-locationservice-fragment-bv-02-re-transmit-all-missed-fragments-for-gnss-on-lora", "relUrl": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#138-cmn-ep-locationservice-fragment-bv-02-re-transmit-all-missed-fragments-for-gnss-on-lora" },"472": { "doc": "13. Location Service MCU Test Cases", "title": "13.9 CMN-EP-LOCATIONSERVICE-LOCATIONSWITCH-BV-01: Location resolution level move from 1 to 3.", "content": "13.9.1 Test Purpose . Verify switch location resolution from level 1 to level 3 automatically. 13.9.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE, LoRa or BLE+LoRa mode. | The Sidewalk stack (BLE, LoRa or BLE+LoRa) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | SidewalkNetworkFlag is enabled on the Lower Tester. | There is no BLE but LoRa GW nearby. | There is 1 AP nearby at least. | . 13.9.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 1(on BLE stack) or Link Mask 3(on LoRa stack) or Link Mask 5(on BLE+LoRa stack) Upper_Tester->>DUT: location init Upper_Tester->>DUT: location send DUT->>Upper_Tester: WIFI_LOCATION_RESOLUTION_RESULT DUT->>Lower_Tester: WIFI_LOCATION_RESOLUTION_SEND_COMPLETE Lower_Tester->>DUT: WIFI_LOCATION_RESOLUTION_COMPLETE_ACK(if EN is linked on LoRa link only) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 13.9.4 Expected Results . 13.9.4.1 Pass Verdict . When there is no BLE GW nearby but Wi-Fi Access points, device can switch to resolve and send location using AP location automatically. ", "url": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#139-cmn-ep-locationservice-locationswitch-bv-01-location-resolution-level-move-from-1-to-3", "relUrl": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#139-cmn-ep-locationservice-locationswitch-bv-01-location-resolution-level-move-from-1-to-3" },"473": { "doc": "13. Location Service MCU Test Cases", "title": "13.10 CMN-EP-LOCATIONSERVICE-LOCATIONSWITCH-BV-02: Location resolution level move from 1 to 4.", "content": "13.10.1 Test Purpose . Verify switch location resolution from level 1 to level 4 automatically. 13.10.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE, LoRa or BLE+LoRa mode. | The Sidewalk stack (BLE, LoRa or BLE+LoRa) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | SidewalkNetworkFlag is enabled on the Lower Tester. | There is no BLE but LoRa GW nearby. | There is no any APs nearby. | . 13.10.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 1(on BLE stack) or Link Mask 3(on LoRa stack) or Link Mask 5(on BLE+LoRa stack) Upper_Tester->>DUT: location init Upper_Tester->>DUT: location send DUT->>Upper_Tester: GNSS_LOCATION_RESOLUTION_RESULT DUT->>Lower_Tester: GNSS_LOCATION_RESOLUTION_SEND_COMPLETE Lower_Tester->>DUT: GNSS_LOCATION_RESOLUTION_COMPLETE_ACK(if EN is linked on LoRa link only) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0\" . 13.10.4 Expected Results . 13.10.4.1 Pass Verdict . When there is no BLE GW and Wi-Fi Access points nearby, device can switch to resolve and send location using GNSS location automatically. ", "url": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#1310-cmn-ep-locationservice-locationswitch-bv-02-location-resolution-level-move-from-1-to-4", "relUrl": "/specifications/sidewalk-test-spec/location-service-mcu-test-cases.html#1310-cmn-ep-locationservice-locationswitch-bv-02-location-resolution-level-move-from-1-to-4" },"474": { "doc": "12. Sidewalk Location Service Test Cases", "title": "12. Sidewalk Location Service Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/location-service-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/location-service-test-cases.html" },"475": { "doc": "12. Sidewalk Location Service Test Cases", "title": "12.1 LOCSVC-E2E/EP/BLE-GNSS-SCAN/UL/BV/01: Resolve EN location on BLE uplink message containing GNSS scan information", "content": "12.1.1 Test Purpose . Send GNSS scan data on a BLE uplink message. 12.1.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | . 12.1.3 Test Procedure . sequenceDiagram participant DUT as DUT participant Upper_Tester as Upper Tester Note over DUT,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: location init DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over DUT,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid conn_req 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over DUT,Upper_Tester: Ensure DUT's Link_Mask is 1 Upper_Tester->>DUT: location send 4 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: SBDT_NDB(4) st 2->3 DUT->>Upper_Tester: Transfer completed successfully DUT->>Upper_Tester: loc send result: 0 . sequenceDiagram participant REST_API_User as REST API User participant Cloud as Cloud Note over REST_API_User,Cloud: Query device location REST_API_User->>Cloud: get device position with wireless_device_id Cloud->>REST_API_User: Returns GeoJSON position (type Point, coordinates [lon, lat, alt], properties: verticalAccuracy, horizontalAccuracy, timestamp) . 12.1.4 Expected Results . 12.1.4.1 Pass Verdict . The DUT should successfully send the uplink message with GNSS scan information, and the Cloud should be able to resolve the device location based on the GNSS data. ", "url": "/specifications/sidewalk-test-spec/location-service-test-cases.html#121-locsvc-e2eepble-gnss-scanulbv01-resolve-en-location-on-ble-uplink-message-containing-gnss-scan-information", "relUrl": "/specifications/sidewalk-test-spec/location-service-test-cases.html#121-locsvc-e2eepble-gnss-scanulbv01-resolve-en-location-on-ble-uplink-message-containing-gnss-scan-information" },"476": { "doc": "12. Sidewalk Location Service Test Cases", "title": "12.2 LOCSVC-E2E/EP/BLE-WIFI-SCAN/UL/BV/02: Resolve EN location on BLE uplink message containing Wi-Fi scan information", "content": "12.2.1 Test Purpose . Send Wi-Fi Scan results on a BLE uplink message. 12.2.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | . 12.2.3 Test Procedure . sequenceDiagram participant DUT as DUT participant Upper_Tester as Upper Tester Note over DUT,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: location init DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over DUT,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid conn_req 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over DUT,Upper_Tester: Ensure DUT's Link_Mask is 1 Upper_Tester->>DUT: location send 3 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: SBDT_NDB(3) st 2->3 DUT->>Upper_Tester: Transfer completed successfully DUT->>Upper_Tester: loc send result: 0 . sequenceDiagram participant REST_API_User as REST API User participant Cloud as Cloud Note over REST_API_User,Cloud: Query device location REST_API_User->>Cloud: get device position with wireless_device_id Cloud->>REST_API_User: Returns GeoJSON position (type Point, coordinates [lon, lat, alt], properties: verticalAccuracy, horizontalAccuracy, timestamp) . 12.2.4 Expected Results . 12.2.4.1 Pass Verdict . The DUT should successfully send the uplink message with Wi-Fi scan information, and the Cloud should resolve the device location. ", "url": "/specifications/sidewalk-test-spec/location-service-test-cases.html#122-locsvc-e2eepble-wifi-scanulbv02-resolve-en-location-on-ble-uplink-message-containing-wi-fi-scan-information", "relUrl": "/specifications/sidewalk-test-spec/location-service-test-cases.html#122-locsvc-e2eepble-wifi-scanulbv02-resolve-en-location-on-ble-uplink-message-containing-wi-fi-scan-information" },"477": { "doc": "12. Sidewalk Location Service Test Cases", "title": "12.3 LOCSVC-E2E/EP/BLE-GW-LOC/UL/BV/03: Resolve EN location on BLE uplink message with connected GW location", "content": "12.3.1 Test Purpose . Send DUT location as a proximity to a GW connected over BLE. 12.3.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | . 12.3.3 Test Procedure . sequenceDiagram participant DUT as DUT participant Upper_Tester as Upper Tester Note over DUT,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: location init DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over DUT,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid conn_req 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over DUT,Upper_Tester: Ensure DUT's Link_Mask is 1 Upper_Tester->>DUT: location send 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: SBDT_NDB(1) st 2->3 DUT->>Upper_Tester: Transfer completed successfully DUT->>Upper_Tester: loc send result: 0 . sequenceDiagram participant REST_API_User as REST API User participant Cloud as Cloud Note over REST_API_User,Cloud: Query device location REST_API_User->>Cloud: get device position with wireless_device_id Cloud->>REST_API_User: Returns GeoJSON position (type Point, coordinates [lon, lat, alt], properties: verticalAccuracy, horizontalAccuracy, timestamp) . 12.3.4 Expected Results . 12.3.4.1 Pass Verdict . The DUT should successfully send the uplink message with gateway location information, and the Cloud should resolve the device location. ", "url": "/specifications/sidewalk-test-spec/location-service-test-cases.html#123-locsvc-e2eepble-gw-loculbv03-resolve-en-location-on-ble-uplink-message-with-connected-gw-location", "relUrl": "/specifications/sidewalk-test-spec/location-service-test-cases.html#123-locsvc-e2eepble-gw-loculbv03-resolve-en-location-on-ble-uplink-message-with-connected-gw-location" },"478": { "doc": "12. Sidewalk Location Service Test Cases", "title": "12.4 LOCSVC-E2E/EP/LORA-GNSS-SCAN/UL/BV/01: Resolve EN location on LoRa uplink message containing GNSS scan information", "content": "12.4.1 Test Purpose . Send GNSS location scan data on LoRa. 12.4.2 Initial Conditions . | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode. | . 12.4.3 Test Procedure . sequenceDiagram participant DUT as DUT participant Upper_Tester as Upper Tester Note over DUT,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: location init DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over DUT,Upper_Tester: Ensure DUT's Link_Mask is 4 Upper_Tester->>DUT: location send 4 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: SBDT_NDB(4) st 2->3 DUT->>Upper_Tester: Transfer completed successfully DUT->>Upper_Tester: loc send result: 0 . sequenceDiagram participant REST_API_User as REST API User participant Cloud as Cloud Note over REST_API_User,Cloud: Query device location REST_API_User->>Cloud: get device position with wireless_device_id Cloud->>REST_API_User: Returns GeoJSON position (type Point, coordinates [lon, lat, alt], properties: verticalAccuracy, horizontalAccuracy, timestamp) . 12.4.4 Expected Results . 12.4.4.1 Pass Verdict . The DUT should successfully send the uplink messages with GNSS scan information via LoRa, and the Cloud should resolve the device location. ", "url": "/specifications/sidewalk-test-spec/location-service-test-cases.html#124-locsvc-e2eeplora-gnss-scanulbv01-resolve-en-location-on-lora-uplink-message-containing-gnss-scan-information", "relUrl": "/specifications/sidewalk-test-spec/location-service-test-cases.html#124-locsvc-e2eeplora-gnss-scanulbv01-resolve-en-location-on-lora-uplink-message-containing-gnss-scan-information" },"479": { "doc": "12. Sidewalk Location Service Test Cases", "title": "12.5 LOCSVC-E2E/EP/LORA-WIFI-SCAN/UL/BV/02: Resolve EN location on LoRa uplink message containing Wi-Fi scan information", "content": "12.5.1 Test Purpose . Send Wi-Fi scan data on LoRa. 12.5.2 Initial Conditions . | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode. | . 12.5.3 Test Procedure . sequenceDiagram participant DUT as DUT participant Upper_Tester as Upper Tester Note over DUT,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: location init DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over DUT,Upper_Tester: Ensure DUT's Link_Mask is 4 Upper_Tester->>DUT: location send 3 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: SBDT_NDB(3) st 2->3 DUT->>Upper_Tester: Transfer completed successfully DUT->>Upper_Tester: loc send result: 0 . sequenceDiagram participant REST_API_User as REST API User participant Cloud as Cloud Note over REST_API_User,Cloud: Query device location REST_API_User->>Cloud: get device position with wireless_device_id Cloud->>REST_API_User: Returns GeoJSON position (type Point, coordinates [lon, lat, alt], properties: verticalAccuracy, horizontalAccuracy, timestamp) . 12.5.4 Expected Results . 12.5.4.1 Pass Verdict . The DUT should successfully send the uplink message with Wi-Fi scan information via LoRa, and the Cloud should resolve the device location. ", "url": "/specifications/sidewalk-test-spec/location-service-test-cases.html#125-locsvc-e2eeplora-wifi-scanulbv02-resolve-en-location-on-lora-uplink-message-containing-wi-fi-scan-information", "relUrl": "/specifications/sidewalk-test-spec/location-service-test-cases.html#125-locsvc-e2eeplora-wifi-scanulbv02-resolve-en-location-on-lora-uplink-message-containing-wi-fi-scan-information" },"480": { "doc": "LoRa MLAT (L5)", "title": "LoRa MLAT (L5)", "content": " ", "url": "/app-notes/location-library/lora-mlat-l5.html", "relUrl": "/app-notes/location-library/lora-mlat-l5.html" },"481": { "doc": "LoRa MLAT (L5)", "title": "Introduction", "content": "LoRa multilateration (MLAT) resolves a device’s position from a single connectionless LoRa broadcast heard by multiple gateways. The device transmits once, with no gateway connection required; Amazon Sidewalk estimates the distance to each receiving gateway from signal strength and multilaterates a position. ", "url": "/app-notes/location-library/lora-mlat-l5.html#introduction", "relUrl": "/app-notes/location-library/lora-mlat-l5.html#introduction" },"482": { "doc": "LoRa MLAT (L5)", "title": "How the Cloud Resolves the Fix", "content": "Because one broadcast is heard by many gateways, their reports are accumulated and resolved together: . | Each receiving gateway’s known position is looked up, and its reported signal strength is used to estimate the gateway-to-device distance. | Gateways whose positions are outliers relative to the rest are discarded, so a stray or mislocated gateway does not pull the fix. | The device position is estimated from the remaining gateways and their signal-derived distances, and an accuracy estimate is produced with the fix. | . The resolved position is validated against the device’s recent location history before it is published, so a result that is physically implausible for the device’s movement is not published. ", "url": "/app-notes/location-library/lora-mlat-l5.html#how-the-cloud-resolves-the-fix", "relUrl": "/app-notes/location-library/lora-mlat-l5.html#how-the-cloud-resolves-the-fix" },"483": { "doc": "LoRa MLAT (L5)", "title": "Accuracy and Constraints", "content": ". | Requires a network-synced LoRa link. | How well a broadcast resolves depends on the gateways that hear it: more gateways, spread around the device rather than clustered on one side, produce a better fix. A broadcast heard by only one or two gateways, or by gateways in poor geometry (collinear or clustered), resolves coarsely or may not resolve at all. | Because distance is estimated from received signal strength, signal quality and obstructions between the device and each gateway also affect accuracy. | . ", "url": "/app-notes/location-library/lora-mlat-l5.html#accuracy-and-constraints", "relUrl": "/app-notes/location-library/lora-mlat-l5.html#accuracy-and-constraints" },"484": { "doc": "3. LoRa Power Optimization", "title": "3. LoRa Power Optimization", "content": " ", "url": "/app-notes/power-optimization/lora-power-optimization.html", "relUrl": "/app-notes/power-optimization/lora-power-optimization.html" },"485": { "doc": "3. LoRa Power Optimization", "title": "3.1 Introduction", "content": "LoRa (Long Range) Sub-GHz communication provides excellent range and power efficiency for Amazon Sidewalk devices. This chapter covers power optimization techniques specific to LoRa links, including CSS (Chirp Spread Spectrum) modulation characteristics. ", "url": "/app-notes/power-optimization/lora-power-optimization.html#31-introduction", "relUrl": "/app-notes/power-optimization/lora-power-optimization.html#31-introduction" },"486": { "doc": "3. LoRa Power Optimization", "title": "3.2 Device Profile Optimization", "content": "3.2.1 Profile A vs Profile B . Choose the appropriate LoRa profile based on power and connectivity requirements: . 3.2.1.1 Profile A (Customizable RX Windows) . // Configure LoRa Profile A with customizable RX window count struct sid_device_profile profileA = { .unicast_params = { .device_profile_id = SID_LINK3_PROFILE_A, .rx_window_count = 0, // Custom: 0 for uplink-only, or any number needed .unicast_window_interval.async_rx_interval_ms = 5000, // 5 second intervals .wakeup_type = SID_TX_AND_RX_WAKEUP }, .profile_misc_config = { .link3_misc_config = { .low_latency = SID_LINK3_LOW_LATENCY_DISABLE } } }; . Profile A Characteristics: . | (any number, including 0 for uplink-only) | RX window count of 0 = no downlink capability (maximum power savings) | Power consumption scales directly with RX window count | Suitable for applications with predictable or no downlink needs | . 3.2.1.2 Profile B (Infinite RX Windows) . // Configure LoRa Profile B with infinite RX windows (fixed) struct sid_device_profile profileB = { .unicast_params = { .device_profile_id = SID_LINK3_PROFILE_B, .rx_window_count = SID_RX_WINDOW_CNT_INFINITE, // Fixed: must be infinite .unicast_window_interval.async_rx_interval_ms = 5000, // 5 second intervals .wakeup_type = SID_TX_AND_RX_WAKEUP }, .profile_misc_config = { .link3_misc_config = { .low_latency = SID_LINK3_LOW_LATENCY_DISABLE } } }; . Profile B Characteristics: . | (cannot be changed) | Continuous downlink reachability | Higher power consumption due to continuous listening | Suitable for applications requiring always-on connectivity | . ", "url": "/app-notes/power-optimization/lora-power-optimization.html#32-device-profile-optimization", "relUrl": "/app-notes/power-optimization/lora-power-optimization.html#32-device-profile-optimization" },"487": { "doc": "3. LoRa Power Optimization", "title": "3.3 Low Latency Configuration", "content": "3.3.1 Low Latency Mode . Configure low latency mode for time-critical applications: . // Enable low latency mode (higher power consumption) struct sid_device_profile low_latency_profile = { .unicast_params = { .device_profile_id = SID_LINK3_PROFILE_B, .rx_window_count = SID_RX_WINDOW_CNT_INFINITE, .async_rx_interval_ms = 5000, .wakeup_type = SID_TX_AND_RX_WAKEUP }, .profile_misc_config = { .link3_misc_config = { .low_latency = SID_LINK3_LOW_LATENCY_ENABLE // Enable for low latency } } }; . Power Impact: . | Increased transmission repetitions | Faster battery drain | Use only when latency is critical | . ", "url": "/app-notes/power-optimization/lora-power-optimization.html#33-low-latency-configuration", "relUrl": "/app-notes/power-optimization/lora-power-optimization.html#33-low-latency-configuration" },"488": { "doc": "3. LoRa Power Optimization", "title": "3.4 LoRa Transmit Power Control (TPC)", "content": "LoRa Transmit Power Control (TPC) is a feature that optimizes power consumption while maintaining reliable communication by intelligently adjusting transmission power levels. The system uses a probe power level for testing lower settings and a normal power level (probe power + 4dB margin) for regular transmissions. It operates in two phases: Search Phase, which finds the lowest workable power using binary search, and Trial Phase, which periodically checks (every 12 hours) if power can be reduced further. TPC monitors message acknowledgments from existing user data traffic without generating extra control messages. If messages fail to get acknowledged, TPC automatically increases power to maintain connectivity. Key Features: . | Conservative power adjustment using transport-ack feedback | Binary search for initial power setting, then linear adjustment | Normal power range: +4 dBm to +22 dBm with small step adjustments (typically 1 dB) | Probe power range: 0 dBm to +17 dBm | Channel-specific power mapping with safety margins | Self-recovery mechanisms if connection degrades | . Algorithm Approach: . | Uses acknowledgments from user data transmissions for power optimization | Adaptive algorithm with binary search and trial phases | Cooldown periods between adjustments | Only reduces power when proven successful through transport-ack | . Benefits: . | Optimizes battery life by reducing unnecessary transmission power | Reduces channel congestion from multiple gateway reception | Maintains reliable connectivity with conservative approach | . Note: This feature requires enabling application layer acknowledgment (AWS IoT) for optimal operation. 3.4.1 LoRa TPC Testing Results . The LoRa TPC feature was evaluated to assess its power optimization performance across different hardware platforms and device profiles. Testing focused on LoRa Profile A and Profile B configurations with high acknowledgment rates to validate TPC effectiveness. Test Environment Configurations: . | Device profiles: LoRa Profile A and Profile B | ACK success rate: 95% application layer acknowledgment (AWS IoT) | Test environment: Controlled shielding room with distance <1m between device and gateway, single device and gateway operation | . TPC Performance Results: . LoRa TPC Power Consumption Results . |   |   |   |   |   |   | . | Environment | TPC On | TPC Off | Power | Avg RF Power | Avg RF Power | . |   | Power (mA) | Power (mA) | Reduction | TPC On (dBm) | TPC Off (dBm) | . | ACK 95%, Profile A | 71.932 | 128.680 | 44.1% | 11 | 19 | . | ACK 95%, Profile B | 68.896 | 128.625 | 46.44% | 11 | 19 | . Key Findings: . | : Up to 46.44% achieved with Profile B configuration | : Both Profile A and Profile B show effective TPC operation with consistent results | : TPC effectiveness correlates with acknowledgment success rates, performing optimally at 95% ACK rate | : TPC provides consistent 44-46% power reduction across different profiles | . Implementation Recommendations: . | Deploy TPC in environments with high ACK success rates for maximum benefit | Monitor ACK rates to ensure TPC operates in optimal conditions | Expect 44-46% power reduction in typical high-reliability scenarios | . ", "url": "/app-notes/power-optimization/lora-power-optimization.html#34-lora-transmit-power-control-tpc", "relUrl": "/app-notes/power-optimization/lora-power-optimization.html#34-lora-transmit-power-control-tpc" },"489": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5. LoRa (900MHz) Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html" },"490": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.1 LORA/EP/DATA/DL/BV/01: Endpoint receives downlink packets with various sizes of Command data.", "content": "5.1.1 Test Purpose . DUT is able to receive downlink packets with various sizes of Command data (1B, 10B, 19B) sent from the Lower Tester. 5.1.2 Initial Conditions . | DUT is configured as profile B. | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operate on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 5.1.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, LoRa Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with 1B of Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: 1B\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with 10B of Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: 10B\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with 19B of Command data) DUT->>Upper_Tester: on_msg_received() \"Command data: 19B\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 5.1.4 Expected Results . 5.1.4.1 Pass Verdict . Packets with various sizes of Command data sent by Lower Tester are able to reach the DUT. The Command data content must be verified for correctness on the Upper Tester side. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#51-loraepdatadlbv01-endpoint-receives-downlink-packets-with-various-sizes-of-command-data", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#51-loraepdatadlbv01-endpoint-receives-downlink-packets-with-various-sizes-of-command-data" },"491": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.2 LORA/EP/DATA/UL/BV/01: Gateway receives uplink packets with various Command data sizes from Endpoint.", "content": "5.2.1 Test Purpose . Lower Tester is able to receive uplink packets with various Command data sizes (1B, 10B, 19B) sent from the DUT. 5.2.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operates on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 5.2.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, LoRa Connected Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data 1B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data 10B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 10B of Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data 19B) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 19B of Command data) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 5.2.4 Expected Results . 5.2.4.1 Pass Verdict . Packets with various sizes of Command data sent by DUT are able to reach the Lower Tester. The Command data content of each packet must be verified for correctness on the Lower Tester side. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#52-loraepdataulbv01-gateway-receives-uplink-packets-with-various-command-data-sizes-from-endpoint", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#52-loraepdataulbv01-gateway-receives-uplink-packets-with-various-command-data-sizes-from-endpoint" },"492": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.3 LORA/EP/SEC/UUID/BV/01: Endpoint rotates UUID immediately after time sync.", "content": "5.3.1 Test Purpose . DUT is able to change the current UUID and use it right after the time synchronization procedure is completed. 5.3.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operates on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | . 5.3.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 4, LoRa Connected\" DUT->>Lower_Tester: GET_TIME(TX-UUID-1) Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Up, Time Synced, Link Mask 4, LoRa Connected\" DUT->>Lower_Tester: SET_JOIN_REQ(TX-UUID-2) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, LoRa Disconnected\" . 5.3.4 Expected Results . 5.3.4.1 Pass Verdict . UUID of the Endpoint should change right after successful time synchronization procedure, therefore the value of TX-UUID sent as part of the GET_TIME packet should be different from the TX-UUID sent in the SET_JOIN_REQ packet. As the source device ID information is sent as plain text in the link layer, the above condition can be validated on the Lower Tester side. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#53-loraepsecuuidbv01-endpoint-rotates-uuid-immediately-after-time-sync", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#53-loraepsecuuidbv01-endpoint-rotates-uuid-immediately-after-time-sync" },"493": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.4 LORA/EP/SEC/UUID/BV/02: UUID rotates every 15 minutes after time sync.", "content": "5.4.1 Test Purpose . DUT is able to change the UUID every 15 minutes after the time synchronization procedure is completed. 5.4.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operates on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | . 5.4.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 4, LoRa Connected\" DUT->>Lower_Tester: GET_TIME(TX-UUID-1) Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Up, Time Synced, Link Mask 4, LoRa Connected\" DUT->>Lower_Tester: SET_JOIN_REQ(TX-UUID-2) Note over Lower_Tester,Upper_Tester: Wait 15 minutes for DUT to change the UUID Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(TX-UUID-3) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, LoRa Disconnected\" . 5.4.4 Expected Results . 5.4.4.1 Pass Verdict . After successful time synchronization procedure, the UUID of the DUT should change every 15 minutes. Therefore, the TX-UUID value sent as part of the SET_JOIN_REQ packet should be different from the TX-UUID sent 15 minutes later in the CUSTOM_NOTIFY_CMD packet. As the source device ID information is sent as plain text in the link layer, the above condition can be validated on the Lower Tester side. 5.4.5.2 Fail Verdict . A test failure will occur if the DUT re-uses an older TX-UUID at any point during the test. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#54-loraepsecuuidbv02-uuid-rotates-every-15-minutes-after-time-sync", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#54-loraepsecuuidbv02-uuid-rotates-every-15-minutes-after-time-sync" },"494": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.5 LORA/EP/SEC/UUID/BV/03: Endpoint can exchange UL/DL during UUID rotation.", "content": "5.5.1 Test Purpose . DUT is able to exchange the uplink and downlink packets during UUID rotation. 5.5.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operates on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | . 5.5.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 4, LoRa Connected\" DUT->>Lower_Tester: GET_TIME(TX-UUID-1) Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Up, Time Synced, Link Mask 4, LoRa Connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(TX-UUID-2) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(TX-UUID-2) DUT->>Upper_Tester: on_msg_received() Note over Lower_Tester,Upper_Tester: Continue sending the above uplink and downlink packets with 1 second interval until the UUID changes Note over Lower_Tester,DUT: ... Note over Lower_Tester,Upper_Tester: UUID rotation Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(TX-UUID-3) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(TX-UUID-3) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, LoRa Disconnected\" . 5.5.4 Expected Results . 5.5.4.1 Pass Verdict . After successful time synchronization procedure, the UUID of the DUT should change every 15 minutes. All packets, both uplink and downlink, transmitted around the moment of UUID rotation should be handled correctly and reach the destination. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#55-loraepsecuuidbv03-endpoint-can-exchange-uldl-during-uuid-rotation", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#55-loraepsecuuidbv03-endpoint-can-exchange-uldl-during-uuid-rotation" },"495": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.6 LORA/EP/CONN/REG/BV/02: Endpoint can be deregistered from Sidewalk network.", "content": "5.6.1 Test Purpose . To verify that the DUT is able to be deregistered from the Amazon Sidewalk network. 5.6.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | The Sidewalk stack (LoRa) is initialized and started on the DUT. | . 5.6.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, LoRa Connected Upper_Tester->>DUT: sid_set_factory_reset() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: NOTIFY_RESET(RESET_HARD) DUT->>Upper_Tester: on_status_changed() \"Status: Not registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_get_time() DUT->>Upper_Tester: #35;SID_ERROR_INVALID_STATE Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Not registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Not Registered, Link Mask 0, LoRa Disconnected\" . 5.6.4 Expected Results . 5.6.4.1 Pass Verdict . Calling the sid_set_factory_reset method should force the DUT to send the packet NOTIFY_RESET (with RESET_HARD parameter) to the Lower Tester. Then the DUT should report to the Upper Tester the change in registration status to “Not registered”. After successful deregistration, the attempt to send the GET_TIME packet should fail with the SID_ERROR_INVALID_STATE returned to the Upper Tester. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#56-loraepconnregbv02-endpoint-can-be-deregistered-from-sidewalk-network", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#56-loraepconnregbv02-endpoint-can-be-deregistered-from-sidewalk-network" },"496": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.7 LORA/EP/CONN/LP/BV/01: Endpoint can select Profile A and complete Join procedure.", "content": "5.7.1 Test Purpose . DUT is able to set Profile A and complete Join procedure triggered after profile selection. DUT and Lower Tester can exchange data after successful Join procedure. 5.7.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | The Sidewalk stack (LoRa) is initialized and started on the DUT. | Both DUT and Lower Tester operate on the same LDR channel. | DUT has completed the time synchronization. | . 5.7.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, LoRa Connected Upper_Tester->>DUT: sid_option(SET_DEVICE_PROFILE, SID_LINK3_PROFILE_A) DUT->>Lower_Tester: SET_JOIN_REQ (contains \"SID_LINK3_PROFILE_A\") Note over Lower_Tester,Upper_Tester: Wait for up to 21 seconds Lower_Tester->>DUT: RESP_JOIN_REQ Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 5.7.4 Expected Results . 5.7.4.1 Pass Verdict . Transmission of “SET_JOIN_REQ” is triggered after setting the Profile A. Content of the “SET_JOIN_REQ” packet must be verified in terms of whether it contains Profile A data. “RESP_JOIN_REQ” packet must be sent back to DUT (within 21 seconds), confirming that Join procedure finished successfully. After completing Join procedure DUT and Lower Tester can exchange data (UL and DL packet). ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#57-loraepconnlpbv01-endpoint-can-select-profile-a-and-complete-join-procedure", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#57-loraepconnlpbv01-endpoint-can-select-profile-a-and-complete-join-procedure" },"497": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.8 LORA/EP/CONN/LP/BV/02: Endpoint can select Profile B and complete Join procedure.", "content": "5.8.1 Test Purpose . DUT is able to set Profile B and complete Join procedure triggered after profile selection. DUT and Lower Tester can exchange data after successful Join procedure. 5.8.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | The Sidewalk stack (LoRa) is initialized and started on the DUT. | Both DUT and Lower Tester operate on the same LDR channel. | DUT has completed the time synchronization. | . 5.8.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, LoRa Connected Upper_Tester->>DUT: sid_option(SET_DEVICE_PROFILE, SID_LINK3_PROFILE_B) DUT->>Lower_Tester: SET_JOIN_REQ (contains \"SID_LINK3_PROFILE_B\") Note over Lower_Tester,Upper_Tester: Wait for up to 21 seconds Lower_Tester->>DUT: RESP_JOIN_REQ Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 5.8.4 Expected Results . 5.8.4.1 Pass Verdict . Transmission of “SET_JOIN_REQ” is triggered after setting the Profile B. Content of the “SET_JOIN_REQ” packet must be verified in terms of whether it contains Profile B data. “RESP_JOIN_REQ” packet must be sent back to DUT (within 21 seconds), confirming that Join procedure finished successfully. After completing Join procedure DUT and Lower Tester can exchange data (UL and DL packet). ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#58-loraepconnlpbv02-endpoint-can-select-profile-b-and-complete-join-procedure", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#58-loraepconnlpbv02-endpoint-can-select-profile-b-and-complete-join-procedure" },"498": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.9 LORA/EP/CONN/SEQ/BV/01: Uplink packets contain SEQ number.", "content": "5.9.1 Test Purpose . To verify that the uplink packets sent by the DUT contain the sequence number written in the seq_num field in the Link Layer. With each subsequent sent packet, the value of seq_num should be incremented by one. 5.9.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operates on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 5.9.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, LoRa Connected Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with seq_num field in the Link Layer) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with seq_num field in the Link Layer) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with seq_num field in the Link Layer) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with seq_num field in the Link Layer) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 5.9.4 Expected Results . 5.9.4.1 Pass Verdict . The seq_num field is properly filled in the Link Layer of each CUSTOM_NOTIFY_CMD packet sent by DUT. Moreover, seq_num of each CUSTOM_NOTIFY_CMD packet should be incremented by one relative to the seq_num of the previous transmitted packet. As the packet sequence number is sent as plain text in the Link Layer, the above condition can be validated on the Lower Tester side. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#59-loraepconnseqbv01-uplink-packets-contain-seq-number", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#59-loraepconnseqbv01-uplink-packets-contain-seq-number" },"499": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.10 LORA/EP/CONN/SEQ/BV/02: Endpoint increments uplink SEQ number until UUID changes.", "content": "5.10.1 Test Purpose . To verify that the DUT increments the uplink packet sequence number until the UUID is changed. After the UUID is changed, the DUT should generate a new sequence number in the range between 0 and 16383. 5.10.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operates on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 5.10.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, LoRa Connected Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with seq_num field in the Link Layer) DUT->>Upper_Tester: on_msg_sent() Note over Lower_Tester,DUT: ... Note over Lower_Tester,Upper_Tester: Repeat the uplink packet once per minute for up to 15 minutes Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with the new seq_num in the Link Layer) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 5.10.4 Expected Results . 5.10.4.1 Pass Verdict . The seq_num field should be properly incremented by one for each subsequent packet sent by DUT within a maximum of 15 minutes from the previous UUID change, then a new sequence number should be generated in the range between 0 and 16383. As the packet sequence number is sent as plain text in the Link Layer, all CUSTOM_NOTIFY_CMD packets can be verified for seq_num field content on the Lower Tester side. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#510-loraepconnseqbv02-endpoint-increments-uplink-seq-number-until-uuid-changes", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#510-loraepconnseqbv02-endpoint-increments-uplink-seq-number-until-uuid-changes" },"500": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.11 LORA/EP/CONN/SEQ/BV/03: Endpoint accepts and decodes downlink packets with increased and decreased SEQ.", "content": "5.11.1 Test Purpose . To verify that the downlink packets with both increasing and decreasing sequence number can be decoded by the DUT. 5.11.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operates on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 5.11.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, LoRa Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=2) DUT->>Upper_Tester: on_msg_received() \"seq_num=2\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=3) DUT->>Upper_Tester: on_msg_received() \"seq_num=3\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=6) DUT->>Upper_Tester: on_msg_received() \"seq_num=6\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=5) DUT->>Upper_Tester: on_msg_received() \"seq_num=5\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=4) DUT->>Upper_Tester: on_msg_received() \"seq_num=4\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 5.11.4 Expected Results . 5.11.4.1 Pass Verdict . The first three CUSTOM_NOTIFY_CMD packets sent by Lower Tester to the DUT contain an increasing sequence number ranging from 1 to 3. The next three CUSTOM_NOTIFY_CMD packets contain a decreasing sequence number ranging from 6 to 4. All sent packets should be accepted and properly decoded by the DUT which should manifested by reporting all six events to the Upper Tester. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#511-loraepconnseqbv03-endpoint-accepts-and-decodes-downlink-packets-with-increased-and-decreased-seq", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#511-loraepconnseqbv03-endpoint-accepts-and-decodes-downlink-packets-with-increased-and-decreased-seq" },"501": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.12 LORA/EP/CONN/SEQ/BV/05: Endpoint rejects downlink packet with duplicated SEQ.", "content": "5.12.1 Test Purpose . To verify that a downlink packet which contains a duplicated sequence number is rejected by the DUT. 5.12.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operates on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 5.12.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, LoRa Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=2) DUT->>Upper_Tester: on_msg_received() \"seq_num=2\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=2) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 5.12.4 Expected Results . 5.12.4.1 Pass Verdict . The first CUSTOM_NOTIFY_CMD packet sent by the Lower Tester containing sequence number equal to 1 should be decoded correctly and information about this event should be visible on the Upper Tester side. However, another CUSTOM_NOTIFY_CMD packet sent by the Lower Tester also containing the same sequence number should be rejected by the DUT. The third CUSTOM_NOTIFY_CMD packet containing parameter seq_num increased by one should be decoded correctly and information about this event should again be visible on the Upper Tester side. The fourth CUSTOM_NOTIFY_CMD packet with a duplicated seq_num equal to 2 should be rejected by the DUT. In the case of duplicate packets, information about this event should not be visible on the Upper Tester side. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#512-loraepconnseqbv05-endpoint-rejects-downlink-packet-with-duplicated-seq", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#512-loraepconnseqbv05-endpoint-rejects-downlink-packet-with-duplicated-seq" },"502": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.13 LORA/EP/CONN/SEQ/BV/06: Endpoint rejects downlink packet with duplicated SEQ range.", "content": "5.13.1 Test Purpose . To verify that a group of five downlink packets which contain a duplicate sequence number are rejected by the DUT. 5.13.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operates on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 5.13.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, LoRa Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=2) DUT->>Upper_Tester: on_msg_received() \"seq_num=2\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=3) DUT->>Upper_Tester: on_msg_received() \"seq_num=3\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=4) DUT->>Upper_Tester: on_msg_received() \"seq_num=4\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=5) DUT->>Upper_Tester: on_msg_received() \"seq_num=5\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=2) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=3) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=4) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=5) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 5.13.4 Expected Results . 5.13.4.1 Pass Verdict . The first five CUSTOM_NOTIFY_CMD packets with sequence numbers increasing sequentially from 1 to 5 should be sent from the Lower Tester and correctly decoded on the DUT side. Receipt of all five of these packets should be reported on the Upper Tester side. After re-sending from the Lower Tester the same packets containing sequence numbers from 1 to 5, all of them should be rejected by the DUT. Information on these five events should not be visible on the Upper Tester side. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#513-loraepconnseqbv06-endpoint-rejects-downlink-packet-with-duplicated-seq-range", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#513-loraepconnseqbv06-endpoint-rejects-downlink-packet-with-duplicated-seq-range" },"503": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.14 LORA/EP/CONN/SEQ/BV/07: SEQ number can be accepted again after getting 10 other messages.", "content": "5.14.1 Test Purpose . DUT is able to receive downlink packet with already used SEQ number, after receiving at least 10 additional packets with different, unique SEQ number. 5.14.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operate on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 5.14.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, LoRa Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=2) DUT->>Upper_Tester: on_msg_received() \"seq_num=2\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=3) DUT->>Upper_Tester: on_msg_received() \"seq_num=3\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=4) DUT->>Upper_Tester: on_msg_received() \"seq_num=4\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=5) DUT->>Upper_Tester: on_msg_received() \"seq_num=5\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=6) DUT->>Upper_Tester: on_msg_received() \"seq_num=6\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=7) DUT->>Upper_Tester: on_msg_received() \"seq_num=7\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=8) DUT->>Upper_Tester: on_msg_received() \"seq_num=8\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=9) DUT->>Upper_Tester: on_msg_received() \"seq_num=9\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=10) DUT->>Upper_Tester: on_msg_received() \"seq_num=10\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=11) DUT->>Upper_Tester: on_msg_received() \"seq_num=11\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 5.14.4 Expected Results . 5.14.4.1 Pass Verdict . First, eleventh and thirteenth CUSTOM_NOTIFY_CMD packet contain the same SEQ number. All the other CUSTOM_NOTIFY_CMD packets contain different, unique SEQ number. Due to the fact that 10 additional packets have to be received by DUT before SEQ number can be reused: Eleventh CUSTOM_NOTIFY_CMD packet should be rejected by DUT (after 9 additional packets received). Thirteenth CUSTOM_NOTIFY_CMD packet should be received and decoded properly by DUT (after 10 additional packets received). ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#514-loraepconnseqbv07-seq-number-can-be-accepted-again-after-getting-10-other-messages", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#514-loraepconnseqbv07-seq-number-can-be-accepted-again-after-getting-10-other-messages" },"504": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.15 LORA/EP/CONN/SEQ/BV/08: SEQ number can be accepted again after Sidewalk stack reinitialization.", "content": "5.15.1 Test Purpose . DUT is able to receive downlink packet with already used SEQ number, after reinitialization of Sidewalk stack. 5.15.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operate on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 5.15.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, LoRa Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Not Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Wait until DUT completes time sync and Join procedure DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 4, LoRa Connected\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (seq_num=1) DUT->>Upper_Tester: on_msg_received() \"seq_num=1\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 5.15.4 Expected Results . 5.15.4.1 Pass Verdict . First and third CUSTOM_NOTIFY_CMD packets should be received and decoded properly by DUT, despite having the same SEQ number. Since there was no stack reinitialization before second CUSTOM_NOTIFY_CMD packet, it should be rejected by DUT because of repeating SEQ number. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#515-loraepconnseqbv08-seq-number-can-be-accepted-again-after-sidewalk-stack-reinitialization", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#515-loraepconnseqbv08-seq-number-can-be-accepted-again-after-sidewalk-stack-reinitialization" },"505": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.16 LORA/EP/CONN/SEQ/BV/09: Endpoint drops the packet with SEQ which is out of range.", "content": "5.16.1 Test Purpose . To verify that a downlink packet which contains an out of range sequence number is dropped by the DUT. 5.16.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operates on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization and the Join procedure. | . 5.16.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, LoRa Connected Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=16383) DUT->>Upper_Tester: on_msg_received() \"seq_num=16383\" Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(seq_num=16384) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE . 5.16.4 Expected Results . 5.16.4.1 Pass Verdict . The first CUSTOM_NOTIFY_CMD packet sent by the Lower Tester containing the maximum allowed sequence number (16383) should be decoded correctly and information about this event should be visible on the Upper Tester side. The second CUSTOM_NOTIFY_CMD packet sent by the Lower Tester should be dropped by the DUT due to the seq_num parameter being exceeded and therefore this event should not be reported to the Upper Tester. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#516-loraepconnseqbv09-endpoint-drops-the-packet-with-seq-which-is-out-of-range", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#516-loraepconnseqbv09-endpoint-drops-the-packet-with-seq-which-is-out-of-range" },"506": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.17 LORA/EP/NW/SYNC/JOIN/BV/02: Endpoint keeps synchronization with the network by periodic transmission of Join request.", "content": "5.17.1 Test Purpose . DUT is able to keep synchronization with the network by periodic transmission of Join request. When the time sync and Join procedure is completed device is automatically synchronized with the network. Then after a period of 300 seconds of uplink inactivity (no data is transmitted), the DUT should send another Join request command to keep link with the network active/alive. 5.17.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operates on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | . 5.17.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 4, LoRa Connected\" DUT->>Lower_Tester: GET_TIME Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Up, Time Synced, Link Mask 4, LoRa Connected\" DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ Note over Lower_Tester,Upper_Tester: Wait 300 seconds for the end of 'in sync' state on DUT DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ Note over Lower_Tester,Upper_Tester: Wait 31 seconds Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, LoRa Disconnected\" . 5.17.4 Expected Results . 5.17.4.1 Pass Verdict . DUT is able to acquire positive response from the network when Join request is sent during the active synchronization process. The GET_TIME packet must be the first uplink transmission right after initializing the Sidewalk stack with LoRa modulation. The RESP_TIME packet will be sent to DUT within 30 seconds and no re-transmission of the GET_TIME packet should occur during this time. Also no other uplink transmission is allowed before the DUT receives the RESP_TIME packet which will be reported via Time Status: Synced. Completion of the time synchronization procedure should also change the Link Status to Up. DUT should send the SET_JOIN_REQ packet right after the time synchronization procedure is complete. The RESP_JOIN_REQ packet should be sent back to DUT within 20 seconds and until then DUT should not repeat the transmission of the next SET_JOIN_REQ commands. After sending the first RESP_JOIN_REQ, wait 300 seconds after which DUT should send the second SET_JOIN_REQ packet to keep synchronization with the network. No uplink transmission should occur during this period. After sending the second RESP_JOIN_REQ, wait 20 seconds and verify that DUT has not resent SET_JOIN_REQ. This means that the DUT is able to maintain synchronization with the network by periodic transmission of Join request. As the SET_JOIN_REQ carries requested async profile attributes, its content must be verified against the declared capabilities of the DUT. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#517-loraepnwsyncjoinbv02-endpoint-keeps-synchronization-with-the-network-by-periodic-transmission-of-join-request", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#517-loraepnwsyncjoinbv02-endpoint-keeps-synchronization-with-the-network-by-periodic-transmission-of-join-request" },"507": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.18 LORA/EP/NW/SYNC/JOIN/BV/03: Endpoint keeps synchronization with the network by embedded sync request.", "content": "5.18.1 Test Purpose . DUT is able to keep synchronization with the network with the use of embedded sync request. When the time sync and Join procedure is completed device is automatically synchronized with the network. However, 150 seconds after a successful synchronization, the DUT should start attaching a sync request to each uplink packet in order to maintain the synchronization without the need to send a separate Join request, which reduces signalling. 5.18.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | DUT is configured as Profile B. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | Both DUT and Lower Tester operates on the same LDR channel. | The protocol is enabled on the Lower Tester. | SidewalkNetworkFlag is enabled on Lower Tester. | . 5.18.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 4, LoRa Connected\" DUT->>Lower_Tester: GET_TIME Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Up, Time Synced, Link Mask 4, LoRa Connected\" DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ Note over Lower_Tester,Upper_Tester: Wait 150 seconds until DUT starts attaching the sync request to the packet Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, \"PING\") DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD with NDB format 3 embedded in the Network Diagnostic Data block of the Presentation Layer Lower_Tester->>DUT: NTFY_JOIN_REQ Note over Lower_Tester,Upper_Tester: Wait 170 seconds to make sure that the DUT remains synchronized and does not send a Join request Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, LoRa Disconnected\" . 5.18.4 Expected Results . 5.18.4.1 Pass Verdict . DUT is able to acquire Join notify from the network when synchronization request is embedded in uplink data. The GET_TIME packet must be the first uplink transmission right after initializing the Sidewalk stack with LoRa modulation. The RESP_TIME packet will be sent to DUT within 30 seconds and no re-transmission of the GET_TIME packet should occur during this time. Also no other uplink transmission is allowed before the DUT receives the RESP_TIME packet which will be reported via Time Status: Synced. Completion of the time synchronization procedure should also change the Link Status to Up. DUT should send the SET_JOIN_REQ packet right after the time synchronization procedure is complete. The RESP_JOIN_REQ packet should be sent back to DUT within 20 seconds and until then DUT should not repeat the transmission of the next SET_JOIN_REQ commands. After sending the RESP_JOIN_REQ, wait 150 seconds, then the Upper Tester must trigger sending uplink data on the DUT (CUSTOM_NOTIFY_CMD with “PING” as the Command data). As a result, the mentioned packet will be sent to the network. The uplink data must include TLV key 0x01 synchronization request in Network Data Blob format 3 and it must be verified on the Lower Tester side. The NTFY_JOIN_REQ packet should be sent back to DUT within 25 seconds. After sending the NTFY_JOIN_REQ, wait another 170 seconds and verify that DUT does not send SET_JOIN_REQ during this period. This means that the DUT is able to maintain synchronization with the network by embedded sync request during transmission of regular data. As the SET_JOIN_REQ carries requested async profile attributes, its content must be verified against the declared capabilities of the DUT. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#518-loraepnwsyncjoinbv03-endpoint-keeps-synchronization-with-the-network-by-embedded-sync-request", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#518-loraepnwsyncjoinbv03-endpoint-keeps-synchronization-with-the-network-by-embedded-sync-request" },"508": { "doc": "5. LoRa (900MHz) Test Cases", "title": "5.19 LORA/EP/NW/SYNC/TIME/BV/01: Endpoint completes the initial time sync procedure.", "content": "5.19.1 Test Purpose . DUT is able to pass the initial time synchronization procedure. 5.19.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in the default mixed (MULTI_RATE) mode. | The protocol is enabled on the Lower Tester. | Both DUT and Lower Tester operate on the same LDR channel. | SidewalkNetworkFlag is enabled on Lower Tester. | . 5.19.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialised on DUT Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 4, LoRa Connected\" DUT->>Lower_Tester: GET_TIME Note over Lower_Tester,Upper_Tester: Wait for up to 30 seconds Lower_Tester->>DUT: RESP_TIME DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Up, Time Synced, Link Mask 4, LoRa Connected\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Link Down, No Time, Link Mask 0, LoRa Disconnected\" . 5.19.4 Expected Results . 5.19.4.1 Pass Verdict . DUT is able to acquire time from the network. The RESP_TIME packet will be sent to DUT within 30 seconds and no re-transmission of the GET_TIME packet should occur during this time. No other UL transmission should take place until the DUT receives a correct RESP_TIME packet which will be reported via Time Status: Synced. Completion of the time synchronization procedure should also change the Link Status to Up. ", "url": "/specifications/sidewalk-test-spec/lora-test-cases.html#519-loraepnwsynctimebv01-endpoint-completes-the-initial-time-sync-procedure", "relUrl": "/specifications/sidewalk-test-spec/lora-test-cases.html#519-loraepnwsynctimebv01-endpoint-completes-the-initial-time-sync-procedure" },"509": { "doc": "6. LoRa Test Cases", "title": "LoRa Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#lora-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#lora-test-cases" },"510": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/DATA/DL/BV-01: End Node receives downlink packets with different payload size from Gateway", "content": "| Attribute | Value | . | Case ID | C83934651 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 1 DL packet from AWS IoT with 1 byte payload | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: 1, LINK: 4, LINK_MODE: <x>, ACK_REQUESTED: <x>, ACK: <x>, DUP: <x>, RSSI: <x>, SNR: <x> Data: <payload> Key check: Delivery ratio 100% | . | 2 | Send 1 DL packet from AWS IoT with 10 bytes payload | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: 10, LINK: 4, LINK_MODE: <x>, ACK_REQUESTED: <x>, ACK: <x>, DUP: <x>, RSSI: <x>, SNR: <x> Data: <payload> Key check: Delivery ratio 100% | . | 3 | Send 1 DL packet from AWS IoT with 19 bytes payload | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: 19, LINK: 4, LINK_MODE: <x>, ACK_REQUESTED: <x>, ACK: <x>, DUP: <x>, RSSI: <x>, SNR: <x> Data: <payload> Key check: Delivery ratio 100% | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraendatadlbv-01-end-node-receives-downlink-packets-with-different-payload-size-from-gateway", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraendatadlbv-01-end-node-receives-downlink-packets-with-different-payload-size-from-gateway" },"511": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/DATA/UL/BV-01: Gateway receives uplink packets with different payload sizes from End Node", "content": "| Attribute | Value | . | Case ID | C83934652 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 1 UL packet from EN with 1 byte payload: sid send <1-byte-payload> | CMD: ERR: 0 TYPE: 2 ID: <id> EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4 LINK_MODE: 0 ADDITIONAL ATTRS: 0 Key check: Packet received on AWS | . | 2 | Send 1 UL packet from EN with 10 bytes payload: sid send <10-byte-payload> | CMD: ERR: 0 TYPE: 2 ID: <id> EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4 LINK_MODE: 0 ADDITIONAL ATTRS: 0 Key check: Packet received on AWS | . | 3 | Send 1 UL packet from EN with 19 bytes payload: sid send <19-byte-payload> | CMD: ERR: 0 TYPE: 2 ID: <id> EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4 LINK_MODE: 0 ADDITIONAL ATTRS: 0 Key check: Packet received on AWS | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraendataulbv-01-gateway-receives-uplink-packets-with-different-payload-sizes-from-end-node", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraendataulbv-01-gateway-receives-uplink-packets-with-different-payload-sizes-from-end-node" },"512": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/SEC/UUID/BV-01: End Node rotates UUID immediately after time sync", "content": "| Attribute | Value | . | Case ID | C83934653 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Get initial TX UUID: print txid | TXID: 0x<uuid> Key check: Note the UUID value | . | 2 | Wait for time sync | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4 EVENT SID STATUS LINK MODE: LORA: 1, FSK: 0, BLE: 0 Key check: Time: 0 (time synced) | . | 3 | Get TX UUID again: print txid | TXID: 0x<new_uuid> Key check: UUID is different from Step 1 (rotated after time sync) | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraensecuuidbv-01-end-node-rotates-uuid-immediately-after-time-sync", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraensecuuidbv-01-end-node-rotates-uuid-immediately-after-time-sync" },"513": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/SEC/UUID/BV-02: UUID rotates every 15 minutes after time sync", "content": "| Attribute | Value | . | Case ID | C83934654 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Get initial TX UUID: print txid | TXID: 0x<uuid> Key check: Note the UUID value | . | 2 | Monitor UUID rotation for 2 rounds. Check UUID every 30 seconds: print txid | Round 1: UUID rotated after ~15 minutes. Round 2: UUID rotated after ~15 minutes. Key check: Each rotation within 14-16 minutes | . | 3 | Verify all collected UUIDs are unique | All UUIDs are unique. Key check: No duplicate UUID detected | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraensecuuidbv-02-uuid-rotates-every-15-minutes-after-time-sync", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraensecuuidbv-02-uuid-rotates-every-15-minutes-after-time-sync" },"514": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/SEC/UUID/BV-03: End Node can exchange UL/DL during UUID rotation", "content": "| Attribute | Value | . | Case ID | C83934655 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Get initial TX UUID: print txid | TXID: 0x<uuid> | . | 2 | Wait for 1st UUID rotation (check every 30s): print txid | TXID: 0x<new_uuid> Key check: UUID rotated (1st rotation detected) | . | 3 | Wait ~14 minutes, then send UL/DL continuously until 2nd UUID rotation: sid send <5-byte-payload> (UL) and send DL from AWS IoT (DL). After 2nd rotation, send one more UL/DL to confirm. | UL: EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4 LINK_MODE: 0 DL: EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: 5, LINK: 4, ... 2nd UUID rotation detected. UL/DL still works after rotation. Key check: UL/DL successful before and after UUID rotation | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraensecuuidbv-03-end-node-can-exchange-uldl-during-uuid-rotation", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraensecuuidbv-03-end-node-can-exchange-uldl-during-uuid-rotation" },"515": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/CONN/REG/BV-02: End Node can be deregistered from Sidewalk network", "content": "| Attribute | Value | . | Case ID | C83934657 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Run the following command to deregister the device: sid factory_reset | CMD: ERR: 0 EVENT SID STATUS: State: 1, Reg: 1, Time: 1, Link_Mask: 0 Key check: Reg: 1 (deregistered) | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnregbv-02-end-node-can-be-deregistered-from-sidewalk-network", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnregbv-02-end-node-can-be-deregistered-from-sidewalk-network" },"516": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/CONN/LP/BV-01: End Node can select Profile A and complete Join procedure", "content": "| Attribute | Value | . | Case ID | C83934658 | . | Executable by Customer | Yes | . Preconditions . | sid option -lp_set 128 5 | sid option -lp_get_l3 | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start LoRa stack with Profile A: sid init 3 sid option -lp_set 128 5 sid start | Each command returns: CMD: ERR: 0 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4 EVENT SID STATUS LINK MODE: LORA: 1, FSK: 0, BLE: 0 Njoin(1, 2) st 2->6 Key check: Time: 0 (time synced), join completed | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnlpbv-01-end-node-can-select-profile-a-and-complete-join-procedure", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnlpbv-01-end-node-can-select-profile-a-and-complete-join-procedure" },"517": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/CONN/LP/BV-02: End Node can select Profile B and complete Join procedure", "content": "| Attribute | Value | . | Case ID | C83934659 | . | Executable by Customer | Yes | . Preconditions . | sid option -lp_set 129 0 | sid option -lp_get_l3 | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start LoRa stack with Profile B: sid init 3 sid option -lp_set 129 0 sid start | Each command returns: CMD: ERR: 0 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4 EVENT SID STATUS LINK MODE: LORA: 1, FSK: 0, BLE: 0 Njoin(1, 2) st 2->6 Key check: Time: 0 (time synced), join completed | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnlpbv-02-end-node-can-select-profile-b-and-complete-join-procedure", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnlpbv-02-end-node-can-select-profile-b-and-complete-join-procedure" },"518": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/CONN/SEQ/BV-01: Uplink packets contain SEQ number", "content": "| Attribute | Value | . | Case ID | C83934660 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 5 UL packets from EN with 10 byte payload: sid send <10-byte-payload> | CMD: ERR: 0 TYPE: 2 ID: <id> EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4 LINK_MODE: 0 ADDITIONAL ATTRS: 0 Key check: UL packets received on AWS | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-01-uplink-packets-contain-seq-number", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-01-uplink-packets-contain-seq-number" },"519": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/CONN/SEQ/BV-02: End Node increments uplink SEQ number until UUID changes", "content": "| Attribute | Value | . | Case ID | C83934661 | . | Executable by Customer | Yes | . Preconditions . | The seq num field should be properly incremented by one for each subsequent packet sent by DUT within a maximum of 15 minutes from the previous UUID change, then a new sequence number should be generated in the range between 0 and 16383. | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 1 UL packet: sid send TEST | LoraTx:EnqPkt sqn:<seq> src_frmt:1 src_id:0x<txid> dst_frmt:0 dst_id:0x<gw_id> msg_id:<id> Key check: Note the SEQ number | . | 2 | Wait for UUID rotation (~15 minutes after time sync) | UUID rotated (TX UUID changes) | . | 3 | Send 1 UL packet after UUID rotation: sid send TEST | LoraTx:EnqPkt sqn:<new_seq> src_frmt:1 src_id:0x<new_txid> dst_frmt:0 dst_id:0x<gw_id> msg_id:<id> Key check: New SEQ number is different from Step 1 (reset after UUID change) | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-02-end-node-increments-uplink-seq-number-until-uuid-changes", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-02-end-node-increments-uplink-seq-number-until-uuid-changes" },"520": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/CONN/SEQ/BV-03: End Node accepts and decodes downlink packets with increased and decreased SEQ", "content": "| Attribute | Value | . | Case ID | C83934662 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 3 DL packets from AWS IoT with SEQ: 1, 2, 3 | All 3 DL packets received and accepted by EN: EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 4, ... Key check: Delivery ratio 100% | . | 2 | Send 3 DL packets from AWS IoT with SEQ: 6, 5, 4 | All 3 DL packets received and accepted by EN: EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 4, ... Key check: Delivery ratio 100% | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-03-end-node-accepts-and-decodes-downlink-packets-with-increased-and-decreased-seq", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-03-end-node-accepts-and-decodes-downlink-packets-with-increased-and-decreased-seq" },"521": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/CONN/SEQ/BV-05: End Node rejects downlink packet with duplicated SEQ", "content": "| Attribute | Value | . | Case ID | C83934663 | . | Executable by Customer | Yes | . Preconditions . | EN MCU <= 1.13 | . Test Steps . | Step | Description | Expected Result | . | 1 | Send DL with SEQ=1, then send DL with SEQ=1 again (duplicate) | First: EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 4, ... (accepted). Second: No EVENT SID RECEIVED within 20 seconds (duplicate rejected). Key check: Duplicate rejected | . | 2 | Send DL with SEQ=2, then send DL with SEQ=2 again (duplicate) | First: EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 4, ... (accepted). Second: No EVENT SID RECEIVED within 20 seconds (duplicate rejected). Key check: Duplicate rejected | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-05-end-node-rejects-downlink-packet-with-duplicated-seq", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-05-end-node-rejects-downlink-packet-with-duplicated-seq" },"522": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/CONN/SEQ/BV-06: End Node rejects downlink packet with duplicated SEQ range", "content": "| Attribute | Value | . | Case ID | C83934664 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 5 DL packets with SEQ: 1, 2, 3, 4, 5 | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 4, ... Key check: All 5 packets received | . | 2 | Send 5 DL packets with SEQ: 1, 2, 3, 4, 5 again (all duplicates) | No EVENT SID RECEIVED for any packet. Key check: All duplicates rejected | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-06-end-node-rejects-downlink-packet-with-duplicated-seq-range", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-06-end-node-rejects-downlink-packet-with-duplicated-seq-range" },"523": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/CONN/SEQ/BV-07: SEQ number can be accepted again after getting 10 other messages", "content": "| Attribute | Value | . | Case ID | C83934665 | . | Executable by Customer | Yes | . Preconditions . | EN MCU <= 1.13 | Seq=1,2,3,4,5,6,7,8,9,10,11,1 | . Test Steps . | Step | Description | Expected Result | . | 1 | Send 10 DL packets from AWS IoT with SEQ: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 | All 10 DL packets received and accepted by EN. Delivery ratio 100% | . | 2 | Send 1 DL packet with SEQ=1 (duplicate) | No EVENT SID RECEIVED within 20 seconds. Key check: Delivery ratio 0% | . | 3 | Send 1 DL packet with SEQ=11 (new, non-duplicate) | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 4, ... Key check: Delivery ratio 100% | . | 4 | Send 1 DL packet with SEQ=1 again (now outside the 10-SEQ window) | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 4, ... Key check: SEQ=1 accepted again after 10 other messages | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-07-seq-number-can-be-accepted-again-after-getting-10-other-messages", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-07-seq-number-can-be-accepted-again-after-getting-10-other-messages" },"524": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/CONN/SEQ/BV-08: SEQ number can be accepted again after End Node reinitialization", "content": "| Attribute | Value | . | Case ID | C83934666 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Send DL packet with SEQ=1 | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 4, ... Key check: Packet accepted | . | 2 | Send DL packet with SEQ=1 again (duplicate) | No EVENT SID RECEIVED within 20 seconds. Key check: Duplicate rejected | . | 3 | Reinitialize Sidewalk stack: sid stop sid deinit sid init 3 sid start | Each command returns: CMD: ERR: 0 Wait for time sync: EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4 Wait for join: Nsync st ->2 | . | 4 | Send DL packet with SEQ=1 again (after reinit) | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 4, ... Key check: SEQ=1 accepted again after reinit | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-08-seq-number-can-be-accepted-again-after-end-node-reinitialization", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-08-seq-number-can-be-accepted-again-after-end-node-reinitialization" },"525": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/CONN/SEQ/BV-09: End Node drops the packet with SEQ which is out of range", "content": "| Attribute | Value | . | Case ID | C83934667 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Send DL packet with SEQ=0 (minimum valid) | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 4, ... Key check: Accepted | . | 2 | Send DL packet with SEQ=16383 (maximum valid) | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: <len>, LINK: 4, ... Key check: Accepted | . | 3 | Send DL packet with SEQ=-1 (out of range) | No EVENT SID RECEIVED within 20 seconds. Key check: Rejected (out of range) | . | 4 | Send DL packet with SEQ=16384 (out of range) | No EVENT SID RECEIVED within 20 seconds. Key check: Rejected (out of range) | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-09-end-node-drops-the-packet-with-seq-which-is-out-of-range", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraenconnseqbv-09-end-node-drops-the-packet-with-seq-which-is-out-of-range" },"526": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/NW-SYNC/JOIN/BV-02: End Node keeps synchronization with the network by periodic transmission of Join request", "content": "| Attribute | Value | . | Case ID | C83934668 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start LoRa stack: sid init 3 sid start Wait for time sync and join | Each command returns: CMD: ERR: 0 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4 Njoin(1, 2) st 2->6 Key check: Time synced and joined | . | 2 | Wait 14 minutes after time sync. Do not send any UL. | No UL packets sent during this period | . | 3 | Wait for join response | Njoin(1, 2) st 2->6 Key check: Join response received (periodic join request) | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraennw-syncjoinbv-02-end-node-keeps-synchronization-with-the-network-by-periodic-transmission-of-join-request", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraennw-syncjoinbv-02-end-node-keeps-synchronization-with-the-network-by-periodic-transmission-of-join-request" },"527": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/NW-SYNC/JOIN/BV-03: End Node keeps synchronization with the network by embedded sync request", "content": "| Attribute | Value | . | Case ID | C83934669 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | EN time-sync and joined | EN is time-synced and joined to the network | . | 2 | Wait 150 seconds, EN send a UL packet | EN receives NTFY_JOIN_REQ | . | 3 | Wait 170 seconds | EN does not send SET_JOIN_REQ in this period | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraennw-syncjoinbv-03-end-node-keeps-synchronization-with-the-network-by-embedded-sync-request", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraennw-syncjoinbv-03-end-node-keeps-synchronization-with-the-network-by-embedded-sync-request" },"528": { "doc": "6. LoRa Test Cases", "title": "Test Case ID: LORA/EN/NW-SYNC/TIME/BV-01: End Node completes the initial time sync procedure", "content": "| Attribute | Value | . | Case ID | C83934670 | . | Executable by Customer | Yes | . Test Steps . | Step | Description | Expected Result | . | 1 | Reboot EN, then initialize and start LoRa stack: reboot sid init 3 sid start Wait for time sync | Each command returns: CMD: ERR: 0 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4 EVENT SID STATUS LINK MODE: LORA: 1, FSK: 0, BLE: 0 Key check: Time: 0 (time synced) | . ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraennw-synctimebv-01-end-node-completes-the-initial-time-sync-procedure", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html#test-case-id-loraennw-synctimebv-01-end-node-completes-the-initial-time-sync-procedure" },"529": { "doc": "6. LoRa Test Cases", "title": "6. LoRa Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/lora-test-cases.html" },"530": { "doc": "11. MAC Address Test Cases", "title": "11. MAC Address Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/mac-address-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/mac-address-test-cases.html" },"531": { "doc": "11. MAC Address Test Cases", "title": "11.1 BLE/EP/BCN/MAC/BV/01: Verify MAC address rotation after registration.", "content": "11.1.1 Test Purpose . DUT BLE MAC address should rotate after registration. 11.1.2 Initial Conditions . | DUT is not registered on Amazon Sidewalk Network. | Lower Tester is a Sidewalk gateway and a BLE sniffer. | Upper Tester operates as a SID API user. | . 11.1.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Un-Registered, No Time, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC1 DUT->>Lower_Tester: Start registration via FFN DUT->>Lower_Tester: Registration success DUT->>Upper_Tester: on_status_changed() \"Status: Registered, No Time, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC2 . 11.1.4 Expected Results . 11.1.4.1 Pass Verdict . MAC1 is different with MAC2. ", "url": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#111-bleepbcnmacbv01-verify-mac-address-rotation-after-registration", "relUrl": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#111-bleepbcnmacbv01-verify-mac-address-rotation-after-registration" },"532": { "doc": "11. MAC Address Test Cases", "title": "11.2 BLE/EP/BCN/MAC/BV/02: Verify MAC address rotation after time sync.", "content": "11.2.1 Test Purpose . DUT BLE MAC address should rotate after time sync. 11.2.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester is a Sidewalk gateway and a BLE sniffer. | Upper Tester operates as a SID API user. | . 11.2.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, No Time, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC1 DUT->>Lower_Tester: Time sync request Lower_Tester->>DUT: Time sync response DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC2 . 11.2.4 Expected Results . 11.2.4.1 Pass Verdict . MAC1 is different with MAC2. ", "url": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#112-bleepbcnmacbv02-verify-mac-address-rotation-after-time-sync", "relUrl": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#112-bleepbcnmacbv02-verify-mac-address-rotation-after-time-sync" },"533": { "doc": "11. MAC Address Test Cases", "title": "11.3 BLE/EP/BCN/MAC/BV/03: Verify MAC address rotates every 15 minutes.", "content": "11.3.1 Test Purpose . DUT BLE MAC address should rotate after time sync every 15 minutes along with TX-UUID. 11.3.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester is a Sidewalk gateway and a BLE sniffer. | Upper Tester operates as a SID API user. | . 11.3.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, No Time, Link Mask 0, BLE Disconnected\" DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC1 Note over Lower_Tester,Upper_Tester: MAC Address will transform within 15 minutes, record it as MAC2 DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: For the next 1 hour and 45 minutes, the MAC address will change every 15 minutes, record them . 11.3.4 Expected Results . 11.3.4.1 Pass Verdict . MAC address and TX-UUID change every 15 minutes. ", "url": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#113-bleepbcnmacbv03-verify-mac-address-rotates-every-15-minutes", "relUrl": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#113-bleepbcnmacbv03-verify-mac-address-rotates-every-15-minutes" },"534": { "doc": "11. MAC Address Test Cases", "title": "11.4 BLE/EP/BCN/MAC/BV/04: Verify MAC address rotation after connection request sent to cloud.", "content": "11.4.1 Test Purpose . DUT BLE MAC address should rotate after connection request sent from EN to cloud. 11.4.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester is a Sidewalk gateway and a BLE sniffer. | Upper Tester operates as a SID API user. | . 11.4.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC1 Upper_Tester->>DUT: sid conn_req 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC2 . 11.4.4 Expected Results . 11.4.4.1 Pass Verdict . MAC1 is different with MAC2. ", "url": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#114-bleepbcnmacbv04-verify-mac-address-rotation-after-connection-request-sent-to-cloud", "relUrl": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#114-bleepbcnmacbv04-verify-mac-address-rotation-after-connection-request-sent-to-cloud" },"535": { "doc": "11. MAC Address Test Cases", "title": "11.5 BLE/EP/BCN/MAC/BV/05: Verify MAC address rotation on disconnection from Sidewalk cloud.", "content": "11.5.1 Test Purpose . DUT BLE MAC address rotated after disconnection. 11.5.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester is a Sidewalk gateway and a BLE sniffer. | Upper Tester operates as a SID API user. | . 11.5.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected Upper_Tester->>DUT: sid conn_req 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC1 DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 1, BLE Connected\" Note over Lower_Tester,Upper_Tester: Idle for 30 seconds DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC2 . 11.5.4 Expected Results . 11.5.4.1 Pass Verdict . MAC1 is different with MAC2. ", "url": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#115-bleepbcnmacbv05-verify-mac-address-rotation-on-disconnection-from-sidewalk-cloud", "relUrl": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#115-bleepbcnmacbv05-verify-mac-address-rotation-on-disconnection-from-sidewalk-cloud" },"536": { "doc": "11. MAC Address Test Cases", "title": "11.6 BLE/EP/BCN/MAC/BV/06: Verify MAC address rotation on downlink reception.", "content": "11.6.1 Test Purpose . DUT BLE MAC address should rotate after receiving a downlink. 11.6.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester is a Sidewalk gateway, a BLE sniffer, and ready on AWS IOT side. | Upper Tester operates as a SID API user. | . 11.6.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC1 Lower_Tester->>DUT: Send a DL DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 1, BLE Connected\" DUT->>Upper_Tester: Receive a DL Note over Lower_Tester,Upper_Tester: Idle for 30 seconds DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC2 . 11.6.4 Expected Results . 11.6.4.1 Pass Verdict . MAC1 is different with MAC2. ", "url": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#116-bleepbcnmacbv06-verify-mac-address-rotation-on-downlink-reception", "relUrl": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#116-bleepbcnmacbv06-verify-mac-address-rotation-on-downlink-reception" },"537": { "doc": "11. MAC Address Test Cases", "title": "11.7 BLE/EP/BCN/MAC/BV/07: Verify MAC address rotation on key refresh.", "content": "11.7.1 Test Purpose . DUT BLE MAC address should rotate after key refresh. 11.7.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester is a Sidewalk gateway, a BLE sniffer, and ready on AWS IOT side. | Upper Tester operates as a SID API user. | . 11.7.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC1 Lower_Tester->>DUT: Trigger a key refresh event DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 1, BLE Connected\" DUT->>Upper_Tester: Key refresh event finish DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC2 . 11.7.4 Expected Results . 11.7.4.1 Pass Verdict . MAC1 is different with MAC2. ", "url": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#117-bleepbcnmacbv07-verify-mac-address-rotation-on-key-refresh", "relUrl": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#117-bleepbcnmacbv07-verify-mac-address-rotation-on-key-refresh" },"538": { "doc": "11. MAC Address Test Cases", "title": "11.8 BLE/EP/BCN/MAC/BV/08: Verify MAC address rotation on long lived connection.", "content": "11.8.1 Test Purpose . DUT BLE MAC address should rotate every 15 minutes if the connection to Sidewalk cloud is maintained beyond 15 minutes. 11.8.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester is a Sidewalk gateway, a BLE sniffer, and ready on AWS IOT side. | Upper Tester operates as a SID API user. | . 11.8.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Time Synced, Link Mask 0, BLE disconnected DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC1 Upper_Tester->>DUT: sid option -ble_con 1 1 1 Upper_Tester->>DUT: sid conn_req 1 DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 1, BLE Connected\" Note over Lower_Tester,Upper_Tester: Wait for 15 minutes Lower_Tester->>DUT: BLE Disconnect to DUT DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon DUT->>Lower_Tester: Beacon Note over Lower_Tester,Upper_Tester: Record beacon MAC address as MAC2 . 11.8.4 Expected Results . 11.8.4.1 Pass Verdict . MAC1 is different with MAC2. ", "url": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#118-bleepbcnmacbv08-verify-mac-address-rotation-on-long-lived-connection", "relUrl": "/specifications/sidewalk-test-spec/mac-address-test-cases.html#118-bleepbcnmacbv08-verify-mac-address-rotation-on-long-lived-connection" },"539": { "doc": "12. MAC Address Rotation Test Cases", "title": "MAC Address Rotation Test Cases", "content": "This section covers test cases for verifying BLE MAC address rotation behavior on Sidewalk Endpoints. MAC address rotation is a privacy mechanism that ensures the BLE beacon MAC address changes on specific events and at regular intervals. ", "url": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#mac-address-rotation-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#mac-address-rotation-test-cases" },"540": { "doc": "12. MAC Address Rotation Test Cases", "title": "Test Case BLE/EP/BCN/MAC/BV/01: Verify MAC address rotation after registration", "content": "| Field | Value | . | Case ID | C103619309 | . | Executable by Customer | Yes | . Preconditions . | BT sniffer is ready to capture BLE beacons | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack and collect MAC address in beacon:sid init 1sid start | CMD: ERR: 0BT sniffer captures BLE beacon with MAC address: <mac_addr_1> | . | 2 | Wait for EN to register and collect MAC address again | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1BT sniffer captures BLE beacon with MAC address: <mac_addr_2> | . | 3 | Check MAC address rotation | mac_addr_1 != mac_addr_2 | . Key check: MAC address rotated after registration (Reg: 0 confirms registered state) . ", "url": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv01-verify-mac-address-rotation-after-registration", "relUrl": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv01-verify-mac-address-rotation-after-registration" },"541": { "doc": "12. MAC Address Rotation Test Cases", "title": "Test Case BLE/EP/BCN/MAC/BV/02: Verify MAC address rotation after time sync", "content": "| Field | Value | . | Case ID | C103619310 | . | Executable by Customer | Yes | . Preconditions . | BT sniffer is ready to capture BLE beacons | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack and collect MAC address before time sync:sid init 1sid start | CMD: ERR: 0EVENT SID STATUS: State: 0, Reg: 0, Time: 1, Link_Mask: 1BT sniffer captures BLE beacon with MAC address: <mac_addr_1>Key check: EN registered (Reg: 0), time not yet synced (Time: 1) | . | 2 | Wait for time sync, wait for BLE disconnected, then collect MAC address again | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0BT sniffer captures BLE beacon with MAC address: <mac_addr_2> | . | 3 | Check MAC address rotation | mac_addr_1 != mac_addr_2 | . Key check: MAC address rotated after time sync (Time: 0 confirms synced state) . ", "url": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv02-verify-mac-address-rotation-after-time-sync", "relUrl": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv02-verify-mac-address-rotation-after-time-sync" },"542": { "doc": "12. MAC Address Rotation Test Cases", "title": "Test Case BLE/EP/BCN/MAC/BV/03: Verify MAC address rotates every 15 minutes", "content": "| Field | Value | . | Case ID | C103619311 | . | Executable by Customer | Yes | . Preconditions . | BT sniffer is ready to capture BLE beacons | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack, wait for time sync, wait another 30s to confirm BLE disconnected:sid init 1sid start | CMD: ERR: 0EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 0EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0Key check: Time synced (Time: 0), BLE disconnected | . | 2 | Monitor 2 MAC address rotations (check every 30s, expect rotation ~15 min) | Round 1: MAC rotated after ~900s (<mac_addr_1> -> <mac_addr_2>)Round 2: MAC rotated after ~900s (<mac_addr_2> -> <mac_addr_3>) | . | 3 | Check MAC address rotation interval | All 3 MAC addresses are unique | . Key check: Each rotation interval is between 840s~960s (14~16 min). MAC rotates every ~15 minutes. ", "url": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv03-verify-mac-address-rotates-every-15-minutes", "relUrl": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv03-verify-mac-address-rotates-every-15-minutes" },"543": { "doc": "12. MAC Address Rotation Test Cases", "title": "Test Case BLE/EP/BCN/MAC/BV/04: Verify MAC address rotation after connection request sent to cloud", "content": "| Field | Value | . | Case ID | C103619312 | . | Executable by Customer | Yes | . Preconditions . | BT sniffer is ready to capture BLE beacons | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack, wait for time sync, wait another 30s to confirm BLE disconnected, collect MAC address:sid init 1sid start | CMD: ERR: 0EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 0EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0BT sniffer captures BLE beacon with MAC address: <mac_addr_1> | . | 2 | Establish BLE connection and collect MAC address:sid conn_req 1 | CMD: ERR: 0EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1BT sniffer captures BLE beacon with MAC address: <mac_addr_2>Key check: BLE connection established (BLE: 1) | . | 3 | Check MAC address rotation | mac_addr_1 != mac_addr_2 | . Key check: MAC address rotated after connection request . ", "url": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv04-verify-mac-address-rotation-after-connection-request-sent-to-cloud", "relUrl": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv04-verify-mac-address-rotation-after-connection-request-sent-to-cloud" },"544": { "doc": "12. MAC Address Rotation Test Cases", "title": "Test Case BLE/EP/BCN/MAC/BV/05: Verify MAC address rotation on disconnection from Sidewalk cloud", "content": "| Field | Value | . | Case ID | C103619313 | . | Executable by Customer | Yes | . Preconditions . | BT sniffer is ready to capture BLE beacons | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack, wait for time sync, wait for BLE disconnected, collect MAC address:sid init 1sid start | CMD: ERR: 0EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 0EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0BT sniffer captures BLE beacon with MAC address: <mac_addr_1> | . | 2 | Establish BLE connection:sid conn_req 1 | CMD: ERR: 0EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1BT sniffer captures BLE beacon with MAC address: <mac_addr_2>Key check: BLE connection established (BLE: 1), MAC rotated on connection | . | 3 | Wait for BLE to disconnect, collect MAC address | EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0BT sniffer captures BLE beacon with MAC address: <mac_addr_3> | . | 4 | Check MAC address rotation after disconnection | mac_addr_2 != mac_addr_3 | . Key check: MAC address rotated after disconnection from Sidewalk cloud . ", "url": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv05-verify-mac-address-rotation-on-disconnection-from-sidewalk-cloud", "relUrl": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv05-verify-mac-address-rotation-on-disconnection-from-sidewalk-cloud" },"545": { "doc": "12. MAC Address Rotation Test Cases", "title": "Test Case BLE/EP/BCN/MAC/BV/06: Verify MAC address rotation on downlink reception", "content": "| Field | Value | . | Case ID | C103619314 | . | Executable by Customer | Yes | . Preconditions . | BT sniffer is ready to capture BLE beacons | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack, wait for time sync, wait for BLE disconnected, collect MAC address:sid init 1sid start | CMD: ERR: 0EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 0EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0BT sniffer captures BLE beacon with MAC address: <mac_addr_1> | . | 2 | Send DL from AWS IoT | EVENT SID RECEIVED: TYPE: 2, ID: <id>, LEN: <len>, LINK: 1, LINK_MODE: 1, ACK_REQUESTED: 0, ACK: 0, DUP: 0, RSSI: <rssi>, SNR: <snr>Key check: DL received through BLE (LINK: 1) | . | 3 | Wait for BLE to disconnect, collect MAC address | EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0BT sniffer captures BLE beacon with MAC address: <mac_addr_2> | . | 4 | Check MAC address rotation | mac_addr_1 != mac_addr_2 | . Key check: MAC address rotated after downlink reception . ", "url": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv06-verify-mac-address-rotation-on-downlink-reception", "relUrl": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv06-verify-mac-address-rotation-on-downlink-reception" },"546": { "doc": "12. MAC Address Rotation Test Cases", "title": "Test Case BLE/EP/BCN/MAC/BV/07: Verify MAC address rotation on key refresh", "content": "| Field | Value | . | Case ID | C103619315 | . | Executable by Customer | No | . Preconditions . | Nordic-based BT sniffer connected to PC | . Test Steps . | Step | Description | Expected Result | . | 1 | Setup Nordic-based BT sniffer, connect it to PC and start sniffing packets | Sniffer gives possibility to capture BT traffic (beacons) including MAC address sent over the air | . | 2 | Trigger key refresh | BLE connection is established and key refresh is completed | . | 3 | Wait until BLE connection is disconnected | MAC address has rotated and is different than in previous step | . Key check: MAC address rotated after key refresh event . ", "url": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv07-verify-mac-address-rotation-on-key-refresh", "relUrl": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv07-verify-mac-address-rotation-on-key-refresh" },"547": { "doc": "12. MAC Address Rotation Test Cases", "title": "Test Case BLE/EP/BCN/MAC/BV/08: Verify MAC address rotation on long lived connection", "content": "| Field | Value | . | Case ID | C103619316 | . | Executable by Customer | Yes | . Preconditions . | BT sniffer is ready to capture BLE beacons | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE stack, wait for time sync, wait for BLE disconnected, collect MAC address:sid init 1sid start | CMD: ERR: 0EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 0EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0BT sniffer captures BLE beacon with MAC address: <mac_addr_1> | . | 2 | Set long lived connection policy:ble_policy 1 1 1 | CMD: ERR: 0BLE conn policy 1Key check: Long lived policy set | . | 3 | Establish BLE connection:sid conn_req 1 | CMD: ERR: 0EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1Key check: BLE connection established (BLE: 1) | . | 4 | Wait 15 minutes and verify BLE is still connected | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1Key check: BLE still connected after 15 min (Link_Mask: 1) | . | 5 | Set default policy and wait for BLE to disconnect, collect MAC address:ble_policy 1 0 | CMD: ERR: 0EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0BT sniffer captures BLE beacon with MAC address: <mac_addr_2> | . | 6 | Check MAC address rotation | mac_addr_1 != mac_addr_2 | . Key check: MAC address rotated after long lived connection ended . ", "url": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv08-verify-mac-address-rotation-on-long-lived-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html#test-case-bleepbcnmacbv08-verify-mac-address-rotation-on-long-lived-connection" },"548": { "doc": "12. MAC Address Rotation Test Cases", "title": "12. MAC Address Rotation Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/mac-address-test-cases.html" },"549": { "doc": "7. Multi-link Test Cases", "title": "7. Multi-link Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html" },"550": { "doc": "7. Multi-link Test Cases", "title": "7.1 MULTI-LINK/EP/BLE-AUTO-CONNECT/UL/BI/01: Send UL without auto-connect, DUT is BLE disconnected (Link_Mask 0).", "content": "7.1.1 Test Purpose . A registered DUT without enabling BLE auto-connect shouldn’t attempt to establish a BLE connection with the Lower Tester and send uplink via BLE when sending an uplink with a Link_Mask 0 status. Instead, the DUT should report a proper error message to the Upper Tester. 7.1.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | . 7.1.3 Test Procedure . sequenceDiagram participant DUT as DUT participant Upper_Tester as Upper Tester Note over DUT,Upper_Tester: Sidewalk application started Note over DUT,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_send_error(SID_ERROR_INVALID_STATE) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 7.1.4 Expected Results . 7.1.4.1 Pass Verdict . The DUT should report the proper error message, SID_ERROR_INVALID_STATE, to the Upper Tester. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#71-multi-linkepble-auto-connectulbi01-send-ul-without-auto-connect-dut-is-ble-disconnected-link_mask-0", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#71-multi-linkepble-auto-connectulbi01-send-ul-without-auto-connect-dut-is-ble-disconnected-link_mask-0" },"551": { "doc": "7. Multi-link Test Cases", "title": "7.2 MULTI-LINK/EP/BLE-AUTO-CONNECT/UL/BV/02: Send UL with auto-connect, ack is true, retry is 3, TTL is 60.", "content": "7.2.1 Test Purpose . A registered DUT enabling BLE auto-connect should attempt to establish a BLE connection with the Lower Tester and send uplink via BLE when sending an uplink with a Link_Mask 0 status. 7.2.2 Initial Conditions . | The Sidewalk stack (BLE) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | . 7.2.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 1 1 5 30 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any, Ack: True, Retries: 3, TTL: 60) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 7.2.4 Expected Results . 7.2.4.1 Pass Verdict . A registered DUT should successfully establish a BLE connection with the Lower Tester and send an uplink. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#72-multi-linkepble-auto-connectulbv02-send-ul-with-auto-connect-ack-is-true-retry-is-3-ttl-is-60", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#72-multi-linkepble-auto-connectulbv02-send-ul-with-auto-connect-ack-is-true-retry-is-3-ttl-is-60" },"552": { "doc": "7. Multi-link Test Cases", "title": "7.3 MULTI-LINK/EP/FSK-AUTO-CONNECT/UL/BI/01: Send UL without auto-connect, DUT is FSK disconnected (Link_Mask 0).", "content": "7.3.1 Test Purpose . A registered DUT without enabling FSK auto-connect shouldn’t attempt to establish a FSK connection with the Lower Tester and send uplink via FSK when sending an uplink with a Link_Mask 0 status. Instead, the DUT should report a proper error message to the Upper Tester. 7.3.2 Initial Conditions . | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in FSK mode. | . 7.3.3 Test Procedure . sequenceDiagram participant DUT as DUT participant Upper_Tester as Upper Tester Note over DUT,Upper_Tester: Sidewalk application started Note over DUT,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_send_error(SID_ERROR_INVALID_STATE) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 7.3.4 Expected Results . 7.3.4.1 Pass Verdict . The DUT should report the proper error message, SID_ERROR_INVALID_STATE, to the Upper Tester. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#73-multi-linkepfsk-auto-connectulbi01-send-ul-without-auto-connect-dut-is-fsk-disconnected-link_mask-0", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#73-multi-linkepfsk-auto-connectulbi01-send-ul-without-auto-connect-dut-is-fsk-disconnected-link_mask-0" },"553": { "doc": "7. Multi-link Test Cases", "title": "7.4 MULTI-LINK/EP/FSK-AUTO-CONNECT/UL/BV/02: Send UL with auto-connect, ack is true, retry is 3, TTL is 60.", "content": "7.4.1 Test Purpose . A registered DUT enabling FSK auto-connect should attempt to establish a FSK connection with the Lower Tester and send uplink via FSK when sending an uplink with a Link_Mask 0 status. 7.4.2 Initial Conditions . | The Sidewalk stack (FSK) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in FSK mode. | . 7.4.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 2 1 20 90 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any, Ack: True, Retries: 3, TTL: 60) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 2, FSK connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 7.4.4 Expected Results . 7.4.4.1 Pass Verdict . A registered DUT should successfully establish a FSK connection with the Lower Tester and send an uplink. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#74-multi-linkepfsk-auto-connectulbv02-send-ul-with-auto-connect-ack-is-true-retry-is-3-ttl-is-60", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#74-multi-linkepfsk-auto-connectulbv02-send-ul-with-auto-connect-ack-is-true-retry-is-3-ttl-is-60" },"554": { "doc": "7. Multi-link Test Cases", "title": "7.5 MULTI-LINK/EP/LoRa-AUTO-CONNECT/UL/BI/01: Send UL without auto-connect, DUT is LoRa disconnected (Link_Mask 0).", "content": "7.5.1 Test Purpose . A registered DUT without enabling LoRa auto-connect shouldn’t attempt to establish a LoRa connection with the Lower Tester and send uplink via LoRa when sending an uplink with a Link_Mask 0 status. Instead, the DUT should report a proper error message to the Upper Tester. 7.5.2 Initial Conditions . | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode. | . 7.5.3 Test Procedure . sequenceDiagram participant DUT as DUT participant Upper_Tester as Upper Tester Note over DUT,Upper_Tester: Sidewalk application started Note over DUT,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: on_send_error(SID_ERROR_INVALID_STATE) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 7.5.4 Expected Results . 7.5.4.1 Pass Verdict . The DUT should report the proper error message, SID_ERROR_INVALID_STATE, to the Upper Tester. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#75-multi-linkeplora-auto-connectulbi01-send-ul-without-auto-connect-dut-is-lora-disconnected-link_mask-0", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#75-multi-linkeplora-auto-connectulbi01-send-ul-without-auto-connect-dut-is-lora-disconnected-link_mask-0" },"555": { "doc": "7. Multi-link Test Cases", "title": "7.6 MULTI-LINK/EP/LoRa-AUTO-CONNECT/UL/BV/02: Send UL with auto-connect, ack is true, retry is 3, TTL is 60.", "content": "7.6.1 Test Purpose . A registered DUT enabling LoRa auto-connect should attempt to establish a LoRa connection with the Lower Tester and send uplink via LoRa when sending an uplink with a Link_Mask 0 status. 7.6.2 Initial Conditions . | The Sidewalk stack (LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode. | . 7.6.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 3 1 30 120 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any, Ack: True, Retries: 3, TTL: 60) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 4, LoRa connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 7.6.4 Expected Results . 7.6.4.1 Pass Verdict . A registered DUT should successfully establish a LoRa connection with the Lower Tester and send an uplink. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#76-multi-linkeplora-auto-connectulbv02-send-ul-with-auto-connect-ack-is-true-retry-is-3-ttl-is-60", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#76-multi-linkeplora-auto-connectulbv02-send-ul-with-auto-connect-ack-is-true-retry-is-3-ttl-is-60" },"556": { "doc": "7. Multi-link Test Cases", "title": "7.7 MULTI-LINK/EP/BLE-LoRa-AUTO-CONNECT/UL/BV/01: Send UL with auto-connect when BLE link priority is higher than LoRa, EN Link_Mask is 0, Specify BLE+LoRa link.", "content": "7.7.1 Test Purpose . A registered DUT that enables BLE, and LoRa auto-connect should attempt to establish a connection with each link type according to the configured link priority and send an uplink via the connected link type. Given the BLE>LoRa link priority and enabling BLE on the Lower Tester, the DUT should attempt to establish a BLE connection with the Lower Tester and automatically send the uplink when sending an uplink with a Link_Mask 0 status. 7.7.2 Initial Conditions . | The Sidewalk stack (BLE+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | . 7.7.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 1 1 10 30 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 3 1 30 120 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any, Ack: True, Retries: 3, TTL: 60) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 7.7.4 Expected Results . 7.7.4.1 Pass Verdict . A registered DUT should successfully establish a BLE connection with the Lower Tester and send an uplink. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#77-multi-linkepble-lora-auto-connectulbv01-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link_mask-is-0-specify-blelora-link", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#77-multi-linkepble-lora-auto-connectulbv01-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link_mask-is-0-specify-blelora-link" },"557": { "doc": "7. Multi-link Test Cases", "title": "7.8 MULTI-LINK/EP/BLE-LoRa-AUTO-CONNECT/UL/BV/02: Send UL with auto-connect when BLE link priority is higher than LoRa, EN Link_Mask is 0, Specify BLE+LoRa link, disable BLE on GW.", "content": "7.8.1 Test Purpose . A registered DUT that enables BLE and LoRa auto-connect should attempt to establish a connection with each link type according to the configured link priority and send an uplink via the connected link type. Given the BLE>LoRa link priority and enabling LoRa on the Lower Tester, the DUT should first attempt to establish a BLE connection, which will fail. Afterward, it should attempt to establish a LoRa connection with the Lower Tester and automatically send the uplink when sending an uplink with a Link_Mask 0 status. 7.8.2 Initial Conditions . | The Sidewalk stack (BLE+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode. | . 7.8.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 1 1 10 30 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 3 1 30 120 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any, Ack: True, Retries: 3, TTL: 60) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection failed DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 4, LoRa connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 7.8.4 Expected Results . 7.8.4.1 Pass Verdict . A registered DUT should attempt to establish a BLE connection and fail. Afterward, it should attempt to establish a LoRa connection with the Lower Tester and automatically send the uplink when sending an uplink with a Link_Mask 0 status . ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#78-multi-linkepble-lora-auto-connectulbv02-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link_mask-is-0-specify-blelora-link-disable-ble-on-gw", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#78-multi-linkepble-lora-auto-connectulbv02-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link_mask-is-0-specify-blelora-link-disable-ble-on-gw" },"558": { "doc": "7. Multi-link Test Cases", "title": "7.9 MULTI-LINK/EP/BLE-LoRa-AUTO-CONNECT/UL/BV/03: Send UL with auto-connect when BLE link priority is higher than LoRa, EN Link_Mask is 0, disables BLE & LoRa on GW.", "content": "7.9.1 Test Purpose . A registered DUT that enables BLE, and LoRa auto-connect should attempt to establish a connection with each link type according to the configured link priority and send an uplink via the connected link type. The DUT will stop the connection search process if it can’t connect with the proper link type before the TTL has expired. Given the BLE>LoRa link priority and enabling LoRa on the Lower Tester, the DUT should first attempt to establish a BLE connection, which will fail. Afterward, it should attempt to establish a LoRa connection, which will also fail. The DUT will repeat the same process and stop the process after the TTL has expired. 7.9.2 Initial Conditions . | The Sidewalk stack (BLE+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester disables BLE&LoRa mode . | . 7.9.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 1 1 10 30 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 3 1 30 120 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any, Ack: True, Retries: 3, TTL: 60) DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Start the auto-connect process DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection failed DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: LoRa connection attempt timeout Note over Lower_Tester,Upper_Tester: Repeat the above process until TTL expires Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&LoRa Disconnected\" . 7.9.4 Expected Results . 7.9.4.1 Pass Verdict . A registered DUT should first attempt to establish a BLE connection, which will fail. Afterward, it should attempt to establish a LoRa connection, which will also fail. The DUT will repeat the same process and stop the process after the TTL has expired. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#79-multi-linkepble-lora-auto-connectulbv03-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link_mask-is-0-disables-ble--lora-on-gw", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#79-multi-linkepble-lora-auto-connectulbv03-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link_mask-is-0-disables-ble--lora-on-gw" },"559": { "doc": "7. Multi-link Test Cases", "title": "7.10 MULTI-LINK/EP/BLE-LoRa-AUTO-CONNECT/UL/BV/04: Send UL with auto-connect when BLE link priority is higher than LoRa, EN Link_Mask is 0, Specify FSK link.", "content": "7.10.1 Test Purpose . For an auto-connect registered DUT, when the link mask in the sid_put message does not have the auto-connect enabled, an error is returned, and the link connection is not established. 7.10.2 Initial Conditions . | The Sidewalk stack (BLE+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode . | . 7.10.3 Test Procedure . sequenceDiagram participant DUT as DUT participant Upper_Tester as Upper Tester Note over DUT,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 1 1 10 30 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 3 1 30 120 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over DUT,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any, LinkType: FSK) DUT->>Upper_Tester: on_send_error(SID_ERROR_NO_ROUTE_AVAILABLE) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&LoRa Disconnected\" . 7.10.4 Expected Results . 7.10.4.1 Pass Verdict . The DUT should report the proper error message, SID_ERROR_NO_ROUTE_AVAILABLE, to the Upper Tester. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#710-multi-linkepble-lora-auto-connectulbv04-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link_mask-is-0-specify-fsk-link", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#710-multi-linkepble-lora-auto-connectulbv04-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link_mask-is-0-specify-fsk-link" },"560": { "doc": "7. Multi-link Test Cases", "title": "7.11 MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/01: UL sent through BLE when no connection.", "content": "7.11.1 Test Purpose . A registered DUT that enables BLE, FSK, and LoRa auto-connect should attempt to establish a connection with each link type according to the configured link priority and send an uplink via the connected link type. Given the BLE>FSK>LoRa link priority and enabling BLE on the Lower Tester, the DUT should attempt to establish a BLE connection with the Lower Tester and automatically send the uplink when sending an uplink with a Link_Mask 0 status. 7.11.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode . | . 7.11.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 1 1 10 30 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 2 1 20 90 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 3 1 30 120 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any, Ack: True, Retries: 3, TTL: 60) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 7.11.4 Expected Results . 7.11.4.1 Pass Verdict . A registered DUT should successfully establish a BLE connection with the Lower Tester and send an uplink. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#711-multi-linkepble-fsk-lora-auto-connectulbv01-ul-sent-through-ble-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#711-multi-linkepble-fsk-lora-auto-connectulbv01-ul-sent-through-ble-when-no-connection" },"561": { "doc": "7. Multi-link Test Cases", "title": "7.12 MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/02: UL sent through FSK when no connection.", "content": "7.12.1 Test Purpose . A registered DUT that enables BLE, FSK, and LoRa auto-connect should attempt to establish a connection with each link type according to the configured link priority and send an uplink via the connected link type. Given the BLE>FSK>LoRa link priority and enabling FSK on the Lower Tester, the DUT should first attempt to establish a BLE connection, which will fail. Subsequently, it should then attempt to establish an FSK connection with the Lower Tester and automatically send the uplink when sending an uplink with a Link_Mask 0 status. 7.12.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in FSK mode . | . 7.12.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 1 1 10 30 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 2 1 20 90 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 3 1 30 120 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any, Ack: True, Retries: 3, TTL: 60) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 2, FSK connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 7.12.4 Expected Results . 7.12.4.1 Pass Verdict . A registered DUT should attempt to establish a BLE connection and fail. It should then try to establish an FSK connection with the Lower Tester and send the uplink automatically when sending an uplink with a Link_Mask 0 status. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#712-multi-linkepble-fsk-lora-auto-connectulbv02-ul-sent-through-fsk-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#712-multi-linkepble-fsk-lora-auto-connectulbv02-ul-sent-through-fsk-when-no-connection" },"562": { "doc": "7. Multi-link Test Cases", "title": "7.13 MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/03: UL sent through LoRa when no connection.", "content": "7.13.1 Test Purpose . A registered DUT that enables BLE, FSK, and LoRa auto-connect should attempt to establish a connection with each link type according to the configured link priority and send an uplink via the connected link type. Given the BLE>FSK>LoRa link priority and enabling LoRa on the Lower Tester, the DUT should first attempt to establish a BLE connection, which will fail. Subsequently, it should then attempt to establish an FSK connection, which will also fail. Afterward, it should attempt to establish a LoRa connection with the Lower Tester and automatically send the uplink when sending an uplink with a Link_Mask 0 status. 7.13.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode . | . 7.13.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 1 1 10 30 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 2 1 20 90 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 3 1 30 120 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any, Ack: True, Retries: 3, TTL: 60) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: FSK connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 4, LoRa connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 7.13.4 Expected Results . 7.13.4.1 Pass Verdict . A registered DUT should attempt to establish a BLE connection and fail. It should then try to establish an FSK connection and fail. Afterward, it should attempt to establish a LoRa connection with the Lower Tester and automatically send the uplink when sending an uplink with a Link_Mask 0 status . ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#713-multi-linkepble-fsk-lora-auto-connectulbv03-ul-sent-through-lora-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#713-multi-linkepble-fsk-lora-auto-connectulbv03-ul-sent-through-lora-when-no-connection" },"563": { "doc": "7. Multi-link Test Cases", "title": "7.14 MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable.", "content": "7.14.1 Test Purpose . A registered DUT that enables BLE, FSK, and LoRa auto-connect should attempt to establish a connection with each link type according to the configured link priority and send an uplink via the connected link type. The DUT will stop the connection search process if it can’t connect with the proper link type before the TTL has expired. Given the BLE>FSK>LoRa link priority and disabling BLE&FSK&LoRa on the Lower Tester, the DUT should first attempt to establish a BLE connection, which will fail. Subsequently, it should then attempt to establish an FSK connection, which will also fail. Afterward, it should attempt to establish a LoRa connection, which will also fail. The DUT will repeat the same process and stop the process after the TTL has expired. 7.14.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester disables BLE & FSK & LoRa mode . | . 7.14.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 1 1 10 30 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 2 1 20 90 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 3 1 30 120 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any, Ack: True, Retries: 3, TTL: 60) DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Start the auto-connect process DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: FSK connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: LoRa connection attempt timeout Note over Lower_Tester,Upper_Tester: Repeat the above process until TTL expires Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&FSK&LORa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&FSK&LORa Disconnected\" . 7.14.4 Expected Results . 7.14.4.1 Pass Verdict . A registered DUT should first attempt to establish a BLE connection, which will fail. Subsequently, it should then attempt to establish an FSK connection, which will also fail. Afterward, it should attempt to establish a LoRa connection, which will also fail. The DUT will repeat the same process and stop the process after the TTL has expired. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#714-multi-linkepble-fsk-lora-auto-connectulbv04-ul-not-send-when-no-connection-and-blefsklora-unavailable", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#714-multi-linkepble-fsk-lora-auto-connectulbv04-ul-not-send-when-no-connection-and-blefsklora-unavailable" },"564": { "doc": "7. Multi-link Test Cases", "title": "7.15 MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/05: UL sent through BLE when EN’s Link_Mask is 1.", "content": "7.15.1 Test Purpose . When the link is connected, a registered auto-connect DUT does not initiate a connection but sends out a message on the connected link. 7.15.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates BLE mode. | . 7.15.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 1 1 10 30 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 2 1 20 90 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -c 3 1 30 120 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid conn_req 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&FSK&LORa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&FSK&LORa Disconnected\" . 7.15.4 Expected Results . 7.15.4.1 Pass Verdict . A registered DUT should send an uplink via BLE directly. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#715-multi-linkepble-fsk-lora-auto-connectulbv05-ul-sent-through-ble-when-ens-link_mask-is-1", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#715-multi-linkepble-fsk-lora-auto-connectulbv05-ul-sent-through-ble-when-ens-link_mask-is-1" },"565": { "doc": "7. Multi-link Test Cases", "title": "7.16 MULTI-LINK/EP/MLM-ACTIVE/UL/BV/01: UL sent through BLE when no connection.", "content": "7.16.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM ACTIVE policy, which is BLE>FSK>LoRa. 7.16.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode . | . 7.16.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 0 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 7.16.4 Expected Results . 7.16.4.1 Pass Verdict . A registered DUT should successfully establish a BLE connection with the Lower Tester and send an uplink. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#716-multi-linkepmlm-activeulbv01-ul-sent-through-ble-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#716-multi-linkepmlm-activeulbv01-ul-sent-through-ble-when-no-connection" },"566": { "doc": "7. Multi-link Test Cases", "title": "7.17 MULTI-LINK/EP/MLM-ACTIVE/UL/BV/02: UL sent through FSK when no connection.", "content": "7.17.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM ACTIVE policy, which is BLE>FSK>LoRa. 7.17.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in FSK mode . | . 7.17.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 0 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 2, FSK connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 7.17.4 Expected Results . 7.17.4.1 Pass Verdict . A registered DUT should try to connect with BLE and fail, then attempt to connect with FSK on the Lower Tester and send the uplink automatically when sending an uplink with a Link_Mask 0 status. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#717-multi-linkepmlm-activeulbv02-ul-sent-through-fsk-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#717-multi-linkepmlm-activeulbv02-ul-sent-through-fsk-when-no-connection" },"567": { "doc": "7. Multi-link Test Cases", "title": "7.18 MULTI-LINK/EP/MLM-ACTIVE/UL/BV/03: UL sent through LoRa when no connection.", "content": "7.18.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM ACTIVE policy, which is BLE>FSK>LoRa. 7.18.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode . | . 7.18.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 0 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: FSK connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 4, LoRa connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 7.18.4 Expected Results . 7.18.4.1 Pass Verdict . A registered DUT should try to connect with BLE and fail, then attempt to connect with FSK and fail. Afterward, it should attempt to connect with LoRa on the Lower Tester and send the uplink automatically when sending an uplink with a Link_Mask 0 status. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#718-multi-linkepmlm-activeulbv03-ul-sent-through-lora-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#718-multi-linkepmlm-activeulbv03-ul-sent-through-lora-when-no-connection" },"568": { "doc": "7. Multi-link Test Cases", "title": "7.19 MULTI-LINK/EP/MLM-ACTIVE/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable.", "content": "7.19.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type. The DUT will halt the connection search process if it cannot connect with the proper link type before the TTL has expired. Once the TTL has expired, a background process may or may not be triggered according to the configured MLM policy. For MLM ACTIVE, the background process should not be triggered. The TTL will be equal to the LoRa link type’s TTL. 7.19.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester disables BLE & FSK & LoRa mode . | . 7.19.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 0 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Start the auto-connect process DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: FSK connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: LoRa connection attempt timeout Note over Lower_Tester,Upper_Tester: Repeat the above process until TTL expires DUT->>Upper_Tester: Disable background process Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&FSK&LORa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&FSK&LORa Disconnected\" . 7.19.4 Expected Results . 7.19.4.1 Pass Verdict . A registered DUT should attempt to connect with BLE and fail, then try to connect with FSK and fail, and attempt to connect with LoRa and fail. The DUT will repeat the same process and stop it after the TTL has expired. Once the TTL is expired, the background process should not be triggered (indicating that the DUT will not attempt to connect with each link type). ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#719-multi-linkepmlm-activeulbv04-ul-not-send-when-no-connection-and-blefsklora-unavailable", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#719-multi-linkepmlm-activeulbv04-ul-not-send-when-no-connection-and-blefsklora-unavailable" },"569": { "doc": "7. Multi-link Test Cases", "title": "7.20 MULTI-LINK/EP/MLM-ACTIVE/UL/BV/05: UL sent through BLE when EN’s Link_Mask is 1.", "content": "7.20.1 Test Purpose . When the link is connected, a registered MLM ACTIVE DUT does not initiate a connection but sends out a message on the connected link. 7.20.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates BLE mode. | . 7.20.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 0 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid conn_req 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&FSK&LORa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&FSK&LORa Disconnected\" . 7.20.4 Expected Results . 7.20.4.1 Pass Verdict . A registered DUT should send an uplink via BLE directly. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#720-multi-linkepmlm-activeulbv05-ul-sent-through-ble-when-ens-link_mask-is-1", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#720-multi-linkepmlm-activeulbv05-ul-sent-through-ble-when-ens-link_mask-is-1" },"570": { "doc": "7. Multi-link Test Cases", "title": "7.21 MULTI-LINK/EP/MLM-POWER/UL/BV/01: UL sent through BLE when no connection.", "content": "7.21.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM POWER policy, which is BLE>FSK>LoRa. 7.21.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode . | . 7.21.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 7.21.4 Expected Results . 7.21.4.1 Pass Verdict . A registered DUT should successfully establish a BLE connection with the Lower Tester and send an uplink. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#721-multi-linkepmlm-powerulbv01-ul-sent-through-ble-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#721-multi-linkepmlm-powerulbv01-ul-sent-through-ble-when-no-connection" },"571": { "doc": "7. Multi-link Test Cases", "title": "7.22 MULTI-LINK/EP/MLM-POWER/UL/BV/02: UL sent through FSK when no connection.", "content": "7.22.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM POWER policy, which is BLE>FSK>LoRa. 7.22.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in FSK mode . | . 7.22.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 2, FSK connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 7.22.4 Expected Results . 7.22.4.1 Pass Verdict . A registered DUT should try to connect with BLE and fail, then attempt to connect with FSK on the Lower Tester and send the uplink automatically when sending an uplink with a Link_Mask 0 status. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#722-multi-linkepmlm-powerulbv02-ul-sent-through-fsk-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#722-multi-linkepmlm-powerulbv02-ul-sent-through-fsk-when-no-connection" },"572": { "doc": "7. Multi-link Test Cases", "title": "7.23 MULTI-LINK/EP/MLM-POWER/UL/BV/03: UL sent through LoRa when no connection.", "content": "7.23.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM POWER policy, which is BLE>FSK>LoRa. 7.23.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode . | . 7.23.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: FSK connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 4, LoRa connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 7.23.4 Expected Results . 7.23.4.1 Pass Verdict . A registered DUT should try to connect with BLE and fail, then attempt to connect with FSK and fail. Afterward, it should attempt to connect with LoRa on the Lower Tester and send the uplink automatically when sending an uplink with a Link_Mask 0 status. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#723-multi-linkepmlm-powerulbv03-ul-sent-through-lora-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#723-multi-linkepmlm-powerulbv03-ul-sent-through-lora-when-no-connection" },"573": { "doc": "7. Multi-link Test Cases", "title": "7.24 MULTI-LINK/EP/MLM-POWER/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable.", "content": "7.24.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type. The DUT will halt the connection search process if it cannot connect with the proper link type before the TTL has expired. Once the TTL has expired, a background process may or may not be triggered according to the configured MLM policy. For MLM POWER, the background process should not be triggered. The TTL will be equal to the LoRa link type’s TTL. 7.24.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester disables BLE & FSK & LoRa mode . | . 7.24.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Start the auto-connect process DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: FSK connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: LoRa connection attempt timeout Note over Lower_Tester,Upper_Tester: Repeat the above process until TTL expires DUT->>Upper_Tester: Disable background process Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&FSK&LORa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&FSK&LORa Disconnected\" . 7.24.4 Expected Results . 7.24.4.1 Pass Verdict . A registered DUT should attempt to connect with BLE and fail, then try to connect with FSK and fail, and attempt to connect with LoRa and fail. The DUT will repeat the same process and stop it after the TTL has expired. Once the TTL is expired, the background process should not be triggered (indicating that the DUT will not attempt to connect with each link type). ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#724-multi-linkepmlm-powerulbv04-ul-not-send-when-no-connection-and-blefsklora-unavailable", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#724-multi-linkepmlm-powerulbv04-ul-not-send-when-no-connection-and-blefsklora-unavailable" },"574": { "doc": "7. Multi-link Test Cases", "title": "7.25 MULTI-LINK/EP/MLM-POWER/UL/BV/05: UL sent through BLE when EN’s Link_Mask is 1.", "content": "7.25.1 Test Purpose . When the link is connected, a registered MLM POWER DUT does not initiate a connection but sends out a message on the connected link. 7.25.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates BLE mode. | . 7.25.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid conn_req 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&FSK&LORa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&FSK&LORa Disconnected\" . 7.25.4 Expected Results . 7.25.4.1 Pass Verdict . A registered DUT should send an uplink via BLE directly. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#725-multi-linkepmlm-powerulbv05-ul-sent-through-ble-when-ens-link_mask-is-1", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#725-multi-linkepmlm-powerulbv05-ul-sent-through-ble-when-ens-link_mask-is-1" },"575": { "doc": "7. Multi-link Test Cases", "title": "7.26 MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/01: UL sent through BLE when no connection.", "content": "7.26.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM PERFORMANCE policy, which is BLE>FSK>LoRa. 7.26.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode . | . 7.26.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 7.26.4 Expected Results . 7.26.4.1 Pass Verdict . A registered DUT should successfully establish a BLE connection with the Lower Tester and send an uplink. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#726-multi-linkepmlm-performanceulbv01-ul-sent-through-ble-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#726-multi-linkepmlm-performanceulbv01-ul-sent-through-ble-when-no-connection" },"576": { "doc": "7. Multi-link Test Cases", "title": "7.27 MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/02: UL sent through FSK when no connection.", "content": "7.27.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM PERFORMANCE policy, which is BLE>FSK>LoRa. 7.27.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in FSK mode . | . 7.27.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 2, FSK connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 7.27.4 Expected Results . 7.27.4.1 Pass Verdict . A registered DUT should try to connect with BLE and fail, then attempt to connect with FSK on the Lower Tester and send the uplink automatically when sending an uplink with a Link_Mask 0 status. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#727-multi-linkepmlm-performanceulbv02-ul-sent-through-fsk-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#727-multi-linkepmlm-performanceulbv02-ul-sent-through-fsk-when-no-connection" },"577": { "doc": "7. Multi-link Test Cases", "title": "7.28 MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/03: UL sent through LoRa when no connection.", "content": "7.28.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM PERFORMANCE policy, which is BLE>FSK>LoRa. 7.28.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode . | . 7.28.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: FSK connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 4, LoRa connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 7.28.4 Expected Results . 7.28.4.1 Pass Verdict . A registered DUT should try to connect with BLE and fail, then attempt to connect with FSK and fail. Afterward, it should attempt to connect with LoRa on the Lower Tester and send the uplink automatically when sending an uplink with a Link_Mask 0 status. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#728-multi-linkepmlm-performanceulbv03-ul-sent-through-lora-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#728-multi-linkepmlm-performanceulbv03-ul-sent-through-lora-when-no-connection" },"578": { "doc": "7. Multi-link Test Cases", "title": "7.29 MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable.", "content": "7.29.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type. The DUT will halt the connection search process if it cannot connect with the proper link type before the TTL has expired. Once the TTL has expired, a background process may or may not be triggered according to the configured MLM policy. For MLM PERFORMANCE, the background process should be triggered. The DUT will perform the background process (BLE>FSK>LoRa) indefinitely. The TTL will be equal to the LoRa link type’s TTL. 7.29.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester disables BLE & FSK & LoRa mode . | . 7.29.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Start the auto-connect process DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: FSK connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: LoRa connection attempt timeout Note over Lower_Tester,Upper_Tester: Repeat the above process until TTL expires DUT->>Upper_Tester: Disable background process Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&FSK&LORa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&FSK&LORa Disconnected\" . 7.29.4 Expected Results . 7.29.4.1 Pass Verdict . A registered DUT should attempt to connect with BLE and fail, then try to connect with FSK and fail, and finally attempt to connect with LoRa and fail. This process should be repeated until the TTL expires. Once the TTL has expired, the background process should be triggered. The DUT will then try to connect with BLE, FSK, and LoRa indefinitely. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#729-multi-linkepmlm-performanceulbv04-ul-not-send-when-no-connection-and-blefsklora-unavailable", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#729-multi-linkepmlm-performanceulbv04-ul-not-send-when-no-connection-and-blefsklora-unavailable" },"579": { "doc": "7. Multi-link Test Cases", "title": "7.30 MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/05: UL sent through BLE when EN’s Link_Mask is 1.", "content": "7.30.1 Test Purpose . When the link is connected, a registered MLM PERFORMANCE DUT does not initiate a connection but sends out a message on the connected link. 7.30.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates BLE mode. | . 7.30.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid conn_req 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&FSK&LORa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&FSK&LORa Disconnected\" . 7.30.4 Expected Results . 7.30.4.1 Pass Verdict . A registered DUT should send an uplink via BLE directly. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#730-multi-linkepmlm-performanceulbv05-ul-sent-through-ble-when-ens-link_mask-is-1", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#730-multi-linkepmlm-performanceulbv05-ul-sent-through-ble-when-ens-link_mask-is-1" },"580": { "doc": "7. Multi-link Test Cases", "title": "7.31 MULTI-LINK/EP/MLM-LATENCY/UL/BV/01: UL sent through BLE when no connection.", "content": "7.31.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM LATENCY policy, which is BLE>FSK>LoRa. 7.31.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode . | . 7.31.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 3 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 7.31.4 Expected Results . 7.31.4.1 Pass Verdict . A registered DUT should successfully establish a BLE connection with the Lower Tester and send an uplink. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#731-multi-linkepmlm-latencyulbv01-ul-sent-through-ble-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#731-multi-linkepmlm-latencyulbv01-ul-sent-through-ble-when-no-connection" },"581": { "doc": "7. Multi-link Test Cases", "title": "7.32 MULTI-LINK/EP/MLM-LATENCY/UL/BV/02: UL sent through FSK when no connection.", "content": "7.32.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM LATENCY policy, which is BLE>FSK>LoRa. 7.32.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in FSK mode . | . 7.32.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 3 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 2, FSK connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 7.32.4 Expected Results . 7.32.4.1 Pass Verdict . A registered DUT should try to connect with BLE and fail, then attempt to connect with FSK on the Lower Tester and send the uplink automatically when sending an uplink with a Link_Mask 0 status. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#732-multi-linkepmlm-latencyulbv02-ul-sent-through-fsk-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#732-multi-linkepmlm-latencyulbv02-ul-sent-through-fsk-when-no-connection" },"582": { "doc": "7. Multi-link Test Cases", "title": "7.33 MULTI-LINK/EP/MLM-LATENCY/UL/BV/03: UL sent through LoRa when no connection.", "content": "7.33.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM LATENCY policy, which is BLE>FSK>LoRa. 7.33.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode . | . 7.33.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 3 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: FSK connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 4, LoRa connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 7.33.4 Expected Results . 7.33.4.1 Pass Verdict . A registered DUT should try to connect with BLE and fail, then attempt to connect with FSK and fail. Afterward, it should attempt to connect with LoRa on the Lower Tester and send the uplink automatically when sending an uplink with a Link_Mask 0 status. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#733-multi-linkepmlm-latencyulbv03-ul-sent-through-lora-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#733-multi-linkepmlm-latencyulbv03-ul-sent-through-lora-when-no-connection" },"583": { "doc": "7. Multi-link Test Cases", "title": "7.34 MULTI-LINK/EP/MLM-LATENCY/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable.", "content": "7.34.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type. The DUT will halt the connection search process if it cannot connect with the proper link type before the TTL has expired. Once the TTL has expired, a background process may or may not be triggered according to the configured MLM policy. For MLM LATENCY, the background process should be triggered. The DUT will perform the background process (BLE>FSK>LoRa) indefinitely. The TTL will be equal to the LoRa link type’s TTL. 7.34.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester disables BLE & FSK & LoRa mode . | . 7.34.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 3 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Start the auto-connect process DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: FSK connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: LoRa connection attempt timeout Note over Lower_Tester,Upper_Tester: Repeat the above process until TTL expires DUT->>Upper_Tester: Disable background process Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&FSK&LORa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&FSK&LORa Disconnected\" . 7.34.4 Expected Results . 7.34.4.1 Pass Verdict . A registered DUT should attempt to connect with BLE and fail, then try to connect with FSK and fail, and finally attempt to connect with LoRa and fail. This process should be repeated until the TTL expires. Once the TTL has expired, the background process should be triggered. The DUT will then try to connect with BLE, FSK, and LoRa indefinitely. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#734-multi-linkepmlm-latencyulbv04-ul-not-send-when-no-connection-and-blefsklora-unavailable", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#734-multi-linkepmlm-latencyulbv04-ul-not-send-when-no-connection-and-blefsklora-unavailable" },"584": { "doc": "7. Multi-link Test Cases", "title": "7.35 MULTI-LINK/EP/MLM-LATENCY/UL/BV/05: UL sent through BLE when EN’s Link_Mask is 1.", "content": "7.35.1 Test Purpose . When the link is connected, a registered MLM LATENCY DUT does not initiate a connection but sends out a message on the connected link. 7.35.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates BLE mode. | . 7.35.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 3 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid conn_req 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&FSK&LORa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&FSK&LORa Disconnected\" . 7.35.4 Expected Results . 7.35.4.1 Pass Verdict . A registered DUT should send an uplink via BLE directly. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#735-multi-linkepmlm-latencyulbv05-ul-sent-through-ble-when-ens-link_mask-is-1", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#735-multi-linkepmlm-latencyulbv05-ul-sent-through-ble-when-ens-link_mask-is-1" },"585": { "doc": "7. Multi-link Test Cases", "title": "7.36 MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/01: UL sent through BLE when no connection.", "content": "7.36.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM RELIABILITY policy, which is BLE>FSK>LoRa. 7.36.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in BLE mode . | . 7.36.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 4 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 7.36.4 Expected Results . 7.36.4.1 Pass Verdict . A registered DUT should successfully establish a BLE connection with the Lower Tester and send an uplink. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#736-multi-linkepmlm-reliabilityulbv01-ul-sent-through-ble-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#736-multi-linkepmlm-reliabilityulbv01-ul-sent-through-ble-when-no-connection" },"586": { "doc": "7. Multi-link Test Cases", "title": "7.37 MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/02: UL sent through FSK when no connection.", "content": "7.37.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM RELIABILITY policy, which is BLE>FSK>LoRa. 7.37.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in FSK mode . | . 7.37.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 4 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 2, FSK connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop FSK connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, FSK Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, FSK Disconnected\" . 7.37.4 Expected Results . 7.37.4.1 Pass Verdict . A registered DUT should try to connect with BLE and fail, then attempt to connect with FSK on the Lower Tester and send the uplink automatically when sending an uplink with a Link_Mask 0 status. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#737-multi-linkepmlm-reliabilityulbv02-ul-sent-through-fsk-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#737-multi-linkepmlm-reliabilityulbv02-ul-sent-through-fsk-when-no-connection" },"587": { "doc": "7. Multi-link Test Cases", "title": "7.38 MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/03: UL sent through LoRa when no connection.", "content": "7.38.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type, following the priority table defined by the MLM policy, when sending an uplink with a Link_Mask 0 status. Specifically, in this instance, the DUT should adhere to the priority of the MLM RELIABILITY policy, which is BLE>FSK>LoRa. 7.38.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates in LoRa mode . | . 7.38.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 4 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: FSK connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 4, LoRa connected\" DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop LoRa connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" . 7.38.4 Expected Results . 7.38.4.1 Pass Verdict . A registered DUT should try to connect with BLE and fail, then attempt to connect with FSK and fail. Afterward, it should attempt to connect with LoRa on the Lower Tester and send the uplink automatically when sending an uplink with a Link_Mask 0 status. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#738-multi-linkepmlm-reliabilityulbv03-ul-sent-through-lora-when-no-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#738-multi-linkepmlm-reliabilityulbv03-ul-sent-through-lora-when-no-connection" },"588": { "doc": "7. Multi-link Test Cases", "title": "7.39 MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable.", "content": "7.39.1 Test Purpose . A registered DUT configured with the MLM policy will attempt to establish a connection with each link type and send an uplink via the connected link type. The DUT will halt the connection search process if it cannot connect with the proper link type before the TTL has expired. Once the TTL has expired, a background process may or may not be triggered according to the configured MLM policy. For MLM RELIABILITY, the background process should be triggered. The DUT will perform the background process (FSK>LoRa) indefinitely. The TTL will be equal to the LoRa link type’s TTL. 7.39.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester disables BLE & FSK & LoRa mode . | . 7.39.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 4 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Start the auto-connect process DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: BLE connection attempt timeout DUT->>Lower_Tester: Trigger GW discovery process Lower_Tester->>DUT: Establish FSK connection DUT->>Upper_Tester: FSK connection attempt timeout DUT->>Lower_Tester: SET_JOIN_REQ Lower_Tester->>DUT: RESP_JOIN_REQ DUT->>Upper_Tester: LoRa connection attempt timeout Note over Lower_Tester,Upper_Tester: Repeat the above process until TTL expires DUT->>Upper_Tester: Disable background process Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&FSK&LORa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&FSK&LORa Disconnected\" . 7.39.4 Expected Results . 7.39.4.1 Pass Verdict . A registered DUT should attempt to connect with BLE and fail, then try to connect with FSK and fail, and finally attempt to connect with LoRa and fail. This process should be repeated until the TTL expires. Once the TTL has expired, the background process should be triggered. The DUT will then try to connect with FSK, and LoRa indefinitely. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#739-multi-linkepmlm-reliabilityulbv04-ul-not-send-when-no-connection-and-blefsklora-unavailable", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#739-multi-linkepmlm-reliabilityulbv04-ul-not-send-when-no-connection-and-blefsklora-unavailable" },"589": { "doc": "7. Multi-link Test Cases", "title": "7.40 MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/05: UL sent through BLE when EN’s Link_Mask is 1.", "content": "7.40.1 Test Purpose . When the link is connected, a registered MLM RELIABILITY DUT does not initiate a connection but sends out a message on the connected link. 7.40.2 Initial Conditions . | The Sidewalk stack (BLE+FSK+LoRa) is initialized and started on the DUT. | DUT is registered with Amazon Sidewalk network. | DUT is time-synced with Amazon Sidewalk network. | Lower Tester operates BLE mode. | . 7.40.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: Sidewalk application started Upper_Tester->>DUT: sid_option -m 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_option -ml 4 DUT->>Upper_Tester: #35;SID_ERROR_NONE Note over Lower_Tester,Upper_Tester: Ensure DUT's Link_Mask is 0 Upper_Tester->>DUT: sid conn_req 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 1, BLE connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: any) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD(with and Command data) DUT->>Upper_Tester: on_msg_received() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE&FSK&LORa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE&FSK&LORa Disconnected\" . 7.40.4 Expected Results . 7.40.4.1 Pass Verdict . A registered DUT should send an uplink via BLE directly. ", "url": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#740-multi-linkepmlm-reliabilityulbv05-ul-sent-through-ble-when-ens-link_mask-is-1", "relUrl": "/specifications/sidewalk-test-spec/multi-link-test-cases.html#740-multi-linkepmlm-reliabilityulbv05-ul-sent-through-ble-when-ens-link_mask-is-1" },"590": { "doc": "7. Multi-link Test Cases", "title": "Multi-link Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#multi-link-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#multi-link-test-cases" },"591": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/BLE-AUTO-CONNECT/UL/BI/01: Send UL without auto-connect, DUT is BLE disconnected (Link Mask 0)", "content": "| Field | Value | . | Case ID | C103619231 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start BLE stack: sid init 1 sid start | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: EN initialized with BLE, Link_Mask: 0 | . | 2 | Wait for BLE disconnected: sid last_status | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: BLE is disconnected | . | 3 | Send UL without auto-connect: sid send -l 1 TEST | CMD: ERR: -40 Key check: UL rejected, no connection available | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-auto-connectulbi01-send-ul-without-auto-connect-dut-is-ble-disconnected-link-mask-0", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-auto-connectulbi01-send-ul-without-auto-connect-dut-is-ble-disconnected-link-mask-0" },"592": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/BLE-AUTO-CONNECT/UL/BV/02: Send UL with auto-connect, ack is true, retry is 3, TTL is 60", "content": "| Field | Value | . | Case ID | C103619232 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start BLE stack: sid init 1 sid start | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: EN initialized with BLE | . | 2 | Wait for BLE disconnected: sid last_status | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: BLE is disconnected | . | 3 | Set auto-connect policy: sid option -m 1 sid option -c 1 1 5 30 | CMD: ERR: 0 Key check: auto-connect policy set | . | 4 | Send UL with auto-connect (ack=true, retry=3, TTL=60): sid send -l 1 -a 1 3 60 TEST | ACM(0) st 0->1 CMD: ERR: 0 TYPE: 2 ID: 1 ACM: Connect 1 for 30 sec err 0 BLE Connected EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 1 LINK_MODE: 0 Key check: BLE auto-connected, UL sent successfully, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-auto-connectulbv02-send-ul-with-auto-connect-ack-is-true-retry-is-3-ttl-is-60", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-auto-connectulbv02-send-ul-with-auto-connect-ack-is-true-retry-is-3-ttl-is-60" },"593": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/FSK-AUTO-CONNECT/UL/BI/01: Send UL without auto-connect, DUT is FSK disconnected (Link Mask 0)", "content": "| Field | Value | . | Case ID | C103619233 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start FSK stack, wait for time sync: sid init 2 sid start | EVENT SID STATUS: State: 0, Reg: 0, Time: 1, Link_Mask: 2 Njoin(1, 2) st 2->6 Key check: EN time-synced via FSK | . | 2 | Send UL without auto-connect: sid send -l 2 TEST | CMD: ERR: -40 Key check: UL rejected, no connection available | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepfsk-auto-connectulbi01-send-ul-without-auto-connect-dut-is-fsk-disconnected-link-mask-0", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepfsk-auto-connectulbi01-send-ul-without-auto-connect-dut-is-fsk-disconnected-link-mask-0" },"594": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/FSK-AUTO-CONNECT/UL/BV/02: Send UL with auto-connect, ack is true, retry is 3, TTL is 60", "content": "| Field | Value | . | Case ID | C103619234 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start FSK stack, wait for time sync: sid init 2 sid start | EVENT SID STATUS: State: 0, Reg: 0, Time: 1, Link_Mask: 2 Njoin(1, 2) st 2->6 Key check: EN time-synced via FSK | . | 2 | Set auto-connect policy: sid option -m 1 sid option -c 2 1 20 90 | CMD: ERR: 0 Key check: auto-connect policy set | . | 3 | Send UL with auto-connect (ack=true, retry=3, TTL=60): sid send -l 2 -a 1 3 60 TEST | ACM(0) st 0->1 CMD: ERR: 0 TYPE: 2 ID: 1 ACM: Connect 2 for 90 sec err 0 Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 2 LINK_MODE: 0 Key check: FSK auto-connected, UL sent successfully, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepfsk-auto-connectulbv02-send-ul-with-auto-connect-ack-is-true-retry-is-3-ttl-is-60", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepfsk-auto-connectulbv02-send-ul-with-auto-connect-ack-is-true-retry-is-3-ttl-is-60" },"595": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/LoRa-AUTO-CONNECT/UL/BI/01: Send UL without auto-connect, DUT is LoRa disconnected (Link Mask 0)", "content": "| Field | Value | . | Case ID | C103619235 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start LoRa stack, wait for time sync: sid init 3 sid start | EVENT SID STATUS: State: 0, Reg: 0, Time: 1, Link_Mask: 4 Njoin(1, 4) st 2->6 Key check: EN time-synced via LoRa | . | 2 | Send UL without auto-connect: sid send -l 3 TEST | CMD: ERR: -40 Key check: UL rejected, no connection available | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkeplora-auto-connectulbi01-send-ul-without-auto-connect-dut-is-lora-disconnected-link-mask-0", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkeplora-auto-connectulbi01-send-ul-without-auto-connect-dut-is-lora-disconnected-link-mask-0" },"596": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/LoRa-AUTO-CONNECT/UL/BV/02: Send UL with auto-connect, ack is true, retry is 3, TTL is 60", "content": "| Field | Value | . | Case ID | C103619236 | . | Executable by Customer | Yes | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start LoRa stack, wait for time sync: sid init 3 sid start | EVENT SID STATUS: State: 0, Reg: 0, Time: 1, Link_Mask: 4 Njoin(1, 4) st 2->6 Key check: EN time-synced via LoRa | . | 2 | Set auto-connect policy: sid option -m 1 sid option -c 3 1 30 120 | CMD: ERR: 0 Key check: auto-connect policy set | . | 3 | Send UL with auto-connect (ack=true, retry=3, TTL=60): sid send -l 3 -a 1 3 60 TEST | ACM(0) st 0->1 CMD: ERR: 0 TYPE: 2 ID: 1 ACM: Connect 4 for 120 sec err 0 Njoin(1, 4) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4 EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 4 LINK_MODE: 0 Key check: LoRa auto-connected, UL sent successfully, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkeplora-auto-connectulbv02-send-ul-with-auto-connect-ack-is-true-retry-is-3-ttl-is-60", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkeplora-auto-connectulbv02-send-ul-with-auto-connect-ack-is-true-retry-is-3-ttl-is-60" },"597": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/BLE-LoRa-AUTO-CONNECT/UL/BV/01: Send UL with auto-connect when BLE link priority is higher than LoRa, EN Link Mask is 0, Specify BLE+LoRa link", "content": "| Field | Value | . | Case ID | C103619237 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled (FSK and LoRa unavailable) | . | 2 | Initialize and start BLE+LoRa stack, set auto-connect policy: sid init 4 sid start sid option -m 1 sid option -c 1 1 10 30 sid option -c 3 1 30 120 | CMD: ERR: 0 Key check: EN initialized with BLE+LoRa, auto-connect policy set | . | 3 | Wait for time sync | EVENT SID STATUS: State: 1, Reg: 0, Time: 1, Link_Mask: 0 Key check: EN time-synced | . | 4 | Wait for Link_Mask = 0: sid last_status | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: BLE disconnected, Link_Mask: 0 | . | 5 | Send UL with BLE+LoRa link specified: sid send -l 4 TEST | ACM: Connect 1 for 30 sec err 0 BLE Connected EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 1 LINK_MODE: 0 Key check: BLE auto-connected (higher priority than LoRa), UL sent via BLE, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-lora-auto-connectulbv01-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link-mask-is-0-specify-blelora-link", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-lora-auto-connectulbv01-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link-mask-is-0-specify-blelora-link" },"598": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/BLE-LoRa-AUTO-CONNECT/UL/BV/02: Send UL with auto-connect when BLE link priority is higher than LoRa, EN Link Mask is 0, Specify BLE+LoRa link, disable BLE on GW", "content": "| Field | Value | . | Case ID | C103619238 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Disable GW BLE: adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE disabled | . | 2 | Initialize and start BLE+LoRa stack, set auto-connect policy: sid init 4 sid start sid option -m 1 sid option -c 1 1 10 30 sid option -c 3 1 30 120 | CMD: ERR: 0 Key check: EN initialized with BLE+LoRa, auto-connect policy set | . | 3 | Wait for time sync | EVENT SID STATUS: State: 1, Reg: 0, Time: 1, Link_Mask: 0 Key check: EN time-synced | . | 4 | Send UL with BLE+LoRa link specified: sid send -l 4 TEST | ACM: Connect 1 for 30 sec err 0 (BLE connect fails) ACM: Connect 4 for 120 sec err 0 Njoin(1, 4) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4 EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 4 LINK_MODE: 0 Key check: BLE failed, LoRa auto-connected, UL sent via LoRa, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-lora-auto-connectulbv02-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link-mask-is-0-specify-blelora-link-disable-ble-on-gw", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-lora-auto-connectulbv02-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link-mask-is-0-specify-blelora-link-disable-ble-on-gw" },"599": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/BLE-LoRa-AUTO-CONNECT/UL/BV/03: Send UL with auto-connect when BLE link priority is higher than LoRa, EN Link Mask is 0, disables BLE & LoRa on GW", "content": "| Field | Value | . | Case ID | C103619239 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled (FSK and LoRa unavailable) | . | 2 | Initialize and start BLE+LoRa stack, set auto-connect policy: sid init 4 sid start sid option -m 1 sid option -c 1 1 10 30 sid option -c 3 1 30 120 | CMD: ERR: 0 Key check: EN initialized with BLE+LoRa, auto-connect policy set | . | 3 | Wait for time sync | EVENT SID STATUS: State: 1, Reg: 0, Time: 1, Link_Mask: 0 Key check: EN time-synced | . | 4 | Wait for Link_Mask = 0: sid last_status | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: BLE disconnected, Link_Mask: 0 | . | 5 | Disable GW BLE: adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE disabled | . | 6 | Send UL with auto-connect: sid send -l 4 -a 1 1 60 TEST | ACM: Connect 1 for 30 sec err 0 (BLE connect fails) ACM: Connect 4 for 120 sec err 0 (LoRa connect fails) EVENT SID SEND STATUS: SID ERR: -2, TYPE: 2, ID: 1, LINK: 4 LINK_MODE: 0 Key check: Both BLE and LoRa failed, UL not sent, SID ERR: -2 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-lora-auto-connectulbv03-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link-mask-is-0-disables-ble--lora-on-gw", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-lora-auto-connectulbv03-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link-mask-is-0-disables-ble--lora-on-gw" },"600": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/BLE-LoRa-AUTO-CONNECT/UL/BV/04: Send UL with auto-connect when BLE link priority is higher than LoRa, EN Link Mask is 0, Specify FSK link", "content": "| Field | Value | . | Case ID | C103619240 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled (FSK and LoRa unavailable) | . | 2 | Initialize and start BLE+LoRa stack, set auto-connect policy: sid init 4 sid start sid option -m 1 sid option -c 1 1 10 30 sid option -c 3 1 30 120 | CMD: ERR: 0 Key check: EN initialized with BLE+LoRa, auto-connect policy set | . | 3 | Wait for time sync | EVENT SID STATUS: State: 1, Reg: 0, Time: 1, Link_Mask: 0 Key check: EN time-synced | . | 4 | Wait for Link_Mask = 0: sid last_status | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: BLE disconnected, Link_Mask: 0 | . | 5 | Send UL specifying FSK link (not initialized): sid send -l 2 TEST | CMD: ERR: -40 Key check: UL rejected, FSK link not available in BLE+LoRa stack | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-lora-auto-connectulbv04-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link-mask-is-0-specify-fsk-link", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-lora-auto-connectulbv04-send-ul-with-auto-connect-when-ble-link-priority-is-higher-than-lora-en-link-mask-is-0-specify-fsk-link" },"601": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/01: UL sent through BLE when no connection", "content": "| Field | Value | . | Case ID | C103619241 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize and start BLE+FSK+LoRa stack: sid init 7 sid start | CMD: ERR: 0 Key check: EN initialized with BLE+FSK+LoRa | . | 2 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled (FSK and LoRa unavailable) | . | 3 | Set auto-connect policy: sid option -m 1 sid option -c 1 1 10 30 sid option -c 2 1 20 90 sid option -c 3 1 30 120 | CMD: ERR: 0 Key check: auto-connect policy set | . | 4 | Wait for time sync | EVENT SID STATUS: State: 1, Reg: 0, Time: 1, Link_Mask: 0 Key check: EN time-synced | . | 5 | Wait for Link_Mask = 0: sid last_status | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: all links disconnected | . | 6 | Send UL (no link specified): sid send TEST | ACM: Connect 1 for 30 sec err 0 BLE Connected EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 1 LINK_MODE: 0 Key check: BLE auto-connected (highest priority), UL sent via BLE, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-fsk-lora-auto-connectulbv01-ul-sent-through-ble-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-fsk-lora-auto-connectulbv01-ul-sent-through-ble-when-no-connection" },"602": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/02: UL sent through FSK when no connection", "content": "| Field | Value | . | Case ID | C103619242 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW BLE and LoRa (FSK only mode): adb shell halo_cli -c 0 -i 875 0001 adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE and LoRa disabled Key check: Only FSK available on GW | . | 3 | Start stack, wait for time sync and FSK join: sid start | Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Key check: EN joined via FSK | . | 4 | Set auto-connect policy: sid option -m 1 sid option -c 1 1 10 30 sid option -c 2 1 20 90 sid option -c 3 1 30 20 | CMD: ERR: 0 Key check: auto-connect policy set | . | 5 | Force Link_Mask = 0 by sending LoRa UL with short TTL: sid send -l 3 -a 1 1 10 TEST | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 Key check: Link_Mask = 0 | . | 6 | Wait for auto-connect to terminate | ACM(<n>) st <n>->0 Key check: previous auto-connect terminated | . | 7 | Send UL with auto-connect: sid send -a 1 1 120 TEST | ACM: Connect 1 for 30 sec err 0 (BLE connect fails) ACM: Connect 2 for 90 sec err 0 Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 2 LINK_MODE: 0 Key check: BLE failed, FSK auto-connected, UL sent via FSK, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-fsk-lora-auto-connectulbv02-ul-sent-through-fsk-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-fsk-lora-auto-connectulbv02-ul-sent-through-fsk-when-no-connection" },"603": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/03: UL sent through LoRa when no connection", "content": "| Field | Value | . | Case ID | C103619243 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW BLE and LoRa (FSK only mode): adb shell halo_cli -c 0 -i 875 0001 adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE and LoRa disabled Key check: Only FSK available on GW | . | 3 | Start stack, wait for time sync and FSK join: sid start | Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Key check: EN joined via FSK | . | 4 | Set auto-connect policy: sid option -m 1 sid option -c 1 1 10 10 sid option -c 2 1 20 30 sid option -c 3 1 30 20 | CMD: ERR: 0 Key check: auto-connect policy set | . | 5 | Force Link_Mask = 0 by sending LoRa UL with short TTL: sid send -l 3 -a 1 1 10 TEST | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 Key check: Link_Mask = 0 | . | 6 | Wait for auto-connect to terminate | ACM(<n>) st <n>->0 Key check: previous auto-connect terminated | . | 7 | Enable GW LoRa only (disable FSK): adb shell halo_cli -c 0 -i 875 0002 sid option -c 3 1 30 90 | GW LoRa enabled, FSK disabled Key check: Only LoRa available on GW | . | 8 | Send UL with auto-connect: sid send -a 1 1 120 TEST | ACM: Connect 1 for 10 sec err 0 (BLE connect fails) ACM: Connect 2 for 30 sec err 0 (FSK connect fails) ACM: Connect 4 for 90 sec err 0 Njoin(1, 4) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4 EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 4 LINK_MODE: 0 Key check: BLE and FSK failed, LoRa auto-connected, UL sent via LoRa, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-fsk-lora-auto-connectulbv03-ul-sent-through-lora-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-fsk-lora-auto-connectulbv03-ul-sent-through-lora-when-no-connection" },"604": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/04: UL not sent when no connection and BLE/FSK/LoRa unavailable", "content": "| Field | Value | . | Case ID | C103619244 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW BLE and LoRa (FSK only mode): adb shell halo_cli -c 0 -i 875 0001 adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE and LoRa disabled Key check: Only FSK available on GW | . | 3 | Start stack, wait for time sync and FSK join: sid start | Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Key check: EN joined via FSK | . | 4 | Set auto-connect policy: sid option -m 1 sid option -c 1 1 10 10 sid option -c 2 1 20 30 sid option -c 3 1 30 20 | CMD: ERR: 0 Key check: auto-connect policy set | . | 5 | Force Link_Mask = 0 by sending LoRa UL with short TTL: sid send -l 3 -a 1 1 10 TEST | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 Key check: Link_Mask = 0 | . | 6 | Wait for auto-connect to terminate | ACM(<n>) st <n>->0 Key check: previous auto-connect terminated | . | 7 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled Key check: All links unavailable on GW | . | 8 | Send UL with auto-connect: sid send -a 1 1 50 TEST | ACM: Connect 1 for 10 sec err 0 (BLE connect fails) ACM: Connect 2 for 30 sec err 0 (FSK connect fails) ACM: Connect 4 for 20 sec err 0 (LoRa connect fails) EVENT SID SEND STATUS: SID ERR: -2, TYPE: 2, ID: 1, LINK: 7 LINK_MODE: 0 Key check: All links failed, UL not sent, SID ERR: -2 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-fsk-lora-auto-connectulbv04-ul-not-sent-when-no-connection-and-blefsklora-unavailable", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-fsk-lora-auto-connectulbv04-ul-not-sent-when-no-connection-and-blefsklora-unavailable" },"605": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/05: UL sent through BLE when EN’s Link Mask is 1", "content": "| Field | Value | . | Case ID | C103619245 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled Key check: Only BLE available on GW | . | 3 | Start stack, wait for time sync: sid start | EVENT SID STATUS: State: 1, Reg: 0, Time: 1, Link_Mask: 0 Key check: EN time-synced | . | 4 | Set auto-connect policy: sid option -m 1 sid option -c 1 1 10 10 sid option -c 2 1 20 30 sid option -c 3 1 30 20 | CMD: ERR: 0 Key check: auto-connect policy set | . | 5 | Wait for Link_Mask = 0: sid last_status | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 Key check: all links disconnected | . | 6 | Establish BLE connection via conn_req: sid conn_req 1 | BLE Connected EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE connected, Link_Mask: 1 | . | 7 | Send UL: sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 1 LINK_MODE: 0 Key check: UL sent via BLE, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-fsk-lora-auto-connectulbv05-ul-sent-through-ble-when-ens-link-mask-is-1", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepble-fsk-lora-auto-connectulbv05-ul-sent-through-ble-when-ens-link-mask-is-1" },"606": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-ACTIVE/UL/BV/01: UL sent through BLE when no connection", "content": "| Field | Value | . | Case ID | C103619246 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-ACTIVE/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-activeulbv01-ul-sent-through-ble-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-activeulbv01-ul-sent-through-ble-when-no-connection" },"607": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-ACTIVE/UL/BV/02: UL sent through FSK when no connection", "content": "| Field | Value | . | Case ID | C103619247 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-ACTIVE/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-activeulbv02-ul-sent-through-fsk-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-activeulbv02-ul-sent-through-fsk-when-no-connection" },"608": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-ACTIVE/UL/BV/03: UL sent through LoRa when no connection", "content": "| Field | Value | . | Case ID | C103619248 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-ACTIVE/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-activeulbv03-ul-sent-through-lora-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-activeulbv03-ul-sent-through-lora-when-no-connection" },"609": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-ACTIVE/UL/BV/04: UL not sent when no connection and BLE/FSK/LoRa unavailable", "content": "| Field | Value | . | Case ID | C103619249 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW BLE and LoRa (FSK only mode): adb shell halo_cli -c 0 -i 875 0001 adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE and LoRa disabled Key check: Only FSK available on GW | . | 3 | Start stack, wait for time sync and FSK join: sid start | Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Key check: EN joined via FSK | . | 4 | Set MLM policy: sid option -m 2 sid option -ml 0 | CMD: ERR: 0 Key check: MLM policy set | . | 5 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled Key check: All links unavailable on GW | . | 6 | Wait for Link_Mask = 0 | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 Key check: Link_Mask = 0 | . | 7 | Send UL: sid send TEST | MLM: Connect 1 for 30 sec err 0 (BLE connect fails) MLM: Connect 2 for 60 sec err 0 (FSK connect fails) MLM: Connect 4 for 60 sec err 0 (LoRa connect fails) EVENT SID SEND STATUS: SID ERR: -2, TYPE: 2, ID: 1, LINK: 7 LINK_MODE: 0 Key check: All links failed, UL not sent, SID ERR: -2 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-activeulbv04-ul-not-sent-when-no-connection-and-blefsklora-unavailable", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-activeulbv04-ul-not-sent-when-no-connection-and-blefsklora-unavailable" },"610": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-ACTIVE/UL/BV/05: UL sent through BLE when EN’s Link Mask is 1", "content": "| Field | Value | . | Case ID | C103619250 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW BLE and LoRa (FSK only mode): adb shell halo_cli -c 0 -i 875 0001 adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE and LoRa disabled Key check: Only FSK available on GW | . | 3 | Start stack, wait for time sync and FSK join: sid start | Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Key check: EN joined via FSK | . | 4 | Set MLM policy: sid option -m 2 sid option -ml 0 | CMD: ERR: 0 Key check: MLM policy set | . | 5 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled | . | 6 | Wait for Link_Mask = 0 | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 Key check: Link_Mask = 0 | . | 7 | Enable GW BLE and establish BLE connection: adb shell start trackerd sid conn_req 1 | BLE Connected EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE connected, Link_Mask: 1 | . | 8 | Send UL: sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 1 LINK_MODE: 0 Key check: UL sent via BLE, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-activeulbv05-ul-sent-through-ble-when-ens-link-mask-is-1", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-activeulbv05-ul-sent-through-ble-when-ens-link-mask-is-1" },"611": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-POWER/UL/BV/01: UL sent through BLE when no connection", "content": "| Field | Value | . | Case ID | C103619251 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-POWER/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-powerulbv01-ul-sent-through-ble-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-powerulbv01-ul-sent-through-ble-when-no-connection" },"612": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-POWER/UL/BV/02: UL sent through FSK when no connection", "content": "| Field | Value | . | Case ID | C103619252 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-POWER/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-powerulbv02-ul-sent-through-fsk-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-powerulbv02-ul-sent-through-fsk-when-no-connection" },"613": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-POWER/UL/BV/03: UL sent through LoRa when no connection", "content": "| Field | Value | . | Case ID | C103619253 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-POWER/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-powerulbv03-ul-sent-through-lora-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-powerulbv03-ul-sent-through-lora-when-no-connection" },"614": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-POWER/UL/BV/04: UL not sent when no connection and BLE/FSK/LoRa unavailable", "content": "| Field | Value | . | Case ID | C103619254 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW BLE and LoRa (FSK only mode): adb shell halo_cli -c 0 -i 875 0001 adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE and LoRa disabled Key check: Only FSK available on GW | . | 3 | Start stack, wait for time sync and FSK join: sid start | Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Key check: EN joined via FSK | . | 4 | Set MLM policy: sid option -m 2 sid option -ml 1 | CMD: ERR: 0 Key check: MLM policy set | . | 5 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled Key check: All links unavailable on GW | . | 6 | Wait for Link_Mask = 0 | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 Key check: Link_Mask = 0 | . | 7 | Send UL: sid send TEST | MLM: Connect 1 for 30 sec err 0 (BLE connect fails) MLM: Connect 2 for 60 sec err 0 (FSK connect fails) MLM: Connect 4 for 60 sec err 0 (LoRa connect fails) EVENT SID SEND STATUS: SID ERR: -2, TYPE: 2, ID: 1, LINK: 7 LINK_MODE: 0 Key check: All links failed, UL not sent, SID ERR: -2 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-powerulbv04-ul-not-sent-when-no-connection-and-blefsklora-unavailable", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-powerulbv04-ul-not-sent-when-no-connection-and-blefsklora-unavailable" },"615": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-POWER/UL/BV/05: UL sent through BLE when EN’s Link Mask is 1", "content": "| Field | Value | . | Case ID | C103619255 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW BLE and LoRa (FSK only mode): adb shell halo_cli -c 0 -i 875 0001 adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE and LoRa disabled Key check: Only FSK available on GW | . | 3 | Start stack, wait for time sync and FSK join: sid start | Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Key check: EN joined via FSK | . | 4 | Set MLM policy: sid option -m 2 sid option -ml 1 | CMD: ERR: 0 Key check: MLM policy set | . | 5 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled | . | 6 | Wait for Link_Mask = 0 | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 Key check: Link_Mask = 0 | . | 7 | Enable GW BLE and establish BLE connection: adb shell start trackerd sid conn_req 1 | BLE Connected EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE connected, Link_Mask: 1 | . | 8 | Send UL: sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 1 LINK_MODE: 0 Key check: UL sent via BLE, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-powerulbv05-ul-sent-through-ble-when-ens-link-mask-is-1", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-powerulbv05-ul-sent-through-ble-when-ens-link-mask-is-1" },"616": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/01: UL sent through BLE when no connection", "content": "| Field | Value | . | Case ID | C103619256 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-performanceulbv01-ul-sent-through-ble-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-performanceulbv01-ul-sent-through-ble-when-no-connection" },"617": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/02: UL sent through FSK when no connection", "content": "| Field | Value | . | Case ID | C103619257 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-performanceulbv02-ul-sent-through-fsk-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-performanceulbv02-ul-sent-through-fsk-when-no-connection" },"618": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/03: UL sent through LoRa when no connection", "content": "| Field | Value | . | Case ID | C103619258 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-performanceulbv03-ul-sent-through-lora-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-performanceulbv03-ul-sent-through-lora-when-no-connection" },"619": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/04: UL not sent when no connection and BLE/FSK/LoRa unavailable", "content": "| Field | Value | . | Case ID | C103619259 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW BLE and LoRa (FSK only mode): adb shell halo_cli -c 0 -i 875 0001 adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE and LoRa disabled Key check: Only FSK available on GW | . | 3 | Start stack, wait for time sync and FSK join: sid start | Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Key check: EN joined via FSK | . | 4 | Set MLM policy: sid option -m 2 sid option -ml 2 | CMD: ERR: 0 Key check: MLM policy set | . | 5 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled Key check: All links unavailable on GW | . | 6 | Wait for Link_Mask = 0 | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 Key check: Link_Mask = 0 | . | 7 | Send UL: sid send TEST | MLM: Connect 1 for 30 sec err 0 (BLE connect fails) MLM: Connect 2 for 60 sec err 0 (FSK connect fails) MLM: Connect 4 for 30 sec err 0 (LoRa connect fails) EVENT SID SEND STATUS: SID ERR: -2, TYPE: 2, ID: 1, LINK: 7 LINK_MODE: 0 Key check: All links failed, UL not sent, SID ERR: -2 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-performanceulbv04-ul-not-sent-when-no-connection-and-blefsklora-unavailable", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-performanceulbv04-ul-not-sent-when-no-connection-and-blefsklora-unavailable" },"620": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/05: UL sent through BLE when EN’s Link Mask is 1", "content": "| Field | Value | . | Case ID | C103619260 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW BLE and LoRa (FSK only mode): adb shell halo_cli -c 0 -i 875 0001 adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE and LoRa disabled Key check: Only FSK available on GW | . | 3 | Start stack, wait for time sync and FSK join: sid start | Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Key check: EN joined via FSK | . | 4 | Set MLM policy: sid option -m 2 sid option -ml 2 | CMD: ERR: 0 Key check: MLM policy set | . | 5 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled | . | 6 | Wait for Link_Mask = 0 | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 Key check: Link_Mask = 0 | . | 7 | Enable GW BLE and establish BLE connection: adb shell start trackerd sid conn_req 1 | BLE Connected EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE connected, Link_Mask: 1 | . | 8 | Send UL: sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 1 LINK_MODE: 0 Key check: UL sent via BLE, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-performanceulbv05-ul-sent-through-ble-when-ens-link-mask-is-1", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-performanceulbv05-ul-sent-through-ble-when-ens-link-mask-is-1" },"621": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-LATENCY/UL/BV/01: UL sent through BLE when no connection", "content": "| Field | Value | . | Case ID | C103619261 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-LATENCY/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-latencyulbv01-ul-sent-through-ble-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-latencyulbv01-ul-sent-through-ble-when-no-connection" },"622": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-LATENCY/UL/BV/02: UL sent through FSK when no connection", "content": "| Field | Value | . | Case ID | C103619262 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-LATENCY/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-latencyulbv02-ul-sent-through-fsk-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-latencyulbv02-ul-sent-through-fsk-when-no-connection" },"623": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-LATENCY/UL/BV/03: UL sent through LoRa when no connection", "content": "| Field | Value | . | Case ID | C103619263 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-LATENCY/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-latencyulbv03-ul-sent-through-lora-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-latencyulbv03-ul-sent-through-lora-when-no-connection" },"624": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-LATENCY/UL/BV/04: UL not sent when no connection and BLE/FSK/LoRa unavailable", "content": "| Field | Value | . | Case ID | C103619264 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW BLE and LoRa (FSK only mode): adb shell halo_cli -c 0 -i 875 0001 adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE and LoRa disabled Key check: Only FSK available on GW | . | 3 | Start stack, wait for time sync and FSK join: sid start | Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Key check: EN joined via FSK | . | 4 | Set MLM policy: sid option -m 2 sid option -ml 3 | CMD: ERR: 0 Key check: MLM policy set | . | 5 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled Key check: All links unavailable on GW | . | 6 | Wait for Link_Mask = 0 | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 Key check: Link_Mask = 0 | . | 7 | Send UL: sid send TEST | MLM: Connect 1 for 15 sec err 0 (BLE connect fails) MLM: Connect 2 for 30 sec err 0 (FSK connect fails) MLM: Connect 4 for 60 sec err 0 (LoRa connect fails) EVENT SID SEND STATUS: SID ERR: -2, TYPE: 2, ID: 1, LINK: 7 LINK_MODE: 0 Key check: All links failed, UL not sent, SID ERR: -2 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-latencyulbv04-ul-not-sent-when-no-connection-and-blefsklora-unavailable", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-latencyulbv04-ul-not-sent-when-no-connection-and-blefsklora-unavailable" },"625": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-LATENCY/UL/BV/05: UL sent through BLE when EN’s Link Mask is 1", "content": "| Field | Value | . | Case ID | C103619265 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW BLE and LoRa (FSK only mode): adb shell halo_cli -c 0 -i 875 0001 adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE and LoRa disabled Key check: Only FSK available on GW | . | 3 | Start stack, wait for time sync and FSK join: sid start | Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Key check: EN joined via FSK | . | 4 | Set MLM policy: sid option -m 2 sid option -ml 3 | CMD: ERR: 0 Key check: MLM policy set | . | 5 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled | . | 6 | Wait for Link_Mask = 0 | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 Key check: Link_Mask = 0 | . | 7 | Enable GW BLE and establish BLE connection: adb shell start trackerd sid conn_req 1 | BLE Connected EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE connected, Link_Mask: 1 | . | 8 | Send UL: sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 1 LINK_MODE: 0 Key check: UL sent via BLE, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-latencyulbv05-ul-sent-through-ble-when-ens-link-mask-is-1", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-latencyulbv05-ul-sent-through-ble-when-ens-link-mask-is-1" },"626": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/01: UL sent through BLE when no connection", "content": "| Field | Value | . | Case ID | C103619266 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-reliabilityulbv01-ul-sent-through-ble-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-reliabilityulbv01-ul-sent-through-ble-when-no-connection" },"627": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/02: UL sent through FSK when no connection", "content": "| Field | Value | . | Case ID | C103619267 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-reliabilityulbv02-ul-sent-through-fsk-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-reliabilityulbv02-ul-sent-through-fsk-when-no-connection" },"628": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/03: UL sent through LoRa when no connection", "content": "| Field | Value | . | Case ID | C103619268 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Note: This scenario is covered by MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/04: UL not send when no connection and BLE/FSK/LoRa unavailable. No separate execution required. | N/A | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-reliabilityulbv03-ul-sent-through-lora-when-no-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-reliabilityulbv03-ul-sent-through-lora-when-no-connection" },"629": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/04: UL not sent when no connection and BLE/FSK/LoRa unavailable", "content": "| Field | Value | . | Case ID | C103619269 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW BLE and LoRa (FSK only mode): adb shell halo_cli -c 0 -i 875 0001 adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE and LoRa disabled Key check: Only FSK available on GW | . | 3 | Start stack, wait for time sync and FSK join: sid start | Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Key check: EN joined via FSK | . | 4 | Set MLM policy: sid option -m 2 sid option -ml 4 | CMD: ERR: 0 Key check: MLM policy set | . | 5 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled Key check: All links unavailable on GW | . | 6 | Wait for Link_Mask = 0 | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 Key check: Link_Mask = 0 | . | 7 | Send UL: sid send TEST | MLM: Connect 1 for 15 sec err 0 (BLE connect fails) MLM: Connect 2 for 60 sec err 0 (FSK connect fails) MLM: Connect 4 for 120 sec err 0 (LoRa connect fails) EVENT SID SEND STATUS: SID ERR: -2, TYPE: 2, ID: 1, LINK: 7 LINK_MODE: 0 Key check: All links failed, UL not sent, SID ERR: -2 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-reliabilityulbv04-ul-not-sent-when-no-connection-and-blefsklora-unavailable", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-reliabilityulbv04-ul-not-sent-when-no-connection-and-blefsklora-unavailable" },"630": { "doc": "7. Multi-link Test Cases", "title": "Test Case ID: MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/05: UL sent through BLE when EN’s Link Mask is 1", "content": "| Field | Value | . | Case ID | C103619270 | . | Executable by Customer | No | . Preconditions . | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize BLE+FSK+LoRa stack (do not start yet): sid init 7 | CMD: ERR: 0 Key check: EN initialized | . | 2 | Disable GW BLE and LoRa (FSK only mode): adb shell halo_cli -c 0 -i 875 0001 adb shell stop trackerd; adb shell stop btmanagerd; adb shell stop halo-core-swp; adb shell start halo-core-swp | GW BLE and LoRa disabled Key check: Only FSK available on GW | . | 3 | Start stack, wait for time sync and FSK join: sid start | Njoin(1, 2) st 2->6 EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2 Key check: EN joined via FSK | . | 4 | Set MLM policy: sid option -m 2 sid option -ml 4 | CMD: ERR: 0 Key check: MLM policy set | . | 5 | Disable GW 900MHz (FSK + LoRa): adb shell halo_cli set_protocol_on off | GW 900MHz disabled | . | 6 | Wait for Link_Mask = 0 | EVENT SID STATUS: State: 1, Reg: 0, Time: 0, Link_Mask: 0 Key check: Link_Mask = 0 | . | 7 | Enable GW BLE and establish BLE connection: adb shell start trackerd sid conn_req 1 | BLE Connected EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1 EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 Key check: BLE connected, Link_Mask: 1 | . | 8 | Send UL: sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: 1, LINK: 1 LINK_MODE: 0 Key check: UL sent via BLE, SID ERR: 0 | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-reliabilityulbv05-ul-sent-through-ble-when-ens-link-mask-is-1", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html#test-case-id-multi-linkepmlm-reliabilityulbv05-ul-sent-through-ble-when-ens-link-mask-is-1" },"631": { "doc": "7. Multi-link Test Cases", "title": "7. Multi-link Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-link-test-cases.html" },"632": { "doc": "6. Multi-radio Test Cases", "title": "6. Multi-radio Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html" },"633": { "doc": "6. Multi-radio Test Cases", "title": "6.1 MULTI/EP/API/INIT/BV/01: Switch between 900MHz and BLE stack multiple times.", "content": "6.1.1 Test Purpose . To verify that DUT is able to switch between 900MHz (LoRa) and BLE stack multiple times and the stack is initialized correctly each time. 6.1.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | The Sidewalk stack is not initialized on the DUT. | . 6.1.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 4, LoRa Connected\" DUT->>Lower_Tester: GET_TIME Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon with time sync request Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 4, LoRa Connected\" DUT->>Lower_Tester: GET_TIME Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, LoRa Disconnected\" Upper_Tester->>DUT: sid_init(SID_LINK_TYPE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid_start() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" DUT->>Lower_Tester: Beacon with time sync request Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected\" . 6.1.4 Expected Results . 6.1.4.1 Pass Verdict .  The DUT should correctly switch between the 900MHz (LoRa) and BLE stacks. Each time after initializing and starting the 900MHz (LoRa) stack, the DUT should send a GET_TIME packet via LoRa. In turn, after each initialization and start of the BLE stack, the DUT should start broadcasting Beacons containing a request for time synchronization. ", "url": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#61-multiepapiinitbv01-switch-between-900mhz-and-ble-stack-multiple-times", "relUrl": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#61-multiepapiinitbv01-switch-between-900mhz-and-ble-stack-multiple-times" },"634": { "doc": "6. Multi-radio Test Cases", "title": "6.2 MULTI/EP/CONN/DL/BV/01: Endpoint is able to receive a downlink packet using BLE.", "content": "6.2.1 Test Purpose . To verify that the DUT is able to receive a downlink packet over BLE when the last uplink packet was sent also over BLE. 6.2.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE + LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 6.2.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, BLE Disconnected, LoRa Connected Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 5, BLE Connected, LoRa Connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: 1B, SID_LINK_TYPE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data via BLE) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with 1B of Command data via BLE) DUT->>Upper_Tester: on_msg_received() \"Command data: 1B\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected, LoRa Disconnected\" . 6.2.4 Expected Results . 6.2.4.1 Pass Verdict .  When the DUT sends an uplink packet over BLE, it should expect a response in downlink direction to arrive using the same technology and should be able to receive it. ", "url": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#62-multiepconndlbv01-endpoint-is-able-to-receive-a-downlink-packet-using-ble", "relUrl": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#62-multiepconndlbv01-endpoint-is-able-to-receive-a-downlink-packet-using-ble" },"635": { "doc": "6. Multi-radio Test Cases", "title": "6.3 MULTI/EP/CONN/DL/BV/02: Endpoint is able to receive a downlink packet using LoRa.", "content": "6.3.1 Test Purpose . To verify that DUT receives a downlink packet through LoRa, when multi-radio (BLE + LoRa) is initialized. 6.3.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE + LoRa mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE + LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization. | DUT has completed join procedure for LoRa stack . | . 6.3.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, BLE Disconnected, LoRa Connected Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: 1B, SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data via LoRa) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with 1B of Command data via LoRa) DUT->>Upper_Tester: on_msg_received() \"Command data: 1B\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected, LoRa Disconnected\" . 6.3.4 Expected Results . 6.3.4.1 Pass Verdict . When the Sidewalk multi-radio stack (BLE + LoRa) initialized, DUT is able to receive a downlink packet using LoRa. The CUSTOM_NOTIFY_CMD downlink packet should be verified on the DUT and Lower Tester side: For Lower Tester: downlink packet was successfully transmitted using correct technology (LoRa) For DUT: downlink packet was received. To make sure that the downlink packet will be sent using correct technology, DUT has to send an additional uplink packet via LoRa first. ", "url": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#63-multiepconndlbv02-endpoint-is-able-to-receive-a-downlink-packet-using-lora", "relUrl": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#63-multiepconndlbv02-endpoint-is-able-to-receive-a-downlink-packet-using-lora" },"636": { "doc": "6. Multi-radio Test Cases", "title": "6.4 MULTI/EP/CONN/DL/BV/03: Endpoint is able to receive a downlink packet using LoRa, while BLE connection with Gateway is established.", "content": "6.4.1 Test Purpose . To verify that DUT receives a downlink packet through LoRa, when multi-radio (BLE + LoRa) is initialized and BLE connection is established between DUT and Lower Tester. 6.4.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE + LoRa mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE + LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization. | DUT has completed join procedure for LoRa stack . | . 6.4.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, BLE Disconnected, LoRa Connected Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 5, BLE Connected, LoRa Connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data: 1B, SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data via LoRa) DUT->>Upper_Tester: on_msg_sent() Lower_Tester->>DUT: CUSTOM_NOTIFY_CMD (with 1B of Command data via LoRa) DUT->>Upper_Tester: on_msg_received() \"Command data: 1B\" Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected, LoRa Disconnected\" . 6.4.4 Expected Results . 6.4.4.1 Pass Verdict . When the Sidewalk multi-radio stack (BLE + LoRa) initialized and BLE connection established between DUT and Lower Tester, DUT is still able to receive a downlink packet using LoRa. The CUSTOM_NOTIFY_CMD downlink packet should be verified on the DUT and Lower Tester side: For Lower Tester: downlink packet was successfully transmitted using correct technology (LoRa) For DUT: downlink packet was received. To make sure that the downlink packet will be sent using correct technology, DUT has to send an additional uplink packet via LoRa after establishing BLE connection and before the downlink packet is scheduled. ", "url": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#64-multiepconndlbv03-endpoint-is-able-to-receive-a-downlink-packet-using-lora-while-ble-connection-with-gateway-is-established", "relUrl": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#64-multiepconndlbv03-endpoint-is-able-to-receive-a-downlink-packet-using-lora-while-ble-connection-with-gateway-is-established" },"637": { "doc": "6. Multi-radio Test Cases", "title": "6.5 MULTI/EP/CONN/SEND/LINK/BV/01: Uplink performed through BLE, when send_link 0 and active BT connection.", "content": "6.5.1 Test Purpose . To verify that DUT sends uplink packet through BLE when Multi-radio (BLE + LORA) is initialized, the send_link is set to SID_LINK_TYPE_ANY and there is an active BLE connection. 6.5.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE + LoRa mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE + LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 6.5.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, BLE Disconnected, LoRa Connected Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 5, BLE Connected, LoRa Connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data 1B, SID_LINK_TYPE_ANY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data via BLE) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected, LoRa Disconnected\" . 6.5.4 Expected Results . 6.5.4.1 Pass Verdict . When the Sidewalk multi-radio stack (BLE + LoRa) initialized, the link type is set to SID_LINK_TYPE_ANY and both BLE and LoRa are connected, the DUT should use BLE to send any uplink packet. The CUSTOM_NOTIFY_CMD packet should be verified on the Lower Tester side against the technology in which it was received (BLE). ", "url": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#65-multiepconnsendlinkbv01-uplink-performed-through-ble-when-send_link-0-and-active-bt-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#65-multiepconnsendlinkbv01-uplink-performed-through-ble-when-send_link-0-and-active-bt-connection" },"638": { "doc": "6. Multi-radio Test Cases", "title": "6.6 MULTI/EP/CONN/SEND/LINK/BV/02: Uplink performed through BLE, when send_link 1 and active BT connection.", "content": "6.6.1 Test Purpose . To verify that DUT sends uplink packet through BLE when Multi-radio (BLE + LORA) is initialized, the send_link is set to SID_LINK_TYPE_1 (BLE) and there is an active BLE connection. 6.6.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE + LoRa mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE + LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 6.6.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, BLE Disconnected, LoRa Connected Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 5, BLE Connected, LoRa Connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data 1B, SID_LINK_TYPE_1) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data via BLE) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected, LoRa Disconnected\" . 6.6.4 Expected Results . 6.6.4.1 Pass Verdict . When the Sidewalk multi-radio stack (BLE + LoRa) initialized, the link type is set to SID_LINK_TYPE_1 (BLE) and both BLE and LoRa are connected, the DUT should use BLE to send any uplink packet. The CUSTOM_NOTIFY_CMD packet should be verified on the Lower Tester side against the technology in which it was received (BLE). ", "url": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#66-multiepconnsendlinkbv02-uplink-performed-through-ble-when-send_link-1-and-active-bt-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#66-multiepconnsendlinkbv02-uplink-performed-through-ble-when-send_link-1-and-active-bt-connection" },"639": { "doc": "6. Multi-radio Test Cases", "title": "6.7 MULTI/EP/CONN/SEND/LINK/BV/03: Uplink performed through LoRa, when send_link 3 and active BT connection.", "content": "6.7.1 Test Purpose . To verify that DUT sends uplink packet through LoRa when Multi-radio (BLE + LORA) is initialized, the send_link is set to SID_LINK_TYPE_3 (LoRa) and there is an active BLE connection. 6.7.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE + LoRa mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE + LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 6.7.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, BLE Disconnected, LoRa Connected Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 5, BLE Connected, LoRa Connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data 1B, SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data via LoRa) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected, LoRa Disconnected\" . 6.7.4 Expected Results . 6.7.4.1 Pass Verdict . When the Sidewalk multi-radio stack (BLE + LoRa) initialized, the link type is set to SID_LINK_TYPE_3 (LoRa) and both BLE and LoRa are connected, the DUT should use LoRa to send any uplink packet. The CUSTOM_NOTIFY_CMD packet should be verified on the Lower Tester side against the technology in which it was received (LoRa). ", "url": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#67-multiepconnsendlinkbv03-uplink-performed-through-lora-when-send_link-3-and-active-bt-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#67-multiepconnsendlinkbv03-uplink-performed-through-lora-when-send_link-3-and-active-bt-connection" },"640": { "doc": "6. Multi-radio Test Cases", "title": "6.8 MULTI/EP/CONN/SEND/LINK/BV/04: Uplink performed through LoRa, when send_link 0 and terminated BT connection.", "content": "6.8.1 Test Purpose . To verify that DUT sends uplink packet through LoRa when Multi-radio (BLE + LORA) is initialized, the send_link is set to SID_LINK_TYPE_ANY and the BLE is disconnected. 6.8.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE + LoRa mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE + LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 6.8.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, BLE Disconnected, LoRa Connected Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 5, BLE Connected, LoRa Connected\" Note over Lower_Tester,Upper_Tester: Wait for 30s DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 4, BLE Disconnected, LoRa Connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data 1B, SID_LINK_TYPE_ANY) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: CUSTOM_NOTIFY_CMD (with 1B of Command data via LoRa) DUT->>Upper_Tester: on_msg_sent() Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected, LoRa Disconnected\" . 6.8.4 Expected Results . 6.8.4.1 Pass Verdict . When the Sidewalk multi-radio stack (BLE + LoRa) initialized, the link type is set to SID_LINK_TYPE_ANY, BLE is terminated but LoRa is connected, the DUT should use LoRa to send any uplink packet. The CUSTOM_NOTIFY_CMD packet should be verified on the Lower Tester side against the technology in which it was received (LoRa). ", "url": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#68-multiepconnsendlinkbv04-uplink-performed-through-lora-when-send_link-0-and-terminated-bt-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#68-multiepconnsendlinkbv04-uplink-performed-through-lora-when-send_link-0-and-terminated-bt-connection" },"641": { "doc": "6. Multi-radio Test Cases", "title": "6.9 MULTI/EP/CONN/SEND/LINK/BV/05: Uplink not performed, when send_link 1 and terminated BT connection.", "content": "6.9.1 Test Purpose . To verify that DUT does not send uplink packet when Multi-radio (BLE . | LORA) is initialized, the send_link is set to SID_LINK_TYPE_1 (BLE) and the BLE is disconnected. | . 6.9.2 Initial Conditions . | DUT is registered with Amazon Sidewalk network. | Lower Tester operates in BLE + LoRa mode. | SidewalkNetworkFlag is enabled on the Lower Tester. | The Sidewalk stack (BLE + LoRa) is initialized and started on the DUT. | DUT has completed the time synchronization. | . 6.9.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: DUT Status: Registered, Link Mask 4, BLE Disconnected, LoRa Connected Upper_Tester->>DUT: sid_ble_bcn_connection_request(set = true) DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Lower_Tester: Beacon with connection request Lower_Tester->>DUT: Establish BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 5, BLE Connected, LoRa Connected\" Note over Lower_Tester,Upper_Tester: Wait for 30s DUT->>Lower_Tester: Drop BLE connection DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 4, BLE Disconnected, LoRa Connected\" Upper_Tester->>DUT: sid_put_msg(SID_MSG_TYPE_NOTIFY, Command data 1B, SID_LINK_TYPE_1) DUT->>Upper_Tester: on_send_error(SID_ERROR_INVALID_STATE) Upper_Tester->>DUT: sid_stop() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Time Synced, Link Mask 0, BLE Disconnected, LoRa Disconnected\" Upper_Tester->>DUT: sid_deinit() DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"No Time, Link Mask 0, BLE Disconnected, LoRa Disconnected\" . 6.9.4 Expected Results . 6.9.4.1 Pass Verdict . When the Sidewalk multi-radio stack (BLE + LoRa) initialized, the link type is set to SID_LINK_TYPE_1 (BLE) but BLE connection is terminated, then it should not be possible to send any uplink packet. The DUT should return an appropriate error indicating that the requested stack is in the invalid state. Additional verification should be done on the Lower Tester side to make sure that no packet has been received. ", "url": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#69-multiepconnsendlinkbv05-uplink-not-performed-when-send_link-1-and-terminated-bt-connection", "relUrl": "/specifications/sidewalk-test-spec/multi-radio-test-cases.html#69-multiepconnsendlinkbv05-uplink-not-performed-when-send_link-1-and-terminated-bt-connection" },"642": { "doc": "8. Multi-radio Test Cases", "title": "Multi-radio Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#multi-radio-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#multi-radio-test-cases" },"643": { "doc": "8. Multi-radio Test Cases", "title": "Test Case ID: MULTI/EN/API/INIT/BV-01: Switch between 900MHz and BLE stack multiple times", "content": "| Field | Value | . | Case ID | C103619216 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize LoRa stack and wait for time sync:sid deinitsid init 3sid start | CMD: ERR: 0EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4Key check: Time sync received (Time: 0) | . | 2 | Switch to BLE stack and wait for time sync:sid deinitsid init 1sid start | CMD: ERR: 0EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1Key check: Time sync received (Time: 0) | . | 3 | Switch back to LoRa and wait for time sync:sid deinitsid init 3sid start | CMD: ERR: 0EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4Key check: Time sync received (Time: 0) | . | 4 | Switch back to BLE and wait for time sync:sid deinitsid init 1sid start | CMD: ERR: 0EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 1Key check: Time sync received (Time: 0) | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienapiinitbv-01-switch-between-900mhz-and-ble-stack-multiple-times", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienapiinitbv-01-switch-between-900mhz-and-ble-stack-multiple-times" },"644": { "doc": "8. Multi-radio Test Cases", "title": "Test Case ID: MULTI/EN/CONN/DL/BV-01: End Node is able to receive a downlink packet using BLE", "content": "| Field | Value | . | Case ID | C103619222 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | Multi-radio stack initialized (BLE + LoRa) | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request:sid conn_req 1 | CMD: ERR: 0EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1Key check: BLE: 1 (connected) | . | 2 | Send UL packet through BLE:sid send -l 1 TEST | CMD: ERR: 0 TYPE: 2 ID: <id>EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 1 LINK_MODE: 1Key check: LINK: 1 (BLE) | . | 3 | Send DL packet from AWS IoT | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: 4, LINK: 1, LINK_MODE: 1, ACK_REQUESTED: 0, ACK: 0, DUP: 0, RSSI: <rssi>, SNR: <snr> Data: 54455354Key check: LINK: 1 (BLE), data received | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconndlbv-01-end-node-is-able-to-receive-a-downlink-packet-using-ble", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconndlbv-01-end-node-is-able-to-receive-a-downlink-packet-using-ble" },"645": { "doc": "8. Multi-radio Test Cases", "title": "Test Case ID: MULTI/EN/CONN/DL/BV-02: End Node is able to receive a downlink packet using LoRa", "content": "| Field | Value | . | Case ID | C103619223 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | Multi-radio stack initialized (BLE + LoRa) | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected:sid last_status | EVENT SID STATUS LINK MODE: LORA: 1, FSK: 0, BLE: 0Key check: BLE: 0 (disconnected) | . | 2 | Send UL packet through LoRa:sid send -l 3 TEST | CMD: ERR: 0 TYPE: 2 ID: <id>EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4 LINK_MODE: 1Key check: LINK: 4 (LoRa) | . | 3 | Send DL packet from AWS IoT | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: 4, LINK: 4, LINK_MODE: 1, ACK_REQUESTED: 0, ACK: 0, DUP: 0, RSSI: <rssi>, SNR: <snr> Data: 54455354Key check: LINK: 4 (LoRa), data received | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconndlbv-02-end-node-is-able-to-receive-a-downlink-packet-using-lora", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconndlbv-02-end-node-is-able-to-receive-a-downlink-packet-using-lora" },"646": { "doc": "8. Multi-radio Test Cases", "title": "Test Case ID: MULTI/EN/CONN/DL/BV-03: End Node is able to receive a downlink packet using LoRa, while BLE connection with Gateway is established", "content": "| Field | Value | . | Case ID | C103619224 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | Multi-radio stack initialized (BLE + LoRa) | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request:sid conn_req 1 | CMD: ERR: 0EVENT SID STATUS LINK MODE: LORA: 1, FSK: 0, BLE: 1Key check: BLE: 1 (connected), LoRa: 1 (active) | . | 2 | While BLE connection is active, send UL packet through LoRa:sid send -l 3 TEST | CMD: ERR: 0 TYPE: 2 ID: <id>EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4 LINK_MODE: 1Key check: LINK: 4 (LoRa) | . | 3 | Send DL packet from AWS IoT | EVENT SID RECEIVED: TYPE: <type>, ID: <id>, LEN: 4, LINK: 4, LINK_MODE: 1, ACK_REQUESTED: 0, ACK: 0, DUP: 0, RSSI: <rssi>, SNR: <snr> Data: 54455354Key check: LINK: 4 (LoRa), data received | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconndlbv-03-end-node-is-able-to-receive-a-downlink-packet-using-lora-while-ble-connection-with-gateway-is-established", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconndlbv-03-end-node-is-able-to-receive-a-downlink-packet-using-lora-while-ble-connection-with-gateway-is-established" },"647": { "doc": "8. Multi-radio Test Cases", "title": "Test Case ID: MULTI/EN/CONN/SEND-LINK/BV-01: UL performed through BLE, when send_link 0 and active BT connection", "content": "| Field | Value | . | Case ID | C103619217 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | Multi-radio stack initialized (BLE + LoRa) | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request:sid conn_req 1 | CMD: ERR: 0EVENT SID STATUS LINK MODE: LORA: 1, FSK: 0, BLE: 1Key check: BLE: 1 (connected) | . | 2 | Send UL with send_link=0 (any):sid send TEST | CMD: ERR: 0 TYPE: 2 ID: <id>EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 1 LINK_MODE: 1Key check: LINK: 1 (BLE auto-selected when BLE connected) | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconnsend-linkbv-01-ul-performed-through-ble-when-send_link-0-and-active-bt-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconnsend-linkbv-01-ul-performed-through-ble-when-send_link-0-and-active-bt-connection" },"648": { "doc": "8. Multi-radio Test Cases", "title": "Test Case ID: MULTI/EN/CONN/SEND-LINK/BV-02: UL performed through BLE, when send_link 1 and active BT connection", "content": "| Field | Value | . | Case ID | C103619218 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | Multi-radio stack initialized (BLE + LoRa) | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request:sid conn_req 1 | CMD: ERR: 0EVENT SID STATUS LINK MODE: LORA: 1, FSK: 0, BLE: 1Key check: BLE: 1 (connected) | . | 2 | Send UL with send_link=1 (BLE):sid send -l 1 TEST | CMD: ERR: 0 TYPE: 2 ID: <id>EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 1 LINK_MODE: 1Key check: LINK: 1 (BLE) | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconnsend-linkbv-02-ul-performed-through-ble-when-send_link-1-and-active-bt-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconnsend-linkbv-02-ul-performed-through-ble-when-send_link-1-and-active-bt-connection" },"649": { "doc": "8. Multi-radio Test Cases", "title": "Test Case ID: MULTI/EN/CONN/SEND-LINK/BV-03: UL performed through LoRa, when send_link 3 and active BT connection", "content": "| Field | Value | . | Case ID | C103619219 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | Multi-radio stack initialized (BLE + LoRa) | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected, then set connection request:sid conn_req 1 | CMD: ERR: 0EVENT SID STATUS LINK MODE: LORA: 1, FSK: 0, BLE: 1Key check: BLE: 1 (connected) | . | 2 | Send UL with send_link=3 (LoRa):sid send -l 3 TEST | CMD: ERR: 0 TYPE: 2 ID: <id>EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4 LINK_MODE: 1Key check: LINK: 4 (LoRa, forced even with BLE connected) | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconnsend-linkbv-03-ul-performed-through-lora-when-send_link-3-and-active-bt-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconnsend-linkbv-03-ul-performed-through-lora-when-send_link-3-and-active-bt-connection" },"650": { "doc": "8. Multi-radio Test Cases", "title": "Test Case ID: MULTI/EN/CONN/SEND-LINK/BV-04: UL performed through LoRa, when send_link 0 and terminated BT connection", "content": "| Field | Value | . | Case ID | C103619220 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | Multi-radio stack initialized (BLE + LoRa) | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected:sid last_status | EVENT SID STATUS LINK MODE: LORA: 1, FSK: 0, BLE: 0Key check: BLE: 0 (disconnected) | . | 2 | Send UL with send_link=0 (any):sid send TEST | CMD: ERR: 0 TYPE: 2 ID: <id>EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4 LINK_MODE: 1Key check: LINK: 4 (LoRa auto-selected when BLE disconnected) | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconnsend-linkbv-04-ul-performed-through-lora-when-send_link-0-and-terminated-bt-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconnsend-linkbv-04-ul-performed-through-lora-when-send_link-0-and-terminated-bt-connection" },"651": { "doc": "8. Multi-radio Test Cases", "title": "Test Case ID: MULTI/EN/CONN/SEND-LINK/BV-05: Uplink not performed, when send_link 1 and terminated BT connection", "content": "| Field | Value | . | Case ID | C103619221 | . | Executable by Customer | Yes | . Preconditions . | EN is registered in Sidewalk network | EN has time synchronized | Multi-radio stack initialized (BLE + LoRa) | (Preconditions to be provided.) | . Test Steps . | Step | Description | Expected Result | . | 1 | Verify BLE is disconnected:sid last_status | EVENT SID STATUS LINK MODE: LORA: 1, FSK: 0, BLE: 0Key check: BLE: 0 (disconnected) | . | 2 | Send UL with send_link=1 (BLE) while BLE is disconnected:sid send -l 1 TEST | No EVENT SID SEND STATUS receivedKey check: UL not sent (BLE link not available) | . ", "url": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconnsend-linkbv-05-uplink-not-performed-when-send_link-1-and-terminated-bt-connection", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html#test-case-id-multienconnsend-linkbv-05-uplink-not-performed-when-send_link-1-and-terminated-bt-connection" },"652": { "doc": "8. Multi-radio Test Cases", "title": "8. Multi-radio Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/multi-radio-test-cases.html" },"653": { "doc": "2. Network Architecture", "title": "2. Network Architecture", "content": "Amazon Sidewalk is a wireless network providing low power and low cost IoT connectivity both around and beyond the home. Amazon Sidewalk accomplishes this via Amazon Sidewalk Gateways and Endpoints. Amazon Sidewalk Gateways route traffic from Endpoints to the Internet. Amazon Sidewalk supports different data rates from 2 kbps on SubG-CSS, 50 kbps on SubG-FSK, to 1 Mbps on BLE. Each Gateway may handle multiple Amazon Sidewalk-enabled IoT Endpoints like security sensors, trackers and motion sensors. In addition to the SubG-FSK and SubG-CSS radios, the Amazon Sidewalk network and architecture also encompass Bluetooth technologies. Amazon Sidewalk Endpoints operate under two distinct radio-agnostic modes or configurations: Wide Area Network (WAN) and Personal Area Network (PAN). In the Wide Area Network configuration, also known as roaming, there is no association made between the Gateway and Endpoints. Each Endpoint has its own unique identity, and security credentials used to connect to the Amazon Sidewalk network. In the Personal Area Network configuration, there is an association between the Endpoint and the Gateway belonging to the same user. This allows Amazon Sidewalk to set the appropriate data usage limits and routing prioritization. Each of these configurations comes with its own security model. A Gateway has to be configured to participate in the Amazon Sidewalk network. The process of configuring a Gateway to participate in the Amazon Sidewalk network is governed by the Amazon Sidewalk consent agreement. The maximum bandwidth of an Amazon Sidewalk Gateway to the Amazon Sidewalk Cloud is 80 kbps. When a registered Gateway user shares their Gateway’s bandwidth with Amazon Sidewalk, the total monthly data used by Amazon Sidewalk is capped at 500 MB per account. Endpoints working in the Amazon Sidewalk network may use three wireless technologies for communication - see figure 2.1 which shows the corresponding ranges. The short range uses BLE over a 1 or 2 Mbps link. The medium range is based on SubG-FSK. The long range is based on SubG-CSS. Currently, Endpoints may use only one of these wireless technologies. Dynamic switch between these three modulations and consequently data rates are not currently supported on the Endpoint side. Gateways support all three of these technologies. Fig. 2.1 Sidewalk wireless technologies coverage . Endpoints may use one of two connection modes to connect to the network: asynchronous or synchronous. Connection configuration includes the following options: . | The following wireless technologies and communication ranges are enabled on Endpoints: . | Short range communication using BLE | Medium range communication using SubG-FSK | Long range communication using SubG-CSS | . | Modulation usage has an impact on data rate traffic: . | CSS modulation supports the lowest data rate on the SubG-CSS link (see section 5.7.2 for details). | GFSK supports higher data rates on the SubG-FSK, and BLE links (see section 5.7.3 for details). | . | There are two connection modes: . | Asynchronous mode (see section 5.5.2 for details). | Synchronous mode (see section 5.2 for details). | . | There are two types of sub-network in which the Endpoint can operate: . | Personal Area Network, for details see section 2.2. | Wide Area Network, for details see section 2.3. | . | . Theoretically there are many possible ways to configure Amazon Sidewalk Endpoints, but the specification supports three configurations: . | SubG-FSK - synchronous - WAN | SubG-CSS - asynchronous - WAN | BLE | . Dynamic switching between configurations at the mac layer is not possible. The following diagram shows the full Amazon Sidewalk network component end-to-end (E2E) software architecture. Fig. 2.2 Sidewalk E2E Architecture . ", "url": "/specifications/sidewalk-protocol-spec/network-architecture.html", "relUrl": "/specifications/sidewalk-protocol-spec/network-architecture.html" },"654": { "doc": "2. Network Architecture", "title": "2.1 Entities and roles", "content": "The main actors in the Amazon Sidewalk network are as follows: . | End user interface, which could be placed in a mobile phone as an application or in a web service. | The cloud, which is the central entity of the whole system. | Gateways, which are nodes providing Amazon Sidewalk connectivity to Endpoints like security sensors, trackers and motion sensors. | An Endpoint, which provides specific functionality to its owner. | . All of these elements create the Amazon Sidewalk network. A high level description of each element may be found in subsequent sections. The specification defines interaction between Endpoints and Gateways. Cooperation between neighbor Gateways is described from a high level point of view to facilitate a better understanding of the whole system. A detailed description of Gateways interaction is outside the scope of this document. The description of interaction between cloud and Endpoint is provided in the Application Layer level from the protocol stack perspective. 2.1.1 End user interface . User interaction with the whole system is provided via the mobile app and/or via the web interface. User changes in the user interface related to selected Endpoints trigger message flow which is described in figure 2.3. Fig. 2.3 End user interaction with an Endpoint . 2.1.2 Cloud . The cloud is the central component of the Amazon Sidewalk network. It hosts the Amazon Sidewalk Network Server responsible for packet routing. The cloud also provides application level services for different types of Endpoints, participates in communication between end user applications and Endpoints, handles different security aspects, and many other functions. The cloud also works as a database, incorporates a central routing repository, and stores different information about Endpoints, like connection profile settings and radio conditions. The cloud also has knowledge about the network topology, coverage and Gateways supporting roaming. The cloud schedules downlink messages to Endpoints using the best available route. In synchronous mode, the Connection Profile determines the downlink transmit schedule. In asynchronous mode, downlink uses ad hoc scheduling. The cloud is responsible for scheduling downlink transmissions to avoid storing data on the Gateway for long periods. The Amazon Sidewalk Cloud selects the best Gateway, based on RSSI and other heuristics, to route downlink traffic, especially in cases when Endpoints are roaming. 2.1.3 Gateways . Amazon Sidewalk Gateways are special nodes of the Amazon Sidewalk network. These Nodes provide access to the external network for Endpoints organized in PAN and WAN networks. A single Gateway may support one PAN and one WAN network (for more detailed information about network types and topology, see section 2.2 and section 2.3). The traffic from an Endpoint to the cloud is handled by the Gateway as a passthrough node. The Gateway has no access to the application data sent from an Endpoint or received from the cloud because the application data are encrypted at the network and application levels. Gateways may work in different configurations mainly impacting used modulations and subsequently different data rates. SubG-CSS and SubG-FSK modes of operation use the same radio, dynamically switching between the modes at runtime. SubG-CSS allows asynchronous while SubG-FSK allows synchronous communication. SubG-FSK-only or SubG-CSS-only modes of operation are also possible. All of these possible configurations are described in section 5.4. BLE uses a separate radio so works independently of SubG-CSS or SubG-FSK usage. A Gateway may receive data from SubG-CSS or SubG-FSK and BLE links simultaneously. The downlink transmission to an Endpoint is done either by SubG-CSS, SubG-FSK or BLE link based on the cloud’s decision. A Gateway having SubG-CSS or SubG-FSK capability has its own limited database which stores information about TX opportunities for operating Endpoints. Dependent on the user configuration, roaming support may be enabled or disabled. Based on stored information, a Gateway is able to recognize roaming Endpoints and subsequently allow or reject traffic coming from Endpoints. A Gateway also stores Endpoint network measurements reports so it may control Endpoints’ power transmission. As well as functioning as network service providers, Gateways also aid network topology map construction and maintenance in the cloud. Gateways perform periodic scans of their neighboring nodes and relay this information to cloud. Occasionally a Gateway may lose its connection to the cloud. This information is provided to all surrounding Endpoints in the Beacon frame (see section 5.1.3.1). When a Gateway link to a cloud is malfunctioning then it may try to get access to the external network through neighbor Gateways. This mode is called ”distressed mode” and is described in section 5.6.5. Information about the Gateway-cloud link health is not available for SubG-CSS Endpoints. 2.1.4 Endpoints . An Endpoint is a device that does not have responsibility for routing data or maintaining connection with the Amazon Sidewalk network for any device other than itself. These Endpoints provide different types of functionalities for the end user such as tracking devices, motion sensors and many others. These Endpoints have no direct Internet connectivity and are connected to the network through Amazon Sidewalk Gateways. Endpoints operating using the SubG-FSK mode achieve synchronization during the Gateway discovery and subsequently the Beacon detection process. The procedure is described in section 5.2.1. When a Beacon is received, the Endpoint gets uplink and downlink offset and periodicity. The Endpoint may exchange data as long as it is synchronized. A lack of synchronization results in a new Gateway discovery process. An Endpoint operating with SubG-CSS may work in asynchronous mode only and WAN network type. The Endpoint does not need to be time-synchronized or associated with a Gateway. The Endpoint starts its transmission when required and does not specify which Gateway may handle that traffic. The uplink (UL) may be detected by various Gateways and the data is sent by them to the cloud. The decision about which Gateway shall handle downlink to the Endpoint is taken by the Amazon Sidewalk Network Server. The process of sending and receiving data between Endpoint and Gateway is described in section 5.3. Endpoints operating in asynchronous access mode are configured in one of two available Power Profiles. Basically, profiles configure the frequency of RX opportunities. The selected Endpoint profile have a direct impact on power consumption and also latency in both the uplink and downlink directions. Details related to Power Profiles are described in section 5.5. An Endpoint using BLE preserves behavior specified in the Bluetooth Low Energy Specification v 4.2. Chapter 6 provides the specification for Beacon and data frames. It also provides all other information required for appropriate BLE interaction of the Endpoint with the Amazon Sidewalk system that is complementary to the BLE specification. ", "url": "/specifications/sidewalk-protocol-spec/network-architecture.html#21-entities-and-roles", "relUrl": "/specifications/sidewalk-protocol-spec/network-architecture.html#21-entities-and-roles" },"655": { "doc": "2. Network Architecture", "title": "2.2 PAN", "content": "Personal Area Network (PAN) integrates Endpoints and Gateways which belong to the same registered Amazon or Ring user account and allow them to bypass the opt-out and data limit restriction. All Endpoints within the PAN area share the same security key called a PAN key or broadcast key. This key is provided to an Endpoint at the time of device provisioning. PAN can have one or more Gateways. These are central nodes of the network and can serve one or multiple Endpoints.Figure 2.4 shows the case when the PAN has one Gateway as a central node and a few Endpoints which are connected to the cloud via the Gateway. Fig. 2.4 Endpoint—cloud communication . Endpoints on the Amazon Sidewalk network shall limit the number of messages transmitted on the PAN BLE uplink. For the limit see Table 2.1. If an Endpoint exceeds the limit on the number of messages transmitted on the PAN uplink, then it may be disconnected from the Amazon Sidewalk network. Table 2.1 Maximum throughput for each Endpoint on PAN uplink . | PHY | Maximum throughput/messages | . | BLE | 600/min | . ", "url": "/specifications/sidewalk-protocol-spec/network-architecture.html#22-pan", "relUrl": "/specifications/sidewalk-protocol-spec/network-architecture.html#22-pan" },"656": { "doc": "2. Network Architecture", "title": "2.3 WAN", "content": "Wide Area Network (WAN) integrates Endpoints and Gateways independent of their ownership. Each Endpoint within the WAN area has its own unique device key which changes periodically. The cloud is the entity which takes responsibility for ensuring authenticity and integrity of the incoming messages from the Endpoints. The security model adopted by WAN Endpoints is called WAN Network Topology. WAN has multiple Gateways which serve one or multiple Endpoints. Unless roaming support is disabled by the user, all the Gateways are by default configured to serve any Endpoints. In this case, Gateways provide connectivity beyond the limit of the Personal Area Network. The Gateway mostly serves as a passthrough device. Endpoints may use SubG-FSK, SubG-CSS modes and BLE to communicate over the WAN network. The end user may restrict usage of its own Gateway from supporting other users’ Endpoints in the WAN network topology. Endpoints working in SubG-FSK mode may get the indication whether Gateway supports roaming Endpoints. This information is provided in the Beacon frame format on the Link Layer level. When an Endpoint is in WAN mode outside its own Gateway coverage then should refrain from sending a message to the Gateway when it does not support roaming. Endpoints working in SubG-CSS mode have no information about which Gateway supports roaming or not. The SubG-CSS Endpoint sends the message and each Gateway receiving that message takes a decision whether the data should be forwarded to the cloud. Due to Amazon Sidewalk network’s spatial diversity, it is possible that two or more Gateways may forward the same message to the cloud. It is the cloud’s task to recognize duplicated packets and also take a decision about which Gateway would handle downlink transmission. Communication in the WAN network is shown in figure 2.5. The end user may restrict usage of its own Gateway from supporting other users’ Endpoints over all PHYs. Fig. 2.5 WAN network . The Amazon Sidewalk network enforces uplink maximum traffic rates for endpoints. Please refer to Sidewalk End Device Maximum Uplink Traffic Rates in the Sidewalk documentation for details. ", "url": "/specifications/sidewalk-protocol-spec/network-architecture.html#23-wan", "relUrl": "/specifications/sidewalk-protocol-spec/network-architecture.html#23-wan" },"657": { "doc": "4.6 Obfuscated TX(Transmission) ID", "title": "4.6 Obfuscated TX(Transmission) ID", "content": "Due to pseudo-anonymity requirements, the Device ID may not be exposed for unauthorized tracking in the radio protocol. An obfuscation process is implemented to avoid exposing the Device ID. 4.6.1 Device ID obfuscation . ID obfuscation is a method for increasing device anonymity/privacy by generating a temporary ID to help prevent brute force attacks. The Network Server key generated during registration is used to create a Device ID obfuscation key. The Device ID obfuscation key is used to generate TXID using the equation below. The TXID rotation window is negotiated during registration. The default value for the TXID rotation window is 900 s. | TXID=HMAC(DeviceIDobfuscationKey, sha256(Time_Reference, Device ID))[0:4] | . where . | DeviceIDobfuscationKey: TXID_CTRREF for counter-based procedure and TXID for GCS time-based procedure | Time_Reference: counter or GCS time. Time size: 4 B are allocated. | [ 0 ..4] - TXID is five LSB from AES-HMAC algorithm result. | . The mapping from the TXID to the customer ID is maintained by the Application Server. Due to possible differences between Endpoint local time and network server time (time drift), three TXIDs are generated with Time_Reference, Time_Reference+900 s and Time_Reference - 900 s which are called the Current, Next and Previous TXIDs. Three TXIDs are generated to validate the obfuscated Device ID received in the message. Packets with an obsolete TXID are discarded by the receiver. fig 4.11 ID rotation . TXIDs are calculated in both the Network Server and the Endpoint. ", "url": "/specifications/sidewalk-protocol-spec/security/obfuscated-tx-transmission-id.html", "relUrl": "/specifications/sidewalk-protocol-spec/security/obfuscated-tx-transmission-id.html" },"658": { "doc": "7. Observability and Troubleshooting", "title": "7. Observability and troubleshooting", "content": "A GSK transition drives the device out of SID_STATE_READY and back. On a sub-GHz-only product, every establishment, expiry and fallback drives on_status_changed to SID_STATE_NOT_READY (1) and back on SubG-CSS, unless the application selected MDR (§2.1); on SubG-FSK a GSK transition does not itself leave network synchronization, so state does not change. On SubG-CSS the re-initialization can report SID_STATUS_NO_TIME (1) transiently. Neither is a fault. Gate sends on SID_STATE_READY (0), which requires network synchronization (Glossary), but drive product state machines on a state sustained longer than the several minutes a transition can take. | Symptom | Likely cause | Action | . | No GSK activity, with registration, sub-GHz network synchronization or GSK enablement unconfirmed | Not registered; or radio-connected but not network-synchronized; or the network has not enabled GSK for this device; or the link in use is Bluetooth LE | Confirm that registration_status and time_sync_status report network synchronization (Glossary), and that a sub-GHz link is in use. If all hold, GSK is not enabled for this device (§8, step 0). | . | No GSK activity, with all three confirmed | The quiet window never elapses: on a busy device idle_timeout_sec exceeds the routine gap between sub-GHz messages; on a quiet device the effective keep-alive interval is at or below idle_timeout_sec — most often a LoRa Profile B device at a 2 or 3 min network-sync interval against the 240 s default window, including one set by passing nwsync_time = 0 with is_set = true (§4). Shortly after bring-up, expect minutes of delay before the first establishment | Lower idle_timeout_sec below the shortest routine inter-message gap; the minimum is 10 s. Read the effective keep-alive interval (§4) and apply Figure 6.1: raise nwsync_time to at least idle_timeout_sec / 45, in minutes, never to 0 (§6). | . | LoRa link never establishes a session in this region | MDR is not available in this region — never in the EU (§2.1); a rejected attempt changes no data rate and costs no link bounce | None. The device operates normally at LDR (§2.1), at 5000 ms separation only. | . | Device stuck with time_sync_status == SID_STATUS_NO_TIME (1) persistently | No network time, so establishment cannot start | Resolve time synchronization first — coverage, registration, Gateway reachability. A transient NO_TIME during a LoRa PHY change is expected (above). | . | SubG-FSK link drops and returns; state cycles NOT_READY then READY | Not an establishment signature. A successful FSK establishment does not leave network synchronization, so it changes nothing in state (the Amazon Sidewalk Sid API Developer Guide). A visible FSK bounce is a join that never completed — a GSK establishment that could not re-join, or an ordinary FSK link outage | Re-send what failed during the bounce. If it repeats, treat it as FSK coverage, not GSK. | . | The SubG-CSS link bounces once after a reboot, or cycles — bounce, quiet, bounce again — with no reboot | The stored session was not accepted when the link returned, so a fresh establishment ran (§2.2) — usually a reboot out of coverage or near a different Gateway | None if it correlates with poor coverage at boot. If it happens on every reboot in good coverage, capture the reboot-to-first-uplink sequence and raise it as in §8, step 0. | . | LoRa throughput, range or downlink latency changes without an application request | Activation moved the link to MDR; a fallback moved it back to LDR and reset the live window (unless the application selected MDR, §2.1) | Size coverage, airtime and latency for both data rates (§2.1). A required MDR separation is re-applied by the stack and needs no action (§4). | . | A run of ack-requested uplinks fails with SID_ERROR_TIMEOUT (-2), then traffic succeeds again | The detector reached app_ack_miss_threshold and discarded the session (§2.2). Those messages were not retransmitted. | Re-send the payloads you cannot lose, as above. If this recurs in good RF, raise the threshold toward 6 or 8; expect non-GSK mode until the next establishment retry (retry_interval_sec, §3) or a reboot. | . | The LoRa link bounces twice per retry_interval_sec — at the same time each day at the default — and no session ever appears | Each establishment retry is failing: one bounce into MDR on the way in, one back to LDR on the way out (§2.1) | No application-side fix. Confirm GSK enablement as in §8, step 0, and verify MDR coverage at the device’s location (§2.1). | . Table 7.1: GSK observability and troubleshooting. ", "url": "/app-notes/gateway-session-key/observability-and-troubleshooting.html#7-observability-and-troubleshooting", "relUrl": "/app-notes/gateway-session-key/observability-and-troubleshooting.html#7-observability-and-troubleshooting" },"659": { "doc": "7. Observability and Troubleshooting", "title": "7. Observability and Troubleshooting", "content": " ", "url": "/app-notes/gateway-session-key/observability-and-troubleshooting.html", "relUrl": "/app-notes/gateway-session-key/observability-and-troubleshooting.html" },"660": { "doc": "On Amazon Sidewalk Badge Guidelines", "title": "On Amazon Sidewalk – Badge Guidelines", "content": "On Amazon Sidewalk Badge Guidelines . The On Amazon Sidewalk badge may only be used in connection with Amazon Sidewalk Devices (as defined in the AWS Service Terms), which includes any of your devices or chips that connect to Amazon Sidewalk, that have been and remain qualified through the On Amazon Sidewalk qualification program. Any developer or chip manufacturer that is incorporating the On Amazon Sidewalk badge, logo, or symbols into their content should use the guidance outlined below. For a company to download and use Sidewalk’s trademarks, the company must have completed the Sidewalk Qualification Process for the specific product the trademarks will be applied to. Amazon may revoke the right to use these trademarks at any time for any purpose. Download On Amazon Sidewalk Assets here . What is the On Amazon Sidewalk Badge? . The On Amazon Sidewalk badge helps communicate the relationship between Amazon Sidewalk and your products or services. We encourage all qualified products to leverage the appropriate badge to drive consistency and brand recognition. Qualified products can integrate badges into product packaging, online placements, and marketing collateral. Once qualified, if you would like to use the On Amazon Sidewalk badge, contact Amazon Sidewalk team to request for the applicable badge design to be provided to you. Don’t use multiple badges in your marketing collateral. On Amazon Sidewalk Badge Usage Guidelines . Clear Space . Clear space is the area around the badge that should remain free of any other logos, graphics, text, or borders. The minimum clear space for the logo should be equivalent to the height of the Amazon Sidewalk text, . and logo must appear by itself in a clearly visible location. Minimum Size . Horizontal badges must be no smaller than 7mm high for print, and 55px for 1x resolution screen, or 110 pixels on a 2x resolution screen.  . Placement . When Amazon Sidewalk badges are used in third-party applications such as banner ads, as well as product packaging, retail displays, and marketing materials, the following guidelines should be followed: . Amazon Sidewalk badge should be a secondary element and not the primary branded element in the materials. The Amazon Sidewalk badge should be smaller than the key third-party product, message, or brand being represented. The Amazon Sidewalk badge in the lower third of the application or packaging when possible. ", "url": "/sidewalk-terms-and-agreements/on-amazon-sidewalk-badge-guidelines.html#on-amazon-sidewalk--badge-guidelines", "relUrl": "/sidewalk-terms-and-agreements/on-amazon-sidewalk-badge-guidelines.html#on-amazon-sidewalk--badge-guidelines" },"661": { "doc": "On Amazon Sidewalk Badge Guidelines", "title": "On Amazon Sidewalk Badge Guidelines", "content": " ", "url": "/sidewalk-terms-and-agreements/on-amazon-sidewalk-badge-guidelines.html", "relUrl": "/sidewalk-terms-and-agreements/on-amazon-sidewalk-badge-guidelines.html" },"662": { "doc": "On Amazon Sidewalk Qualification Guidelines", "title": "On Amazon Sidewalk Qualification Guidelines", "content": "These On Amazon Sidewalk Qualification Guidelines are part of the Policies governing your use of AWS IoT Core for Amazon Sidewalk and/or participation in the On Amazon Sidewalk qualification program. Capitalized terms used, but not defined, in these guidelines have the meanings given in the AWS Customer Agreement or the AWS Service Terms, as applicable. End Users trust that Amazon Sidewalk Devices meet a high standard for quality and integration with Amazon Sidewalk. You may not sell, distribute, or otherwise make available any Amazon Sidewalk Device, or use any On Amazon Sidewalk Marks in connection with any Amazon Sidewalk Device, unless that Amazon Sidewalk Device has been and remains qualified at all times through the On Amazon Sidewalk qualification program. For details on the On Amazon Sidewalk qualification program, see our On Amazon Sidewalk program documentation (which are incorporated into and are a part of these guidelines). ", "url": "/sidewalk-terms-and-agreements/on-amazon-sidewalk-qualification-guidelines.html", "relUrl": "/sidewalk-terms-and-agreements/on-amazon-sidewalk-qualification-guidelines.html" },"663": { "doc": "On Amazon Sidewalk Qualification Guidelines", "title": "General Guidelines", "content": ". | We may determine in our sole discretion which Amazon Sidewalk Devices receive and maintain On Amazon Sidewalk qualification. Meeting these qualification guidelines does not guarantee that your Amazon Sidewalk Device will be qualified, but you must comply with these guidelines to be eligible for qualification. We review On Amazon Sidewalk qualification requests based on the quality of your Amazon Sidewalk Device’s integration with Amazon Sidewalk, its specifications, and other information you provide to us, among other criteria. | We may limit qualification to specific countries or territories and require you to re-qualify an Amazon Sidewalk Device before selling, distributing, or otherwise making it available in additional countries or territories. | We may update these qualification guidelines to introduce new features or requirements. You must comply with these qualification guidelines, as updated from time to time, to maintain qualification of your Amazon Sidewalk Devices. | You agree that we may publish the following information about your Amazon Sidewalk Device’s qualification: Amazon Sidewalk Device details, features claimed, Amazon Sidewalk protocol specification version, qualification status, and any Amazon Sidewalk Device documentation that you provide for publication with an Amazon Sidewalk Device’s qualification listing. | At all times, including whether or not in connection with use of the On Amazon Sidewalk badge, you may not misrepresent, mislead, or embellish the nature of your relationship to us, your Amazon Sidewalk Devices’ qualification status, the scope or meaning of your Amazon Sidewalk Devices’ qualification, or the compatibility of any of your Amazon Sidewalk Devices with Amazon Sidewalk, each Amazon Sidewalk may be determined by us in our sole discretion. | . ", "url": "/sidewalk-terms-and-agreements/on-amazon-sidewalk-qualification-guidelines.html#general-guidelines", "relUrl": "/sidewalk-terms-and-agreements/on-amazon-sidewalk-qualification-guidelines.html#general-guidelines" },"664": { "doc": "On Amazon Sidewalk Qualification Guidelines", "title": "Quality Guidelines", "content": ". | Each Amazon Sidewalk Device must maintain reliable service and an overall good customer experience. For example, if your Amazon Sidewalk Device, or the associated application or service, experiences outages, latency, or other events that impact customers’ experience using the Amazon Sidewalk Device, the Amazon Sidewalk Device may lose its qualification. | Your Amazon Sidewalk Device and its associated application or service must be up-to-date with the latest applicable mandatory Amazon Sidewalk SDK functionality (including, without limitation, the Amazon Sidewalk hardware SDK and the Amazon Sidewalk mobile app SDK). If Amazon introduces mandatory new features or functionality to Amazon Sidewalk SDKs for your Amazon Sidewalk Device or associated applications or services, you must update your Amazon Sidewalk integration to include the mandatory new feature or functionality, as applicable. You are responsible for integration and distribution of any required security updates into your Amazon Sidewalk Devices and associated applications and services. | We may revoke qualification if an Amazon Sidewalk Device contains a vulnerability that impacts Amazon Sidewalk or other devices. You must continue to provide security updates for your Amazon Sidewalk Devices for the minimum time period we specify, and you must implement security updates to address vulnerabilities related to your Amazon Sidewalk Devices within the time periods we specify. You must immediately report the discovery of any vulnerability related to your Amazon Sidewalk Device to us. | . ", "url": "/sidewalk-terms-and-agreements/on-amazon-sidewalk-qualification-guidelines.html#quality-guidelines", "relUrl": "/sidewalk-terms-and-agreements/on-amazon-sidewalk-qualification-guidelines.html#quality-guidelines" },"665": { "doc": "3. One Time Onboarding", "title": "3. One-Time Onboarding", "content": "Complete the steps in this chapter before starting factory work. Sections 3.1 to 3.3 are performed once per company, because they are tied to your Amazon developer account and not to a product. Sections 3.4 and 3.5 are repeated for each product, because the device profile, APID and DAK belong to a single device type. Two steps require an action from Amazon. Submit these requests to Amazon Sidewalk support through the Amazon Sidewalk 360 portal early, because they carry external lead time. | Step | What you request | What you provide | . | 3.3 Scope allow-listing | Allow-list your LWA security profile for the sidewalk::manage_endpoint and frustration_free_setup::device:control_log scopes | Vendor ID, Customer ID, LWA Client ID, Security Profile ID, AWS account ID, device profile ID | . | 3.5 HSM provisioning and factory support | Provision the production DAK on your YubiHSM 2 unit, generate or link the APID for your device profile, and vend the DeviceTypeId | The seven items listed in Section 3.5 | . ", "url": "/app-notes/registration-over-wire/one-time-onboarding.html#3-one-time-onboarding", "relUrl": "/app-notes/registration-over-wire/one-time-onboarding.html#3-one-time-onboarding" },"666": { "doc": "3. One Time Onboarding", "title": "3.1 Control log onboarding", "content": "Control log onboarding is the same step used by the existing mass production flow. | Sign in to your Amazon developer account and go to the Amazon Frustration-Free Setup (Amazon FFS) developer console at developer.amazon.com/frustration-free-setup/console. | Go to the Control Logs section and choose Manage Control Logs. | Enter information about the business you want to onboard, which includes the Company Name, Contact name, Group Email and Contact phone. Use a group mailbox rather than a personal address, because it receives the control log notifications. | Choose Onboard. | . This registers your business for control log ingestion. During device onboard, sid-mfg-tool then uploads the control log for each device. Figure 2: Onboarding a business for control logs in the Amazon FFS developer console . ", "url": "/app-notes/registration-over-wire/one-time-onboarding.html#31-control-log-onboarding", "relUrl": "/app-notes/registration-over-wire/one-time-onboarding.html#31-control-log-onboarding" },"667": { "doc": "3. One Time Onboarding", "title": "3.2 Login with Amazon (LWA)", "content": "sid-mfg-tool authenticates to the Amazon Sidewalk cloud with Login with Amazon (LWA). | In the Amazon developer portal, create a security profile under Login with Amazon. | Under Web Settings, add exactly http://localhost:8000/ to Allowed Return URLs. The tool’s browser login receives the authorization code on a local listener at this address, and LWA only redirects to a return URL that is registered on the security profile. Leave Allowed Origins empty. | Record the Client ID and Client Secret shown under Web Settings, and the Security Profile ID shown on the profile’s General tab. | Record your Vendor ID and Customer ID from the Customer Details page at developer.amazon.com/settings/console/mycid. | . Figure 3: LWA security profile Web Settings . ", "url": "/app-notes/registration-over-wire/one-time-onboarding.html#32-login-with-amazon-lwa", "relUrl": "/app-notes/registration-over-wire/one-time-onboarding.html#32-login-with-amazon-lwa" },"668": { "doc": "3. One Time Onboarding", "title": "3.3 Scope allow-listing", "content": "Amazon must allow-list the security profile from Section 3.2 for both of the following scopes: . | sidewalk::manage_endpoint | frustration_free_setup::device:control_log | . Contact Amazon Sidewalk support with the details listed in the table at the start of this chapter. Until sidewalk::manage_endpoint is allow-listed, the tool’s browser login fails with invalid parameter : scope. Until frustration_free_setup::device:control_log is allow-listed, the first device onboard fails at the control log upload with LWA client_credentials returned 400. ", "url": "/app-notes/registration-over-wire/one-time-onboarding.html#33-scope-allow-listing", "relUrl": "/app-notes/registration-over-wire/one-time-onboarding.html#33-scope-allow-listing" },"669": { "doc": "3. One Time Onboarding", "title": "3.4 AWS IoT Core for Amazon Sidewalk", "content": "AWS IoT Core for Amazon Sidewalk is available only in the us-east-1 Region. | Create a device profile and a destination in us-east-1. | Record the device profile ID and the application server public key (64 hexadecimal characters) shown on the device profile page. | Create a named AWS CLI profile that is allowed to call sts:GetCallerIdentity and iotwireless:CreateWirelessDevice. If you use bulk device creation (see Chapter 4), the profile also needs the iotwireless:*WirelessDeviceImportTask actions and S3 PutObject. | . sid-mfg-tool uses only this named profile. It does not fall back to default credentials. After Amazon has provisioned your HSM (Section 3.5), the APID appears on the same device profile page. You can also obtain it with the GetDeviceProfile API operation or the aws iotwireless get-device-profile CLI command. The DeviceTypeId is vended by Amazon together with the HSM. ", "url": "/app-notes/registration-over-wire/one-time-onboarding.html#34-aws-iot-core-for-amazon-sidewalk", "relUrl": "/app-notes/registration-over-wire/one-time-onboarding.html#34-aws-iot-core-for-amazon-sidewalk" },"670": { "doc": "3. One Time Onboarding", "title": "3.5 HSM provisioning and factory support", "content": "HSM provisioning is the same step used by the existing mass production flow. Purchase a YubiHSM 2 unit directly from Yubico and submit the request described in “Getting an HSM Provisioned” in the Amazon Sidewalk Manufacturing documentation. Amazon provisions the production DAK on the HSM, generates or links the APID for your device profile, vends the DeviceTypeId and ships the HSM back. Amazon sends the DAK PIN by encrypted email, together with the product tag that identifies the DAK in the HSM. The product tag is the same value the Sidewalk signing tool accepts as --product (for example RNET_DAK_<PROJECT>), and is entered as the product name in sid-mfg-tool configure (Chapter 4). The APID must be linked to your device profile (factory support) before any devices are provisioned. ", "url": "/app-notes/registration-over-wire/one-time-onboarding.html#35-hsm-provisioning-and-factory-support", "relUrl": "/app-notes/registration-over-wire/one-time-onboarding.html#35-hsm-provisioning-and-factory-support" },"671": { "doc": "3. One Time Onboarding", "title": "3. One Time Onboarding", "content": " ", "url": "/app-notes/registration-over-wire/one-time-onboarding.html", "relUrl": "/app-notes/registration-over-wire/one-time-onboarding.html" },"672": { "doc": "2. Overview of the Functionality", "title": "2. Overview of the functionality", "content": "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. | Phase | Description | . | Gateway Discovery | The procedure of discovering nearby gateways through their periodic Beacon transmissions. During this phase, the Endpoint performs a passive scan listening for Amazon Sidewalk FSK beacons. Each discovered gateway to which an Endpoint can connect is added to a list. The discovery process is described in detail in the Amazon Sidewalk Specification, Section 5.2.1 Beacon discovery. | . | Gateway Selection | The second phase is the gateway selection process in which the Endpoint selects the best gateway from the list of gateways identified during the first phase based on a pre-configured selection criteria. | . | Connection Health Monitoring | The third phase is the monitoring of connection health with the connected gateway to take corrective action early in case the health of the connection with the connected gateway is deteriorating. | . Table 2.1: Gateway Discovery phases. The following sections describe the parameters and algorithms that are used in each of the three phases. ", "url": "/app-notes/gateway-discovery-selection/overview-of-functionality.html#2-overview-of-the-functionality", "relUrl": "/app-notes/gateway-discovery-selection/overview-of-functionality.html#2-overview-of-the-functionality" },"673": { "doc": "2. Overview of the Functionality", "title": "2.1 Gateway Discovery parameters", "content": "The following table describes the parameters for gateway discovery. | Parameters for gateway discovery | Description | . | Scanning timeout in seconds | Gateway discovery scanning timeout in seconds. How long the gateway scanning process is performed before selecting the best gateway out of the discovered gateways, or failure is reported to the developer that no gateways are found. See Chapter 4 for details. | . | Scanning back off | The parameters that determine the scanning back off algorithm. These parameters set the intervals of active scanning and also the sleep intervals between scanning. To reduce power consumption, Scanning back off increases the sleep intervals if the discovery process fails (when there are no gateways available for connection). See section 2.1.2 for details. | . | Continue scanning after fail | If this option is set to True, the stack will continue the scanning process even after reporting failure to the developer of no gateways found after Scanning timeout is expired. A new Gateway Discovery scanning cycle will start after the back off timeout ends. | . Table 2.2: Parameters for gateway discovery. 2.1.1 Discovery algorithm . The gateway discovery is performed according to the following algorithm: . | The Scanning timeout in seconds parameter determines the total time of the SubG-FSK discovery process that the Endpoint will perform. | During the discovery process, the Endpoint adds to the discovery list all gateways it can connect to. | 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. | If after the discovery process is completed there are found gateways in the list, then control passes to the Gateway Selection algorithm. | 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. | 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. | 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: . | Iteration | Scan duration in seconds | Sleep time in seconds | . | 1–5 | 40 | 60 | . | 6–15 | 40 | 300 | . | > 15 | 40 | 3600 | . Table 2.3: Default back off intervals. If the gateway is not found, the Endpoint operates as follows: . | 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. | 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. | 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. ", "url": "/app-notes/gateway-discovery-selection/overview-of-functionality.html#21-gateway-discovery-parameters", "relUrl": "/app-notes/gateway-discovery-selection/overview-of-functionality.html#21-gateway-discovery-parameters" },"674": { "doc": "2. Overview of the Functionality", "title": "2.2 Gateway Selection parameters", "content": "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. | Parameters for gateway selection | Description | . | Minimum RSSI to connect | Minimum RSSI level of the beacon which should be considered for Gateway Selection. On the platforms that support LQI, RSSI is replaced by LQI. | . | Use Gateway Load Indicator | Use the Gateway Load indicator indicated in the beacon’s payload to evaluate the gateway during selection. See section 2.2.1 for details. | . | Use Gateway Connection Health | Use the Gateway Connection Health indicated in the beacon’s payload to evaluate the gateway during selection. See section 2.2.2 for details. | . | Use Transmit Power Rank | Use Transmit Power Rank to evaluate the gateway during selection. In this case, the algorithm will use EIRP power of the gateway indicated in the beacon’s payload to evaluate the gateway during selection. See section 2.2.3 for details. | . 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: . | Cloud Connection Health | Description | . | 0 | Temporarily disconnected. This state means that the gateway is not connected to the Cloud at the moment, but is able to receive messages from Endpoints and buffer them. New connections are not allowed. But connected Endpoints still remain connected. | . | 1 | Experiencing recent intermittent disconnects. This state means that the gateway is currently connected to the cloud, but has recently been disconnected. In this state, the Endpoints can connect to the gateway, but its score may be reduced. | . | 2 | No connection with the cloud. In this state, new Endpoint connections are not allowed. All connected Endpoints will be disconnected. | . | 3 | Healthy connection. | . 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. | Gateway EIRP used for beacon transmission | Average RSSI of received beacons | Transmit Power Rank | Description | . | High | High | 2 | The EP might be closer to the gateway and might be able to use a lower tx power to communicate with the gateway. | . | High | Low | 4 | The EP might be farther from the gateway and might not be able to reach the gateway or has to use higher tx power. | . | Low | High | 1 | The EP might be closer to the gateway and might be able to use a lower tx power to communicate with the gateway. | . | Low | Low | 3 | The EP might be farther from the gateway and might not be able to reach the gateway or has to use higher tx power. | . 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. | Parameters for gateway score calculation | Weight calculation | Description | . | Gateway PAN | Is PAN GW: Yes = 5, No = 0 | If the gateway is private, then 5 points are added to its score. | . | Average gateway RSSI | Difference from min RSSI in dBm: 0–10 = 1, 11–20 = 2, 21–30 = 3, 31–40 = 4, >= 41 = 5 | The gateway with a higher RSSI level is a higher priority for selection. Points will be added to the gateway score depending on how much the signal level is above the Minimum RSSI to connect. | . | Gateway Load indicator | Load indicator: 0 = 4, 1 = 3, 2 = 2, 3 = 1 | Load on the gateway indicated in the beacon’s payload. If the Use Gateway Load Indicator parameter is set to True, then points will be added to the gateway score. | . | Cloud Connection Health | Experiencing recent disconnects (= 1) = 1, Healthy connection (= 3) = 3 | Cloud Connection health indicated in the beacon’s payload. The gateways with connection health value ‘0’ and ‘2’ are not added to the gateway discovered list. | . | Transmit Power Rank | Rank: 1 = 4, 2 = 3, 3 = 2, 4 = 1 | Transmit Power Rank of the gateway. If the Use Transmit Power Rank parameter is set to True, then points will be added to the Gateway score. | . 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. | Gateway # | Is PAN | Average RSSI | Load Indicator | Gateway Connection Health | Transmit Power Rank | Score | . | 1 | True<br>Weight = 5 | -60<br>Difference from min RSSI is 30<br>Weight = 3 | 2<br>Weight = 2 | 1<br>Weight = 1 | 2<br>Weight = 3 | 5 + 3 + 2 + 1 + 3 = 14 | . | 2 | False<br>Weight = 0 | -45<br>Difference from min RSSI is 45<br>Weight = 5 | 0<br>Weight = 4 | 3<br>Weight = 3 | 1<br>Weight = 4 | 0 + 5 + 4 + 3 + 4 = 13 | . | 3 | False<br>Weight = 0 | -90<br>Difference from min RSSI is 0<br>Weight = 1 | 3<br>Weight = 1 | 3<br>Weight = 3 | 4<br>Weight = 1 | 0 + 1 + 1 + 3 + 1 = 6 | . Table 2.8: Gateway score calculation example. 2.2.5 Gateway Selection Algorithm . The gateway selection is performed according to the following algorithm: . | From the list of discovered gateways, those gateways to which a connection is possible are considered. | 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. | The score is calculated by adding the weights of the parameters mentioned in the above table. | Depending on policy settings, certain parameters may not be considered when calculating the score. | If no gateway is found that satisfies the selection criteria, the developer is notified using the control event notify callback on_control_event_notify. | 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. | After connecting the EP to the gateway, the control moves to the Connection Health Monitoring phase. | . ", "url": "/app-notes/gateway-discovery-selection/overview-of-functionality.html#22-gateway-selection-parameters", "relUrl": "/app-notes/gateway-discovery-selection/overview-of-functionality.html#22-gateway-selection-parameters" },"675": { "doc": "2. Overview of the Functionality", "title": "2.3 Gateway Connection Health Monitoring", "content": "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. | Parameters for connection health monitoring | Description | . | Threshold RSSI to disconnect | RSSI level at which the EP initiates disconnection from the connected gateway. On the platforms that support LQI, RSSI is replaced by LQI. | . | Number of messages for threshold RSSI | Number of beacons to calculate the average RSSI level to initiate disconnection by Threshold RSSI to disconnect. | . | Maximum missed beacons | The maximum number of consecutive beacons that can be missed before the EP notifies disconnection and starts a new discovery process. | . | Maximum skipped beacons | The maximum number of beacons the EP can skip listening. Please note that this parameter does not influence the decision to disconnect but is used to save power after connected. | . | Gateway Load to disconnect | If the load indicator on the beacon indicates the gateway is experiencing greater loads, the EP initiates disconnection. | . 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: . | The Endpoint monitors the beacons of the connected gateway and analyzes the values of its internal fields. | 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. | 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. | 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. | 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. | . ", "url": "/app-notes/gateway-discovery-selection/overview-of-functionality.html#23-gateway-connection-health-monitoring", "relUrl": "/app-notes/gateway-discovery-selection/overview-of-functionality.html#23-gateway-connection-health-monitoring" },"676": { "doc": "2. Overview of the Functionality", "title": "2.4 Gateway Discovery and Selection policies", "content": "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 . | Parameter | Setting | . | Scanning timeout in seconds | 40 | . | Continue scanning after fail | True | . Scanning back off: . | Iteration | 1–5 | 6–15 | > 15 | . | Scan duration | 40 | 40 | 40 | . | Sleep time | 60 | 300 | 3600 | . Gateway selection parameters: Not applicable to default policy. Connection health monitoring . | Parameter | Setting | . | Threshold RSSI to disconnect | Not used | . | Number of messages for threshold RSSI | Not used | . | Maximum missed beacons | 3 | . | Maximum skipped beacons | 0 | . | Gateway Load to disconnect | Not used | . 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 . | Parameter | Setting | . | Scanning timeout in seconds | 30 | . | Continue scanning after fail | True | . Scanning back off: . | Iteration | 1–5 | 6–15 | > 15 | . | Scan duration | 30 | 30 | 20 | . | Sleep time | 30 | 60 | 120 | . Gateway selection parameters . | Parameter | Setting | . | Minimum RSSI to connect | -90 | . | Use Gateway Load indicator | True | . | Use Gateway Connection Health | True | . | Use Transmit Power Rank | False | . Connection health monitoring . | Parameter | Setting | . | Threshold RSSI to disconnect | -95 | . | Number of messages for threshold RSSI | 3 | . | Maximum missed beacons | 2 | . | Maximum skipped beacons | 0 | . | Gateway Load to disconnect | Not used | . 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 . | Parameter | Setting | . | Scanning timeout in seconds | 90 | . | Continue scanning after fail | True | . Scanning back off: . | Iteration | 1–5 | 6–15 | > 15 | . | Scan duration | 90 | 30 | 30 | . | Sleep time | 30 | 300 | 3600 | . Gateway selection parameters . | Parameter | Setting | . | Minimum RSSI to connect | -75 | . | Use Gateway Load indicator | True | . | Use Gateway Connection Health | True | . | Use Transmit Power Rank | True | . Connection health monitoring . | Parameter | Setting | . | Threshold RSSI to disconnect | -85 | . | Number of messages for threshold RSSI | 3 | . | Maximum missed beacons | 3 | . | Maximum skipped beacons | 0 | . | Gateway Load to disconnect | 3 | . 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 . | Parameter | Setting | . | Scanning timeout in seconds | 120 | . | Continue scanning after fail | True | . Scanning back off: . | Iteration | 1–5 | 6–15 | > 15 | . | Scan duration | 30 | 20 | 10 | . | Sleep time | 120 | 600 | 3600 | . Gateway selection parameters . | Parameter | Setting | . | Minimum RSSI to connect | -80 | . | Use Gateway Load indicator | True | . | Use Gateway Connection Health | True | . | Use Transmit Power Rank | True | . Connection health monitoring . | Parameter | Setting | . | Threshold RSSI to disconnect | -85 | . | Number of messages for threshold RSSI | 3 | . | Maximum missed beacons | 5 | . | Maximum skipped beacons | 2 | . | Gateway Load to disconnect | 3 | . 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 . | Parameter | Setting | . | Scanning timeout in seconds | 120 | . | Continue scanning after fail | Provided by developer | . Scanning back off: . | Iteration | 1–5 | 6–15 | > 15 | . | Scan duration | 30 | 30 | 30 | . | Sleep time | 60 | 300 | 3600 | . Gateway selection parameters . | Parameter | Setting | . | Minimum RSSI to connect | Provided by developer | . | Use Gateway Load indicator | Provided by developer | . | Use Gateway Connection Health | Provided by developer | . | Use Transmit Power Rank | Provided by developer | . Connection health monitoring . | Parameter | Setting | . | Threshold RSSI to disconnect | Provided by developer | . | Number of messages for threshold RSSI | Provided by developer | . | Maximum missed beacons | Provided by developer | . | Maximum skipped beacons | Provided by developer | . | Gateway Load to disconnect | Provided by developer | . 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: . | Parameter | Setting | . | Scanning timeout in seconds | 30 seconds | . | Continue scanning after fail | True | . Scanning back off: . | Iteration | 1–5 | 6–15 | > 15 | . | Scan duration | 30 | 30 | 30 | . | Sleep time | 60 | 300 | 3600 | . Gateway selection parameters: . | Parameter | Setting | . | Minimum RSSI to connect | -90 | . | Use Gateway Load indicator | True | . | Use Gateway Connection Health | True | . | Use Transmit Power Rank | True | . Connection health monitoring: . | Parameter | Setting | . | Threshold RSSI to disconnect | -100 | . | Number of messages for threshold RSSI | 3 | . | Maximum missed beacons | 3 | . | Maximum skipped beacons | 0 | . | Gateway Load to disconnect | 3 | . 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: . | Parameter | Setting | . | Scanning timeout in seconds | 60 seconds | . | Continue scanning after fail | True | . Scanning back off: . | Iteration | 1–10 | 11–20 | 21–30 | > 30 | . | Scan duration | 60 | 60 | 60 | 60 | . | Sleep time | 60 | 120 | 240 | 480 | . Gateway selection parameters: . | Parameter | Setting | . | Minimum RSSI to connect | Not used | . | Use Gateway Load indicator | False | . | Use Gateway Connection Health | False | . | Use Transmit Power Rank | True | . Connection health monitoring: . | Parameter | Setting | . | Threshold RSSI to disconnect | Not used | . | Number of messages for threshold RSSI | Not used | . | Maximum missed beacons | 3 | . | Maximum skipped beacons | 0 | . | Gateway Load to disconnect | Not used | . 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: . | Parameter | Setting | . | Scanning timeout in seconds | 40 seconds | . | Continue scanning after fail | False | . Scanning back off: . | Iteration | >= 1 | . | Scan duration | 20 | . | Sleep time | 20 | . Gateway selection parameters: . | Parameter | Setting | . | Minimum RSSI to connect | -85 | . | Use Gateway Load indicator | True | . | Use Gateway Connection Health | True | . | Use Transmit Power Rank | True | . Connection health monitoring: . | Parameter | Setting | . | Threshold RSSI to disconnect | -95 | . | Number of messages for threshold RSSI | 5 | . | Maximum missed beacons | 4 | . | Maximum skipped beacons | 0 | . | Gateway Load to disconnect | Not used | . 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. ", "url": "/app-notes/gateway-discovery-selection/overview-of-functionality.html#24-gateway-discovery-and-selection-policies", "relUrl": "/app-notes/gateway-discovery-selection/overview-of-functionality.html#24-gateway-discovery-and-selection-policies" },"677": { "doc": "2. Overview of the Functionality", "title": "2. Overview of the Functionality", "content": " ", "url": "/app-notes/gateway-discovery-selection/overview-of-functionality.html", "relUrl": "/app-notes/gateway-discovery-selection/overview-of-functionality.html" },"678": { "doc": "2. Overview of Functionality", "title": "2. Overview of Functionality", "content": "Amazon Sidewalk provides an Application Programming Interface API (the “Sid API”) that allows Amazon Sidewalk device creators to onboard their devices to Amazon Sidewalk, and to manage an encrypted data pipe over BLE and sub-GHz radio interfaces. A developer’s application interacts with the Amazon Sidewalk stack through the Sid API. The Sid API supports the following operations for Amazon Sidewalk links: . | Initialize and de-initialize links. | Start and stop links. | Send and receive messages. | Set and get configuration through IOCTLs. | . ", "url": "/sid-api-dg/overview-of-functionality.html", "relUrl": "/sid-api-dg/overview-of-functionality.html" },"679": { "doc": "2. Overview of Functionality", "title": "2.1 Supported Links", "content": "Amazon Sidewalk supports three radio link types that can be used by devices to transport messages between the application running on the Endpoint device and the application services interacting with AWS IoT Core for Amazon Sidewalk, and one wired link type that is used only for factory registration (section 2.3.4). These links are enumerated in the following code, and described below. /** * Describes the link types supported by the Sidewalk stack. * * Note: Previously SID_LINK_TYPE_BLE used here now maps to SID_LINK_TYPE_1. * The change is done to abstract link names from physical link types since * more combinations are expected to be added in the future. */ enum SID_LINK_TYPE { /** Bluetooth Low Energy link */ SID_LINK_TYPE_1 = 1 << 0, /** 900 MHz link for FSK */ SID_LINK_TYPE_2 = 1 << 1, /** 900 MHz link for LoRa */ SID_LINK_TYPE_3 = 1 << 2, /** Wired (serial/UART) link, used only for factory registration */ SID_LINK_TYPE_8 = 1 << 7, /** Any Link Type */ SID_LINK_TYPE_ANY = INT_MAX, }; enum SID_LINK_TYPE_idx { /** Bluetooth Low Energy link */ SID_LINK_TYPE_1_IDX = 0, /** 900 MHz link for FSK */ SID_LINK_TYPE_2_IDX = 1, /** 900 MHz link for LoRa */ SID_LINK_TYPE_3_IDX = 2, /** sid max supported links */ SID_LINK_TYPE_MAX_IDX, }; . SID_LINK_TYPE_8 is not a radio link. It is brought up by the serial registration API (section 3.30), not by sid_init or sid_start, and it is not a valid link_mask member. It is required in the diagnostics firmware, the image the factory flashes to provision the Endpoint and register it over wire, or in any other image that performs factory registration; the production firmware does not otherwise need to include it. 2.1.1 BLE link . Amazon Sidewalk over BLE is called SID_LINK_TYPE_1. Amazon Sidewalk over BLE uses the Bluetooth Specification v4.2+ standard to transport messages through Amazon Sidewalk enabled Amazon/Ring Gateways. The Amazon Sidewalk stack configures the BLE advertisement payload according to the use case to allow an Amazon Sidewalk BLE Gateway to detect the Endpoint and establish a connection. The beacons are periodically advertised by the Endpoint. The beacon advertisements switch between fast (160ms) and slow (1s) periodicity. After detecting a beacon from the Endpoint the Gateway establishes connection only when the Amazon Sidewalk cloud instructs the Gateway to connect. (Note that the Amazon Sidewalk Cloud provides network management services for Amazon Sidewalk. The operation and control of these services is not visible to the developer.) The Gateway uses the standard BLE connection establishment procedure. If, and only if, one of the following three conditions occurs, a BLE Gateway connects to the Endpoint: . | The Endpoint requests time synchronization by updating the advertisement payload. | The advertisement payload in the beacon is correctly received by the Gateway | The advertisement payload contains information that informs the Gateway that the Endpoint is requesting time synchronization. | . | The Endpoint requests a connection by updating the advertisement payload. | If the Endpoint has data to send to the AWS IoT Core for Amazon Sidewalk, or Amazon Sidewalk cloud services, it updates the request to the Gateway that it has data to send. | The Gateway propagates this request to Amazon Sidewalk cloud services. | The Amazon Sidewalk cloud service requests the Gateway to establish an encrypted connection with the Endpoint. | . | Amazon Sidewalk cloud services or the application on AWS IoT Core for Amazon Sidewalk has data to send to the Endpoint. | The cloud service instructs a Gateway in range of the Endpoint to establish connection with the Endpoint to send downlink data. (An Endpoint is in range of a Gateway if the Gateway can listen to the beacons advertised by the Endpoint and periodically forward to the Amazon Sidewalk Cloud.) | . | . For more details see the Amazon Sidewalk Specification. 2.1.2 FSK Link . Amazon Sidewalk over FSK is called SID_LINK_TYPE_2. Amazon Sidewalk over FSK uses a 2-GFSK modulation scheme in sub-GHz spectrum. If the Gateway is using FSK, it periodically transmits a beacon. The beacon is discovered by FSK capable Endpoints to detect the presence of Amazon Sidewalk sub-GHz capable Gateways. The beacon also allows Endpoints that are using FSK to communicate with the Gateway to synchronize and schedule uplink and downlink messages. For more details see the Amazon Sidewalk Specification. 2.1.3 LoRa Link . Amazon Sidewalk over LoRa is called SID_LINK_TYPE_3. Amazon Sidewalk over LoRa uses CSS in sub-GHz spectrum. Amazon Sidewalk over LoRa is an asynchronous radio protocol and so does not use beacons. The Amazon Sidewalk stack operates the LoRa link at one of two data rates: a default data rate and, where the regulatory region permits it, a higher data rate. See section 2.11.2. For more details see the Amazon Sidewalk Specification. ", "url": "/sid-api-dg/overview-of-functionality.html#21-supported-links", "relUrl": "/sid-api-dg/overview-of-functionality.html#21-supported-links" },"680": { "doc": "2. Overview of Functionality", "title": "2.2 Supported Link modes", "content": "Amazon Sidewalk supports two link modes SID_LINK_MODE_CLOUD, and SID_LINK_MODE_MOBILE. | SID_LINK_MODE_CLOUD is used for SID_LINK_TYPE_1, SID_LINK_TYPE_2, and SID_LINK_TYPE_3. | SID_LINK_MODE_MOBILE is only used for link type SID_LINK_TYPE_1, (BLE). | . If a communication channel is established between an Endpoint and the Amazon Sidewalk cloud/AWS IoT Core for Amazon Sidewalk through a Gateway, the link mode for each link is set to SID_LINK_MODE_CLOUD. If a communication channel is established between an Endpoint and the Sidewalk Mobile SDK, the link mode for the SID_LINK_TYPE_1 link is set to SID_LINK_MODE_MOBILE. A session establishment procedure is used to establish the encrypted link between an Endpoint and the Amazon Sidewalk Mobile SDK. For more details see the Amazon Sidewalk Specification. /** * Describes the link modes supported on each link type. * * Link mode determines the destination of the messages * that sid api user can send on a link. */ enum sid_link_mode { /** Messages can be sent to cloud only, when a link type * notifies support of this mode */ SID_LINK_MODE_CLOUD = 1 << 0, /** Messages can be sent to mobile only, when a link type * notifies support of this mode */ SID_LINK_MODE_MOBILE = 1 << 1, /** Invalid mode */ SID_LINK_MODE_INVALID = INT_MAX, }; . ", "url": "/sid-api-dg/overview-of-functionality.html#22-supported-link-modes", "relUrl": "/sid-api-dg/overview-of-functionality.html#22-supported-link-modes" },"681": { "doc": "2. Overview of Functionality", "title": "2.3 Registration and Deregistration", "content": "An Endpoint that is provisioned with Amazon Sidewalk certificates can use Registration to authenticate itself as an Amazon Sidewalk Endpoint. Registration involves transfer of messages between the Endpoint and the Amazon Sidewalk cloud services. During Registration, messages are transferred through Gateways or through the Amazon Sidewalk Mobile SDK. Registration establishes the authenticity of the Endpoint to the Amazon Sidewalk cloud and also establishes the authenticity of the Amazon Sidewalk cloud to the Endpoint. Successful registration is required before the Endpoint can access services offered by Amazon Sidewalk. The Endpoint requires security credentials to encrypt communications with Amazon Sidewalk Cloud services, and with AWS IoT Core for Amazon Sidewalk. During the registration process the security credentials are stored in the Endpoint’s non-volatile storage. Messages exchanged between the Endpoint and the AWS IoT application are encrypted with two keys: the Application server key and the Network server key. The Application server key is derived during registration with AWS IoT Core for Amazon Sidewalk. The Network server key is derived during registration between the Endpoint and the Amazon Sidewalk cloud service. User payloads are secured using two levels of encryption: . | The Application server key is used with the AES-CTR encryption scheme, to encrypt the User’s payload. | The Network server key is used with the AES-GCM and AES-CTR encryption scheme, as a second layer of encryption on the payload. | . Internal messages between the Amazon Sidewalk stack and cloud services are only encrypted with the Network server key. For more details on security refer to the Amazon Sidewalk white paper. Over the air, Endpoint registration is only supported on SID_LINK_TYPE_2 (FSK) and SID_LINK_TYPE_1 (BLE). Endpoints cannot register with Amazon Sidewalk using SID_LINK_TYPE_3 (LoRa). Please note that only consent-enabled Amazon Sidewalk Gateways can be used to register Endpoints. There is no explicit API call to the Amazon Sidewalk stack to start the process of registration over SID_LINK_TYPE_2 or SID_LINK_TYPE_1. An Endpoint can also be registered at the factory over a wired link, SID_LINK_TYPE_8, through an explicit API, see section 2.3.4. The Amazon Sidewalk stack automatically detects the registration status and triggers the registration procedure with the Amazon Sidewalk cloud services if the following conditions are met: . | The Amazon Sidewalk stack is initialized. | The link is started. | The Endpoint is not already registered. | . The APIs to initialize and start the links are described below. The Amazon Sidewalk stack exposes an API to de-register through the factory reset API, see section 2.3.5. Registration uses one of four procedures described below. 2.3.1 Registration using Amazon Sidewalk Mobile SDK . The Amazon Sidewalk Mobile SDK allows a developer to integrate endpoint registration and de-registration controls into the developer’s own mobile application. (The Amazon Sidewalk Mobile SDK also supports a connection to an Endpoint to directly transmit and receive packets.) . The Endpoint uses SID_LINK_TYPE_1 (BLE) to register, and the Amazon Sidewalk Mobile SDK uses the phone’s BLE to communicate with the Endpoint. During registration the Endpoint communicates with a mobile app that uses the Amazon Sidewalk Mobile SDK. The Amazon Sidewalk Mobile SDK handles the interaction between the Amazon Sidewalk cloud and the edge device, exchanging keys and registering the edge device, so that the edge device can then connect to the Amazon Sidewalk via Amazon Sidewalk gateways. | The Endpoint’s beacons communicate its pre-registered state to the Gateway. | The Amazon Sidewalk Mobile SDK connects to the Endpoint. | The Amazon Sidewalk Mobile SDK triggers the registration sequence. | The registration sequence completes. | . For more details see the Amazon Sidewalk Mobile SDK Developer Guide. 2.3.2 Registration using FFS or FFN over BLE . Registration using FFS/FFN (Frustration Free Setup/Frustration Free Networking) over BLE requires SID_LINK_TYPE_1 (BLE). The Endpoint uses SID_LINK_TYPE_1 to register. During registration the Endpoint communicates with an Amazon Sidewalk enabled BLE Gateway. Registration proceeds as follows: . | The Endpoint’s beacons communicate its pre-registered state to the Gateway. | The Gateway is instructed by Amazon Sidewalk cloud services to connect to the Endpoint. | The Gateway triggers the registration sequence. | The registration sequence completes. | . 2.3.3 Registration using FFS or FFN over FSK . Registration using FFS/FFN over FSK requires SID_LINK_TYPE_2 (FSK) . The Endpoint uses SID_LINK_TYPE_2 to register. During registration the Endpoint communicates an Amazon Sidewalk enabled FSK Gateway. Registration proceeds as follows: . | The Endpoint scans for Amazon Sidewalk FSK beacons. | The Endpoint synchronizes to a beacon from a Gateway that has Amazon Sidewalk consent enabled. | The Endpoint triggers the registration sequence. | The registration sequence completes. | . Please note that in case of FSK, it is the Endpoint that starts the registration sequence while in the case of BLE, the registration is started by the Amazon Sidewalk cloud services through an Amazon Sidewalk BLE Gateway . 2.3.4 Factory registration over a wired link . An Endpoint can be registered at the factory, before it has any radio contact, over a serial connection to a manufacturing host that runs the Amazon Sidewalk manufacturing tool. The exchange runs over SID_LINK_TYPE_8. The Endpoint authenticates the Amazon Sidewalk cloud and the cloud authenticates the Endpoint exactly as in the procedures above, and the security credentials are stored in the Endpoint’s non-volatile storage. For the manufacturing flow see the Amazon Sidewalk Registration over Wire Application Note. The developer’s application does not use sid_init or sid_start for this. It initializes the serial transport, calls sid_serial_registration_init with the transport and a completion callback, calls sid_serial_registration_start when the host requests registration, and calls sid_serial_registration_process from its main loop until the callback reports completion, see sections 3.30 to 3.33. Registration proceeds as follows: . | The host sends the registration request over the serial link. | The Endpoint and the Amazon Sidewalk cloud exchange the registration messages through the host. | The registration sequence completes and the completion callback is called. | . An Endpoint registered this way is factory-registered. On a build with SID_SDK_INTERNAL_CONFIG_IS_FACTORY_REGISTERED (section 2.15) the Amazon Sidewalk stack requests field activation itself once a link is started; sid_get_status reports SID_STATUS_NOT_REGISTERED until the Amazon Sidewalk cloud completes it, and on_status_changed reports SID_STATUS_REGISTERED when it does. On the lite build variants (section 2.15) the credentials are restored from the manufacturing page when the Amazon Sidewalk stack is initialized and the Endpoint reports SID_STATUS_REGISTERED immediately. 2.3.5 De-Registration . The Endpoint can be de-registered from Amazon Sidewalk. The de-registration process involves deletion of security keys and configuration parameters from the Endpoint’s non-volatile storage. De-registration of an Endpoint uses one of three procedures described below. | Endpoint application initiated: the Sid API exposes the factory reset API. Calling this API de-registers the Endpoint from Amazon Sidewalk. The on factory reset callback notifies the developer’s application of the status of de-registration by the Amazon Sidewalk stack. Note that calling this API changes the device’s registered state to ready for registration. If the Amazon Sidewalk stack is not stopped or de-initialized, the Endpoint can start the process of registration immediately through FFS/FFN through an Amazon Sidewalk Gateway or through a mobile app that has Amazon Sidewalk Mobile SDK support. | AWS IoT application service initiated: The AWS IoT application can de-register the device by issuing a factory reset command to the Amazon Sidewalk stack running on the Endpoint. The on factory reset callback notifies the developer’s Endpoint application that the Endpoint is de-registered from Amazon Sidewalk. | Initiated via Sidewalk Mobile SDK: The Amazon Sidewalk Mobile SDK exposes an API for the core application to trigger Amazon Sidewalk Endpoint de-registration. | When the Amazon Sidewalk Mobile SDK triggers a request to de-register the Endpoint, The Amazon Sidewalk cloud sends a Factory Reset command which shall be routed via an Amazon Sidewalk Gateway OR the Amazon Sidewalk Mobile SDK. The routing choice for a factory reset command is based on the range of the Endpoint to the mobile. | When the Endpoint is in range of the Amazon Sidewalk Mobile SDK, the de-registration process is simplified because the Amazon Sidewalk Mobile SDK has already established a direct communication path to the Endpoint to de-register. Using the Amazon Sidewalk Mobile SDK to inject a factory reset command is also useful if the developer’s application triggers the deregistration procedure when the Endpoint is not in range of an Amazon Sidewalk gateway. | . | . On the lite build variants (section 2.15) the factory reset does not delete the factory credentials. The Amazon Sidewalk stack clears its non-volatile storage, restores the factory-provisioned credentials from the manufacturing page, re-applies the live network key and time-sync counter, and returns the Endpoint to the factory-registered state; the Endpoint then field-activates again on its next contact with the Amazon Sidewalk network. The on factory reset callback is called in both cases. /** * Describes the Registration status of the Sidewalk stack. */ enum sid_registration_status { /** Used to indicate Sidewalk stack is registered with * Sidewalk cloud services */ SID_STATUS_REGISTERED = 0, /** Used to indicate Sidewalk stack is not registered * with Sidewalk cloud services */ SID_STATUS_NOT_REGISTERED = 1, }; . ", "url": "/sid-api-dg/overview-of-functionality.html#23-registration-and-deregistration", "relUrl": "/sid-api-dg/overview-of-functionality.html#23-registration-and-deregistration" },"682": { "doc": "2. Overview of Functionality", "title": "2.4 Time Synchronization", "content": "The Amazon Sidewalk stack uses GPS time as a common frame of reference between Endpoints and the Amazon Sidewalk cloud service. The GPS time is used for encryption, and for derivation of the keys used to encrypt messages exchanged between Endpoints and Amazon Sidewalk services. A device has to be in the registered state to request time from the Amazon Sidewalk cloud service. After device registration is complete, or after the device resets in the registered state, the Amazon Sidewalk stack requests GPS time from the Amazon Sidewalk service. The time sync request process is described below: . | Time sync on SID_LINK_TYPE_1 (BLE) . | The Endpoint updates the advertisement payload on the beacon requesting time. | Any BLE Gateway in range of the Endpoint forwards the request to the cloud service. | The cloud service authenticates the Endpoint using its beacon payload. | If authentication succeeds, the cloud service instructs the BLE Gateway through which the beacon was received to connect to the Endpoint and provide the time. | The BLE Gateway connects to the Endpoint. | The Amazon Sidewalk cloud service provides the time through the BLE Gateway. (The Endpoint does not need to send a time sync request message.) | . | Time sync on SID_LINK_TYPE_2 (FSK) . | The Endpoint synchronizes to the beacon. | The Endpoint sends a time sync request message to the Amazon Sidewalk service through the FSK enabled Gateway. | The Amazon Sidewalk cloud authenticates the request. | If authentication succeeds, the cloud service sends a time sync response message to the Endpoint. This message contains the GPS time. | The EP authenticates the time sync response message. | If authentication succeeds, the Endpoint accepts the GPS time from the message. | . | Time sync on SID_LINK_TYPE_3 (LoRa) . | The time sync request message is sent by the Endpoint to the Amazon Sidewalk service through the LoRa enabled Amazon Sidewalk Gateway. The time sync request is sent soon after reset. The Amazon Sidewalk cloud authenticates the request and provides time to the Endpoint in the time sync response message. The Endpoint authenticates the time sync response message before accepting the time from the message. | . | . To compensate for clock drift, the Endpoint periodically requests updated GPS time from the Amazon Sidewalk service. The periodicity is dependent on the device tolerance to clock drift and is the same for all of the device’s links. For more details on time sync request periodicity of the Endpoint see the Amazon Sidewalk Specification. When the Amazon Sidewalk stack is in time synced state, the developer’s application can get the GPS time by querying the stack. The Amazon Sidewalk stack does not provide UTC or local time. /** * Describes the Time synchronization status of the Sidewalk * stack with the cloud services. * Sidewalk security relies on the synchronization of time * between the cloud services and the end device. * * @note Sidewalk stack can have time synchronization with * cloud service only when the device is registered * */ enum sid_time_sync_status { /** Used to indicate Sidewalk stack is registered with * Sidewalk cloud services */ SID_STATUS_TIME_SYNCED = 0, /** Used to indicate Sidewalk stack is not time synchronized * with cloud services */ SID_STATUS_NO_TIME = 1, }; /** * Option to get current time. * * @attention GPS time is the time in milliseconds since 6/1/1980. * GPS time is not adjusted by leap seconds. * UTC time is the number of milliseconds since 1/1/1970. * Local time is the adjusted time taking timezone into consideration. */ enum sid_time_format { /** Option to get current gps time */ SID_GET_GPS_TIME = 0, }; . ", "url": "/sid-api-dg/overview-of-functionality.html#24-time-synchronization", "relUrl": "/sid-api-dg/overview-of-functionality.html#24-time-synchronization" },"683": { "doc": "2. Overview of Functionality", "title": "2.5 Stack States", "content": "The Amazon Sidewalk stack state of an Endpoint can be queried through a Sid API. The Amazon Sidewalk stack state is ready only when the Endpoint is registered, time is synced and at least one of the links is connected. The developer’s application can only send and receive messages when the Amazon Sidewalk stack is in ready state. For the Amazon Sidewalk stack states see table 2.1. A factory-registered Endpoint that has not yet been field-activated (section 2.3.4) reports SID_STATUS_NOT_REGISTERED and SID_STATE_NOT_READY; the Sid API does not distinguish it from an unregistered Endpoint. Table 2.1: Amazon Sidewalk stack states. | State | Type | Value | ————————— | ——- | ———————————————————————————————————————- | Sidewalk registration state | Boolean | Endpoint’s registration status<br>0 = registered<br>1 = not registered | Sidewalk time sync state | Boolean | Endpoint’s time sync status<br>0 = Endpoint has time sync<br>1 = Endpoint does not have time sync | Sidewalk link status | Boolean | Amazon Sidewalk link connection status (per link type)<br>0 = Endpoint is connected<br>1 = Endpoint is not connected | . /** * Describes the state of the Sidewalk stack. */ enum sid_state { /** Used when the Sidewalk stack is ready to * send and receive messages */ SID_STATE_READY = 0, /** Used when the Sidewalk stack is unable to send or receive * messages, such as when the device is not registered * or link gets disconnected or time is not synced */ SID_STATE_NOT_READY = 1, /** Used when the Sidewalk stack encountered an error. * Use sid_get_error() for a diagnostic * error code */ SID_STATE_ERROR = 2, /** Used when the Sidewalk stack is ready to send and receive * messages only with secure channel establishment completed * but device is not registered and time is not synced */ SID_STATE_SECURE_CHANNEL_READY = 3, }; . ", "url": "/sid-api-dg/overview-of-functionality.html#25-stack-states", "relUrl": "/sid-api-dg/overview-of-functionality.html#25-stack-states" },"684": { "doc": "2. Overview of Functionality", "title": "2.6 Stack Status", "content": "The Amazon Sidewalk stack status contains: registration state, time synchronization state, link connection states for each link, and link modes supported for each link. For registration and time synchronization states see section 2.5. The link_status mask holds the connection status of all the links supported by Amazon Sidewalk. The following code defines the link_status mask values. Note that concurrent FSK and LoRa is not supported. // All links are in disconnected state link_status_mask = 0; // Only BLE link is connected link_status_mask = 1; // ((link_status_mask & SID_LINK_TYPE_1) != 0) // Only FSK link is connected link_status_mask = 2; // ((link_status_mask & SID_LINK_TYPE_2) != 0) // Only LoRa link is connected link_status_mask = 4; // ((link_status_mask & SID_LINK_TYPE_3) != 0) // BLE and FSK link is connected link_status_mask = 3; // ((link_status_mask & SID_LINK_TYPE_1) != 0 // and (link_status_mask & SID_LINK_TYPE_2) != 0) // BLE and LoRa link is connected link_status_mask = 5; // ((link_status_mask & SID_LINK_TYPE_1) != 0 // and (link_status_mask & SID_LINK_TYPE_3) != 0) . The supported link modes is an array giving the connection mode for each link. Entries in the supported link modes array are accessed using the link type index. /** * Describes the link connection status with the gateway device * */ struct sid_status_detail { /** * Used to indicate which link is up, if the bit corresponding to a link * is set it is up otherwise it is down. * For example to check if SID_LINK_TYPE_1 is up, * !!(link_status_mask & SID_LINK_TYPE_1) needs to be true * * supported link modes indicate the modes supported by each link. * A link type may support more than one mode simultaneously * * @see #sid_link_type_idx * */ enum sid_registration_status registration_status; enum sid_time_sync_status time_sync_status; uint32_t link_status_mask; uint32_t supported_link_modes[SID_LINK_TYPE_MAX_IDX]; }; . The Amazon Sidewalk stack provides no Sid API call and no callback dedicated to reporting the data rate at which it operates the LoRa link, or whether a Gateway Session Key is in use. Get Device Profile reports the RX window interval in effect, and section 2.9 states which intervals are accepted at each data rate. See section 2.11.1 and section 2.11.2. ", "url": "/sid-api-dg/overview-of-functionality.html#26-stack-status", "relUrl": "/sid-api-dg/overview-of-functionality.html#26-stack-status" },"685": { "doc": "2. Overview of Functionality", "title": "2.7 Link States", "content": "The connection establishment and maintenance of the established connection is different for each of the link types supported by Amazon Sidewalk, and is described below. 2.7.1 BLE Link States . When the Endpoint has messages to send to AWS IoT Core for Amazon Sidewalk, the Endpoint updates its beacon’s advertisement payload to request a connection. If there is an Amazon Sidewalk BLE Gateway in range, the gateway establishes a connection. For details of connection establishment see section 2.1.1 . The Endpoint’s Amazon Sidewalk stack maintains the connection with the Amazon Sidewalk BLE Gateway only when there is uplink or downlink traffic. If the Endpoint does not transmit uplink traffic to the gateway, or receive downlink traffic from the Gateway for a period of 30 seconds, the Endpoint’s stack terminates the connection with the Amazon Sidewalk BLE Gateway and the developer’s application is notified. To re-connect, the developer’s application again requests the Amazon Sidewalk stack to updates its beacon’s advertisement payload to request a connection. The developer’s application can prevent the Amazon Sidewalk stack from terminating the connection by sending at least one uplink message to AWS IoT Core for Amazon Sidewalk every 30 seconds, or if at least one downlink message is received by the Endpoint every 30 seconds the connection is maintained by the Amazon Sidewalk stack. When the Endpoint on a BLE link does not have time synchronization, the Amazon Sidewalk stack updates the beacon’s payload requesting time sync. This is handled automatically by the Amazon Sidewalk stack. When the Endpoint does not have time synchronization, the developer’s application is notified of the time acquisition status and the developer’s application cannot send or receive messages until GPS time is acquired. 2.7.2 FSK Link States . The connection establishment procedure for an Amazon Sidewalk FSK Gateway starts with the Endpoint synchronizing with an FSK Gateway’s beacon that has consent enabled. When the beacon is synchronized, the Amazon Sidewalk stack starts the time acquistion process if the End point does not have GPS time. When the Endpoint has acquired GPS time, the developer is notified of the successful time acquisition status. After the Endpoint successfully acquires time, the Amazon Sidewalk stack starts the join procedure with Amazon Sidewalk cloud. See the Amazon Sidewalk Specification for more details on Join procedure. If the Endpoint has not successfully acquired time or completed the Join procedure, the developer’s application cannot send or receive messages. When the Endpoint has completed the Join procedure successfully, the developer’s application is notified of the successful link connection status and the developer’s application can send and receive messages. When the Endpoint misses 3 consecutive beacons from the already synchronized Amazon Sidewalk FSK gateway, the developer’s applcation is notified of link disconnected status. The Amazon Sidewalk stack starts the gateway discovery procedure to discover Amazon Sidewalk FSK gateways after disconnection. Note that time synchronization process is started by the Amazon Sidewalk stack only when the Endpoint does not have GPS time. The synchronization with a Amazon Sidewalk FSK gateway’s beacon will not always trigger time acquisition process. However, every time the Endpoint transistions from gateway discovering state to a successful gateway discovered state, Join procedure is triggered. The configuration of the device profile settings configuration determines the following: . | The parameters that are sent in the join request. | The downlink schedules of the Endpoint. | . See the Amazon Sidewalk Sub-GHz Device Profiles Application Note for more details. 2.7.3 LoRa Link States . The LoRa link does not establish a connection with an Amazon Sidewalk LoRa Gateway (the link between the Endpoint and the Gateway is asynchronous and connectionless). After the link is initialized and started, the Amazon Sidewalk stack starts the time acquistion process if the End point does not have GPS time. When the Endpoint has acquired GPS time, the developer is notified of the successful time acquisition status. After the Endpoint successfully acquires time, the Amazon Sidewalk stack starts the join procedure with Amazon Sidewalk cloud. See the Amazon Sidewalk Specification for more details on Join procedure. If the Endpoint has not successfully acquired time or completed the Join procedure, the developer’s application cannot send or receive messages. When the Endpoint has completed the Join procedure successfully, the developer’s application is notified of the successful link connection status and the developer’s application can send and receive messages. The configuration of the device profile settings configuration determines the following: . | The parameters that are sent in the join request. | The downlink schedules of the Endpoint. | In some cases, the requirements on the Endpoint to send periodic uplinks. | . See the Amazon Sidewalk Sub-GHz Device Profiles Application Note for more details. An accepted change to the device profile on a started, network synchronized LoRa link takes the link out of network synchronization. SID_LINK_TYPE_3 therefore leaves and later re-enters link_status_mask, and the developer’s application is notified through the on status changed callback. That notification is indistinguishable from any other LoRa outage, so the developer’s application cannot use it to establish the cause. A change of the data rate at which the Amazon Sidewalk stack operates the LoRa link has the same effect. Establishing a key moves the link to the higher data rate, so the Join occurs only where the Amazon Sidewalk stack has to make that change; if the developer’s application already requested that rate, nothing in the Amazon Sidewalk stack status changes. Where the Amazon Sidewalk stack ceases to use a key and the developer’s application has not requested the higher data rate, it returns the link to the default data rate: SID_LINK_TYPE_3 leaves and later re-enters link_status_mask, and in some cases the link restarts and re-enters time acquisition before re-joining. Otherwise the link stays at the higher data rate: the Endpoint does not repeat the Join procedure, nothing in the Amazon Sidewalk stack status changes, and an RX window interval shorter than the default, if one was in effect, remains in effect until the link moves away from the higher data rate. On the FSK link, establishing a Gateway Session Key makes the Endpoint repeat the Join procedure without taking the link out of network synchronization, so a successful repeat changes nothing in the Amazon Sidewalk stack status; a repeat that does not succeed is reported like any other FSK outage. The developer’s application shall not use the on status changed callback to detect a key change on either link. See section 2.11.1 and section 2.11.2. 2.7.4 Route Selection For Downlinks . The last uplink message affects how Amazon Sidewalk processes downlink messages. Cloud services send any pending downlink packets using the link on which the Endpoint last sent an uplink packet. For BLE, if there is no active link, downlink packets for an Endpoint are sent to the BLE Gateway that last received a beacon from that Endpoint. For FSK, downlink packets for an Endpoint are sent to the FSK Gateway that last received an uplink message from that Endpoint. For LoRa, downlink packets for an Endpoint are sent to the LoRa Gateway that last received an uplink message from that Endpoint. How soon the Endpoint can receive a pending LoRa downlink depends on when it next opens an RX window, which the device profile and the configured RX window interval together determine, once the link has completed the Join procedure. For how that interval is configured, see section 2.9. If BLE beacons and uplinks from FSK or LoRa reach the cloud simultaneously, BLE is the preferred link for the downlink transmission. ", "url": "/sid-api-dg/overview-of-functionality.html#27-link-states", "relUrl": "/sid-api-dg/overview-of-functionality.html#27-link-states" },"686": { "doc": "2. Overview of Functionality", "title": "2.8 Amazon Sidewalk Messages", "content": "The Amazon Sidewalk stack provides APIs to send messages to AWS IoT and notifies the developer’s application of messages received from AWS IoT Core for Amazon Sidewalk. Each Amazon Sidewalk message is associated with metadata that uniquely identifies the message. The metadata in a message also notifies the Amazon Sidewalk stack of the attributes that are to be applied to each message. Amazon Sidewalk messages are agnostic to the link on which the messages are being sent. The only varying factor is the MTU of the link. The message types and attributes of messages are the same irrespective of the link the message is being sent on. For the MTU of the links supported by Amazon Sidewalk see table 2.2. Table 2.2: MTU of Amazon Sidewalk links. | Link Type | MTU (Bytes) | —————— | ———– | BLE (link type 1) | 255 | FSK (link type 2) | 200 | LoRa (link type 3) | 19 | . The message consists of msg and msg_desc data structures. The msg data structure has size and a pointer to the payload of the message. The msg_desc data structure has message attributes which are described in detail below: . union sid_msg_desc_attributes { /** Attributes that are applied only when message is * transmitted, see #sid_put_msg */ struct sid_msg_desc_tx_attributes tx_attr; /** Attributes reported per message when the message is * reported to the developer's application, see #on_msg_received */ struct sid_msg_desc_rx_attributes rx_attr; }; struct sid_msg_desc { /** The link type on which this message is to be sent * or was received from */ uint32_t link_type; /** The message type */ enum sid_msg_type type; /** The link mode on which message is sent or received */ enum sid_link_mode link_mode; /** The id associated with a message, generated by the * Sidewalk stack * The maximum value the id can take is 0x3FFF after * which the id resets % to */ uint16_t id; /** Attributes applied to the message */ union sid_msg_desc_attributes msg_desc_attr; }; /** * Describes a message payload. */ struct sid_msg { void *data; size_t size; }; . 2.8.1 Amazon Sidewalk Message Types . Sid API supports four types of messages. The same message types are available to the application on AWS IoT Core for Amazon Sidewalk. When messages are exchanged between the Endpoint and AWS IoT Core for Amazon Sidewalk, the message type is also notified. The four message types are as follows: . | GET to retrieve some data from destination. This message type elicits a mandatory response from the receiver. | SET requests to write some data on destined devices. These requests can be used to update feature configuration or trigger an operation on device. | RESP type messages are sent in response to GET, SET or NOTIFY. RESP messages are an empty acknowledgement, and shall not contain any payload data. The RESP messages are sent in response only when there is an explicit request from the message sender | NOTIFY messages are sent by a device or application. NOTIFY messages do not correspond to any preceding requests. | . When the API to send a message is called, the Amazon Sidewalk stack generates a unique ID. This unique ID is the message ID. The developer’s application is expected to store this message ID to compare with the corresponding message ID returned in a send status event or in an acknowledgement from the AWS IoT Core for Amazon Sidewalk. The stack generates a unique message ID for all message types except RESP. For message type RESP, the stack expects the message ID to be provided by the developer’s application. There is no restriction on the use of a message type in a different manner than what is documented above except for message type RESP. For example the message type GET can be used to trigger an operation on a device or NOTIFY can be used by the developer’s application to get some data from destination. /** * The Sidewalk stack message types. * The messages from cloud services to the End device are designated as * \"Downlink Messages\" * The messages from End device to Cloud services are designated as * \"Uplink Messages\" */ enum sid_msg_type { /** #SID_MSG_TYPE_GET is used by the sender to retrieve information from * the receiver, the sender * expects a mandatory response from the receiver. On reception of * SID_MSG_TYPE_GET, the receiver is expected to send a message with type * #SID_MSG_TYPE_RESPONSE with the same message id it received from the * message type #SID_MSG_TYPE_GET. * This is to ensure the sender can map message type #SID_MSG_TYPE_GET * with the received #SID_MSG_TYPE_RESPONSE. * Both uplink and downlink messages use this message type. * @see sid_put_msg(). * @see on_msg_received in #sid_event_callbacks. */ SID_MSG_TYPE_GET = 0, /** #SID_MSG_TYPE_SET indicates that the sender is expecting the receiver * to take an action on receiving the message and the sender does not * expect a response. * #SID_MSG_TYPE_SET type is used typically by Cloud services to trigger * an action to be preformed by the End device. * Typical users for this message type are downlink messages. */ SID_MSG_TYPE_SET = 1, /** #SID_MSG_TYPE_NOTIFY is used to notify cloud services of any periodic * events or events triggered/originated from the device. Cloud services * do not typically use #SID_MSG_TYPE_NOTIFY as the nature of messages * from cloud services to the devices are explicit commands instead of * notifications. * Typical users for this message type are uplink messages. */ SID_MSG_TYPE_NOTIFY = 2, /** #SID_MSG_TYPE_RESPONSE is sent as a response to the message of type * #SID_MSG_TYPE_GET. * The sender of #SID_MSG_TYPE_RESPONSE is required to the copy the * message id received in the message of type #SID_MSG_TYPE_GET. * Both uplink and downlink messages use this message type. * @see sid_put_msg(). * @see on_msg_received in #sid_event_callbacks. */ SID_MSG_TYPE_RESPONSE = 3, }; . 2.8.2 Amazon Sidewalk Message Sequence Numbers . Every message sent by the Endpoint or received by the Endpoint has a unique sequence number associated with it. When Amazon Sidewalk stack successfully accepts message for transmission, an unique sequence number is assigned to the messsage. The sequence number can be used to track messages exchanged between the Endpoint and AWS IoT core for Amazon Sidewalk. Amazon Sidewalk stack does not guarantee the order of messages sent and received by the Endpoint. 2.8.3 Amazon Sidewalk Message Attributes . When sending a message, the message attributes can be used to modify each message’s behavior. When receiving a message, the Amazon Sidewalk stack uses the received message attributes to notify the developer’s application of the attributes AWS IoT Core for Amazon Sidewalk has configured for the message. 2.8.3.1 Amazon Sidewalk Message Transmit Attributes . The Amazon Sidewalk stack notifies the status of the message sent over the air by configured link and also the status of message received by the AWS IoT Core for Amazon Sidewalk based on the transmit attributes configured on every message. The status of the message whether received by AWS IoT Core for Amazon Sidewalk is reported to the developer’s application only when Transport Ack is requested by the developer’s application. For each message, the Amazon Sidewalk stack performs retries based on the Number of Retries configuration. The developer’s application can configure the following attributes of the message that is to be sent by the Amazon Sidewalk stack: . | Request Acknowledgment from AWS IoT: When this configuration is set to true, the Amazon Sidewalk stack requests AWS Io Core for Amazon Sidewalk to send an Acknowledgment when AWS IoT Core for Amazon Sidewalk receives the message. Note that the acknowledgment is sent by AWS IoT Core for Amazon Sidewalk, and not by the developer’s AWS IoT application. This is configured with Transport Ack set to TRUE. Acknowledgements are sent using messages with message type RESP and zero size payload. | Number of Retries This requires Transport Ack set to TRUE. When set to TRUE, AWS IoT Core for Amazon Sidewalk sends an Acknowledgment back to the Amazon Sidewalk stack. If the Acknowledgment is not received, the Amazon Sidewalk stack retries the message the number of times configured in Number of Retries. If there is no Acknowledgement received after Number of Retries transmissions, then the Amazon Sidewalk stack sends a failure to send status report to the developer’s application. | Time to Live: The time in milliseconds that the Amazon Sidewalk stack holds the message in its queue before reporting to the developer’s application the failure to receive the acknowledgment from AWS IoT. | . Please note that the retry periodicity is derived from Number of Retries and Time to Live configuration. Retry periodicity = Time to Live / Number of Retries . /** Attributes applied to the message descriptor on tx */ struct sid_msg_desc_tx_attributes { /** Whether this message requests an ack from the AWS IOT service */ bool request_ack; /** Number of retries the Sidewalk stack needs to preform in case the * ack is not received. Setting not applicable if request_ack is set * to false */ uint8_t num_retries; /** Total time the Sidewalk stack holds the message in its queue in case * the ack is not received. Setting not applicable if request_ack is set * to false */ uint16_t ttl_in_seconds; } . 2.8.3.2 Amazon Sidewalk Message Receive Attributes . Each message received by the Amazon Sidewalk stack is notified to the developer’s application using the on msg received callback registered by the developer’s application. The following are the received message attributes reported on every Amazon Sidewalk message: . | Acknowledgement: The received message is an acknowledgement from the AWS IoT Core for Amazon Sidewalk that it has received the message sent by the Endpoint. | Duplicate: The received message is a duplicate. The Amazon Sidewalk stack keeps track of the last 10 messages received from AWS IoT Core for Amazon Sidewalk and either reports or filters duplicates. The choice to report or filter can be configured, see section 2.9. A duplicate is a message that has the same message ID and payload size as a message that has already been reported to the developer’s application. | Acknowledgement Request: The AWS IoT application can request acknowledgment from the device when sending messages to the device. The Amazon Sidewalk stack reports the status that AWS IoT Core for Amazon Sidewalk requested in an acknowledgement for a message. The Amazon Sidewalk stack responds to AWS IoT Core for Amazon Sidewalk immediately with an Acknowledgment and then reports the message to the developer’s application with the acknowledgment request set to TRUE. When the developer’s application receives the message with acknowledgment set to TRUE, the Amazon Sidewalk stack had already queued the Acknowledgment to AWS IoT Core for Amazon Sidewalk. | rssi: the received signal strength at which the message is received by the link’s radio. | snr: the signal to noise ratio reported by the radio on this message. | . /** Attributes with which the message is received */ struct sid_msg_desc_rx_attributes { /** Whether the message received is an acknowledgement. Acknowledgements * have the same message id as that of message sent but with zero payload * size. See #sid_msg_desc_tx_attributes */ bool is_msg_ack; /** Whether the message received is a duplicate. If a message arrives at * the Sidewalk stack with message id and payload size equal to an * already reported message, this message is marked as a duplicate * See #SID_OPTION_SET_MSG_POLICY_FILTER_DUPLICATES */ bool is_msg_duplicate; /** Whether the message received has requested an acknowledgement to be * sent, Acknowledgements have the same message id as that of the * received message. The Sidewalk stack immediately queues an * acknowledgement to the sender before propagating this message to the * developer's application */ bool ack_requested; /** rssi of the received message */ int16_t rssi; /** snr of the received message */ int16_t snr; } . see section 2.3.5. ", "url": "/sid-api-dg/overview-of-functionality.html#28-amazon-sidewalk-messages", "relUrl": "/sid-api-dg/overview-of-functionality.html#28-amazon-sidewalk-messages" },"687": { "doc": "2. Overview of Functionality", "title": "2.9 Stack IOCTLs", "content": "The Sid API allows the developer’s application to modify certain aspects of the Amazon Sidewalk stack’s behavior through IOCTLs. The following IOCTLs are available for the developer’s application to configure: . | Set Device Profile: This IOCTL is valid only for FSK and LoRa and does not apply for BLE. The default profile setting for FSK is Profile 1 and for LoRa it is Profile B. For FSK (Link Type 2), additional parameters can be configured: . | beacon_interval_unit: Specifies the beacon interval unit for FSK communication. Valid values are SID_LINK2_BEACON_INTERVAL_UNIT_1, SID_LINK2_BEACON_INTERVAL_UNIT_2, and SID_LINK2_BEACON_INTERVAL_UNIT_3. | l2_rx_duration_sec: Defines the Layer 2 receive duration in seconds for FSK links. Valid range is 0 to 65535 seconds. | . | . For LoRa (Link Type 3), the following profiles are supported: . | SID_LINK3_PROFILE_A (0x80): Asynchronous profile with configurable RX windows. The rx_window_count can be set from 0 to SID_RX_WINDOW_CNT_PROFILE_A_MAX (60). No periodic network sync. | SID_LINK3_PROFILE_B (0x81): Default LoRa profile with infinite RX windows. The rx_window_count shall be SID_RX_WINDOW_CNT_INFINITE; any other value is rejected. Supports periodic network sync with configurable interval (1-240 mins, default 5 mins). | SID_LINK3_PROFILE_C (0x82): Continuous RX mode profile. The device stays in continuous receive mode with no RX window interval: the Amazon Sidewalk stack replaces rx_window_count with SID_RX_WINDOW_CONTINUOUS (0xFF) and unicast_window_interval.async_rx_interval_ms with SID_LINK3_RX_WINDOW_SEPARATION_CONTINUOUS (0), rather than validating the values supplied for them. This profile provides lowest latency for downlink messages but highest power consumption. The Amazon Sidewalk stack arms the keep-alive for this profile as it does for SID_LINK3_PROFILE_B, with a default keep-alive interval of 24 hours for this profile; see section 2.9.8 and section 2.9.10. | SID_LINK3_PROFILE_D (0x83): Reserved. Set Device Profile does not accept this profile ID. | . For the LoRa device profile parameters that can be configured, their accepted values, the preconditions of each operation and the error conditions, see section 2.9.11. For more details on FSK and LoRa device profiles, see Amazon Sidewalk Sub-GHz Device Profiles Application Note. | Get Device Profile: Get the device’s current operating profile. The developer’s application shall set unicast_params.device_profile_id to a profile ID of the link being queried before the call; see section 2.9.11. See Amazon Sidewalk Sub-GHz Device Profiles Application Note. | Set filter duplicates: The Amazon Sidewalk stack can filter or report duplicate messages. This setting allows the developer’s application to modify the stack behavior to filter or to report the duplicate messages. When set to 1, the Amazon Sidewalk stack filters the duplicates and does not report duplicate messages to the developer’s application. The default setting is 0, to filter duplicates. When set to 1, the Amazon Sidewalk stack reports the duplicates using the on msg received callback with the is_msg_duplicate set to 1 in the metadata of the message. | Get filter duplicates: Get the current setting of filter duplicates. | Set link connection policy: Set the link connection policy. See section 2.9.1. | Get link connection policy: Get the current setting of link connection policy. See section 2.9.1. | Set auto link connection policy parameters: Set auto link connection policy parameters. See section 2.9.1.2. | Get auto link connection policy parameters: Get the current setting of auto link connection policy parameters. See section 2.9.1.2. | Set multi-link connection policy: Set multi-link connection policy. See section 2.9.1.3. | Get multi-link connection policy: Get the current setting of multi-link connection policy. See section 2.9.1.3. | Get statistics: Get statistics report from Amazon Sidewalk stack. See section 2.9.2. | Clear statistics: Clear statistics collected by Amazon Sidewalk stack. See section 2.9.2. | Get Sidewalk ID: Get the Sidewalk ID for the device. Since Sidewalk ID is given to the device post regsitration. This option will only work post regsitration. See section 2.9.7. | Get/Set delayed ack time: Get/Set the time of delayed ack. See section 2.9.3. | Get/Set gateway discovery and selection policy: Option to get/set the gateway discovery and selection policy. This IOCTL is valid only for FSK. See section 2.9.4. | BLE user configuration: Get/set the current BLE configuration. See section 2.9.5. | Get/Set downlink route validity and keep-alive interval: Option to get/set the current downlink route validity time and, together with it, the keep-alive / network-sync interval for Sub-GHz links. See section 2.9.8. | Sub-GHz user control: Option to send user control commands to Sub-GHz links (FSK/LoRa). See section 2.9.9. | LoRa transmit power control configuration: Option to set transmit power control configuration for LoRa (Link Type 3). | . The currently available IOCTL options are listed below. /** * The set of options to be used with sid_option API. */ enum sid_option { /** Reserved option for future use */ SID_OPTION_RESERVED = 0, /** Option to configure the device profile. * Value is of type struct sid_device_profile */ SID_OPTION_900MHZ_SET_DEVICE_PROFILE = 1, /** Option to get the device profile configuration. * Value is of type struct sid_device_profile */ SID_OPTION_900MHZ_GET_DEVICE_PROFILE = 2, /** Option to set the message policy to filter duplicates, * value is 0 or 1, when set to 0, the default setting, * duplicates are filtered and are not propagated using * #on_msg_received, when set to 1, duplicates are detected * and are propagated using #on_msg_receive, * see #sid_msg_desc_rx_attributes */ SID_OPTION_SET_MSG_POLICY_FILTER_DUPLICATES = 3, /** Option to get the configured policy of filtering duplicates, * 0 - Filter duplicates, 1 - Allow duplicates */ SID_OPTION_GET_MSG_POLICY_FILTER_DUPLICATES = 4, /** Option to set the link connection policy setting */ SID_OPTION_SET_LINK_CONNECTION_POLICY = 5, /** Option to get the current link connection policy setting */ SID_OPTION_GET_LINK_CONNECTION_POLICY = 6, /** Option to allow the stack to attempt connection of the link * when the message is sent using sid_put_msg. This option is valid * only when the message is sent not using #SID_MSG_LINK_TYPE_ANY * #SID_MSG_LINK_TYPE_ANY enables multi-link policy and connection policy * is determined by the configured multi-link policy. see * #sid_link_auto_connect_params */ SID_OPTION_SET_LINK_POLICY_AUTO_CONNECT_PARAMS = 7, /** Option to get the configured auto connect params for a * particular link type. see #sid_link_auto_connect_params. * The link_type needs to filled when getting the auto connect params */ SID_OPTION_GET_LINK_POLICY_AUTO_CONNECT_PARAMS = 8, /** Option to configure mlm link policy settings for the device */ SID_OPTION_SET_LINK_POLICY_MULTI_LINK_POLICY = 9, /** Option to configure mlm link policy settings for the device */ SID_OPTION_GET_LINK_POLICY_MULTI_LINK_POLICY = 10, /** Get msg statistics for the device */ SID_OPTION_GET_STATISTICS = 11, /** Clear msg statistics for the device */ SID_OPTION_CLEAR_STATISTICS = 12, /** Get the Sidewalk ID for the device. Since Sidewalk ID is given to the * device post regsitration. This option will only work post regsitration */ SID_OPTION_GET_SIDEWALK_ID = 13, /** Option to get/set the time of delayed ack */ SID_OPTION_DELAYED_ACK_CONFIG = 14, /** Option to get/set the gateway discovery policy for FSK. * Value is of type struct sid_link_type_2_gw_discovery_policy_config */ SID_OPTION_LINK_TYPE_2_GW_DISCOVERY_POLICY = 15, /** Option to get/set ble config */ SID_OPTION_BLE_USER_CONFIG = 16, /** Option to get/set BLE use for D2D only */ SID_OPTION_USE_BLE_FOR_D2D_ONLY = 17, /** Option to get/set ble connection policy */ SID_OPTION_BLE_CONNECTION_POLICY = 18, /** Option to get/set DL route validity settings for the device */ SID_OPTION_DL_ROUTE_VALIDITY = 19, /** Option to set user control for sub-ghz */ SID_OPTION_SUB_GHZ_USER_CONTROL = 20, /** Option to set transmit power control config for LoRa */ SID_OPTION_LINK_TYPE_3_TRANSMIT_POWER_CONTROL_CONFIG = 21, /** Delimiter to enum sid_option */ SID_OPTION_LAST, }; . The device profile IDs for FSK (Link Type 2) and LoRa (Link Type 3) are defined as follows: . /** * Describes the profile type of the device */ enum sid_device_profile_id { /** Device Profile ID for Synchronous Network (FSK) */ SID_LINK2_PROFILE_1 = 0x01, SID_LINK2_PROFILE_2 = 0x02, SID_LINK2_PROFILE_LAST, /** Device Profile ID for Asynchronous Network (LoRa) */ SID_LINK3_PROFILE_A = 0x80, // Configurable RX windows, no periodic sync SID_LINK3_PROFILE_B = 0x81, // Default, infinite RX windows, periodic sync SID_LINK3_PROFILE_C = 0x82, // Continuous RX mode, no periodic sync SID_LINK3_PROFILE_D = 0x83, // Reserved SID_LINK3_PROFILE_LAST, }; . 2.9.1 Amazon Sidewalk stack Connection Policy . The connection policy adopted by the Amazon Sidewalk stack to establish and maintain connection with Amazon Sidewalk Gateways can be configured by the developer. /** * Describes the connection policy setting */ enum sid_link_connection_policy { /** Default setting. Sidewalk stack does not apply any * connection policy. */ SID_LINK_CONNECTION_POLICY_NONE = 0, /** Auto connection policy, Sidewalk stack applies auto connection policy * based on the parameters * configured through auto connection policy parameters. */ SID_LINK_CONNECTION_POLICY_AUTO_CONNECT, /** Multi-link connection policy, Sidewalk stack applies multi-link * connection policy based on the policy * configured through multi-link connection policy. */ SID_LINK_CONNECTION_POLICY_MULTI_LINK_MANAGER, /** Delimiter to enum sid_link_connection_policy */ SID_LINK_CONNECTION_POLICY_LAST }; // IOCTL to set link connection policy // Set link connection policy to SID_LINK_CONNECTION_POLICY_AUTO_CONNECT enum sid_link_connection_policy set_policy = SID_LINK_CONNECTION_POLICY_AUTO_CONNECT; sid_error_t ret = sid_option(handle, SID_OPTION_SET_LINK_CONNECTION_POLICY, &set_policy, sizeof(set_policy)); // IOCTL to get link connection policy // Get configured link connection policy enum sid_link_connection_policy get_policy; sid_error_t ret = sid_option(handle, SID_OPTION_GET_LINK_CONNECTION_POLICY, &get_policy, sizeof(get_policy)); . 2.9.1.1 SID_LINK_CONNECTION_POLICY_NONE . The Amazon Sidewalk stack does not play a role in the connection establishment and its maintenance with the Amazon Sidewalk Network. The developer is expected to handle the connection establishment and its maintenance in this configuration. The default connection policy the Amazon Sidewalk stack is configured with is SID_LINK_CONNECTION_POLICY_NONE . 2.9.1.2 SID_LINK_CONNECTION_POLICY_AUTO_CONNECT . The developer provides the parameters of the connection establishment and maintenance under this configuration of connection policy. For details on auto connection policy and its parameters, Please see Amazon Sidewalk Multi-link Application Note . /** * Describes link auto connect parameters */ struct sid_link_auto_connect_params { /** Sid link type */ enum sid_link_type link_type; /** Auto connect policy if set enable is equal to 0 */ bool enable; /** Priority of the link type when more than one link is specified * using #sid_put_msg * 0 is highest priority, 2 is lowest priority */ uint8_t priority; /** Maximum period upto which the stack attempts to form a connection */ uint16_t connection_attempt_timeout_seconds; }; // IOCTL to set auto connect parameters // Set auto connection params for SID_LINK_TYPE_1 with priority 1 and // connection_attempt_timeout_seconds to 30 struct sid_link_auto_connect_params params_link_1 = { .link_type = SID_LINK_TYPE_1, .enable = true, .priority = 0, .connection_attempt_timeout_seconds = 30 }; sid_error_t ret = sid_option(handle, SID_OPTION_SET_LINK_POLICY_AUTO_CONNECT_PARAMS, &params_link_1, sizeof(params_link_1)); // IOCTL to get auto connect parameters // Get auto connection parameters configured for SID_LINK_TYPE_1 struct sid_link_auto_connect_params get_params_link_1 = { .link_type = SID_LINK_TYPE_1, }; ret = sid_option(handle, SID_OPTION_GET_LINK_POLICY_AUTO_CONNECT_PARAMS, &get_params_link_1, sizeof(get_params_link_1)); . 2.9.1.3 SID_LINK_CONNECTION_POLICY_MULTI_LINK_MANAGER . The multi-link connection policy determines the message uplink attributes and link connection attributes and does not expect the developer to configure these parameters while sending the message. For details on multi-link connection policy, Please see Amazon Sidewalk Multi-link Application Note. /** multi-link policy modes */ enum sid_link_multi_link_policy { /** Default policy, Default Setting, All links are enabled */ SID_LINK_MULTI_LINK_POLICY_DEFAULT = 0, /** Policy optimized for better power consumption */ SID_LINK_MULTI_LINK_POLICY_POWER_SAVE = 1, /** Policy optimized for performance, better throughput */ SID_LINK_MULTI_LINK_POLICY_PERFORMANCE = 2, /** Policy optimized for latency, faster uplinks */ SID_LINK_MULTI_LINK_POLICY_LATENCY = 3, /** Policy optimized for reliability, messages have a longer Time to live * and more retries */ SID_LINK_MULTI_LINK_POLICY_RELIABILITY = 4, /** Delimiter to enum sid_link_power_policy_type */ SID_LINK_MULTI_LINK_POLICY_LAST }; // IOCTL to set multi-link policy // Set multi-link policy to SID_LINK_MULTI_LINK_POLICY_PERFORMANCE enum sid_link_multi_link_policy policy = SID_LINK_MULTI_LINK_POLICY_PERFORMANCE; sid_error_t ret = sid_option(handle, SID_OPTION_SET_LINK_POLICY_MULTI_LINK_POLICY, &policy, sizeof(policy)); // IOCTL to get multi-link policy // Get current configured multi-link policy enum sid_link_multi_link_policy get_policy; sid_error_t ret = sid_option(handle, SID_OPTION_GET_LINK_POLICY_MULTI_LINK_POLICY, &get_policy, sizeof(get_policy)); . 2.9.2 Amazon Sidewalk stack statistics . The Amazon Sidewalk stack records the statistics from the time the user initializes and starts the Amazon Sidewalk stack to the time the Amazon Sidewalk stack is stopped and deinitialized. The Amazon Sidewalk stack does not store the statistics in non-volatile memory. The following are the statistics that are collected by the Amazon Sidewalk stack. | Number of Messages sent: The number of messages sent successfully by the Amazon Sidewalk stack when the developer’s application calls sid_put_msg API to send a message. See 3.8. | Number of Acknowledgements sent: The number of Acknowledgements sent by the Amazon Sidewalk stack when AWS IoT core for Amazon Sidewalk requests Acknowledgement to be sent for a downlink. | Number of Messages failed to send: The number of messages failed to be sent by the Amazon Sidewalk stack when the developer’s application calls sid_put_msg API to send a message. See 3.8. | Number of Retries: The number of retransmissions attempted by Amazon Sidewalk stack whent the developer’s application calls sid_put_msg API to send a message with retries. See 3.8. | Number of Duplicates: The number of duplicates received by Amazon Sidewalk stack from AWS IoT core for Amazon Sidewalk. Irrespective of the configuration setting of the filter duplicates, the duplicates statistic is incremented whenever the Amazon Sidewalk stack receives a duplicate. | Number of Messages received: The number of messages received by the Amazon Sidewalk stack from AWS IoT core for Amazon Sidewalk and notified to the developer using the on_msg_received callback. See section 2.10. | Number of Acknowledgements received: The number of acknowledgements received by the Amazon Sidewalk stack from AWS IoT core for Amazon Sidewalk and notified to the developer using the on_msg_received callback. See section 2.10. | . /** The cumulative statistics of all links configured on the device */ struct sid_msg_statistics { /** number of messages sent successfully. */ uint32_t tx; /** number of acknowledments sent to AWS-IOT core. */ uint32_t acks_sent; /** number of messages failed transmissions. */ uint32_t tx_fail; /** number of message retries. */ uint32_t retries; /** number of duplicates received. */ uint32_t duplicates; /** number of messages received. */ uint32_t rx; /** number of acknowledments received from AWS-IOT core. */ uint32_t acks_recv; }; /** The metrics collected by the Sidewalk stack */ struct sid_statistics { struct sid_msg_statistics msg_stats; }; // Get statistics struct sid_statistics stats = {0}; sid_error_t ret = sid_option(handle, SID_OPTION_GET_STATISTICS, &stats, sizeof(stats)); // Clear statistics ret = sid_option(handle, SID_OPTION_CLEAR_STATISTICS, NULL, 0); . 2.9.3 Amazon Sidewalk stack Delayed Ack . The Amazon Sidewalk stack allows the developer to enable delayed ack and configure the delay. The default setting when the developer does not enable delayed ack is immediate ack. /** * Structure used to configure the delayed ack */ struct sid_delayed_ack_config { /** time for the delayed ack in milliseconds. Range: 0-20000 msecs */ uint32_t delayed_ack; /** indicates whether to get or set the delayed ack time. * false: Get, true: Set */ bool is_set; }; // IOCTL to set the time for delayed ack // Set delayed ack parameters with time 10000 msecs and is_set = true struct sid_delayed_ack_config delayed_ack_config = { .delayed_ack = 10000, .is_set = true }; sid_error_t ret = sid_option(*cli_cfg.app_cxt->sidewalk_handle, SID_OPTION_DELAYED_ACK_CONFIG, &delayed_ack_config, sizeof(delayed_ack_config)); // IOCTL to get the time for delayed ack struct sid_delayed_ack_config delayed_ack_config = {0}; sid_error_t ret = sid_option(*cli_cfg.app_cxt->sidewalk_handle, SID_OPTION_DELAYED_ACK_CONFIG, &delayed_ack_config, sizeof(delayed_ack_config)); . 2.9.4 Amazon Sidewalk Gateway Discovery and Selection Policy . The Gateway Discovery and Selection policy defines a gateway selection strategy during the FSK discovery process. There are several predefined policies optimized for different applications, as well as a user custom policy that allows the user to configure most of the parameters. For details on Discovery and selection policies, Please see Amazon Sidewalk Gateway Discovery and Selection Application Note. /** * 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, }; /** 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. * A value of 255 means infinite number of retries */ 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; }; /** * Describes the LINK2 GW Discovery events. * These events are notified to the developer through network control events */ enum sid_link_type_2_gw_discovery_event { /** Event indicating gateway under the selected discovered policy is not found */ SID_LINK_TYPE_2_GW_DISCOVERY_EVENT_DISC_FAILED = 0, /** Event indicating the gateway is selected and beacon sync is done */ SID_LINK_TYPE_2_GW_DISCOVERY_EVENT_BEACON_SYNC = 1, /** Event indicating the beacon sync was lost with the selected gateway */ SID_LINK_TYPE_2_GW_DISCOVERY_EVENT_BEACON_SYNC_LOST = 2, }; // 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)); . 2.9.5 Amazon Sidewalk BLE User Configuration . The BLE configuration for establishing and maintaining connections with Amazon Sidewalk Gateways is highly flexible and can be customized by developers to suit a variety of use cases. The following parameter constraints apply: . Advertising Parameters: . | fast_interval: In units of 0.625 ms, range: [32, 8192] (20ms to 5.12s) | fast_timeout: In units of 10 ms, range: [0, 65535], 0 means indefinite | slow_interval: In units of 0.625 ms, range: [1600, 8192] (1s to 5.12s) | slow_timeout: In units of 10 ms, range: [0, 65535], 0 means indefinite | . Connection Parameters: . | min_conn_interval: In units of 1.25 ms, range: [12, 3200] (15ms to 4s) | max_conn_interval: In units of 1.25 ms, range: [12, 3200] (15ms to 4s), must be >= min_conn_interval | slave_latency: Range: [0, 499] | conn_sup_timeout: In units of 10 ms, range: [10, 3200] (100ms to 32s), must satisfy: conn_sup_timeout * 10 > 2 * max_conn_interval * 1.25 * (slave_latency + 1) | . Inactivity Timeout: . | inactivity_timeout: In seconds, range: [1, 3600] (1 second to 1 hour) | . /** * Describes the BLE configuration type */ enum sid_ble_user_config_type { /** BLE advertising configuration */ SID_BLE_USER_CFG_ADV, /** BLE connection parameter configuration */ SID_BLE_USER_CFG_CONN, /** BLE advertising and connection parameter configuration */ SID_BLE_USER_CFG_ADV_AND_CONN, /** BLE inactivity timeout configuration */ SID_BLE_USER_CFG_INACTIVITY_TIMEOUT, }; /** * BLE configuration struct */ typedef struct sid_ble_user_config { /** BLE advertising configuration */ sid_ble_cfg_adv_param_t adv_param; /** BLE connection parameter configuration */ sid_ble_cfg_conn_param_t conn_param; /** BLE configuration command, set config = true, get config = false */ bool is_set; /** BLE configuration type */ enum sid_ble_user_config_type cfg_type; /** BLE inactivity timeout in seconds, range: [1, 3600] */ uint32_t inactivity_timeout; } sid_ble_user_config_t; // IOCTL to get the current BLE configuration sid_ble_user_config_t get_config = { .is_set = false, .cfg_type = SID_BLE_USER_CFG_ADV_AND_CONN }; sid_error_t ret = sid_option(handle, SID_OPTION_BLE_USER_CONFIG, &get_config, sizeof(get_config)); // IOCTL to set the BLE configuration // Example of BLE configuration sid_ble_user_config_t set_config = { .is_set = true, .cfg_type = SID_BLE_USER_CFG_ADV_AND_CONN, .adv_param = { .type = AMA_SERVICE, .fast_enabled = true, .slow_enabled = true, /** In units of 0.625 ms, range: [32, 8192] */ .fast_interval = 160, /** In units of 10 ms, range: [0, 65535], 0 means indefinite */ .fast_timeout = 1000, /** In units of 0.625 ms, range: [1600, 8192] */ .slow_interval = 1600, /** In units of 10 ms, range: [0, 65535], 0 means indefinite */ .slow_timeout = 0, }, .conn_param = { /** In units of 1.25 ms, range: [12, 3200] */ .min_conn_interval = 16, /** In units of 1.25 ms, range: [12, 3200] */ .max_conn_interval = 80, /** Range: [0, 499] */ .slave_latency = 0, /** In units of 10 ms, range: [10, 3200] */ .conn_sup_timeout = 400, }, .inactivity_timeout = 30, // 30 seconds }; sid_error_t ret = sid_option(handle, SID_OPTION_BLE_USER_CONFIG, &set_config, sizeof(set_config)); . 2.9.5.1 Platform Notes: Nordic NCS . Nordic Semiconductor has not yet support for runtime BLE configuration in their nRF Connect SDK (NCS) platform. As a result, the following limitations apply when using SID_OPTION_BLE_USER_CONFIG on Nordic NCS-based devices: . | Runtime advertisement parameter updates are not supported. The NCS BLE stack does not support modifying advertisement parameters at runtime. Advertisement parameters must be configured at compile time through Kconfig or devicetree overlays. | Runtime connection parameter updates are not supported. The NCS BLE stack does not support modifying connection parameters at runtime. Connection parameters must be configured at compile time. | Inactivity timeout configuration remains functional. The SID_BLE_USER_CFG_INACTIVITY_TIMEOUT configuration type is handled at the Sidewalk stack level and is not affected by this platform limitation. | Backward compatibility with legacy Nordic devices. Devices using the older nRF5 SDK (e.g., nRF52832, nRF52840 with the native SoftDevice-based BLE stack) continue to support full runtime BLE configuration through SID_OPTION_BLE_USER_CONFIG. Applications targeting both NCS and legacy nRF5 SDK platforms should account for this difference in behavior. | . Developers migrating from the nRF5 SDK to NCS should review their BLE configuration strategy and move runtime parameter adjustments to compile-time configuration where applicable. 2.9.6 BLE Device-to-Device (D2D) Only Mode . The Amazon Sidewalk stack allows the developer to configure BLE to operate in device-to-device (D2D) only mode. When enabled, BLE will only be used for direct device-to-device communication rather than cloud connectivity through gateways. /** * Structure to configure BLE D2D only mode */ typedef struct sid_ble_d2d_config { /** True: Set configuration, False: Get configuration */ bool is_set; /** True: Use BLE for D2D only, False: Normal operation */ bool set_d2d_only; } sid_ble_d2d_config_t; // Get current D2D configuration sid_ble_d2d_config_t get_d2d_config = { .is_set = false }; sid_error_t ret = sid_option(handle, SID_OPTION_USE_BLE_FOR_D2D_ONLY, &get_d2d_config, sizeof(get_d2d_config)); // Set BLE to D2D only mode sid_ble_d2d_config_t set_d2d_config = { .is_set = true, .set_d2d_only = true // Enable D2D only mode }; ret = sid_option(handle, SID_OPTION_USE_BLE_FOR_D2D_ONLY, &set_d2d_config, sizeof(set_d2d_config)); . 2.9.7 Amazon Sidewalk ID . The Sidewalk ID returned by this option is the Endpoint’s Sidewalk ID. It does not change with the key the Endpoint uses on a sub-GHz link. /** * Structure to hold Sidewalk ID */ struct sid_id { #define MAX_SIDEWALK_ID_LEN 7 /** Array that holds the Sidewalk ID */ uint8_t id[MAX_SIDEWALK_ID_LEN]; /* Len of the Sidewalk ID */ size_t len; }; // Get Sidewalk ID struct sid_id id; sid_error_t ret = sid_option(handle, SID_OPTION_GET_SIDEWALK_ID, &id, sizeof(id)); . 2.9.8 Amazon Sidewalk Downlink Route Validity and Keep-Alive Interval . The Amazon Sidewalk stack allows the developer to configure the downlink route validity (DLRV) time for Sub-GHz links on the Amazon Sidewalk cloud, and, in the same structure, the keep-alive / network-sync interval (nwsync_time). The default DLRV setting is 15 minutes for LoRa and 1080 minutes for FSK when the developer does not configure it. The nwsync_time interval, when left at 0, is derived from the DLRV and the active link profile: on FSK it is the DLRV minus 5 minutes, on LoRa Profile B it is the network-sync interval (default 5 minutes), and on LoRa Profile C it is 24 hours. When set explicitly, its valid range depends on the enabled sub-GHz links (see the list below): LoRa Profile B accepts 1–240 minutes, while FSK and LoRa Profile C accept up to MAX_FSK_KA_INTERVAL_MINS (1440 minutes), which is why nwsync_time is a uint16_t — that range exceeds 255. SID_OPTION_DL_ROUTE_VALIDITY validates only the upper bound of nwsync_time (SID_ERROR_INVALID_ARGS if it exceeds the per-link maximum below), not a lower bound. An explicitly set value below 2 minutes (e.g. 1) is therefore accepted, stored and reported back as-is by a get, but the keep-alive never runs more often than once every 2 minutes: the stack applies a 2-minute floor to the interval it uses, whether that interval was set explicitly or derived. When LoRa is in sid_config.link_mask, sid_init() takes the initial interval from sid_sub_ghz_links_config.link3_b_nwsync_time if it is within 1–240 minutes, and otherwise uses the 5-minute default (DEF_LINK3_PROFILE_B_NW_SYNC_TIME_MINS). On LoRa Profile B the interval is therefore unset only if the application explicitly sets nwsync_time back to 0 (SID_NWSYNC_TIME_NOT_SET) through SID_OPTION_DL_ROUTE_VALIDITY; a subsequent get then reports 2 minutes until the application sets a non-zero value again. FSK and LoRa Profile C do not use link3_b_nwsync_time: they use their derived default (DLRV minus 5 minutes, and 24 hours) until the application sets nwsync_time through SID_OPTION_DL_ROUTE_VALIDITY. The accepted upper bound for nwsync_time depends on which sub-GHz links are enabled in sid_config.link_mask, because the two links share this single interval value (FSK and LoRa never transmit the keep-alive concurrently — they time-division the sub-GHz radio): . | FSK only: up to MAX_FSK_KA_INTERVAL_MINS (1440 minutes). | LoRa only, Profile C: up to 1440 minutes (24 hours, matching Profile C’s default). | LoRa only, any other profile (in practice, Profile B): up to MAX_LINK3_PROFILE_B_NW_SYNC_TIME_MINS (240 minutes). | Both FSK and LoRa enabled (link_mask contains both SID_LINK_TYPE_2 and SID_LINK_TYPE_3): the stricter 240-minute bound applies, so the single shared value stays valid for the LoRa Profile B time-slices too. | . In the single-link build variants (section 2.15) only one sub-GHz link exists, so only that link’s bound applies and the mixed-mode row does not. The keep-alive on a Sub-GHz link is armed automatically once the link is synchronized — on FSK, and on LoRa in Profile B or Profile C (LoRa Profile A has no keep-alive); there is no separate call to turn it on. The stack skips a keep-alive when an uplink that requested an acknowledgement was reported sent through on_msg_sent less than one interval earlier, and sends the next keep-alive one interval after that uplink; a skipped keep-alive produces no SID_CONTROL_EVENT_KA_ACK_STATUS event. Each keep-alive requests an acknowledgement, and the stack tracks consecutive misses. The acknowledgement result of each keep-alive is reported to the developer’s application through the on_control_event_notify callback with the SID_CONTROL_EVENT_KA_ACK_STATUS event (section 2.10). A change to the DLRV, whether negotiated by the Amazon Sidewalk cloud during join or set locally by the application, is reported through the same callback with the SID_CONTROL_EVENT_DL_ROUTE_VALIDITY_CONFIG_UPDATE event, whose event_data points to a uint16_t holding the updated DLRV time in minutes. The miss threshold is 3 consecutive missed keep-alives. Each keep-alive is sent with one retry and a 60-second time-to-live. On each unacknowledged keep-alive the stack reports ack_received=false, then increments the miss counter. Below the threshold, the stack does not wait a full interval before retrying: it cancels the pre-armed full-interval timer and reschedules the next attempt at a shorter capped retry interval, so all attempts complete before the downlink route expires. On reaching the threshold, the stack tears the link down — clearing the link from link_status_mask, stopping the KA timer, resetting the miss counter, forcing a rejoin, and firing on_status_changed (link down). This is the same notification the application would see for any other outage, so it cannot be used on its own to attribute the cause to KA. The keep-alive can never be acknowledged when the link profile is uplink-only, because no receive window is opened after an uplink; see the Amazon Sidewalk Sub-GHz Device Profiles Application Note. sid_option() (section 3.11) with SID_OPTION_DL_ROUTE_VALIDITY and a struct sid_dlrv_config (below) configures the DLRV and nwsync_time. The keep-alive payload is part of the static sub-GHz configuration (sid_sub_ghz_links_config.ka_payload, section 2.9.10), and the keep-alive acknowledgement is reported through SID_CONTROL_EVENT_KA_ACK_STATUS (end of this section and section 2.10). SID_OPTION_DL_ROUTE_VALIDITY returns generic sid_error_t codes; there are no keep-alive-specific error codes: . | Return code | Condition | . | SID_ERROR_INVALID_ARGS | handle is NULL/uninitialized, len is not sizeof(struct sid_dlrv_config), or a value in data is out of range (DLRV time, or nwsync_time above its upper bound). | . | SID_ERROR_NOSUPPORT | The build enables neither FSK nor LoRa (SID_SDK_CONFIG_ENABLE_LINK_TYPE_2 and _3 both 0), so the option is not available. A link that is not in sid_config.link_mask does not cause SID_ERROR_NOSUPPORT: the values are applied only to the enabled links. | . | SID_ERROR_NONE | Success. | . Public constants referenced in this section (declared in sid_900_cfg.h unless noted): . | Constant | Value | Meaning | . | MIN_DL_ROUTE_VALIDITY_TIME_MINS | 1 | Minimum DLRV time. | . | DEF_DL_ROUTE_VALIDITY_TIME_MINS | 15 | Default DLRV time (LoRa). | . | DEF_DL_ROUTE_VALIDITY_TIME_MINS_FSK | 1080 | Default DLRV time (FSK). | . | MAX_DL_ROUTE_VALIDITY_TIME_MINS | 1440 | Maximum DLRV time. | . | MIN_LINK3_PROFILE_B_NW_SYNC_TIME_MINS | 1 | Minimum LoRa Profile B network-sync (KA) interval. | . | DEF_LINK3_PROFILE_B_NW_SYNC_TIME_MINS | 5 | Default LoRa Profile B network-sync interval. | . | MAX_LINK3_PROFILE_B_NW_SYNC_TIME_MINS | 240 | Maximum LoRa Profile B network-sync interval. | . | SID_NWSYNC_TIME_NOT_SET | 0 | Sentinel meaning “not set — use link default” for nwsync_time. | . | MAX_FSK_KA_INTERVAL_MINS | 1440 | Maximum FSK-only KA interval. | . /** * The structure used to configure the DL route validity */ struct sid_dlrv_config { /** time for the DL route validity in mins. Range: 1 ~ 1440 mins */ uint16_t time; /** KA / NW-sync interval in mins. LoRa Pb: 1~240. FSK: up to MAX_FSK_KA_INTERVAL_MINS. * 0 = not set (use link default). uint16_t to hold FSK values > 255. */ uint16_t nwsync_time; /** indicates whether to get or set the dlrv time. false: Get, true: Set */ bool is_set; }; // handle: the struct sid_handle * returned by sid_init() // Set the downlink route validity time to 30 mins and the keep-alive interval to 5 mins struct sid_dlrv_config dlrv_set = { .time = 30, .nwsync_time = 5, .is_set = true }; sid_error_t ret = sid_option(handle, SID_OPTION_DL_ROUTE_VALIDITY, &dlrv_set, sizeof(dlrv_set)); // Get the current downlink route validity time and keep-alive interval struct sid_dlrv_config dlrv_get = {0}; ret = sid_option(handle, SID_OPTION_DL_ROUTE_VALIDITY, &dlrv_get, sizeof(dlrv_get)); . On a successful set, the new DLRV / nwsync_time values are applied to the active sub-GHz link. The keep-alive acknowledgement status is reported through the following structure, delivered as the event_data of the SID_CONTROL_EVENT_KA_ACK_STATUS control event: . /** * Reports whether a link keep-alive received an application-layer ACK. * event_data of SID_CONTROL_EVENT_KA_ACK_STATUS points to this structure. */ struct sid_ka_ack_status { /** The link type on which the keep-alive was sent */ enum sid_link_type link_type; /** true if the app-layer ACK was received, false on timeout */ bool ack_received; }; . The struct is stack-allocated by the Amazon Sidewalk stack for the duration of the callback only — the developer’s application shall not retain the event_data pointer beyond the callback’s return. // Observe keep-alive acknowledgement in the control-event callback void on_control_event_notify(const struct sid_control_event_data *evt, void *ctx) { if (evt->event_type == SID_CONTROL_EVENT_KA_ACK_STATUS) { const struct sid_ka_ack_status *s = evt->event_data; // s->link_type, s->ack_received } else if (evt->event_type == SID_CONTROL_EVENT_DL_ROUTE_VALIDITY_CONFIG_UPDATE) { uint16_t dlrv_mins = *(uint16_t *)evt->event_data; } } . 2.9.9 Amazon Sidewalk Sub-GHz User Control . This option is included in this guide because it affects RX-window availability — and therefore whether a link KA can be acknowledged (section 2.9.8) — but it does not configure the KA. It does not touch the KA payload, interval, or acknowledgement state, and does not change the persistent link profile. The Amazon Sidewalk stack allows the developer to send user control commands to Sub-GHz links (FSK and LoRa). This option provides a mechanism for advanced users to send custom control commands to the Sub-GHz radio layers. /** * Describes the SUB-GHZ user control commands. */ enum sid_sub_ghz_ctl_cmd { /** Reserved command - not for application use */ SID_SUB_GHZ_CTL_CMD_RESERVED, /** Request to terminate ongoing RX operation */ SID_SUB_GHZ_CTL_CMD_RX_TERMINATE_REQUEST, /** Maximum command value */ SID_SUB_GHZ_CTL_CMD_MAX, }; /** * Structure used for Sub-GHz user control commands */ struct sid_sub_ghz_user_control { /** Sub-GHz control command type */ enum sid_sub_ghz_ctl_cmd sub_ghz_ctl_cmd; }; // Example: Send RX terminate request to Sub-GHz link struct sid_sub_ghz_user_control user_cmd = { .sub_ghz_ctl_cmd = SID_SUB_GHZ_CTL_CMD_RX_TERMINATE_REQUEST }; sid_error_t ret = sid_option(handle, SID_OPTION_SUB_GHZ_USER_CONTROL, &user_cmd, sizeof(user_cmd)); . 2.9.10 Amazon Sidewalk Keep-Alive Payload . The developer’s application can set the payload carried by the periodic keep-alive uplink on the FSK link, and on the LoRa link in Profile B or Profile C. The payload is part of the static sub-GHz configuration: the ka_payload member of struct sid_sub_ghz_links_config, passed to sid_init() through sid_config.sub_ghz_link_config. When ka_payload.data is NULL or ka_payload.len is 0, the keep-alive carries the default payload, a single byte 0x00. Applications that do not set ka_payload keep this default behavior and need no change. The buffer is owned by the developer’s application and is not copied. The Amazon Sidewalk stack reads it each time it sends a keep-alive, so the buffer shall remain valid until sid_deinit() is called. The application may change the buffer contents, ka_payload.data or ka_payload.len at any time after sid_init(); the next keep-alive uses the new values, and no API call is needed. The length shall not exceed SID_KA_PAYLOAD_MAX_SIZE (19) bytes. SID_KA_PAYLOAD_MAX_SIZE (19) is the largest keep-alive payload that fits on both sub-GHz links; it equals the LoRa link MTU. sid_init() returns SID_ERROR_INVALID_ARGS if ka_payload.len exceeds SID_KA_PAYLOAD_MAX_SIZE. /** Maximum keep-alive payload size in bytes */ #define SID_KA_PAYLOAD_MAX_SIZE 19 /** * Keep-alive payload on FSK and LoRa Profile B / Profile C links. * Part of struct sid_sub_ghz_links_config. */ struct sid_ka_payload_config { /** Pointer to application-owned static buffer. NULL to use the default payload. */ const uint8_t *data; /** Length of the payload in bytes (0 ~ SID_KA_PAYLOAD_MAX_SIZE). 0 to use the default payload. */ uint8_t len; }; struct sid_sub_ghz_links_config { /* ... existing members ... */ struct sid_ka_payload_config ka_payload; /* trailing member */ }; // Set the keep-alive payload at initialization static uint8_t ka_buf[4] = { 0x01, 0x02, 0x03, 0x04 }; // app-owned, static static struct sid_sub_ghz_links_config sub_ghz_cfg = { /* ... other members ... */ .ka_payload = { .data = ka_buf, .len = sizeof(ka_buf) }, }; struct sid_config config = { /* ... */ .sub_ghz_link_config = &sub_ghz_cfg }; struct sid_handle *handle = NULL; sid_error_t ret = sid_init(&config, &handle); // Change the payload later: edit the buffer or the config; the next keep-alive uses it ka_buf[0] = 0x05; sub_ghz_cfg.ka_payload.len = 2; // Return to the default payload sub_ghz_cfg.ka_payload.len = 0; . 2.9.11 LoRa Device Profile Parameters . Set Device Profile and Get Device Profile, described in section 2.9, exchange a struct sid_device_profile. Its unicast parameters are: . struct sid_device_profile_unicast_params { /** Used to indicate profile type of the device */ enum sid_device_profile_id device_profile_id; /** Used to indicate the number of RX windows opened by the device */ enum sid_rx_window_count rx_window_count; /** Used to indicate the beacon interval in units (10080ms per unit) */ uint8_t beacon_interval_unit; /** Used to indicate the frequency of RX windows opened by the device (in ms) */ union sid_unicast_window_interval { /** Used to indicate the frequency of RX windows opened by the device (in ms) in synchronous mode */ enum sid_link2_rx_window_separation_ms sync_rx_interval_ms; /** Used to indicate the frequency of RX windows opened by the device (in ms) in asynchronous mode */ enum sid_link3_rx_window_separation_ms async_rx_interval_ms; } unicast_window_interval; /** Used to indicate the TX/RX wake up configuration of the device */ enum sid_unicast_wakeup_type wakeup_type; /** Used to indicate the RX windows open duration of the device (in sec) in synchronous mode */ uint32_t l2_rx_duration_sec; /** Used to indicate the frequency of RX windows opened by the device (in ms) in MDR mode */ enum sid_link3_rx_window_separation_ms l3_mdr_rx_window_interval_ms; }; . In the member name and the comment above, MDR abbreviates the higher data rate; see section 2.11.2. unicast_window_interval is a union: the developer’s application sets sync_rx_interval_ms for FSK or async_rx_interval_ms for LoRa, never both. l3_mdr_rx_window_interval_ms is not part of that union, so it and async_rx_interval_ms can hold different values at the same time. Note that SID_RX_WINDOW_CNT_INFINITE and SID_RX_WINDOW_CNT_ZERO are both the value 0; which meaning applies is determined by the profile ID. For LoRa, the following parameters can be configured: . | wakeup_type: shall be SID_TX_AND_RX_WAKEUP (3). Every other value of enum sid_unicast_wakeup_type, including SID_NO_WAKEUP (0), is rejected, so leaving this member zero-initialized is not accepted. | unicast_window_interval.async_rx_interval_ms: the interval at which the Endpoint opens RX windows. Under SID_LINK3_PROFILE_A and SID_LINK3_PROFILE_B, the only value accepted at the default data rate is SID_LINK3_RX_WINDOW_SEPARATION_3 (5000 ms), or 0, which the Amazon Sidewalk stack replaces with it; SID_LINK3_RX_WINDOW_SEPARATION_5 (500 ms) and SID_LINK3_RX_WINDOW_SEPARATION_2 (1000 ms) are accepted only at the higher data rate. Under SID_LINK3_PROFILE_C the value supplied in this member is not used: Set Device Profile replaces it with SID_LINK3_RX_WINDOW_SEPARATION_CONTINUOUS (0), and once the Join procedure has completed the Endpoint receives continuously. When the Amazon Sidewalk stack brings the link up at the higher data rate, or moves it to the higher data rate before the Join procedure has completed, it sets the receive cadence itself under every profile, including this one, until that Join completes; see section 2.11.2. Because a shorter interval is rejected under SID_LINK3_PROFILE_A and SID_LINK3_PROFILE_B while the link operates at the default data rate, set this member to SID_LINK3_RX_WINDOW_SEPARATION_3 or 0 and express any shorter-interval preference through l3_mdr_rx_window_interval_ms, described below. | l3_mdr_rx_window_interval_ms: the RX window interval the developer’s application prefers while the Amazon Sidewalk stack operates the LoRa link at the higher data rate; see section 2.11.2. The accepted values are 0, SID_LINK3_RX_WINDOW_SEPARATION_5 (500 ms), SID_LINK3_RX_WINDOW_SEPARATION_2 (1000 ms) and SID_LINK3_RX_WINDOW_SEPARATION_3 (5000 ms); any other value, including SID_LINK3_RX_WINDOW_SEPARATION_4 (10000 ms), is rejected under every LoRa profile. A value of 0 means no preference is pending: it leaves the interval in effect unchanged and does not request a continuous RX window, even though 0 is also the value of SID_LINK3_RX_WINDOW_SEPARATION_CONTINUOUS. If the link is already at the higher data rate, Set Device Profile applies the preference to async_rx_interval_ms within the same call; otherwise the preference is retained and applied the next time the link moves to the higher data rate, or at the next start-up if the link starts at that rate. When the link moves away from the higher data rate, the interval in effect returns to SID_LINK3_RX_WINDOW_SEPARATION_3 and the preference is retained. The preference has no effect under SID_LINK3_PROFILE_C, although it is still stored and returned by Get Device Profile. A shorter interval makes the Endpoint open receive windows more often while it is receiving, which raises its receive power consumption over that period; choose the longest interval that meets the product’s downlink latency requirement. Under SID_LINK3_PROFILE_A the Endpoint opens receive windows only for a bounded period after each uplink: where that period is derived from rx_window_count and the interval, a shorter interval shortens the downlink opportunity rather than adding receive windows, and where the Endpoint instead receives for a fixed duration, a shorter interval adds receive windows within that duration. Under SID_LINK3_PROFILE_B the downlink opportunity does not depend on the interval. | . Set Device Profile reads and writes the structure the developer’s application passes: as described above, it can replace rx_window_count and unicast_window_interval.async_rx_interval_ms. The developer’s application shall not reuse the structure across calls without re-initializing it, and shall call Get Device Profile for the values in effect. Set Device Profile returns SID_ERROR_INVALID_ARGS if the Sidewalk handle is NULL, if the Amazon Sidewalk stack is not initialized, if len is not sizeof(struct sid_device_profile), or if unicast_params.device_profile_id is not a profile ID of a link in link_mask. It returns SID_ERROR_INVALID_STATE if the Endpoint is not registered, if the LoRa link has not been initialized, or if the LoRa link has been started but has not completed network synchronization. It returns SID_ERROR_INCOMPATIBLE_PARAMS if any of the three LoRa parameters above is outside its accepted set, or if the profile ID is SID_LINK3_PROFILE_D; the return code does not identify which parameter was rejected. When link_mask contains both FSK and LoRa, the Amazon Sidewalk stack initializes the LoRa link only when it alternates onto that link, so apply the LoRa device profile after the Amazon Sidewalk stack reports SID_LINK_TYPE_3 in link_status_mask; see section 2.6. When link_mask contains LoRa without FSK, sid_init initializes the link, so only the other two conditions above apply: the Endpoint shall be registered, and after sid_start the call is accepted only once the Amazon Sidewalk stack reports SID_LINK_TYPE_3 in link_status_mask. An accepted change to the device profile on a started, network synchronized LoRa link causes the Endpoint to repeat the Join procedure; for what the developer’s application observes, see section 2.7.3. Until the Join completes, Get Device Profile returns the previous profile, and a Join that does not complete leaves the profile unchanged. Once the Join completes, the profile, including l3_mdr_rx_window_interval_ms, persists across a device reset and is restored at the next start-up. ", "url": "/sid-api-dg/overview-of-functionality.html#29-stack-ioctls", "relUrl": "/sid-api-dg/overview-of-functionality.html#29-stack-ioctls" },"688": { "doc": "2. Overview of Functionality", "title": "2.10 Stack Notifications", "content": "The Sid API notifies the developer’s application through a set of callbacks. The developer is required to register these calllbacks with the Sid API when initializing the Amazon Sidewalk stack. The following events are notified by the Amazon Sidewalk stack: . | on event: the stack does not create tasks for processing its internal events. The stack processes its internal events in the context supplied by the developer’s application. In order to process its pending internal events, the stack notifies the developer’s application through the on event callback. On getting the on event callback, the developer’s application is required to call the sid_process API to cause the stack to process the pending events. The on event callback can be called in ISR context, and the arguments in the callback indicate whether the on event callback is being called in an ISR context or not. | on msg received: The stack uses this callback to notify the developer’s application that a message has arrived. The on msg received callback is always called in the context in which sid_process is called. | on msg sent: When the stack sends the message over the desired link, the stack notifies the developer’s application that it has sent the message successfully using the on msg sent callback. Note that the on msg sent callback does not indicate the message has been received by the AWS IoT application. The on msg sent callback only indicates that the message has been sent over the link successfully and no over the air transmission errors have occurred. The notification trigger for the on msg sent callback to the developer’s application by the stack is different for each link type that is used to send the message: . | BLE: on a BLE link, when the BLE Endpoint receives an acknowledgement from a BLE Gateway, the on msg sent callback is called. | FSK: on an FSK link, when the FSK Endpoint receives a link layer acknowledgement from an FSK Gateway, the on msg sent callback is called. | LoRa: on a LoRa link the developer’s application shall not treat the on msg sent callback as evidence that a Gateway received the message. Link layer acknowledgement and link layer retransmission are used only while a Gateway Session Key is active on the link, see section 2.11.1; otherwise the callback is called as soon as the message is transferred over the air by the low level LoRa radio driver. The Amazon Sidewalk stack does not report a LoRa transmission failure at the time it occurs; a message that is not delivered within its Time to Live period is reported through the on send error callback with SID_ERROR_TIMEOUT. | . | on send error: The on send error message is sent if the stack cannot send the message for any of the following reasons. | Link is not connected: If the link on which the message is being sent is disconnected, the on send error callback is called. | AWS IoT Core for Amazon Sidewalk has not sent Acknowledgement: If the message requires a Transport Ack from AWS IoT Core for Amazon Sidewalk and the Transport Ack was not received in the configured Time to live period, the on send error callback is called. | . | . Note that on msg sent and on send error are not mutually exclusive. There could be instances where the message could be sent over the air to the Gateway, but the message might not make it to the destination of AWS IoT Core for Amazon Sidewalk. In this scenario, on send error and on msg sent are called with the same message ID. This indicates that even though the message was able to be sent over the air to the Gateway, the message did not reach AWS IoT Core for Amazon Sidewalk within the Time to live period configured for that message. | on status changed: The on status changed callback is called when the Amazon Sidewalk stack state changes. The Amazon Sidewalk state is comprised of the following as explained in the previous sections. | Connection status of the link | Time sync status | Registration status | . | . When any of these items change status, the on status changed callback is called. | on factory reset This callback is called when the AWS IoT application has de-registered the device or the developer’s application has called sid_set_factory_reset. The Amazon Sidewalk stack removes all the non-volatile data stored during registration, and then uses the on factory reset callback to notify the developer’s application that the Endpoint is de-registered from the Amazon Sidewalk. On the lite build variants the Endpoint returns to the factory-registered state instead, see section 2.3.5. | on control event This callback is called when the Sidewalk stack notifies the developer application on control events. The control events that the Sidewalk stack notifies are when the developer’s application exceeds the traffic threshold limits | . /** * The set of callbacks a developer's application can register through * sid_init(). */ struct sid_event_callbacks { /** Object used to store user data */ void *context; /** * Callback to invoke when any Sidewalk event occurs. * * The Sidewalk stack invokes this callback when there is at least one * event to process, including internal events. Upon receiving this * callback the sid api user is required to schedule * a call to sid_process() within the application's * main loop or running context. * * @warning sid_process() MUST NOT be called from within the * #on_event callback to avoid re-entrancy and recursion problems. * * @see sid_process * * @param[in] in_isr true if invoked from within an ISR context, * false otherwise. * @param[in] context The context pointer given in * sid_event_callbacks.context */ void (*on_event)(bool in_isr, void *context); /** * Callback to invoke when a message from Sidewalk is received. * * @warning sid_put_msg() MUST NOT be called from within the * #on_msg_received callback to avoid re-entrancy and recursion problems. * * @param[in] msg_desc A pointer to the received message descriptor, which * is never NULL. * @param[in] msg A pointer to the received message payload, which is * never NULL. * @param[in] context The context pointer given in * sid_event_callbacks.context */ void (*on_msg_received)(const struct sid_msg_desc *msg_desc, const struct sid_msg *msg, void *context); /** * Callback to invoke when a message was successfully delivered to * Sidewalk. * * @param[in] msg_desc A pointer to the sent message descriptor, * which is never NULL. * @param[in] context The context pointer given in * sid_event_callbacks.context */ void (*on_msg_sent)(const struct sid_msg_desc *msg_desc, void *context); /** * Callback to invoke when a queued message failed to be delivered to * Sidewalk. * * A developer's application can use this notification to schedule * retrying sending a message, or invoke other error handling. * * @see sid_put_msg * * @warning sid_put_msg() MUST NOT be called from within the * #on_send_error callback to avoid re-entrancy and recursion problems. * * @param[in] error The error code associated with the failure * @param[in] msg_desc A pointer to the unsent message descriptor, * which is never NULL. * @param[in] context The context pointer given in * sid_event_callbacks.context */ void (*on_send_error)(sid_error_t error, const struct sid_msg_desc *msg_desc, void *context); /** * Callback to invoke when the Sidewalk stack status changes. * * Once sid_start() is called, a #SID_STATE_READY status indicates * the stack is ready to accept messages sid_put_msg(). * * When receiving #SID_STATE_ERROR, sid api user can * call sid_get_error() from within the #on_status_changed callback * context to obtain more detail about the error condition. * Receiving this status means the Sidewalk stack encountered a fatal * condition and won't be able to proceed. Hence, this notification is * mostly for diagnostic purposes. * * @param[in] status The current status, valid until the next invocation * of this callback. * @param[in] context The context pointer given in * sid_event_callbacks.context */ void (*on_status_changed)(const struct sid_status *status, void *context); /** * Callback to invoke when the Sidewalk stack * receives a Sidewalk factory reset from the cloud service. * * When the factory reset is triggered from cloud service * or #sid_set_factory_reset api call, the Sidewalk stack clears * its configuration from the non volatile storage * and resets its state accordingly. * This callback is then called by the Sidewalk stack * to notify the sid api user of Sidewalk network factory reset * * The device needs to successfully complete device registration with the * cloud services for the Sidewalk stack to send and receive messages * * @param[in] context The context pointer given in * sid_event_callbacks.context */ void (*on_factory_reset)(void *context); /** * Callback to invoke when the Sidewalk library notifies network control * event. * * Sidewalk stack notifies certain control events to the user */ void (*on_control_event_notify)(const struct sid_control_event_data *data, void *context); }; . The following control events, delivered through the on_control_event_notify callback registered during sid_init(), are related to the keep-alive feature and extend the sid_control_event_type enumeration: . /** Event indicating change in DL route validity configuration. * event_data points to a uint16_t holding the DLRV time in minutes. */ SID_CONTROL_EVENT_DL_ROUTE_VALIDITY_CONFIG_UPDATE = 3, /** Event indicating a KA ACK was received or timed out on a Sub-GHz link. * event_data points to struct sid_ka_ack_status. */ SID_CONTROL_EVENT_KA_ACK_STATUS = 6, . SID_CONTROL_EVENT_KA_ACK_STATUS is delivered only if the developer’s application has registered an on_control_event_notify callback; it is an observability hook and does not affect the keep-alive acknowledgement tracking or link teardown behavior. See section 2.9.8 for the associated struct sid_ka_ack_status. ", "url": "/sid-api-dg/overview-of-functionality.html#210-stack-notifications", "relUrl": "/sid-api-dg/overview-of-functionality.html#210-stack-notifications" },"689": { "doc": "2. Overview of Functionality", "title": "2.11 Stack Configuration", "content": "The Amazon Sidewalk stack requires configuration to be passed during initialization. Configuration includes the following items: . | link_mask: The Amazon Sidewalk stack can be initialized to operate as one link or a combination of more than one link. The link_mask is a bit mask that allows the developer’s application to specify a single link or a combination of more than one link. The following code shows the link combinations that are currently supported and the value the link_mask takes for these combinations. FSK and LoRa links are mutually exclusive, and the Amazon Sidewalk stack cannot support these links simultaneously. If only one of them is in link_mask, the developer’s application has to de-initialize and re-initialize the Amazon Sidewalk stack to switch to the other. If both are in link_mask, the Amazon Sidewalk stack alternates between them until one connects. SID_LINK_TYPE_8 is not a link_mask value, see section 2.1. | . // BLE only uint32_t link_mask = SID_LINK_TYPE_1; // link_mask = 1; // FSK only uint32_t link_mask = SID_LINK_TYPE_2; // link_mask = 2; // LoRa only uint32_t link_mask = SID_LINK_TYPE_3; // link_mask = 4; // BLE and LoRa uint32_t link_mask = SID_LINK_TYPE_1 | SID_LINK_TYPE_3; // link_mask = 5; // BLE and FSK uint32_t link_mask = SID_LINK_TYPE_1 | SID_LINK_TYPE_2; // link_mask = 3; // FSK and LoRa uint32_t link_mask = SID_LINK_TYPE_2 | SID_LINK_TYPE_3; // link_mask = 6; // BLE and FSK and LoRa uint32_t link_mask = SID_LINK_TYPE_1 | SID_LINK_TYPE_2 | SID_LINK_TYPE_3; // link_mask = 7; . | callbacks: a pointer to the callback structure documented above. | link_config: static configuration for the BLE link. A struct sid_ble_link_config pointer is required irrespective of the link_mask. | sub_ghz_link_config: static configuration for the FSK and LoRa links, including the LoRa data rate requested by the developer’s application. This member is optional. See section 2.11.2. | dev_ch: the characteristics of the end device: its type, its power source, and the qualification ID assigned at qualification. | log_config: diagnostic logging configuration. Contains the pointer to the buffer in which logs are stored, the size of that buffer, and the log level. The allocated buffer shall be at least 1KB. | time_sync_config: time synchronization configuration, an array of sync intervals in hours. The intervals shall be strictly increasing and each shall be between 2 and 720 hours. If the member is not provided, or the values do not meet those conditions, the default intervals are used. See section 2.4. | gsk_config: Gateway Session Key configuration. See section 2.11.1. If it is not provided, default values are used. | . The Amazon Sidewalk stack does not copy the structures referenced by callbacks, link_config, sub_ghz_link_config, and time_sync_config. The developer’s application shall keep those structures, and anything they point to, in static storage for as long as the Amazon Sidewalk stack is initialized (this includes the keep-alive payload buffer referenced by sub_ghz_link_config->ka_payload; see section 2.9.10). log_config and gsk_config are read once during sid_init and are not retained, but the log buffer that log_config points to shall remain valid for as long as the Amazon Sidewalk stack is initialized. 2.11.1 Gateway Session Key Configuration . A Gateway Session Key (GSK) is a key that the Amazon Sidewalk stack may establish for a sub-GHz link. Using a GSK does not change how user payloads are encrypted; see section 2.3. Gateway Session Keys apply only to the sub-GHz links; the BLE link never uses one. On the LoRa link a key and the higher data rate go together: the Amazon Sidewalk stack moves the link to the higher data rate itself in order to establish a key, whichever data rate the developer’s application requested. See section 2.11.2. There is no Sid API call to start or stop establishment. Amazon Sidewalk determines whether this procedure runs for a given device and link, and may also limit how long a key is used and how many messages are sent under it; the values in struct sid_gsk_config affect only when the Amazon Sidewalk stack attempts establishment and when it stops using a key. Gateway Session Key support is a build-time option in the Amazon Sidewalk stack, and is enabled by default. Where it is not built in, gsk_config has no effect and no Gateway Session Key is established. A field left at zero selects that field’s default. Any other value outside the permitted range is adjusted to the nearest permitted value rather than rejected. sid_init therefore never fails because of gsk_config. #define SID_GSK_IDLE_TIMEOUT_MIN_SEC 10 #define SID_GSK_IDLE_TIMEOUT_MAX_SEC 600 #define SID_GSK_IDLE_TIMEOUT_DEFAULT_SEC 240 #define SID_GSK_APP_ACK_MISS_MIN 3 #define SID_GSK_APP_ACK_MISS_MAX 10 #define SID_GSK_APP_ACK_MISS_DEFAULT 6 #define SID_GSK_RETRY_INTERVAL_MIN_SEC 43200 /* 12 h */ #define SID_GSK_RETRY_INTERVAL_MAX_SEC 129600 /* 36 h */ #define SID_GSK_RETRY_INTERVAL_DEFAULT_SEC 86400 /* 24 h */ struct sid_gsk_config { uint32_t idle_timeout_sec; uint32_t app_ack_miss_threshold; uint32_t retry_interval_sec; }; . | idle_timeout_sec: the combined transmit and receive idle period on the sub-GHz link that shall elapse before the Amazon Sidewalk stack begins establishment of its own accord. Traffic that uses a key and traffic that uses the legacy credentials both reset it, so on a product that transmits on a sub-GHz link more often than idle_timeout_sec establishment does not start on this basis. The idle period is not on its own sufficient: establishment also requires the Endpoint to be registered, the per-link enablement to be present, a capable sub-GHz link to have completed the Join procedure, no key to be held already, and, on the LoRa link, a regulatory region in which the higher data rate is permitted. Nor is it always awaited: after the Amazon Sidewalk stack stops using a key because of a failure over the air, such as a time synchronization or Join failure under the key, it may begin establishment immediately. | app_ack_miss_threshold: the number of consecutive unacknowledged uplink messages sent under the key on the sub-GHz link, after which the Amazon Sidewalk stack stops using the key. Only messages that were transmitted and that requested an acknowledgment are counted; see section 2.8.3.1. The count is reset when the Endpoint next receives a message under that key. Such a message timing out is reported through the on send error callback with SID_ERROR_TIMEOUT, but the developer’s application shall not assume those reports account for every message counted towards this field. On reaching the threshold the Amazon Sidewalk stack discards the stored keys rather than suspending the key in use, and does not attempt establishment again until retry_interval_sec has elapsed. | retry_interval_sec: the period between attempts to establish a GSK, after an unsuccessful attempt or after the Amazon Sidewalk stack has stopped using a GSK. The idle period in idle_timeout_sec applies to a scheduled attempt as well. Within a single attempt the Amazon Sidewalk stack retries its request a bounded number of times with an escalating delay; neither the number of retries nor that delay is configurable, and the minimum of twelve hours does not follow a single lost message. | . Establishing a Gateway Session Key, or ceasing to use one, can make the Endpoint repeat the Join procedure. Whether it does, and what the developer’s application observes, depends on the sub-GHz link and, on the LoRa link, on the data rate the developer’s application requested; see section 2.7.3. The developer’s application shall not use the on status changed callback to detect a key change. Establishment and key maintenance generate sub-GHz uplinks that the developer’s application did not request, and these count against its energy and duty cycle budget. Raising idle_timeout_sec or retry_interval_sec makes them less frequent. app_ack_miss_threshold also affects them, for a product whose messages request acknowledgment: the Amazon Sidewalk stack makes a further establishment attempt after each time it stops using a key, so a threshold that is reached often produces more of this traffic. The Amazon Sidewalk stack may also stop using a key for reasons the developer’s application does not configure, including a limit that Amazon Sidewalk places on the key’s age or on the number of messages sent under it, a failure to confirm the key over the air, or a time synchronization failure while the key is in use. A key survives a device reset and is resumed at the next start-up; a factory reset clears it. The value returned by sid_get_mtu does not change while a Gateway Session Key is in use; see section 3.10. On the LoRa link two things the developer’s application can observe do change with a key: link layer acknowledgement and link layer retransmission are used only while a key is active on that link, see section 2.10; and where establishing the key moves the link to the higher data rate, any retained RX window interval preference is applied at that point, subject to the profile conditions in section 2.9. 2.11.2 LoRa Data Rate . The Amazon Sidewalk stack operates the LoRa link at one of two data rates: a default data rate and a higher data rate. The developer’s application requests one through the link3_data_rate member of the sub-GHz link configuration passed to sid_init. There is no IOCTL counterpart; for what the Amazon Sidewalk stack reports about the data rate, see section 2.6. The higher data rate shortens the time each message occupies the air, at the cost of a reduced link budget in both directions: the Endpoint and the Gateway each need a stronger signal from the other to stay reachable. Request it for a product that sends or receives frequently and that operates within reliable range of a Gateway; leave the default data rate for a product that needs the greatest range. The data rate is requested using the following enumeration. enum sid_link3_data_rate { /** Low data rate */ SID_LINK3_DATA_RATE_LDR = 0, /** Medium data rate */ SID_LINK3_DATA_RATE_MDR = 1, }; . SID_LINK3_DATA_RATE_LDR is the default data rate and SID_LINK3_DATA_RATE_MDR is the higher data rate; this guide uses those two descriptions throughout. sid_init does not validate this member. A zero-initialized sub-GHz link configuration, no sub-GHz link configuration at all, and any value other than SID_LINK3_DATA_RATE_MDR all select the default data rate. The higher data rate additionally requires a regulatory region that permits it, established before the LoRa link is initialized. A request the region does not permit is refused the same way a mis-set member is: the link runs at the default data rate, with no return code and no callback to indicate it. The developer’s application’s request is read once, during sid_init; modifying the sub-GHz link configuration afterwards does not change the data rate. The regulatory region condition is re-evaluated whenever the Amazon Sidewalk stack initializes the LoRa link, and again whenever it moves the link to the higher data rate. The developer’s application shall therefore establish the regulatory region before it calls sid_init. A region established afterwards takes effect only if and when the Amazon Sidewalk stack next performs one of those steps, which is not guaranteed to happen and is not reported to the developer’s application; until it does, the link operates at the default data rate. To make a region established after sid_init take effect, de-initialize and initialize the Amazon Sidewalk stack. Where the regulatory region permits the higher data rate, the Amazon Sidewalk stack operates the LoRa link at it when the developer’s application has requested it, and also whenever a Gateway Session Key is being established or is in use on the link, including a key that is resumed at start-up after a device reset. While a key is being established the data rate changes first and the key becomes active afterwards. See section 2.11.1. Requesting the higher data rate does not require Gateway Session Key support to be built in, and does not by itself enable link layer acknowledgement or link layer retransmission; see section 2.10. Where the Amazon Sidewalk stack brings the link up at the higher data rate, or moves it to the higher data rate before the Join procedure has completed, it sets the receive cadence itself until that Join completes, and the developer’s application shall not rely on the configured RX window interval being in effect during that period. For the RX window interval and the higher-data-rate interval preference, see section 2.9. The developer’s application shall be functionally correct at the default data rate in every region it ships to: a request for the higher data rate can be refused, and the Amazon Sidewalk stack does not report that it was. ", "url": "/sid-api-dg/overview-of-functionality.html#211-stack-configuration", "relUrl": "/sid-api-dg/overview-of-functionality.html#211-stack-configuration" },"690": { "doc": "2. Overview of Functionality", "title": "2.12 Sidewalk Handle", "content": "The Sidewalk handle is a pointer to an internal structure that is returned to the developer’s application as part of the Amazon Sidewalk stack initialization. The developer’s application is required to pass this handle when making Sid API calls. The Sidewalk handle is set to NULL when the Amazon Sidewalk stack is de-initialized. ", "url": "/sid-api-dg/overview-of-functionality.html#212-sidewalk-handle", "relUrl": "/sid-api-dg/overview-of-functionality.html#212-sidewalk-handle" },"691": { "doc": "2. Overview of Functionality", "title": "2.13 Sidewalk Bulk Data Transfer", "content": "Sidewalk Bulk Data Transfer allows developers to transfer files to a device over BLE link only. These files could be firmware files for OTA upgrades. The developer’s application interacts with the Amazon Sidewalk bulk data transfer functionality through the Amazon Sidewalk Bulk Data Transfer API (SBDT API). Broadly the following operations are supported: . | Initialize and de-initialize SBDT API | Accept and reject incoming transfers | Cancel ongoing transfers | Verify the received file at the end of the transfer | . 2.13.1 Flow . Internally the file that is transferred is divided into fragments, the size of the fragments is configured by the developer when the transfer is setup. This fragment is further divided into chunks of size limited by the link on which the transfer is being done. The maximum size of the chunks for SID_LINK_TYPE_1 (Bluetooth low power energy) is 216 bytes. The device receives each of the chunks that makes up the fragment, the fragment is then verified if the verification fails the block is retransmitted, if not it sends an acknowledgement indicating that the fragment was successfully received. Then, the device receives the next fragment. The procedure continues until the whole file is transferred. Once the whole file is transferred, the application has the opportunity to validate the file. The file validation can be achieved by validating the CRC of the file, or by validating the signature. 2.13.2 File Id . Each transfer to the device is identified by a unique 4 byte id, called as the file_id. 2.13.3 Identifying an incoming transfer . An incoming transfer can be identified via file_descriptor field that developer provides when the transfer is created. The file_descriptor format is developer-defined, and is restricted to size not exceeding 40 bytes. 2.13.4 Memory Usage . The SBDT feature requires buffers to be allocated to handle the file transfer. The amount of memory needed is 2 times the chosen file transfer fragment size + context_memory (memory needed to hold the state). This memory is requested from the developer from the on_transfer_request callback. Some part of the memory is used for storing the transfer context, 1 fragment is used to store the received encrypted data and 1 fragment is used to hold the decrypted data. This memory is owned by SBDT until on_release_scratch is called. 2.13.5 Flash Storage . To allow for seamless functioning of the file transfer on reboots or planned device shutdown’s, the SBDT stack stores information that it receives at file transfer request to kv_store at the various stages of the transfer. 2.13.6 Requesting a transfer . When a transfer is started, the application has the option to reject or accept a transfer. An application can choose to reject transfers based on multiple reasons. The currently available options are listed below. enum sid_bulk_data_transfer_reject_reason { /** No reject reason */ SID_BULK_DATA_TRANSFER_REJECT_REASON_NONE = 0x0, /** Rejected for generic reasons */ SID_BULK_DATA_TRANSFER_REJECT_REASON_GENERIC = 0x1, /** Rejected because file is too big */ SID_BULK_DATA_TRANSFER_REJECT_REASON_FILE_TOO_BIG = 0x3, /** Rejected because device has not space */ SID_BULK_DATA_TRANSFER_REJECT_REASON_NO_SPACE = 0x4, /** Rejected bacause low battery to complete transfer */ SID_BULK_DATA_TRANSFER_REJECT_REASON_LOW_BATTERY = 0x5, /** Rejected because file verification failed */ SID_BULK_DATA_TRANSFER_REJECT_REASON_FILE_VERIFICATION_FAILED = 0x9, /** Rejected because file already exist */ SID_BULK_DATA_TRANSFER_REJECT_REASON_FILE_ALREADY_EXISTS = 0xB, /** Rejected because fragment size is not supported */ SID_BULK_DATA_TRANSFER_REJECT_REASON_INVALID_FRAGMENT_SIZE = 0xE, }; . The developer is provided with multiple information points such as fragment_size, file_size, file_descriptor (Identifying an incoming transfer) that can help them determining the reason for rejection. 2.13.7 Receiving data . Once each fragment is received, the developer’s application is given fragment via on_data_received callback. The additional information that is provided includes file_id, file_offset, and the link that fragment the data is received on. Once the data is received, the developer’s application can then write the data to flash and release the buffer so that the next buffer can be received. 2.13.8 SBDT Callbacks . The SBDT API notifies the developer’s application through a set of callbacks. The developer is required to register these callbacks with SBDT API when initializing the SBDT feature. The following events are notified by SBDT: . | on transfer request: SBDT uses this callback to notify the developer’s application that it received a request to start a file transfer. The callback contains various information about the incoming transfer such as the size of the file, fragment size used for the transfer, the link over which the transfer is going to happen, file descriptor if provided when the transfer was created. This API allows developer’s application to reject the incoming transfer with a reject reason in Sidewalk Bulk Data Transfer Status Codes. | on data received: SBDT uses this callback to notify the developer’s application that it received a fragment. The developer’s application now owns the buffer that contains fragment data and can only be released via sid_bulk_data_transfer_release_buffer API call. | on finalize request: Once all the fragments are transferred, the SBDT triggers this callback to notify the developer that the file has been transferred. The developer’s application can indicate to SBDT if the recieved file is as expected via the sid_bulk_data_transfer_finalize API call. | on cancel request: SBDT uses this callback to notify the developer’s application that it received a cancel request from AWS cloud. This API is also called when the developer’s application calls sid_bulk_data_transfer_cancel to cancel an ongoing transfer. | on error: SBDT uses this callback to notify the developer that it has encountered an unrecoverable error. | on release scratch: This callback is called by the SBDT to release memory it acquired from the developer’s application in on transfer request. This callback is called after on finalize request, on cancel request, on error and sid_bulk_data_transfer_deinit. | . struct sid_bulk_data_transfer_event_callbacks { /** User context data */ void *context; /** * Callback that is invoked when a transfer request is recieved * * The Sidewalk stack invokes this callback to let the user know about * an Incoming transfer request. The user can then choose to accept or * reject said transfer request * * @param[in] transfer_request A pointer to the data transfer request, * which is never NULL * @param[out] transfer_response A pointer to the data transfer response, * which is never NULL * @param[in] context The context pointer given in * sid_bulk_data_transfer_event_callbacks.context * */ void (*on_transfer_request) (const struct sid_bulk_data_transfer_request *const transfer_request, struct sid_bulk_data_transfer_response *const transfer_response, void *context); /** * Callback that is invoked when data has been received * * @param[in] desc A pointer to the bulk transfer data, * which is never NULL * @param[in] buffer A pointer to the buffer that contains the received * data, which is never NULL * @param[in] context The context pointer given in * sid_bulk_data_transfer_event_callbacks.context */ void (*on_data_received) (const struct sid_bulk_data_transfer_desc *const desc, const struct sid_bulk_data_transfer_buffer *const buffer, void *context); /** * Callback that is invoked when data transfer is done * * @param[in] file_id Identifier of the file being transferred * @param[in] context The context pointer given in * sid_bulk_data_transfer_event_callbacks.context */ void (*on_finalize_request)(uint32_t file_id, void *context); /** * Callback that is invoked when data transfer is cancelled from cloud * * @param[in] file_id Identifier of the file being transferred * @param[in] context The context pointer given in * sid_bulk_data_transfer_event_callbacks.context */ void (*on_cancel_request)(uint32_t file_id, void *context); /** * Callback that is invoked when an error is encountered during data * transfer * * The Sidewalk stack will invoke this API to let the user know an error * was encountered during file transfer. Internally Sidewalk stack * cleans up it's state and goes to the same state as when * sid_bulk_data_transfer_start() is called. * * @param[in] file_id Identifier of the file being transferred * @param[in] context The context pointer given in * sid_bulk_data_transfer_event_callbacks.context */ void (*on_error)(uint32_t file_id, void *context); /** * Callback that is invoked when Sidewalk stack wants to release scratch * buffer * * The Sidewalk stack will invoke this API to let the user cleanup the * scratch buffer that was allocated to during on_transfer_request call * * @param[in] file_id Identifier of the file being released * @param[in] context The context pointer given in * sid_bulk_data_transfer_event_callbacks.context */ void (*on_release_scratch)(uint32_t file_id, void *context); }; . ", "url": "/sid-api-dg/overview-of-functionality.html#213-sidewalk-bulk-data-transfer", "relUrl": "/sid-api-dg/overview-of-functionality.html#213-sidewalk-bulk-data-transfer" },"692": { "doc": "2. Overview of Functionality", "title": "2.14 Amazon Sidewalk Location Library", "content": "The Amazon Sidewalk Location Library enables Sidewalk customers to use a range of cloud-based location solvers. Available in SDK >=1.19, this library provides an API that automatically selects the most power and time efficient location mechanism based on available hardware and network conditions. Developers will also have finer grain control to configure and override the mechanism used to determine location as required. 2.14.1 Supported Location Methods . The location library supports four location resolution methods: . | Sidewalk Network Location over BLE - Leverages existing BLE connections to trigger cloud-side location resolution | Sidewalk Network Location over LoRa - Sends a location trigger over an active LoRa connection for cloud-side location resolution | WiFi Scan - Scans for nearby WiFi access points and sends MAC addresses to the cloud for location resolution | GNSS Scan - Uses Global Navigation Satellite System to collect satellite vehicle data for coordinate resolution | . Methods 1 and 2 are network-level triggers that rely on the cloud to resolve location from the device’s network context, requiring no device-side scanning. Methods 3 and 4 perform device-side scans and can be sent over either BLE or LoRa link types. FSK with WiFi/GNSS scanning enabled is not currently supported. WiFi and GNSS scanning leverage the Semtech LoRa Basics Modem middleware to manage and conduct scans on the device. These four methods correspond directly to the four effort levels defined in Section 2.14.2, ordered from lowest to highest power consumption. 2.14.2 Location Levels . Location levels are ordered by lowest effort first (power consumption and time) and are defined by the available hardware on the device. The library automatically steps down through levels at configurable timeouts. 2.14.2.1 Level 1: Connected to Sidewalk via BLE . | Power Consumption: No additional power draw | Description: If the device can be located via BLE over the Sidewalk network, the device notifies the cloud to resolve the location with no further effort. If the device is not connected via BLE or location cannot be resolved, the next level is attempted. | . 2.14.2.2 Level 2: LoRa Location Trigger . | Power Consumption: Low power consumption | Description: Sends a location trigger over LoRa (Link Type 3) to the cloud for location resolution. Requires the LoRa link to be network synced. This level is used when the device is not connected via BLE but has an active LoRa connection. | . 2.14.2.3 Level 3: Send WiFi Scan . | Power Consumption: Low power consumption | Description: Conduct and send a WiFi scan. Minimum of 1 AP must be found in scan or next level will be attempted. If the cloud receives a low confidence score or no resolution is found, the device application must be notified to increment and try the next level. | . 2.14.2.4 Level 4: Send GNSS Scan . | Power Consumption: Higher power consumption than WiFi scanning | Description: Conduct and send a GNSS scan. Minimum 4 Satellite Vehicles must be found for scan to be valid. | . 2.14.3 Architecture . The library provides a single interface for application developers to consume APIs for uplinking location data. WiFi and GNSS have corresponding Platform Abstraction Layers (PALs) that are required when these features are enabled. 2.14.4 Getting Started . 2.14.4.1 Compilation Configuration . To enable the location library in your project, the following CMake variable definitions must be set: . set(SID_SDK_CONFIG_ENABLE_LOCATION 1) set(SID_SDK_CONFIG_ENABLE_WIFI 1) set(SID_SDK_CONFIG_ENABLE_GNSS 1) add_compile_definitions(SID_SDK_CONFIG_ENABLE_LOCATION=1) add_compile_definitions(SID_SDK_CONFIG_ENABLE_WIFI=1) add_compile_definitions(SID_SDK_CONFIG_ENABLE_GNSS=1) . SID_SDK_CONFIG_ENABLE_LOCATION enables the location library as part of the build. SID_SDK_CONFIG_ENABLE_WIFI and SID_SDK_CONFIG_ENABLE_GNSS are features that can be enabled if available hardware supports WiFi and GNSS scanning. Additional configurations may be required depending on the build system of the target. 2.14.4.2 Managed Effort Mode . The manage_effort configuration field controls whether the location library automatically selects and adjusts the effort level used for location operations. When manage_effort is true: . | The application can pass SID_LOCATION_EFFORT_DEFAULT as the mode in sid_location_run(). The library will use its internally tracked effort level. | The library starts at SID_LOCATION_EFFORT_L1 and automatically escalates to higher effort levels if the current level is not supported or returns insufficient results. | After a successful scan at a higher effort level (L3 or L4), the library starts a stepdown timer. When the timer expires, the effort level is reduced back toward L1 based on the configured stepdowns timeouts. | The maximum effort level the library can escalate to is bounded by max_effort. | The application can override the maximum allowed effort at runtime using sid_location_set_max_mode(), for example to limit power consumption during low-battery conditions. | . When manage_effort is false: . | The application must specify an explicit effort level (L1, L2, L3, or L4) in every call to sid_location_run(). Passing SID_LOCATION_EFFORT_DEFAULT will return an error. | No automatic escalation or stepdown occurs. The library uses exactly the effort level requested. | This mode gives the application full control over which location method is used for each operation. | . L2 (LoRa location trigger) can be used explicitly by passing SID_LOCATION_EFFORT_L2 to sid_location_run(). During managed effort escalation, L2 is currently skipped and the library transitions directly between L1 and L3. 2.14.4.3 Fragmentation Timeout Configuration . If configuring the fragmentation timeout, the timeout_ms parameter should be considered carefully. The timeout will be calculated automatically if set to 0 and follows the following formula that mirrors the cloud algorithm to wait/reassemble fragments: . timeout = (total_size / MTU) × link_type_duration × 2 . Where: . | total_size / MTU determines the number of fragments required | link_type_duration is the maximum time the specified link type can take to uplink one fragment | The factor of 2 provides additional margin for retries to reach the cloud. | . Current supported link type durations: . | LoRa: Up to 5 seconds per fragment | BLE: BLE does not utilize fragmentation for location as the MTU is large enough. These configurations will not apply | . 2.14.5 Location Resolve via sid_put_msg . In addition to the explicit location APIs (sid_location_run()), the location library supports requesting location resolution as part of a user message sent via sid_put_msg(). This is done by setting the resolve_location field in the message descriptor’s TX attributes. When resolve_location is set to true, the Sidewalk stack includes a location resolve request with the user’s message. The gateway uses this to resolve the device’s location based on its own known position. This works on both BLE and LoRa links. Prerequisites: . | SID_SDK_CONFIG_ENABLE_LOCATION must be enabled at compile time | sid_location_init() must have been called successfully | The Sidewalk stack must be in SID_STATE_READY state | . 2.14.6 WiFi and GNSS Location Example (LR1110) . The following example shows how to enable GNSS and WiFi with the location library for use with the LR1110 shield. // Platform parameters setup platform_parameters_t platform_parameters = { .mfg_store_region = sid_mfg_config_get(), .platform_init_parameters.radio_cfg = (radio_lr11xx_device_config_t *)get_radio_cfg(), .platform_init_parameters.gnss_wifi_cfg = (lr11xx_gnss_wifi_config_t *)get_location_cfg(), }; // Location library usage void location_callback(const struct sid_location_result *const result, void *context) { // Handle location operation results } static struct sid_location_config cfg = { .sid_location_type_mask = SID_LOCATION_METHOD_ALL, .manage_effort = true, .max_effort = SID_LOCATION_EFFORT_L4, .callbacks = { .on_update = location_callback, .context = NULL, }, .stepdowns = { .l2_to_l1 = 0, .l3_to_l2 = 0, .l4_to_l3 = 0, }, .fragmentation = { .timeout_ms = 0, .max_retries = 1, }, .auto_link_pause_resume = true, }; sid_error_t res = sid_location_init(*app_context->sidewalk_handle, &cfg); // WiFi scan and send struct sid_location_run_config config = { .type = SID_LOCATION_SCAN_AND_SEND, .mode = SID_LOCATION_EFFORT_L3 }; res = sid_location_run(*app_context->sidewalk_handle, &config, 0); // GNSS scan and send config.mode = SID_LOCATION_EFFORT_L4; res = sid_location_run(*app_context->sidewalk_handle, &config, 0); . 2.14.7 BLE-Only Location Example . static struct sid_location_config cfg = { .sid_location_type_mask = SID_LOCATION_METHOD_BLE_GATEWAY, .manage_effort = true, .max_effort = SID_LOCATION_EFFORT_L1, .callbacks = { .on_update = location_callback, .context = NULL, }, .stepdowns = {0}, .fragmentation = {0}, .auto_link_pause_resume = false, }; sid_error_t res = sid_location_init(*app_context->sidewalk_handle, &cfg); struct sid_location_run_config config = { .type = SID_LOCATION_SCAN_AND_SEND, .mode = SID_LOCATION_EFFORT_DEFAULT }; res = sid_location_run(*app_context->sidewalk_handle, &config, 0); . 2.14.8 LoRa Location Example . static struct sid_location_config cfg = { .sid_location_type_mask = SID_LOCATION_METHOD_BLE_GATEWAY, .manage_effort = false, .max_effort = SID_LOCATION_EFFORT_L2, .callbacks = { .on_update = location_callback, .context = NULL, }, .stepdowns = {0}, .fragmentation = {0}, .auto_link_pause_resume = false, }; sid_error_t res = sid_location_init(*app_context->sidewalk_handle, &cfg); struct sid_location_run_config config = { .type = SID_LOCATION_SEND_ONLY, .mode = SID_LOCATION_EFFORT_L2 }; res = sid_location_run(*app_context->sidewalk_handle, &config, 0); . 2.14.9 Platform Abstraction Layers . If the device supports WiFi and GNSS scanning (levels 3 and 4), the WiFi and GNSS Platform Abstraction Layers (PALs) must be implemented and linked. Reference implementations are provided that utilize the Semtech LoRa Basics Modem middleware APIs. 2.14.10 Best Practices . | Use sid_location_set_max_mode() to limit power consumption during low-power modes | Configure appropriate stepdown timeouts based on your application requirements | Always check return values from location API functions | Handle different status codes in your callback function appropriately | Allow the library to manage effort levels automatically when possible | Consider using scan-only operations when immediate uplink is not required | . ", "url": "/sid-api-dg/overview-of-functionality.html#214-amazon-sidewalk-location-library", "relUrl": "/sid-api-dg/overview-of-functionality.html#214-amazon-sidewalk-location-library" },"693": { "doc": "2. Overview of Functionality", "title": "2.15 Build configuration for factory-registered Endpoints and lite variants", "content": "The Amazon Sidewalk stack can be built in a full variant, which supports every link type and registration over the air, or in one of three lite variants, each restricted to a single link type. The lite variants have no over-the-air registration path: an Endpoint running a lite variant is registered at the factory over a wired link (section 2.3.4). The following build settings apply: . | SID_SDK_CONFIG_BUILD_BLE_ONLY, SID_SDK_CONFIG_BUILD_FSK_ONLY, SID_SDK_CONFIG_BUILD_LORA_ONLY: CMake options that select a lite variant. They are mutually exclusive; when none is set the full variant is built. | SID_SDK_INTERNAL_CONFIG_IS_FACTORY_REGISTERED: when set to 1, the Amazon Sidewalk stack accepts a factory-registered Endpoint and performs field activation for it. The default is 0. The reference applications set it for every lite variant and, for the full variant, through their BUILD_FACTORY_REGISTERED build option. | SID_SDK_CONFIG_SECURITY_LEVEL: SID_SDK_CONFIG_SECURITY_LEVEL_HIGH (0, the default) or SID_SDK_CONFIG_SECURITY_LEVEL_LOW (1). This setting only selects the security level the Endpoint reports in its capabilities to the Amazon Sidewalk cloud; the behavior of the stack (restoring the credentials from the manufacturing page, keeping them across a factory reset) follows from the variant. Build the lite variants with SID_SDK_CONFIG_SECURITY_LEVEL_LOW and the full variant with SID_SDK_CONFIG_SECURITY_LEVEL_HIGH, and register the Endpoint with the same security level in the manufacturing tool. | . sid_init behaves differently in the two variants: . | In the full variant, link_mask set to SID_LINK_TYPE_3 (LoRa) only is accepted for a factory-registered Endpoint when SID_SDK_INTERNAL_CONFIG_IS_FACTORY_REGISTERED is set, see section 3.3. | In the lite variants, sid_init returns SID_ERROR_NOSUPPORT when the Endpoint is neither registered nor factory-registered, because the build has no way to register it over the air. | . ", "url": "/sid-api-dg/overview-of-functionality.html#215-build-configuration-for-factory-registered-endpoints-and-lite-variants", "relUrl": "/sid-api-dg/overview-of-functionality.html#215-build-configuration-for-factory-registered-endpoints-and-lite-variants" },"694": { "doc": "2. Overview of Functionality", "title": "2.16 Device Region (Internationalization)", "content": "Amazon Sidewalk device firmware operates in a specific regulatory zone, and the frequency plan and regulatory parameters the radio layer uses at bring-up are selected according to that zone, called the region. The Device Information API (sid_device_information.h) exposes the region to the Amazon Sidewalk stack for system integrators adopting Sidewalk internationalization (i18n). The Amazon Sidewalk stack does not store the region itself. The developer’s application owns it end to end: it persists the region in non-volatile storage, reports it to the Amazon Sidewalk stack through a callback, and accepts cloud/app-driven updates through a callback. The Amazon Sidewalk stack reaches the application’s storage only through the callbacks registered in struct sid_device_info_callbacks. An unregisterable region does not block sid_start() outright: it confines the call to SID_LINK_TYPE_1 (BLE) and fails a request for sub-GHz links alone with SID_ERROR_INVALID_STATE. An application adopting this API shall provision a valid region before registration is required on a sub-GHz link, or the sub-GHz link will not start. See section 2.16.4 for the exact mechanics, and section 3.36. 2.16.1 Data Types . The region is represented by the following enumeration: . enum sid_device_region { SID_DEVICE_REGION_UNSET = 0, /* reserved / unset */ SID_DEVICE_REGION_NORTH_AMERICA = 1, /* North America (US/CA/MX) */ SID_DEVICE_REGION_EUROPE = 2, /* Europe, incl. UK */ SID_DEVICE_REGION_JAPAN = 3, /* Japan (defined, not enabled) */ SID_DEVICE_REGION_AUSTRALIA_NZ = 4, /* Australia / New Zealand (defined, not enabled) */ SID_DEVICE_REGION_NOT_SUPPORT = 0xFF, }; . The region travels in struct sid_device_dyn_info (a tagged union) when type is SID_DEVICE_INFO_TYPE_REGION: . struct sid_device_dyn_info { enum sid_device_info_type type; /* = SID_DEVICE_INFO_TYPE_REGION */ union { /* ... */ enum sid_device_region region; }; }; . The region itself is exchanged through two application-supplied callbacks, registered in struct sid_device_info_callbacks and passed to sid_device_information_init (section 3.34): . | get_info() — the Amazon Sidewalk stack calls this with type == SID_DEVICE_INFO_TYPE_REGION to read the current region, for example to answer a GET_DEVICE_INFORMATION request. | set_info() — the Amazon Sidewalk stack calls this with type == SID_DEVICE_INFO_TYPE_REGION to apply a region change, for example from a DEVICE_CONFIGURATION write. | . 2.16.2 Supported Regions and Build Flags . A region is registerable only if it is North America or Europe, and the firmware was built for it. The build-time flags gate configurability, reported through is_device_region_configurable(). Table 2.3: Supported regions and the build flags that enable them. | Region | Registerable | Enabled by build flag(s) | ————- | —————- | ——————————————— | North America | Yes | REGION_LITE or REGION_US915 | Europe | Yes | REGION_LITE or REGION_EU868 | Australia/NZ | No | defined but not enabled — blocks registration | Japan | No | defined but not enabled — blocks registration | Unset (0) | No | n/a — blocks registration | . A set_info request for a region the firmware was not built for is rejected with NO_SUPPORT_ERROR, and the device keeps its previous region. 2.16.3 Integrating the Device Region API . 1. Implement the callbacks. Handle SID_DEVICE_INFO_TYPE_REGION in both get_info and set_info. The region value shall be persisted to non-volatile storage — the example below keeps it in an app context for brevity, but a production integration shall survive reboot and factory state. static bool on_device_get_info(struct sid_device_dyn_info *info, void *context) { struct app_context *app = context; if (info->type == SID_DEVICE_INFO_TYPE_REGION) { info->region = app->region_set ? (enum sid_device_region)app->region : SID_DEVICE_REGION_UNSET; return true; } /* ... handle ENV / BATTERY_LEVEL / OTA_BLOCK_SIZE as applicable ... */ return false; } static bool on_device_set_info(const struct sid_device_dyn_info *info, void *context) { struct app_context *app = context; if (info->type == SID_DEVICE_INFO_TYPE_REGION) { app->region = (uint8_t)info->region; app->region_set = true; /* MUST persist to NVM here so the region survives reboot/factory state. */ return true; /* return false to signal a storage failure */ } /* ... handle ENV as applicable ... */ return false; } . 2. Register the module. Call sid_device_information_init (section 3.34) after sid_init returns a handle. The configuration passed is not copied and shall remain valid for the lifetime of the application. static struct sid_device_info_callbacks device_info_callbacks = { .context = &g_app_context, .get_info = on_device_get_info, .set_info = on_device_set_info, }; static const struct sid_device_info_config device_info_cfg = { .info = &device_static_info, /* serial, MAC, fw version, device kind */ .callbacks = &device_info_callbacks, }; /* After sid_init() returns a handle. The config must stay valid for the app lifetime. */ sid_error_t ret = sid_device_information_init(&device_info_cfg, sidewalk_handle); . 3. Provision a region. Provision a valid, build-enabled region before the device attempts to register on a sub-GHz link. There are two paths: . | Local provisioning (recommended at manufacturing/setup): the application sets the region through its own storage path, so get_info returns a valid value on first boot. | Remote configuration: the cloud/app sends a DEVICE_CONFIGURATION write with the region tag; the module routes it to set_info. | . If get_info returns SID_DEVICE_REGION_UNSET, the module falls back to a compile-time default only after the device is already registered — it does not fall back before registration. An unset region on a fresh device therefore leaves the device confined to BLE until a valid region is provisioned; see section 2.16.4. 4. Configure the radio region. The region the Endpoint reports through get_info and set_info, and the region its sub-GHz radio operates on, set by platform_init_parameters.region and iso_country in sid_platform_init (3.1), are separate values, and the Amazon Sidewalk stack does not connect them. Derive both from the same stored value: . | At every boot, pass the stored region to sid_platform_init(), rather than a fixed compile-time value. | A region written through set_info reaches the radio at the next platform initialization, normally after the next reboot, because sid_platform_init() runs once per boot. | If no region is stored, pass a region the build includes; the reported region remains SID_DEVICE_REGION_UNSET, which confines sid_start() to BLE until a region is provisioned (section 2.16.4). | On factory reset, clear the stored region. | . If the two values differ, the Endpoint reports one region while its radio operates on the parameters of another. 2.16.4 The Registration Gate . sid_start() (section 3.5) calls sid_device_information_is_region_registerable() (section 3.36) before starting the requested links: . | When the region is North America, Europe, or Australia/NZ, is_region_registerable() returns true and sid_start() proceeds with the link_mask the developer’s application requested, unchanged. | When the region is UNSET or unsupported (e.g. Japan), is_region_registerable() returns false, and sid_start() masks link_mask down to SID_LINK_TYPE_1 (BLE) before proceeding: . | If that leaves no link to start — because the developer’s application requested only FSK, only LoRa, or FSK and LoRa together, with no BLE — sid_start() returns SID_ERROR_INVALID_STATE and no link starts. | If SID_LINK_TYPE_1 was among the requested links, sid_start() proceeds on BLE alone; the sub-GHz links the application requested do not start, and this is not separately reported. | . | . An application adopting this API shall provision a valid region before registration is required on a sub-GHz link, or the sub-GHz link will not start. 2.16.5 Backward Compatibility . An application that does not implement region reporting (legacy firmware without i18n support, or firmware that never calls sid_device_information_init) is unaffected: . | sid_device_information_is_region_registerable() returns true (the gate is open), so sid_start() does not mask link_mask. | The GET_DEVICE_INFORMATION response omits the region tag; the app/cloud uses that absence to detect a legacy device. | . The requirements in this section apply only to integrators adopting the region API. 2.16.6 Example Usage . /* Static device information reported alongside the dynamic region. */ static struct sid_device_info device_static_info = { .serial_number = dsn_buf, .serial_number_size = sizeof(dsn_buf), .mac_address = mac_buf, .mac_address_size = 6, .product_fw_version = fw_ver_buf, .product_fw_version_size = sizeof(fw_ver_buf), }; static struct sid_device_info_callbacks device_info_callbacks = { .context = &g_app_context, .get_info = on_device_get_info, /* returns persisted region */ .set_info = on_device_set_info, /* persists region to NVM */ }; static const struct sid_device_info_config device_info_cfg = { .info = &device_static_info, .callbacks = &device_info_callbacks, }; void app_setup(struct sid_handle *sidewalk_handle) { /* 1. Register the module after sid_init(). */ sid_device_information_init(&device_info_cfg, sidewalk_handle); /* 2. Ensure a valid region is provisioned before sid_start(). * (Either set it here from NVM, or rely on a prior DEVICE_CONFIGURATION write.) */ /* 3. sid_start() invokes the region gate internally; a valid region lets * the requested links proceed, an unset/unsupported one confines * sid_start() to SID_LINK_TYPE_1 (BLE). */ } . 2.16.7 Integration Checklist . | Firmware built with the flag(s) that enable the target region(s). | get_info returns the persisted region for SID_DEVICE_INFO_TYPE_REGION. | set_info persists the region to NVM for SID_DEVICE_INFO_TYPE_REGION. | Callbacks registered via sid_device_information_init() after sid_init(). | A valid (NA/EU/ANZ) region provisioned before the application needs a sub-GHz link to start. | Verified registration succeeds on the sub-GHz links the product uses; confirmed an unset or Japan region is understood to confine sid_start() to BLE. | The region passed to sid_platform_init() at boot is derived from the same stored value that get_info reports. | The stored region is cleared on factory reset. | . ", "url": "/sid-api-dg/overview-of-functionality.html#216-device-region-internationalization", "relUrl": "/sid-api-dg/overview-of-functionality.html#216-device-region-internationalization" },"695": { "doc": "3. Overview of the Functionality", "title": "3. Overview of the Functionality", "content": "Amazon Sidewalk supports three link types illustrated below. The multi-link feature implements a connection policy framework which influences the behavior of the connection and uplink of messages using the supported links. The multi-link feature exerts influence at the application layer of the stack. The behavior of the links at Network, Security, MAC and PHY layers are not impacted by this feature. The feature also plays a role even when only one link is enabled by the developer’s application. It influences the message’s uplink attributes and link’s connection timeout parameters to send the message. The multi-link parameters are explained in detail 3.2 Link Control Attributes. The feature indirectly impacts the link on which the downlinks are received by end point. Sidewalk is an uplink based protocol, the downlink from the Amazon Sidewalk cloud services always follow the link on which the last uplink is received from the end point. The following table provides a brief description of the connection establishment and connection maintenance for the three link types supported by Amazon Sidewalk. ", "url": "/app-notes/multi-link/overview-of-the-functionality.html", "relUrl": "/app-notes/multi-link/overview-of-the-functionality.html" },"696": { "doc": "3. Overview of the Functionality", "title": "3.1 Connection Establishment and Connection Maintenance on Links", "content": "3.1.1 Bluetooth LE . LINK: Bluetooth LE . SID_LINK_TYPE: SID_LINK_TYPE_1 . Description: . | The end point performs the role of a Bluetooth LE peripheral and the gateway the role of Bluetooth LE Central. | Amazon Sidewalk Bluetooth LE advertisements are sent by the end point periodically indicating its presence to the Amazon Sidewalk Bluetooth LE gateways and to mobile application leveraging the Amazon Sidewalk Mobile SDK. The advertisements are sent to allow the Amazon Sidewalk cloud to discover the presence of the Amazon Sidewalk end point which is in the range of any Amazon Sidewalk Bluetooth LE gateway to send a downlink or indicate the reachability of the end point to the AWS IoT Wireless managed service. | When the end point wants to send an uplink, it indicates its intent to connect to the Amazon Sidewalk network by changing the payload in the Bluetooth LE advertisements. The Amazon Sidewalk Bluetooth LE gateway which is in the range of the end point is instructed by the Amazon Sidewalk cloud to start the Bluetooth LE connection process and establish connection. The Amazon Sidewalk Bluetooth LE end point then sends the uplink. | The Amazon Sidewalk Bluetooth LE gateways do not keep the connection persistent for a longer duration. Unless there is an activity (uplink or downlink) in the connected state, the Amazon Sidewalk Bluetooth LE gateways terminate the connection after a certain time (currently configured to 5 minutes). The end point Sidewalk stack also disconnects the Bluetooth LE connection with the Sidewalk Bluetooth LE gateways when the developer’s application does not send any messages to AWS IoT Wireless managed service. The timeout for Sidewalk stack for end point to disconnect the Sidewalk Bluetooth LE gateway is configured to 30 seconds. | Acknowledgements at link level are handled at the link layer by Bluetooth LE protocol stack. The Bluetooth LE protocol stack is responsible to establish connection, maintenance of the connection and reporting of connected and disconnected events to the Amazon Sidewalk stack. The Amazon Sidewalk Bluetooth LE stack maintains connection with Amazon Sidewalk Network while the Bluetooth LE protocol maintains the Bluetooth LE connection between the end point and Amazon Sidewalk cloud. | . Connection: Connection on demand. Loss and establishment of connection is notified by the underlying Bluetooth LE Stack. References: Amazon Sidewalk Specification, SID API User Guide . 3.1.2 SubG-FSK . LINK: SubG-FSK . SID_LINK_TYPE: SID_LINK_TYPE_2 . Description: . | The Amazon Sidewalk SubG-FSK gateways send beacons periodically (configured every  10 seconds). | The Amazon Sidewalk SubG-FSK endpoints synchronize with the beacons to establish and maintain connection. | The Amazon Sidewalk end point scans passively for Amazon Sidewalk beacons to sync(connect) to a Amazon Sidewalk gateway. | End points can detect connection loss with a particular SubG-FSK gateway if it fails to receive a pre-configured (currently 3) number of beacons from the currently connected gateway consecutively. | Acknowledgements are present at the link layer when messages are exchanged between end points and gateways thus providing link layer reliability. | . Connection: Connected. Loss of connection is detected by loss of synchronization of beacons from the connected Sidewalk SubG-FSK gateway. Failure to receive a join response for the join request sent by the end point even when the end point is in synchronization with Sidewalk SubG-FSK gateway’s beacons results in disconnection state. References: Amazon Sidewalk Specification, Device Profiles Application Note . 3.1.3 SubG-CSS . LINK: SubG-CSS . SID_LINK_TYPE: SID_LINK_TYPE_3 . Description: . | There are periodic messages that in Profile B that are required to be sent by the end point stack periodically while in Profile A there are no periodic messages that are required to be sent by end point stack. | Link layer acknowledgements are not present on this link type. | . Connection: Connectionless protocol. Status of availability of link is determined only after sending a message. References: Amazon Sidewalk Specification, Device Profiles Application Note . ", "url": "/app-notes/multi-link/overview-of-the-functionality.html#31-connection-establishment-and-connection-maintenance-on-links", "relUrl": "/app-notes/multi-link/overview-of-the-functionality.html#31-connection-establishment-and-connection-maintenance-on-links" },"697": { "doc": "3. Overview of the Functionality", "title": "3.2 Link Control Attributes", "content": "The following are the attributes that are controlled by the multi-link feature to pick an optimum link for sending messages. 3.2.1 Message Uplink Attributes . The message uplink attributes are as follows: . | Request Acknowledgment from AWS IoT Wireless managed service | Number of Retries | Time to Live | . These attributes and their usage is described in detail in SID API User Guide’s Chapter 2.8.2.1 Sidewalk Message Transmit Attributes. 3.2.2 Link Connection Control Attributes . 3.2.2.1 Link Priority . When more than one link is enabled and no link is in connected state, the order of priority that needs to be followed to attempt connection is determined by the link priority attribute. The value has a range from 0 to 2. Value 3 and greater will cause undefined behavior. Lower the value higher the priority. 3.2.2.2 Maximum Time to Attempt Connection for a Link . The maximum time in seconds for which the Amazon Sidewalk stack attempts to establish connection on a link. ", "url": "/app-notes/multi-link/overview-of-the-functionality.html#32-link-control-attributes", "relUrl": "/app-notes/multi-link/overview-of-the-functionality.html#32-link-control-attributes" },"698": { "doc": "3. Overview of the Functionality", "title": "3.3 Link Connection Policy", "content": "There are two link connection policies that are available to the developer. The link policies are mutually exclusive. Only one policy can be enabled at a time. These policies can also be compiled out at build time. The two available policies are Auto Connection Policy and Multi-link Connection Policy. The option to the select link connection policy that should be used by the Amazon Sidewalk stack can be configured using the sid_option API as shown below. The default link connection policy that stack is configured with is SID_LINK_CONNECTION_POLICY_NONE. In SID_LINK_CONNECTION_POLICY_NONE policy setting the stack does not apply any connection policy settings. The stack is required to be initialized using sid_init before setting link connection policy using sid_option. The link connection policy can be configured successfully before the Sidewalk stack on the end point is registered and time is acquired. The link connection policy configuration does not persist within the stack across reboots. The developer is expected to configure the preferred link connection policy on every reboot of the device. SID_ERROR_INVALID_ARGS is returned if the stack is not initialized or invalid arguments are passed to sid_option API. /** * Describes the connection policy setting */ enum sid_link_connection_policy { /** Default setting. Sidewalk stack does not apply any * connection policy. */ SID_LINK_CONNECTION_POLICY_NONE = 0, /** Auto connection policy, Sidewalk stack applies auto connection policy * based on the parameters * configured through auto connection policy parameters. */ SID_LINK_CONNECTION_POLICY_AUTO_CONNECT, /** Multi-link connection policy, Sidewalk stack applies multi-link * connection policy based on the policy * configured through multi-link connection policy. */ SID_LINK_CONNECTION_POLICY_MULTI_LINK_MANAGER, /** Delimiter to enum sid_link_connection_policy */ SID_LINK_CONNECTION_POLICY_LAST }; // IOCTL to set link connection policy // Set link connection policy to SID_LINK_CONNECTION_POLICY_AUTO_CONNECT enum sid_link_connection_policy set_policy = SID_LINK_CONNECTION_POLICY_AUTO_CONNECT; sid_error_t ret = sid_option (handle, SID_OPTION_SET_LINK_CONNECTION_POLICY, &set_policy, sizeof(set_policy)); // IOCTL to get link connection policy // Get configured link connection policy enum sid_link_connection_policy get_policy; sid_error_t ret = sid_option(handle, SID_OPTION_GET_LINK_CONNECTION_POLICY, &get_policy, sizeof(get_policy)); . 3.3.1 Default Link Connection Policy . When the link connection policy is configured to SID_LINK_CONNECTION_POLICY_NONE, the stack does not apply any connection policy algorithm to the messages enqueued with sid_put_msg API. The developer is expected to establish the connection before enqueuing the message. If the link is not connected and the message is enqueued, the Amazon Sidewalk stack would fail the message with SID_ERROR_INVALID_STATE error code. 3.3.2 Auto Connection Policy . The auto connection policy can be enabled at build time by setting the build flag . SID_SDK_CONFIG_ENABLE_AUTO_CONNECT. The auto connection policy provides flexibility to the developer to configure the link connection control attributes mentioned above. The Amazon Sidewalk stack is required to be initialized using sid_init before setting link auto connection policy parameters using sid_option. The link auto connection policy parameters can be configured successfully before the Sidewalk stack on the end point is registered and time is acquired. The Amazon Sidewalk stack triggers connection on a link only when a message is required to be transmitted by the developer using the sid_put_msg API. The link auto connection policy parameters do not persist within the stack across reboots. The developer is expected to configure the preferred link auto link connection policy parameters on every reboot of the device. SID_ERROR_INVALID_ARGS is returned if the stack is not initialized or invalid arguments are passed to sid_option API. The following shows the parameters that are available to the developer to configure the auto link connection policy. The developer can select the link types, priority among the links and connection attempt timeout seconds. /** * Describes link auto connect parameters */ struct sid_link_auto_connect_params { /** Sid link type */ enum sid_link_type link_type; /** Auto connect policy if set enable is equal to 0 */ bool enable; /** Priority of the link type when more than one link is specified * using #sid_put_msg * 0 is highest priority, 2 is lowest priority */ uint8_t priority; /** Maximum period up to which the stack attempts to form a connection */ uint16_t connection_attempt_timeout_seconds; }; // IOCTL to set auto connect parameters // Set auto connection params for SID_LINK_TYPE_1 with priority 1 and // connection_attempt_timeout_seconds to 30 struct sid_link_auto_connect_params params_link_1 = { .link_type = SID_LINK_TYPE_1, .enable = true, .priority = 0, .connection_attempt_timeout_seconds = 30 }; sid_error_t ret = sid_option(handle, SID_OPTION_SET_LINK_POLICY_AUTO_CONNECT_PARAMS, &params_link_1, sizeof(params_link_1)); // Set auto connection params for SID_LINK_TYPE_2 with priority 2 and // connection_attempt_timeout_seconds to 120 struct sid_link_auto_connect_params params_link_2 = { .link_type = SID_LINK_TYPE_2, .enable = true, .priority = 1, .connection_attempt_timeout_seconds = 120 }; ret = sid_option(handle, SID_OPTION_SET_LINK_POLICY_AUTO_CONNECT_PARAMS, &params_link_2, sizeof(params_link_2)); // Set auto connection params for SID_LINK_TYPE_3 with priority 3 and // connection_attempt_timeout_seconds to 90 struct sid_link_auto_connect_params params_link_3 = { .link_type = SID_LINK_TYPE_3, .enable = true, .priority = 2, .connection_attempt_timeout_seconds = 90 }; ret = sid_option(handle, SID_OPTION_SET_LINK_POLICY_AUTO_CONNECT_PARAMS, &params_link_3, sizeof(params_link_3)); // Disable auto connection on SID_LINK_TYPE_2 link struct sid_link_auto_connect_params params_link_2_disable = { .link_type = SID_LINK_TYPE_2, .enable = false, }; ret = sid_option(handle, SID_OPTION_SET_LINK_POLICY_AUTO_CONNECT_PARAMS, &params_link_2_disable, sizeof(params_link_2_disable)); // IOCTL to get auto connect parameters // Get auto connection parameters configured for SID_LINK_TYPE_1 struct sid_link_auto_connect_params get_params_link_1 = { .link_type = SID_LINK_TYPE_1, }; ret = sid_option(handle, SID_OPTION_GET_LINK_POLICY_AUTO_CONNECT_PARAMS, &get_params_link_1, sizeof(get_params_link_1)); . 3.3.2.1 Connection Attempt Timeout . The following table gives the minimum value of connection_attempt_timeout_seconds that can be configured for each of the link type. SID_ERROR_INVALID_ARGS is returned if a value for connection_attempt_timeout_seconds is configured to be lower than the value indicated in the table below. The minimum value of connection attempt timeout in seconds for each link type. | link_type | minimum connection attempt timeout in seconds | . | SID_LINK_TYPE_1 | 10 | . | SID_LINK_TYPE_2 | 30 | . | SID_LINK_TYPE_3 | 20 | . 3.3.2.2 Link Auto Connection Policy Algorithm . The following conditions are required to be met for the Sidewalk stack to trigger connection on a link. | The link is already started using the sid_start API. | The end point is already registered to the Amazon Sidewalk network and time is acquired successfully. | The link connection policy is configured to SID_LINK_CONNECTION_POLICY_AUTO_CONNECT. | The auto connection policy parameters are enabled on the link. | The link mask present in the sid_put_msg has this link enabled in the sid_msg_desc. | The size of the message that is required to be transmitted is less than the MTU of the links that are started and have the auto connection policy parameters as enabled. | If a Sidewalk stack has at least one link in connected state and the connected link can send the message, the link auto connection policy algorithm does not get triggered as the connected link can successfully send the message. | When the connection cannot be established on any of the links the policy is enabled, the policy will progress through the links in the order of priority configured by the developer multiple times until all the messages that are enqueued by the user have expired. When there are no messages in the end point Amazon Sidewalk stack’s send queue, the algorithm will stop attempting to establish connection with the Amazon Sidewalk network. | . The following examples are used to explain the behavior of the link auto connection policy algorithm. Example 1 . Example 1 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with all links.* At least one link is in connected state, SID_LINK_TYPE_3 is connected. * Auto connect policy is enabled and auto connection policy parameters on all three links. * Link priority order is SID_LINK_TYPE_1 > SID_LINK_TYPE_2 > SID_LINK_TYPE_3. * Message sent using sid_put_msg with message tx attributes of acknowledgment required, retries and time to live set by the developer. * Message sent using sid_put_msg has link_type set to pick any of the three links. (link_type = (SID_LINK_TYPE_1 SID_LINK_TYPE_2 SID_LINK_TYPE_3)) * The payload of the message that is requested to be transmitted can be sent on all the three links. | The auto connection policy does not attempt connection on any links as the link which is in connected state will send the message on the connected link. | . |   |   | . Example 2 . Example 2 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with all links. * No link is in connected state. * Auto connect policy is enabled and auto connection policy parameters on all three links. * Link priority order is SID_LINK_TYPE_1 > SID_LINK_TYPE_2 > SID_LINK_TYPE_3. * Message sent using sid_put_msg with message tx attributes of acknowledgment required, retries and time to live set by the developer. * Message sent using sid_put_msg has link_type set to pick any of the three links. (link_type = (SID_LINK_TYPE_1 | SID_LINK_TYPE_2 | SID_LINK_TYPE_3)) * The payload of the message that is requested to be transmitted can be sent on all the three links. | The auto connection policy starts attempting link connection for a period of connection timeout specified by the auto connection policy for that link. The order of priority to pick links for connection in this case is SID_LINK_TYPE_1 followed by SID_LINK_TYPE_2 and SID_LINK_TYPE_3. During the course of connection attempts, if any of the link gets connected, the message is sent over the connected link. If any of the links do not get connected within the configured time to live setting in the message’s transmit attributes the message will be failed with SID_ERROR_TIMEOUT error code. | . Example 3 . Example 3 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with all links. * No link is in connected state. * Auto connect policy is enabled and auto connection policy parameters on all three links. * Link priority order is SID_LINK_TYPE_3 > SID_LINK_TYPE_2 > SID_LINK_TYPE_1. * Message sent using sid_put_msg with message tx attributes of acknowledgment required, retries and time to live set by the developer. * Message sent using sid_put_msg has link_type set to pick any of the three links. (link_type = (SID_LINK_TYPE_3 | SID_LINK_TYPE_2 | SID_LINK_TYPE_1)) * The payload of the message that is requested to be transmitted can be sent on all the three links. | The auto connection policy starts attempting link connection for a period of connection timeout specified by the auto connection policy for that link. The order of priority to pick links for connection in this case is SID_LINK_TYPE_3 followed by SID_LINK_TYPE_2 and SID_LINK_TYPE_1. During the course of connection attempts, if any of the link gets connected, the message is sent over the connected link. If any of the links do not get connected within the configured time to live setting in the message’s transmit attributes the message will be failed with SID_ERROR_TIMEOUT error code. | . Example 4 . Example 4 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with all links. * No link is in connected state. * Auto connect policy is enabled and auto connection policy parameters on all three links. * Link priority order is SID_LINK_TYPE_1 > SID_LINK_TYPE_2 > SID_LINK_TYPE_3. * Message sent using sid_put_msg with message tx attributes of acknowledgment required, retries and time to live set by the developer. * Message sent using sid_put_msg has link_type set to pick any of the three links. (link_type = (SID_LINK_TYPE_1 | SID_LINK_TYPE_2 | SID_LINK_TYPE_3)) * The payload of the message that is requested to be transmitted can only be sent on only SID_LINK_TYPE_1. | The auto connection policy attempts link connection only on SID_LINK_TYPE_1 as SID_LINK_TYPE_2 and SID_LINK_TYPE_3 cannot send the message as the payload of the message exceeds the MTU of the two links. If the connection can be established within the time to live of message’s transmit attributes, the message will be sent over SID_LINK_TYPE_1. Failure to send would result in message failing with SID_ERROR_TIMEOUT error code. | . Example 5 . Example 5 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with all links. * No link is in connected state. * Auto connect policy is enabled and auto connection policy parameters on all three links. * Link priority order is SID_LINK_TYPE_1 > SID_LINK_TYPE_2 > SID_LINK_TYPE_3. * Message sent using sid_put_msg with message tx attributes of acknowledgment required, retries and time to live set by the developer. * Message sent using sid_put_msg has link_type set to pick only one link. (link_type = SID_LINK_TYPE_2) * The payload of the message that is requested to be transmitted can be sent on all the three links. | The auto connection policy attempts link connection only on SID_LINK_TYPE_2 as SID_LINK_TYPE_1 and SID_LINK_TYPE_3 are not in the link_type setting in sid_put_msg API. If the connection can be established within the time to live of message’s transmit attributes, the message will be sent over SID_LINK_TYPE_1. Failure to send would result in message failing with SID_ERROR_TIMEOUT error code. | . Example 6 . Example 6 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with only one link SID_LINK_TYPE_2. * No link is in connected state. * Auto connect policy is enabled and auto connection policy parameters on all three links. * Link priority order is SID_LINK_TYPE_1 > SID_LINK_TYPE_2 > SID_LINK_TYPE_3. * Message sent using sid_put_msg with message tx attributes of acknowledgment required, retries and time to live set by the developer. * Message sent using sid_put_msg has link_type set to pick any of the three links. (link_type = (SID_LINK_TYPE_1 | SID_LINK_TYPE_2 | SID_LINK_TYPE_3)) * The payload of the message that is requested to be transmitted can be sent on all the three links. | The Sidewalk stack is started with only one link SID_LINK_TYPE_2. Even though the link auto connection policy parameters are configured for all links, the auto connection policy algorithm will function only on one link, in this case SID_LINK_TYPE_2 as the other two links are not started. If the connection can be established within the time to live of message’s transmit attributes, the message will be sent over SID_LINK_TYPE_2. Failure to send would result in message failing with SID_ERROR_TIMEOUT error code. | . Example 7 . Example 7 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with two links (SID_LINK_TYPE_2 | SID_LINK_TYPE_3). * No link is in connected state. * Auto connect policy is enabled and auto connection policy parameters on all three links. * Link priority order is SID_LINK_TYPE_1 > SID_LINK_TYPE_2 > SID_LINK_TYPE_3. * Message sent using sid_put_msg with message tx attributes of acknowledgment required, retries and time to live set by the developer. * Message sent using sid_put_msg has link_type set to pick any of the three links. (link_type = (SID_LINK_TYPE_1 | SID_LINK_TYPE_2 | SID_LINK_TYPE_3)) * The payload of the message that is requested to be transmitted can be sent on all the three links. | The Sidewalk stack is started with two links SID_LINK_TYPE_2 and SID_LINK_TYPE_3. Even though the link auto connection policy parameters are configured for all links, the auto connection policy algorithm will function only on two links, in this case SID_LINK_TYPE_2 and SID_LINK_TYPE_3 as SID_LINK_TYPE_1 is not started. If the connection can be established within the time to live of message’s transmit attributes, the message will be sent over SID_LINK_TYPE_2 or SID_LINK_TYPE_3. Failure to send would result in message failing with SID_ERROR_TIMEOUT error code. | . Example 8 . Example 8 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with two links (SID_LINK_TYPE_2 | SID_LINK_TYPE_3). * No link is in connected state. * Auto connect policy is enabled and auto connection policy parameters on all three links. * Link priority order is SID_LINK_TYPE_1 > SID_LINK_TYPE_2 > SID_LINK_TYPE_3. * Message sent using sid_put_msg with message tx attributes of acknowledgment required, retries and time to live set by the developer. * Message sent using sid_put_msg has link_type set to pick only one link that is not started. (link_type = SID_LINK_TYPE_1) * The payload of the message that is requested to be transmitted can be sent on all the three links. | The Sidewalk stack will not attempt connection as the developer has requested the message to be sent on a link SID_LINK_TYPE_1 which is not started. The message will be immediately failed with error code SID_ERROR_NO_ROUTE_AVAILABLE. | . Example 9 . Example 9 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with two links (SID_LINK_TYPE_2 | SID_LINK_TYPE_3). * No link is in connected state. * Auto connect policy is enabled and auto connection policy parameters on all three links. * Link priority order is SID_LINK_TYPE_1 > SID_LINK_TYPE_2 > SID_LINK_TYPE_3. * Message sent using sid_put_msg with message tx attributes of acknowledgment required, retries and time to live set by the developer. * Message sent using sid_put_msg has link_type set to pick any of the three links. (link_type = (SID_LINK_TYPE_1 | SID_LINK_TYPE_2 | SID_LINK_TYPE_3)) * The payload of the message that is requested to be transmitted can be sent only one link which is SID_LINK_TYPE_1 which is not started. | The Sidewalk stack will not attempt connection as the developer has requested the message whose payload cannot be sent over the links that are started in this case SID_LINK_TYPE_2 and SID_LINK_TYPE_3. The message will be immediately failed with error code SID_ERROR_NO_ROUTE_AVAILABLE. | . Example 10 . Example 10 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with all links. * No link is in connected state. * Auto connect policy is disabled on all links. * Message sent using sid_put_msg with message tx attributes of acknowledgment required, retries and time to live set by the developer. * Message sent using sid_put_msg has link_type set to all links. (link_type = (SID_LINK_TYPE_1 | SID_LINK_TYPE_2 | SID_LINK_TYPE_3)) * The payload of the message that is requested to be transmitted can be sent on all the three links. | The Sidewalk stack will not attempt connection as the link auto connection policy parameters are disabled on all links. The message will be immediately failed with error code SID_ERROR_NO_ROUTE_AVAILABLE. | . 3.3.3 Multi-link Connection Policy . The multi-link connection policy can be enabled at build time by setting the build flag SID_SDK_CONFIG_ENABLE_MULTI_LINK. The multi-link connection policy determines the message uplink attributes and link connection attributes and does not expect the developer to configure these parameters while sending the message. The Amazon Sidewalk stack is required to be initialized using sid_init before setting link multi-link connection policy using sid_option. The link multi-link connection policy can be configured successfully before the Sidewalk stack on the end point is registered and time is acquired. The Amazon Sidewalk stack triggers connection on a link only when a message is required to be transmitted by the developer using the sid_put_msg API. The multi-link connection policy do not persist within the stack across reboots. The developer is expected to set the preferred multi-link connection policy on every reboot of the device. SID_ERROR_INVALID_ARGS is returned if the stack is not initialized or invalid arguments are passed to sid_option API. The following shows the policies that are available to the developer to configure the multi-link connection policy. /** multi-link policy modes */ enum sid_link_multi_link_policy { /** Default policy, Default Setting, All links are enabled */ SID_LINK_MULTI_LINK_POLICY_DEFAULT = 0, /** Policy optimized for better power consumption */ SID_LINK_MULTI_LINK_POLICY_POWER_SAVE = 1, /** Policy optimized for performance, better throughput */ SID_LINK_MULTI_LINK_POLICY_PERFORMANCE = 2, /** Policy optimized for latency, faster uplinks */ SID_LINK_MULTI_LINK_POLICY_LATENCY = 3, /** Policy optimized for reliability, messages have a longer Time to live * and more retries */ SID_LINK_MULTI_LINK_POLICY_RELIABILITY = 4, /** Delimiter to enum sid_link_power_policy_type */ SID_LINK_MULTI_LINK_POLICY_LAST }; // IOCTL to set multi-link policy // Set multi-link policy to SID_LINK_MULTI_LINK_POLICY_PERFORMANCE enum sid_link_multi_link_policy policy = SID_LINK_MULTI_LINK_POLICY_PERFORMANCE; sid_error_t ret = sid_option(handle, SID_OPTION_SET_LINK_POLICY_MULTI_LINK_POLICY, &policy, sizeof(policy)); // IOCTL to get multi-link policy // Get current configured multi-link policy enum sid_link_multi_link_policy get_policy; sid_error_t ret = sid_option(handle, SID_OPTION_GET_LINK_POLICY_MULTI_LINK_POLICY, &get_policy, sizeof(get_policy)); . The following conditions are required to be met for the Sidewalk stack to trigger connection on a link. | The Amazon Sidewalk stack is started successfully using sid_start API. | The Sidewalk stack is already registered and time is acquired successfully. | The link connection policy is configured to SID_LINK_CONNECTION_POLICY_MULTI_LINK_MANAGER. SID_LINK_MULTI_LINK_POLICY_ACTIVE is the default that is used when link connection policy is set to SID_LINK_CONNECTION_POLICY_MULTI_LINK_MANAGER. | The size of the message that is required to be transmitted is less than the MTU of the links that are started and have the auto connection policy parameters as enabled. | . The link connection attributes and message uplink attributes are determined by the multi-link policy and the developer configuration is not used to send the message. The following table provides the configuration of these attributes for each of the multi-link policy. The configuration shown in the below policies cannot be configured by the developer. The configuration is statically encoded in the multi-link policy algorithm. 3.3.3.1 SID_LINK_POLICY_DEFAULT . Multi-link Policy: SID_LINK_POLICY_DEFAULT . Description: This multi-link policy has the default behavior of the stack except for configuring the message reliability parameters and connection attributes. The stack does not attempt to keep the connection with the Sidewalk cloud services when there are no messages enqueued to be sent by the stack. Message Reliability Parameters: . | Parameter | Bluetooth LE | SubG-FSK | SubG-CSS | . | Time to live in seconds | 60 | 120 | 150 | . | Retries | 3 | 3 | 3 | . | Transport acknowledgement requested | true | true | true | . Link Priority for Uplink: . | Link | Priority(lower value = high priority) | . | Bluetooth LE | 0 | . | SubG-FSK | 1 | . | SubG-CSS | 2 | . SID_LINK_TYPE_1 (Bluetooth LE): . | Connection Attributes | Setting | . | Link status | Enabled | . | max connection attempt period in seconds | 30 | . | Attempt to connect to gateway(uplink active) | false | . SID_LINK_TYPE_2 (SubG-FSK): . | Connection Attributes | Setting | . | Link status | Active | . | Keep connection with gateway | true | . | max connection attempt period in seconds | 60 | . SID_LINK_TYPE_3 (SubG-CSS): . | Connection Attributes | Setting | . | Link status | Active | . | max connection attempt period in seconds | 60 | . 3.3.3.2 SID_LINK_POLICY_OPTIMIZE_FOR_POWER . Multi-link Policy: SID_LINK_POLICY_OPTIMIZE_FOR_POWER . Description: This multi-link policy stops the links that are enabled by the stack when the stack is not requested to send any messages. The policy behavior is to optimize the power consumption on the device. Message Reliability Parameters: . | Parameter | Bluetooth LE | SubG-FSK | SubG-CSS | . | Time to live in seconds | 60 | 120 | 150 | . | Retries | 1 | 1 | 1 | . | Transport acknowledgement requested | true | true | true | . Link Priority for Uplink: . | Link | Priority(lower value = high priority) | . | Bluetooth LE | 0 | . | SubG-FSK | 1 | . | SubG-CSS | 2 | . SID_LINK_TYPE_1 (Bluetooth LE): . | Connection Attributes | Setting | . | Link status | Enabled | . | max connection attempt period in seconds | 30 | . | Attempt to connect to gateway(uplink active) | false | . SID_LINK_TYPE_2 (SubG-FSK): . | Connection Attributes | Setting | . | Link status | Active | . | Keep connection with gateway | true | . | max connection attempt period in seconds | 60 | . SID_LINK_TYPE_3 (SubG-CSS): . | Connection Attributes | Setting | . | Link status | Active | . | max connection attempt period in seconds | 60 | . 3.3.3.3 SID_LINK_POLICY_OPTIMIZE_FOR_PERFORMANCE . Multi-link Policy: SID_LINK_POLICY_OPTIMIZE_FOR_PERFORMANCE . Description: This multi-link policy has the behavior to maximize throughput of the device. The stack attempts to keep at least one of the enabled links connected with the Amazon Sidewalk cloud service. The policy maintains the connected state even when no messages are enqueued. Message Reliability Parameters: . | Parameter | Bluetooth LE | SubG-FSK | SubG-CSS | . | Time to live in seconds | 60 | 120 | 120 | . | Retries | 1 | 1 | 1 | . | Transport acknowledgement requested | true | true | true | . Link Priority for Uplink: . | Link | Priority(lower value = high priority) | . | Bluetooth LE | 0 | . | SubG-FSK | 1 | . | SubG-CSS | 2 | . SID_LINK_TYPE_1 (Bluetooth LE): . | Connection Attributes | Setting | . | Link status | Enabled | . | max connection attempt period in seconds | 30 | . | Attempt to connect to gateway(uplink active) | true | . SID_LINK_TYPE_2 (SubG-FSK): . | Connection Attributes | Setting | . | Link status | Active | . | Keep connection with gateway | true | . | max connection attempt period in seconds | 60 | . SID_LINK_TYPE_3 (SubG-CSS): . | Connection Attributes | Setting | . | Link status | Active | . | max connection attempt period in seconds | 30 | . 3.3.3.4 SID_LINK_POLICY_OPTIMIZE_FOR_LATENCY . Multi-link Policy: SID_LINK_POLICY_OPTIMIZE_FOR_LATENCY . Description: This multi-link policy has the behavior to optimize the latency of the uplink messages. The period for which the stack attempts to form a successful connection with the Amazon Sidewalk cloud services is low when compared to other policies. Message Reliability Parameters: . | Parameter | Bluetooth LE | SubG-FSK | SubG-CSS | . | Time to live in seconds | 30 | 60 | 120 | . | Retries | 3 | 3 | 3 | . | Transport acknowledgement requested | true | true | true | . Link Priority for Uplink: . | Link | Priority(lower value = high priority) | . | Bluetooth LE | 0 | . | SubG-FSK | 1 | . | SubG-CSS | 2 | . SID_LINK_TYPE_1 (Bluetooth LE): . | Connection Attributes | Setting | . | Link status | Enabled | . | max connection attempt period in seconds | 15 | . | Attempt to connect to gateway(uplink active) | true | . SID_LINK_TYPE_2 (SubG-FSK): . | Connection Attributes | Setting | . | Link status | Active | . | Keep connection with gateway | true | . | max connection attempt period in seconds | 30 | . SID_LINK_TYPE_3 (SubG-CSS): . | Connection Attributes | Setting | . | Link status | Active | . | max connection attempt period in seconds | 60 | . 3.3.3.5 SID_LINK_POLICY_OPTIMIZE_FOR_RELIABILITY . Multi-link Policy: SID_LINK_POLICY_OPTIMIZE_FOR_RELIABILITY . Description: This multi-link policy has the policy to optimize for reliable sending of the messages. This policy has configuration that has higher message retries and time to live configured for each message. Message Reliability Parameters: . | Parameter | Bluetooth LE | SubG-FSK | SubG-CSS | . | Time to live in seconds | 30 | 120 | 240 | . | Retries | 5 | 5 | 5 | . | Transport acknowledgement requested | true | true | true | . Link Priority for Uplink: . | Link | Priority(lower value = high priority) | . | Bluetooth LE | 0 | . | SubG-FSK | 1 | . | SubG-CSS | 2 | . SID_LINK_TYPE_1 (Bluetooth LE): . | Connection Attributes | Setting | . | Link status | Enabled | . | max connection attempt period in seconds | 60 | . | Attempt to connect to gateway(uplink active) | false | . SID_LINK_TYPE_2 (SubG-FSK): . | Connection Attributes | Setting | . | Link status | Active | . | Keep connection with gateway | true | . | max connection attempt period in seconds | 60 | . SID_LINK_TYPE_3 (SubG-CSS): . | Connection Attributes | Setting | . | Link status | Active | . | max connection attempt period in seconds | 120 | . 3.3.3.6 Multi-link Connection Policy Algorithm . The following conditions are required to be met for the Sidewalk stack to trigger connection on a link. | The link is already started using the sid_start API. | The Sidewalk stack is already registered and time is acquired successfully | The link connection policy is configured to SID_LINK_CONNECTION_POLICY_MULTI_LINK_MANAGER. | The size of the message that is required to be transmitted is less than the MTU of the links that are started. | When the size of the messages that is required to be transmitted exceeds the MTU of the links that are started, the message is failed with SID_ERROR_NO_ROUTE_AVAILABLE by the sid_put_msg API. | The message transmission attributes (time to live, retries and ack requested) of the connected link are applied to messages enqueued with sid_put_msg API. | If more than one link is connected, the message transmission attributes of the link that has the higher throughput is applied to the message that is enqueued with sid_put_msg API. For example, If SID_LINK_TYPE_1 and SID_LINK_TYPE_2 are in connected state, the message transmission attributes of SID_LINK_TYPE_1 are applied for the enqueued message. | If no link is connected, the messages transmission attributes of the link that has the lowest throughput is applied to the message that is enqueued with sid_put_msg API. For example, if SID_LINK_TYPE_1, SID_LINK_TYPE_2 and SID_LINK_TYPE_3 are enabled, and all the links are in disconnected state, the message that is enqueued with sid_put_msg API assumes the message transmission attributes of SID_LINK_TYPE_3. | If a Sidewalk stack has at least one link in connected state and the connected link can send the message, the link auto connection policy algorithm does not get triggered as the connected link can successfully send the message. | The message uplink attributes as well the link_type in sid_msg_desc setting used by the developer is ignored and no validation checks are performed on these uplink message attributes. These attributes are applied based on the multi-link policy configuration set in the table below. | Multi-link policy functionality is enabled even when the Amazon Sidewalk stack is compiled with support for only one link or only when one link is initialized and started. When only one link is present, the multi-link policy manager will attempt connection only on the link which is enabled. | For multi-link connection policies which do not have support of background connection maintenance, when the connection cannot be established on any of the links the policy is enabled, the policy will progress through the links in the order of priority configured in the policy table multiple times until all the messages that are enqueued by the user have expired. When there are no messages in the end point Amazon Sidewalk stack’s send queue, the algorithm will stop attempting to establish connection with the Amazon Sidewalk network. | . The following examples are used to explain the behavior of the link auto connection policy algorithm. Example 1 . Example 1 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with all links. * At least one link is in connected state, SID_LINK_TYPE_3 is connected. * Link connection policy is set to multi-link policy is enabled and SID_LINK_MULTI_LINK_POLICY_ACTIVE is selected. * The payload of the message that is requested to be transmitted can be sent on all the three links. | The message transmission attributes viz, time to live, ack requested and retries are applied from SID_LINK_TYPE_3 message attributes of the SID_LINK_MULTI_LINK_POLICY_ ACTIVE. The multi-link connection policy does not attempt connection on any links as the link which is in connected state will send the message on the connected link. | . Example 2 . Example 2 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with all links. * No link is in connected state. * Link connection policy is set to multi-link policy is enabled and SID_LINK_MULTI_LINK_POLICY_ RELIABILITY is selected. * The payload of the message that is requested to be transmitted can be sent on all the three links. | The message transmission attributes viz, time to live, ack requested and retries are applied from SID_LINK_TYPE_3 message attributes of the SID_LINK_MULTI_LINK_POLICY_ RELIABILITY as no link are in connected state and the link with lowest throughput capacity is SID_LINK_TYPE_3. The multi-link connection policy starts attempting link connection for a period of connection timeout specified by the multi-policy for that link. During the course of connection attempts, if any of the link gets connected, the message is sent over the connected link. If any of the links do not get connected within the configured time to live setting in the multi-link policy’s message attributes setting or the message will be failed with SID_ERROR_TIMEOUT error code. | . Example 3 . Example 3 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with all links. * SID_LINK_TYPE_1 and SID_LINK_TYPE_2 are in connected state. * Link connection policy is set to multi-link policy is enabled and SID_LINK_MULTI_LINK_POLICY_ RELIABILITY is selected. * The payload of the message that is requested to be transmitted can be sent on all the three links. | The message transmission attributes viz, time to live, ack requested and retries are applied from SID_LINK_TYPE_1 message attributes of the SID_LINK_MULTI_LINK_POLICY_ RELIABILITY as SID_LINK_TYPE_1 and SID_LINK_TYPE_2 are in connected state and the link with highest throughput capacity is SID_LINK_TYPE_1. The multi-link connection policy does not attempt connection on any links as both SID_LINK_TYPE_1 and SID_LINK_TYPE_2 are in connected state and the message will be sent on SID_LINK_TYPE_1. | . Example 4 . Example 4 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with two links (SID_LINK_TYPE_1 | SID_LINK_TYPE_2). * No link is in connected state. * Link connection policy is set to multi-link policy is enabled and SID_LINK_MULTI_LINK_POLICY_POWER is selected. * The payload of the message that is requested to be transmitted can be sent on all the three links. | The message transmission attributes viz, time to live, ack requested and retries are applied from SID_LINK_TYPE_2 message attributes of the SID_LINK_MULTI_LINK_POLICY_ POWER as no link are in connected state and the link with lowest throughput capacity is SID_LINK_TYPE_2. The multi-link connection policy starts attempting link connection for a period of connection timeout specified by the multi-policy for that link. During the course of connection attempts, if any of the link gets connected, the message is sent over the connected link. If any of the links do not get connected within the configured time to live setting in the multi-link policy’s message attributes setting or the message will be failed with SID_ERROR_TIMEOUT error code. | . Example 5 . Example 5 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with only one link SID_LINK_TYPE_3. * No link is in connected state. * Link connection policy is set to multi-link policy is enabled and SID_LINK_MULTI_LINK_POLICY_ PERFORMANCE is selected. * The payload of the message that is requested to be transmitted cannot be transmitted on SID_LINK_TYPE_3. | The Sidewalk stack will not attempt connection as the developer has requested the message whose payload cannot be sent over the links that are started in this case SID_LINK_TYPE_3. The message will be immediately failed with error code SID_ERROR_NO_ROUTE_ AVAILABLE. | . Example 6 . Example 6 . | Conditions | Algorithm Operation | . | * Sidewalk stack initialized and started with only one link SID_LINK_TYPE_2. * No link is in connected state. * Link connection policy is set to multi-link policy is enabled and SID_LINK_MULTI_LINK_POLICY_LATENCY is selected. * The payload of the message that is requested to be transmitted can be transmitted on SID_LINK_TYPE_2. | The Sidewalk stack will attempt connection on SID_LINK_TYPE_2 as this is the only link that is started. If the link gets connected in the time period present in the messages’s uplink attributes, the message is sent successfully, or the message is failed with SID_ERROR_TIMEOUT error code. | . Background Connection Maintenance . When the stack is configured with multi link policies SID_LINK_POLICY_OPTIMIZE_FOR_LATENCY and SID_LINK_POLICY_OPTIMIZE_FOR_PERFORMANCE, the multi-link algorithm attempts on SID_LINK_TYPE_1 link keeps connection (uplink active) with the Sidewalk cloud services. This connection maintenance is achieved by updating the advertisement payload to connect. For other policies, the algorithm maintains the default behavior of the link connection policy. ", "url": "/app-notes/multi-link/overview-of-the-functionality.html#33-link-connection-policy", "relUrl": "/app-notes/multi-link/overview-of-the-functionality.html#33-link-connection-policy" },"699": { "doc": "3. Overview of the Functionality", "title": "3.4 Updates to sid_put_msg API", "content": "When the link connection policy is not configured either to SID_LINK_CONNECTION_POLICY_AUTO_CONNECT or SID_LINK_CONNECTION_POLICY_MULTI_LINK_MANAGER, the sid_put_msg will accept messages only when the Sidewalk stack is registered, time is acquired and at least one of the configured links that the Amazon Sidewalk stack is started with, is in connected state. When either of the connection policy is enabled, the sid_put_msg accepts messages even when Sidewalk stack is registered and time acquired. The links need not be in connected state for the sid_put_msg API to accept messages. The Amazon Sidewalk stack will queue this messages in its internal queue waiting on the connection policy algorithm to successfully establish a connection. It should be noted that the rate at which the messages are sent using sid_put_msg API should be dependent on the throughput capacity of the links on which the connection can be established. For example, the SID_LINK_TYPE_3 has a lower throughput for sending messages. Enqueuing messages at a rate faster than the link can successfully send messages will cause undefined behavior. ", "url": "/app-notes/multi-link/overview-of-the-functionality.html#34-updates-to-sid_put_msg-api", "relUrl": "/app-notes/multi-link/overview-of-the-functionality.html#34-updates-to-sid_put_msg-api" },"700": { "doc": "2. Overview", "title": "2. Overview", "content": "With ROW, a device leaves the factory already registered with the Amazon Sidewalk cloud. No mobile application, Sidewalk gateway or in-field registration step is required. The device performs field activation automatically the first time it contacts the Amazon Sidewalk network over the air. ROW uses the same cryptographic registration handshake as over-the-air registration. The difference is the transport: the sid-mfg-tool host tool running on the line PC relays the registration messages between the device (over UART or RTT) and the Amazon Sidewalk cloud (over HTTPS). ", "url": "/app-notes/registration-over-wire/overview.html", "relUrl": "/app-notes/registration-over-wire/overview.html" },"701": { "doc": "2. Overview", "title": "2.1 Registration over Wire and the existing mass production flow", "content": "ROW builds on the components of the existing mass production flow described in the Amazon Sidewalk Manufacturing documentation. The Device Attestation Key (DAK), the Hardware Security Module (HSM), the Advertised Product ID (APID), factory support for the device profile, control log onboarding in the Amazon FFS developer console, and the Factory Diagnostic Firmware certificate commands (cert init, cert smsn, cert csr, as shown in Step 2 of the Amazon Sidewalk Manufacturing documentation) are the same in both flows. The following table summarizes the differences. |   | Existing mass production flow | Registration over Wire | . | Host tooling | Sidewalk signing tool, driven by a line PC script implemented by the CM | sid-mfg-tool, which performs signing, control log upload, device creation and registration in one session | . | Control log upload | EDI or SFTP endpoint | api (per device, from the line PC) or sftp (batched) | . | Onboarding to AWS IoT Core for Amazon Sidewalk | Bulk provisioning with an import task, using the CSV of SMSNs | Per device (immediate) or bulk import task (bulk), performed by the tool | . | Registration | In the field, through a Sidewalk gateway, FFN or a mobile application using the Amazon Sidewalk Mobile SDK | On the factory line; the device performs field activation on first contact with the network | . | Production firmware | Full SDK variant with a BLE or FSK registration path | Full SDK variant (security-level-high) or lite, single-link SDK variant (security-level-low), including LoRa-only devices | . A device follows exactly one of these models. Do not mix the two flows on the same device. ", "url": "/app-notes/registration-over-wire/overview.html#21-registration-over-wire-and-the-existing-mass-production-flow", "relUrl": "/app-notes/registration-over-wire/overview.html#21-registration-over-wire-and-the-existing-mass-production-flow" },"702": { "doc": "2. Overview", "title": "2.2 Roles", "content": "The work is split across three roles. One person or organization may hold more than one role. | Role | Responsible for | Chapters | . | Device maker | One-time onboarding: control log onboarding, LWA security profile, scope allow-listing, AWS IoT Core for Amazon Sidewalk, HSM provisioning and factory support | Chapter 3 | . | Contract manufacturer (CM) line operator | Line PC setup, the per-device flow, and gating the factory line on the verification step | Chapter 4 and Chapter 5 | . | Firmware engineer | Factory Diagnostic Firmware and production firmware, including a matching security level and storage layout | Chapter 6 and Chapter 7 | . Chapter 3 includes requests to Amazon that carry external lead time. Start it at the beginning of the project, alongside the firmware bring-up (Section 2.3). ", "url": "/app-notes/registration-over-wire/overview.html#22-roles", "relUrl": "/app-notes/registration-over-wire/overview.html#22-roles" },"703": { "doc": "2. Overview", "title": "2.3 Bring-up sequence", "content": "Two tracks run in parallel and converge on the line PC: . | Track A: Amazon onboarding. Complete the onboarding in Chapter 3, including scope allow-listing and the APID. Purchase the YubiHSM 2 unit and ship it to Amazon. Amazon provisions the production DAK on the HSM and returns it, together with the DAK PIN. Start this track at the beginning of the project, because its requests to Amazon carry lead time. Track B runs alongside it. | Track B: Firmware bring-up. Build a Factory Diagnostic Firmware image with ROW support. The image is built for the host interface used on the line, UART or RTT (Section 6.1). Use the sid_diagnostics reference application where it exists for your platform, or your own Factory Diagnostic Firmware with ROW integrated as described in Chapter 6. | . flowchart TD subgraph A[\"Track A: Amazon onboarding (Chapter 3)\"] A1[\"Accounts, LWA security profile,\\nscope allow-listing,\\nAWS IoT Core for Amazon Sidewalk (3.1-3.4)\"] A2[\"Request factory support and\\nship the YubiHSM 2 unit to Amazon (3.5)\"] A3[\"Amazon links the APID,\\nprovisions the production DAK,\\nreturns the HSM and DAK PIN\"] A1 --> A2 --> A3 end subgraph B[\"Track B: Firmware bring-up (in parallel)\"] B1[\"Build Factory Diagnostic Firmware with ROW:\\nsid_diagnostics reference application,\\nor ROW integrated into your own firmware\"] end A3 -->|\"Provisioned HSM and DAK PIN\"| WS[\"Line PC setup (Chapter 4)\"] WS --> PD[\"Per-device flow (Chapter 5):\\nflash, onboard, verify\"] B1 -->|\"Factory Diagnostic Firmware image\"| PD B1 ~~~ A2 . Figure 1: Registration over Wire bring-up sequence . ", "url": "/app-notes/registration-over-wire/overview.html#23-bring-up-sequence", "relUrl": "/app-notes/registration-over-wire/overview.html#23-bring-up-sequence" },"704": { "doc": "1. Overview", "title": "1. Overview", "content": " ", "url": "/app-notes/location-library/overview.html", "relUrl": "/app-notes/location-library/overview.html" },"705": { "doc": "1. Overview", "title": "1.1 Introduction", "content": "The Amazon Sidewalk Location Library enables Sidewalk customers to use a range of cloud-based location solvers. Available in SDK >= 1.19, this library provides an API that automatically selects the most power- and time-efficient location mechanism based on available hardware and network conditions. Developers will also have finer-grained control to configure and override the mechanism used to determine location as required. ", "url": "/app-notes/location-library/overview.html#11-introduction", "relUrl": "/app-notes/location-library/overview.html#11-introduction" },"706": { "doc": "1. Overview", "title": "1.2 Supported Location Methods", "content": "The location library supports three types of location resolution methods: . | Sidewalk Network Location over BLE — Leverages existing BLE connections to determine location through the Sidewalk network. | WiFi Scan — Scans for nearby WiFi access points and sends MAC addresses to the cloud for location resolution. | GNSS Scan — Uses Global Navigation Satellite System to collect satellite vehicle data for coordinate resolution. | . These methods are supported on two available link types: . | BLE (Bluetooth Low Energy) | LoRa (Long Range) | . FSK with WiFi/GNSS scanning enabled is not currently supported. WiFi and GNSS scanning leverage the Semtech LoRa Basics Modem middleware to manage and conduct scans on the device. ", "url": "/app-notes/location-library/overview.html#12-supported-location-methods", "relUrl": "/app-notes/location-library/overview.html#12-supported-location-methods" },"707": { "doc": "1. Overview", "title": "1.3 Location Levels", "content": "Location levels are ordered by lowest effort first (power consumption and time) and are defined by the available hardware on the device. The library automatically steps down through levels at configurable timeouts. 1.3.1 Level 1: Connected to Sidewalk via BLE . | Power Consumption: No additional power draw. | Description: If the device can be located via BLE over the Sidewalk network, the device notifies the cloud to resolve the location with no further effort. If the device is not connected via BLE or location cannot be resolved, the next level is attempted. | . 1.3.2 Level 2: LoRa Location Trigger . | Power Consumption: Low power consumption. | Description: Sends a location trigger over LoRa (Link Type 3) to the cloud for location resolution. Requires the LoRa link to be network synced. This level is used when the device is not connected via BLE but has an active LoRa connection. | . 1.3.3 Level 3: Send WiFi Scan . | Power Consumption: Low power consumption. | Description: Conduct and send a WiFi scan. A minimum of 1 AP must be found in the scan or the next level will be attempted. If the cloud receives a low confidence score or no resolution is found, the device application must be notified to increment and try the next level. | . 1.3.4 Level 4: Send GNSS Scan . | Power Consumption: Higher power consumption than WiFi scanning. | Description: Conduct and send a GNSS scan. A minimum of 4 Satellite Vehicles must be found for the scan to be valid. | . ", "url": "/app-notes/location-library/overview.html#13-location-levels", "relUrl": "/app-notes/location-library/overview.html#13-location-levels" },"708": { "doc": "1. Overview", "title": "1.4 Architecture", "content": "The library provides a single interface for application developers to consume APIs for uplinking location data. WiFi and GNSS have corresponding Platform Abstraction Layers (PALs) that are required when these features are enabled. ", "url": "/app-notes/location-library/overview.html#14-architecture", "relUrl": "/app-notes/location-library/overview.html#14-architecture" },"709": { "doc": "7.1 Overview", "title": "7.1 Overview", "content": "7.1.1 Purpose and Benefits . Sidewalk Bulk Data Transfer (SBDT) is a foundational software feature designed to support the end-to-end Amazon Sidewalk network architecture for large data transfer to Sidewalk devices. One of the main benefits of the feature is to allow for the operational maintenance and enhancement of Sidewalk devices, however applications are not limited to Over-the-air (OTA) firmware update and SBDT can be used to deliver other file types as well. A key application of SBDT is enabling developers to remotely deploy new firmware versions onto their devices within the Sidewalk network. This capability is not just a convenience; it’s a strategic feature that expands Sidewalk’s functionality and network accessibility. With SBDT, file transfers can occur over the Sidewalk network, directly to the end devices, without customer interventions. The incorporation of OTA updates within Sidewalk-connected devices brings multiple advantages, including enhanced security compliance and compliance to keep the devices up-to-date with the latest firmware while extending their lifecycle and capabilities, cost-efficiency in maintenance from remote operation, and rapid prototyping to introduce a new firmware to their Sidewalk devices. This initial phase will focus on the fundamental capability to update devices individually, a critical step in establishing the framework’s effectiveness. However, this phase will also have its limitations, including one device updating support at a time, no integration with AWS IoT fleet management configuration, and no handling of corner cases, such as recovery from power failures, network interruptions, or cancellations. Another benefit of the file transfer feature is that it can be used for configuration/setting download which provide the ability to change device behavior. ", "url": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/overview.html", "relUrl": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/overview.html" },"710": { "doc": "1. Overview", "title": "1. Overview", "content": "The Amazon Sidewalk network connects Endpoints to Amazon Sidewalk Cloud servers. The Endpoints connect through Amazon Sidewalk Gateways. Gateways and Endpoints communicate using the Amazon Sidewalk protocol. The Amazon Sidewalk protocol can be carried across the following radios: . | Amazon Sidewalk SubG, referred to as SubG-FSK | The LoRa ® radio, referred to as SubG-CSS | Bluetooth ® Low Energy, referred to as BLE | . Amazon Sidewalk supports synchronous and asynchronous connection modes. In synchronous mode, the Endpoint must synchronize with a single Gateway before communicating through that Gateway. In asynchronous mode, an Endpoint transmits messages, which can be received by multiple Gateways. Amazon Sidewalk Endpoints must register with the Amazon Sidewalk network before they can begin communicating. Registration requires keys that are built into the Endpoint at the time of manufacture. Amazon Sidewalk Endpoints and Gateways communicate using frames. Frames can carry commands to control the connection, or data to communicate with the Amazon Sidewalk Cloud server. Endpoints that are not actively communicating with Gateways can enter a low power mode. Power Profiles are used to manage low power behavior. ", "url": "/specifications/sidewalk-protocol-spec/overview.html", "relUrl": "/specifications/sidewalk-protocol-spec/overview.html" },"711": { "doc": "1. Overview", "title": "1.1 Scope", "content": "This document defines the wireless protocol used by Endpoints in the Amazon Sidewalk network. This document covers the following: . | Protocol stack layers | The SubG-FSK radio | Interactions between Endpoints and other elements of the system (commands and procedures) | Power Profiles | Security | Architecture | Frame formats and detailed descriptions of frame fields | . This document does not include the following: . | Detailed specification of Gateways and the Amazon Sidewalk Cloud | Interactions between Gateways and the Amazon Sidewalk Cloud | . ", "url": "/specifications/sidewalk-protocol-spec/overview.html#11-scope", "relUrl": "/specifications/sidewalk-protocol-spec/overview.html#11-scope" },"712": { "doc": "5. Per-Device Flow", "title": "5. Per-Device Flow", "content": " ", "url": "/app-notes/registration-over-wire/per-device-flow.html", "relUrl": "/app-notes/registration-over-wire/per-device-flow.html" },"713": { "doc": "5. Per-Device Flow", "title": "5.1 Flash and onboard the device", "content": "Flash the Factory Diagnostic Firmware with ROW support (Section 6.1) onto the device under test (DUT) and connect it to the line PC through the host interface the image was built for: the UART of the device, or a J-Link debug probe for RTT. Then run the command for that interface: . # UART sid-mfg-tool device onboard \\ --transport uart --address /dev/ttyUSB0 \\ --dsn <DSN> # RTT through a J-Link probe sid-mfg-tool device onboard \\ --transport rtt --address <J-Link probe serial number> \\ --dsn <DSN> . For UART, --address is the serial port of the device, for example /dev/ttyUSB0 on Linux or COM3 on Windows. For RTT, --address is the serial number of the J-Link probe, which is the on-board J-Link of a development kit or an external probe, and the J-Link device name of the MCU must be set in the tool configuration (Chapter 4). A J-Link probe serves one host program at a time: close J-Link RTT Viewer, J-Link Commander, RTT Logger and Simplicity Studio before running the tool. --transport can be omitted when the default transport was set with configure. The optional --log-level info|warning|error argument controls the tool output. The stages can also be run separately: device provision ... prints the SMSN, and device register ... reads the stored SMSN back from the device. The SMSN is derived from the DeviceTypeId, the DSN and the APID (SMSN = SHA-256(DeviceTypeId, DSN, APID)), and identifies the wireless device record in AWS IoT Core for Amazon Sidewalk. The device maker must not re-use an SMSN that has already been used. Because the DeviceTypeId and the APID are fixed for a product, this means that every unit needs a DSN that has not been used before. A second unit with the same DSN fails at device creation, because a device with that SMSN already exists in the AWS account. Retrying the same unit is safe. Reset the device, then run device register. The tool reads the stored SMSN from the device and does not create the record again. ", "url": "/app-notes/registration-over-wire/per-device-flow.html#51-flash-and-onboard-the-device", "relUrl": "/app-notes/registration-over-wire/per-device-flow.html#51-flash-and-onboard-the-device" },"714": { "doc": "5. Per-Device Flow", "title": "5.2 Verify registration", "content": "Gate the factory line on the following checks: . | The tool reports Device registered over the wire. | As a cloud spot check, the following command returns Sidewalk.Status: REGISTERED: | . aws iotwireless get-wireless-device \\ --identifier-type SidewalkManufacturingSn --identifier <SMSN> . ", "url": "/app-notes/registration-over-wire/per-device-flow.html#52-verify-registration", "relUrl": "/app-notes/registration-over-wire/per-device-flow.html#52-verify-registration" },"715": { "doc": "5. Per-Device Flow", "title": "5.3 After registration", "content": "After a device is registered, the device maker is responsible for the following: . | Flash production firmware that matches the registration configuration, meaning the SDK variant that corresponds to the configured security level (Section 7.1). At security-level-high, the reflash must not erase the KV store (program-only flash). At security-level-low, a reflash that erases the KV store is supported at this point. | Re-register any device that failed registration before shipment. A device that failed registration does not perform field activation, and lite-variant firmware fails sid_init on an unregistered device. | . Devices that are not factory-registered follow the existing mass production flow: they are provisioned only, and the end user registers them in the field through a mobile application, FFN or a Sidewalk gateway. These devices need full-variant firmware with a BLE or FSK registration path. Registration over LoRa is not supported. ", "url": "/app-notes/registration-over-wire/per-device-flow.html#53-after-registration", "relUrl": "/app-notes/registration-over-wire/per-device-flow.html#53-after-registration" },"716": { "doc": "14. Power Optimization Test Cases", "title": "14. Power Optimization Test Cases", "content": " ", "url": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html", "relUrl": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html" },"717": { "doc": "14. Power Optimization Test Cases", "title": "14.1 FSK/EP/PWR/OPT/BV/01: Verify RX duration can be adjusted.", "content": "14.1.1 Test Purpose . DUT FSK RX duration can be adjusted. 14.1.2 Initial Conditions . | DUT is registered on Amazon Sidewalk Network. | Lower Tester acts a Sidewalk gateway and cloud. | Upper Tester operates as a SID API user. | DUT Set FSK Profile 2 command: sid option -lp_set SID_LINK2_PROFILE_2 RX_INTERVAL_IN_MS BEACON_INTERVAL RX_DURATION_IN_S . | . 14.1.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid option -lp_set 2 630 1 6 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 2, FSK Connected\" Note over Lower_Tester,Upper_Tester: After 30 seconds, start a timer T = 0s Upper_Tester->>DUT: T = 0s, sid send test Lower_Tester->>DUT: T <= 5s, Send a downlink DUT->>Upper_Tester: Receive a downlink Lower_Tester->>DUT: T >= 7s, Send a downlink DUT->>Upper_Tester: Does not receive a downlink as expected . 14.1.4 Expected Results . 14.1.4.1 Pass Verdict . The RX window remains open for 6.63 (RX duration + RX window interval) seconds. ", "url": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#141-fskeppwroptbv01-verify-rx-duration-can-be-adjusted", "relUrl": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#141-fskeppwroptbv01-verify-rx-duration-can-be-adjusted" },"718": { "doc": "14. Power Optimization Test Cases", "title": "14.2 FSK/EP/PWR/OPT/BV/02: Verify RX windows after control message sent should not be closed.", "content": "14.2.1 Test Purpose . The RX windows after sending control messages (time-sync and join) should not be overridden by user settings. The RX windows should remain open until the response to the control message is received. 14.2.2 Initial Conditions . | DUT is registered on Amazon Sidewalk Network. | Lower Tester acts a Sidewalk gateway and cloud. | Upper Tester operates as a SID API user. | DUT Set FSK Profile 2 command: sid option -lp_set SID_LINK2_PROFILE_2 RX_INTERVAL_IN_MS BEACON_INTERVAL RX_DURATION_IN_S . | . 14.2.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid option -lp_set 2 5040 1 6 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE Lower_Tester->>DUT: After GW discover prcoess finish, disable GW Wi-Fi Note over Lower_Tester,Upper_Tester: Before 3rd time-sync request sent, enable GW Wi-Fi DUT->>Lower_Tester: EN sent 3rd time-sync request DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 0, FSK not Connected\" Lower_Tester->>DUT: After EN time-synced, disable GW Wi-Fi Note over Lower_Tester,Upper_Tester: Before 3rd join request sent, enable GW Wi-Fi DUT->>Lower_Tester: EN sent 3rd join request DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 2, FSK Connected\" Note over Lower_Tester,Upper_Tester: Wait for 30 seconds Lower_Tester->>DUT: Send a downlink DUT->>Upper_Tester: Does not receive a downlink as expected . 14.2.4 Expected Results . 14.2.4.1 Pass Verdict . Control messages (time-sync and join) are not affected by user config and can be sent and received normally. ", "url": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#142-fskeppwroptbv02-verify-rx-windows-after-control-message-sent-should-not-be-closed", "relUrl": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#142-fskeppwroptbv02-verify-rx-windows-after-control-message-sent-should-not-be-closed" },"719": { "doc": "14. Power Optimization Test Cases", "title": "14.3 FSK/EP/PWR/OPT/BV/03: Verify RX window termination request stop RX window opened at profile 2.", "content": "14.3.1 Test Purpose . Users can close the DUT RX windows at any time using the RX window termination command . 14.3.2 Initial Conditions . | DUT is registered on Amazon Sidewalk Network. | Lower Tester acts a Sidewalk gateway and cloud. | Upper Tester operates as a SID API user. | DUT Set FSK Profile 2 command: sid option -lp_set SID_LINK2_PROFILE_2 RX_INTERVAL_IN_MS BEACON_INTERVAL RX_DURATION_IN_S . | DUT User control commands with sub-ghz: sid option -sub_ghz_ctl CTL_CMD . | . 14.3.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid option -lp_set 2 630 1 20 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 2, FSK Connected\" Note over Lower_Tester,Upper_Tester: After 30 seconds, start a timer T = 0s Upper_Tester->>DUT: T = 0s, sid send test Lower_Tester->>DUT: T <= 5s, Send a downlink DUT->>Upper_Tester: Receive a downlink Upper_Tester->>DUT: T = 8s, sid option -sub_ghz 1 Lower_Tester->>DUT: T = 10s, Send a downlink DUT->>Upper_Tester: Does not receive a downlink as expected . 14.3.4 Expected Results . 14.3.4.1 Pass Verdict . There is no RX window opening after RX window termination command executed. ", "url": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#143-fskeppwroptbv03-verify-rx-window-termination-request-stop-rx-window-opened-at-profile-2", "relUrl": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#143-fskeppwroptbv03-verify-rx-window-termination-request-stop-rx-window-opened-at-profile-2" },"720": { "doc": "14. Power Optimization Test Cases", "title": "14.4 FSK/EP/PWR/OPT/BV/04: Verify RX window termination request should not stop RX window opened at profile 1.", "content": "14.4.1 Test Purpose . As profile 1 default setting is unlimited RX duration, the RX window termination command should not interrupt or close RX windows. 14.4.2 Initial Conditions . | DUT is registered on Amazon Sidewalk Network. | Lower Tester acts a Sidewalk gateway and cloud. | Upper Tester operates as a SID API user. | DUT Set FSK Profile 1 command: sid option -lp_set SID_LINK2_PROFILE_1 BEACON_INTERVAL . | DUT User control commands with sub-ghz: sid option -sub_ghz_ctl CTL_CMD . | . 14.4.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid option -lp_set 1 1 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 2, FSK Connected\" Note over Lower_Tester,Upper_Tester: Wait for 30 seconds Lower_Tester->>DUT: Send a downlink DUT->>Upper_Tester: Receive a downlink Upper_Tester->>DUT: sid option -sub_ghz 1 Lower_Tester->>DUT: Send a downlink DUT->>Upper_Tester: Receive a downlink . 14.4.4 Expected Results . 14.4.4.1 Pass Verdict . RX window termination command should not interrupt or close RX windows. ", "url": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#144-fskeppwroptbv04-verify-rx-window-termination-request-should-not-stop-rx-window-opened-at-profile-1", "relUrl": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#144-fskeppwroptbv04-verify-rx-window-termination-request-should-not-stop-rx-window-opened-at-profile-1" },"721": { "doc": "14. Power Optimization Test Cases", "title": "14.5 FSK/EP/PWR/OPT/BV/05: Verify Beacon interval can be adjusted.", "content": "14.5.1 Test Purpose . Users can modify the number of beacons to skip. 14.5.2 Initial Conditions . | DUT is registered on Amazon Sidewalk Network. | Lower Tester acts a Sidewalk gateway and cloud. | Upper Tester operates as a SID API user. | DUT Set FSK Profile 1 command: sid option -lp_set SID_LINK2_PROFILE_1 BEACON_INTERVAL . | DUT Set FSK Profile 2 command: sid option -lp_set SID_LINK2_PROFILE_2 RX_INTERVAL_IN_MS BEACON_INTERVAL RX_DURATION_IN_S . | . 14.5.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid option -lp_set 2 5040 3 0 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 2, FSK Connected\" DUT->>Upper_Tester: Receive a beacon DUT->>Upper_Tester: Receive a beacon DUT->>Upper_Tester: Receive a beacon Note over Lower_Tester,Upper_Tester: Check beacon interval is 3 * 10080 ms Note over Lower_Tester,Upper_Tester: Repeat the above steps, iterating through sid option -lp_set 2 5040 2 0 (beacon interval = 2 * 10080 ms), sid option -lp_set 2 5040 1 0 (1 * 10080 ms), sid option -lp_set 1 3 (3 * 10080 ms), sid option -lp_set 1 2 (2 * 10080 ms), sid option -lp_set 1 1 (1 * 10080 ms) . 14.5.4 Expected Results . 14.5.4.1 Pass Verdict . Beacon interval can be modified by user setting. ", "url": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#145-fskeppwroptbv05-verify-beacon-interval-can-be-adjusted", "relUrl": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#145-fskeppwroptbv05-verify-beacon-interval-can-be-adjusted" },"722": { "doc": "14. Power Optimization Test Cases", "title": "14.6 FSK/EP/PWR/OPT/BV/06: Verify beacon interval revert to default after 2nd beacon misses.", "content": "14.6.1 Test Purpose . To prevent gateway beacon loss, DUT beacon interval will revert to default (10080 ms) after two consecutive beacon misses . 14.6.2 Initial Conditions . | DUT is registered on Amazon Sidewalk Network. | Lower Tester acts a Sidewalk gateway and cloud. | Upper Tester operates as a SID API user. | DUT Set FSK Profile 2 command: sid option -lp_set SID_LINK2_PROFILE_2 RX_INTERVAL_IN_MS BEACON_INTERVAL RX_DURATION_IN_S . | Sidewalk gateway put in a shielding box. | . 14.6.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid option -lp_set 2 5040 3 0 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 2, FSK Connected\" DUT->>Upper_Tester: Receive a beacon, start a timer T = 0s Note over Lower_Tester,Upper_Tester: Close the shielding box door DUT->>Upper_Tester: T = 30s, miss a beacon DUT->>Upper_Tester: T = 60s, miss a beacon Note over Lower_Tester,Upper_Tester: Open the shielding box door DUT->>Upper_Tester: T = 70s, receive a beacon DUT->>Upper_Tester: T = 100s, receive a beacon Note over Lower_Tester,Upper_Tester: Change DUT profile by sid option -lp_set 2 5040 2 0, repeat above steps. Expected behavior is T = 0s receive a beacon, T = 20s miss a beacon, T = 40s miss a beacon, T = 50s receive a beacon, T = 70s receive a beacon . 14.6.4 Expected Results . 14.6.4.1 Pass Verdict . When the DUT misses two beacons, it triggers a default interval beacon. Upon receiving this beacon, the Beacon interval should be restored to the user-configured setting. ", "url": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#146-fskeppwroptbv06-verify-beacon-interval-revert-to-default-after-2nd-beacon-misses", "relUrl": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#146-fskeppwroptbv06-verify-beacon-interval-revert-to-default-after-2nd-beacon-misses" },"723": { "doc": "14. Power Optimization Test Cases", "title": "14.7 FSK/EP/PWR/OPT/BV/07: Verify DUT can still perform uplinks and downlinks normally after a beacon skipped.", "content": "14.7.1 Test Purpose . After DUT skip a beacon, there will be some time drift, but a compensation mechanism allows TX/RX to maintain normal transmission and reception . 14.7.2 Initial Conditions . | DUT is registered on Amazon Sidewalk Network. | Lower Tester acts a Sidewalk gateway and cloud. | Upper Tester operates as a SID API user. | DUT Set FSK Profile 2 command: sid option -lp_set SID_LINK2_PROFILE_2 RX_INTERVAL_IN_MS BEACON_INTERVAL RX_DURATION_IN_S . | . 14.7.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_2) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid option -lp_set 2 630 3 8 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 2, FSK Connected\" DUT->>Upper_Tester: Receive a beacon, start a timer T = 0s Upper_Tester->>DUT: T = 11s, sid send -a 1 1 10 TEST DUT->>Lower_Tester: A uplink sent Lower_Tester->>DUT: Response an ACK DUT->>Upper_Tester: Receive an ACK Upper_Tester->>DUT: T = 22s, sid send -a 1 1 10 TEST DUT->>Lower_Tester: A uplink sent Lower_Tester->>DUT: Response an ACK DUT->>Upper_Tester: Receive an ACK . 14.7.4 Expected Results . 14.7.4.1 Pass Verdict . Even during the beacon skip phase, uplinks and downlinks can operate normally. ", "url": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#147-fskeppwroptbv07-verify-dut-can-still-perform-uplinks-and-downlinks-normally-after-a-beacon-skipped", "relUrl": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#147-fskeppwroptbv07-verify-dut-can-still-perform-uplinks-and-downlinks-normally-after-a-beacon-skipped" },"724": { "doc": "14. Power Optimization Test Cases", "title": "14.8 LORA/EP/PWR/OPT/BV/01: Verify number of RX windows is limited and can be changed.", "content": "14.8.1 Test Purpose . At profile A, after single transmission in an uplink, DUT should open specified number of RX windows and go to sleep. 14.8.2 Initial Conditions . | DUT is registered on Amazon Sidewalk Network. | Lower Tester acts a Sidewalk gateway and cloud. | Upper Tester operates as a SID API user. | DUT Set LoRa Profile A command: sid option -lp_set SID_LINK3_PROFILE_A RX_WINDOWS . | . 14.8.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid option -lp_set 128 2 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 4, LoRa Connected\" Note over Lower_Tester,Upper_Tester: Wait for 30 seconds Upper_Tester->>DUT: sid send test, start a timer = 0s Lower_Tester->>DUT: T = 3s, send a downlink DUT->>Upper_Tester: Receive a downlink Lower_Tester->>DUT: T = 15s, send a downlink DUT->>Upper_Tester: Does not receive a downlink as expected Note over Lower_Tester,Upper_Tester: Change DUT profile by sid option -lp_set 128 60, repeat above steps. Expected behavior is T = 0s send an uplink, T = 3s send a downlink (expect received), T = 293s send a downlink (expect received), T = 305s send a downlink (expect no downlink received) . 14.8.4 Expected Results . 14.8.4.1 Pass Verdict . The RX windows can be adjusted by user setting. ", "url": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#148-loraeppwroptbv01-verify-number-of-rx-windows-is-limited-and-can-be-changed", "relUrl": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#148-loraeppwroptbv01-verify-number-of-rx-windows-is-limited-and-can-be-changed" },"725": { "doc": "14. Power Optimization Test Cases", "title": "14.9 LORA/EP/PWR/OPT/BV/02: Verify number of RX windows is reset after sending an additional uplink.", "content": "14.9.1 Test Purpose . At profile A, when TX occurs before all RX windows have been opened, then windows counter should be reset again. 14.9.2 Initial Conditions . | DUT is registered on Amazon Sidewalk Network. | Lower Tester acts a Sidewalk gateway and cloud. | Upper Tester operates as a SID API user. | DUT Set LoRa Profile A command: sid option -lp_set SID_LINK3_PROFILE_A RX_WINDOWS . | . 14.9.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid option -lp_set 128 30 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 4, LoRa Connected\" Note over Lower_Tester,Upper_Tester: Wait for 30 seconds Upper_Tester->>DUT: sid send test, start a timer = 0s Lower_Tester->>DUT: T = 73s, send a downlink DUT->>Upper_Tester: Receive a downlink Upper_Tester->>DUT: T = 80s, sid send test Lower_Tester->>DUT: T = 222s, send a downlink DUT->>Upper_Tester: Receive a downlink . 14.9.4 Expected Results . 14.9.4.1 Pass Verdict . The RX windows counter is reset by an uplink sent . ", "url": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#149-loraeppwroptbv02-verify-number-of-rx-windows-is-reset-after-sending-an-additional-uplink", "relUrl": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#149-loraeppwroptbv02-verify-number-of-rx-windows-is-reset-after-sending-an-additional-uplink" },"726": { "doc": "14. Power Optimization Test Cases", "title": "14.10 LORA/EP/PWR/OPT/BV/03: Verify RX window termination request stop RX window opened at profile A.", "content": "14.10.1 Test Purpose . Users can close the DUT RX windows at any time using the RX window termination command . 14.10.2 Initial Conditions . | DUT is registered on Amazon Sidewalk Network. | Lower Tester acts a Sidewalk gateway and cloud. | Upper Tester operates as a SID API user. | DUT Set LoRa Profile A command: sid option -lp_set SID_LINK3_PROFILE_A RX_WINDOWS . | DUT User control commands with sub-ghz: sid option -sub_ghz_ctl CTL_CMD . | . 14.10.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid option -lp_set 128 10 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 4, LoRa Connected\" Note over Lower_Tester,Upper_Tester: Wait for 30 seconds Upper_Tester->>DUT: sid send test, start a timer = 0s Lower_Tester->>DUT: T = 3s, send a downlink DUT->>Upper_Tester: Receive a downlink Upper_Tester->>DUT: sid option -sub_ghz 1 Lower_Tester->>DUT: T = 18s, send a downlink DUT->>Upper_Tester: Does not receive a downlink as expected . 14.10.4 Expected Results . 14.10.4.1 Pass Verdict . There is no RX window opening after RX window termination command executed. ", "url": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#1410-loraeppwroptbv03-verify-rx-window-termination-request-stop-rx-window-opened-at-profile-a", "relUrl": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#1410-loraeppwroptbv03-verify-rx-window-termination-request-stop-rx-window-opened-at-profile-a" },"727": { "doc": "14. Power Optimization Test Cases", "title": "14.11 LORA/EP/PWR/OPT/BV/04: Verify RX window termination request should not stop RX window opened at profile B.", "content": "14.11.1 Test Purpose . As profile B default setting is unlimited RX window count, the RX window termination command should not interrupt or close RX windows. 14.11.2 Initial Conditions . | DUT is registered on Amazon Sidewalk Network. | Lower Tester acts a Sidewalk gateway and cloud. | Upper Tester operates as a SID API user. | DUT Set LoRa Profile B command: sid option -lp_set SID_LINK3_PROFILE_B RX_WINDOWS . | DUT User control commands with sub-ghz: sid option -sub_ghz_ctl CTL_CMD . | . 14.11.3 Test Procedure . sequenceDiagram participant Lower_Tester as Lower Tester participant DUT as DUT participant Upper_Tester as Upper Tester Note over Lower_Tester,Upper_Tester: The Sidewalk stack is uninitialized Upper_Tester->>DUT: sid init(SID_LINK_TYPE_3) DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid option -lp_set 129 0 DUT->>Upper_Tester: #35;SID_ERROR_NONE Upper_Tester->>DUT: sid start DUT->>Upper_Tester: #35;SID_ERROR_NONE DUT->>Upper_Tester: on_status_changed() \"Status: Registered, Time Synced, Link Mask 4, LoRa Connected\" Note over Lower_Tester,Upper_Tester: Wait for 30 seconds Upper_Tester->>DUT: sid send test, start a timer = 0s Lower_Tester->>DUT: T = 3s, send a downlink DUT->>Upper_Tester: Receive a downlink Upper_Tester->>DUT: sid option -sub_ghz 1 Lower_Tester->>DUT: T = 18s, send a downlink DUT->>Upper_Tester: Receive a downlink . 14.11.4 Expected Results . 14.11.4.1 Pass Verdict . RX window termination command should not interrupt or close RX windows. ", "url": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#1411-loraeppwroptbv04-verify-rx-window-termination-request-should-not-stop-rx-window-opened-at-profile-b", "relUrl": "/specifications/sidewalk-test-spec/power-optimization-test-cases.html#1411-loraeppwroptbv04-verify-rx-window-termination-request-should-not-stop-rx-window-opened-at-profile-b" },"728": { "doc": "13. Power Optimization Test Cases", "title": "Power Optimization Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#power-optimization-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#power-optimization-test-cases" },"729": { "doc": "13. Power Optimization Test Cases", "title": "Test Case ID: FSK/EP/PWR/OPT/BV/01: Verify RX duration can be adjusted", "content": "| Field | Value | . | Case ID | C103619364 | . | Executable by Customer | Yes | . Preconditions . | GW and EP should be flashed with debug variant build | EP is registered in Sidewalk network | GW is properly communicating with the Cloud | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize FSK stack with power optimization profile (rx_duration=6s):sid init 2sid option -lp_set 2 630 1 6sid startWait for time sync and join | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2Njoin(1, 2) st 2->6Key check: EN joined via FSK | . | 2 | Wait 30 seconds for RX windows to close | No RX window opening eventKey check: RX windows closed after idle period | . | 3 | Wait for beacon received, then send UL (T=0s):sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 2Key check: UL sent, T=0 | . | 4 | T < 5s: Send DL from cloud to EN | EVENT SID RECEIVED: TYPE: 3, ..., LINK: 2Key check: DL received within RX duration window | . | 5 | Wait until T >= 7s, then send DL from cloud to EN | No DL receivedKey check: DL not received after RX duration expired (rx_duration=6s + rx_window_interval=0.63s) | . ", "url": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv01-verify-rx-duration-can-be-adjusted", "relUrl": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv01-verify-rx-duration-can-be-adjusted" },"730": { "doc": "13. Power Optimization Test Cases", "title": "Test Case ID: FSK/EP/PWR/OPT/BV/02: Verify RX windows after control message sent should not be closed", "content": "| Field | Value | . | Case ID | C103619365 | . | Executable by Customer | Yes | . Preconditions . | GW and EP should be flashed with debug variant build | EP is registered in Sidewalk network | GW is properly communicating with the Cloud | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize FSK stack with power optimization profile:sid init 2sid option -lp_set 2 5040 1 6sid startWait for GWD scan to complete, then disable GW Wi-Fi | GWD(<n>) st <n>->6Key check: GWD finished, GW Wi-Fi disabled | . | 2 | Wait for 2 time-sync requests from EN, then enable GW Wi-Fi | [Tx][0:108:0:<n>] (2 times)Key check: GW Wi-Fi re-enabled before 3rd time-sync request | . | 3 | Wait for time-sync response, then disable GW Wi-Fi | [Rx][0:108:3:<n>]Key check: EN time-synced, GW Wi-Fi disabled again | . | 4 | Wait for 2 join requests from EN, then enable GW Wi-Fi | [Tx][0:22F:1:<n>] (2 times)Key check: GW Wi-Fi re-enabled before 3rd join request | . | 5 | Wait for join response | [Rx][0:22F:3:<n>]Njoin(1, 2) st 2->6Key check: EN joined | . | 6 | Wait 30 seconds, then send DL from cloud to EN | No EVENT SID RECEIVED logKey check: RX windows closed after 30s idle, DL not received | . ", "url": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv02-verify-rx-windows-after-control-message-sent-should-not-be-closed", "relUrl": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv02-verify-rx-windows-after-control-message-sent-should-not-be-closed" },"731": { "doc": "13. Power Optimization Test Cases", "title": "Test Case ID: FSK/EP/PWR/OPT/BV/03: Verify RX window termination request stops RX window opened at profile 2", "content": "| Field | Value | . | Case ID | C103619366 | . | Executable by Customer | Yes | . Preconditions . | GW and EP should be flashed with debug variant build | EP is registered in Sidewalk network | GW is properly communicating with the Cloud | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize FSK stack with power optimization profile (rx_duration=20s):sid init 2sid option -lp_set 2 630 1 20sid startWait for time sync and join | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2Njoin(1, 2) st 2->6Key check: EN joined via FSK | . | 2 | Wait 30 seconds for RX windows to close | No RX window opening eventKey check: RX windows closed | . | 3 | Send UL (T=0s):sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 2Key check: UL sent, T=0 | . | 4 | T < 5s: Send DL from cloud to EN | EVENT SID RECEIVED: TYPE: 3, ..., LINK: 2Key check: DL received within RX duration window | . | 5 | Execute RX terminate command:sid option -sub_ghz_ctl 1 | CMD: ERR: 0Key check: RX windows terminated | . | 6 | T = 10s: Send DL from cloud to EN | No EVENT SID RECEIVED logKey check: DL not received, RX windows already terminated | . ", "url": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv03-verify-rx-window-termination-request-stops-rx-window-opened-at-profile-2", "relUrl": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv03-verify-rx-window-termination-request-stops-rx-window-opened-at-profile-2" },"732": { "doc": "13. Power Optimization Test Cases", "title": "Test Case ID: FSK/EP/PWR/OPT/BV/04: Verify RX window termination request should not stop RX window opened at profile 1", "content": "| Field | Value | . | Case ID | C103619367 | . | Executable by Customer | Yes | . Preconditions . | GW and EP should be flashed with debug variant build | EP is registered in Sidewalk network | GW is properly communicating with the Cloud | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize FSK stack with profile 1:sid init 2sid option -lp_set 1sid startWait for time sync and join | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2Njoin(1, 2) st 2->6Key check: EN joined via FSK with profile 1 | . | 2 | Wait 30 seconds, then send DL from cloud to EN | EVENT SID RECEIVED: TYPE: 3, ..., LINK: 2Key check: DL received, profile 1 RX windows always open | . | 3 | Execute RX terminate command:sid option -sub_ghz_ctl 1 | CMD: ERR: -6Key check: Command fails, profile 1 does not support RX terminate | . | 4 | Send DL from cloud to EN again | EVENT SID RECEIVED: TYPE: 3, ..., LINK: 2Key check: DL still received, RX windows not affected by terminate command | . ", "url": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv04-verify-rx-window-termination-request-should-not-stop-rx-window-opened-at-profile-1", "relUrl": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv04-verify-rx-window-termination-request-should-not-stop-rx-window-opened-at-profile-1" },"733": { "doc": "13. Power Optimization Test Cases", "title": "Test Case ID: FSK/EP/PWR/OPT/BV/05: Verify Beacon interval can be adjusted", "content": "| Field | Value | . | Case ID | C103619368 | . | Executable by Customer | Yes | . Preconditions . | GW and EP should be flashed with debug variant build | EP is registered in Sidewalk network | GW is properly communicating with the Cloud | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize FSK stack with profile 2, beacon interval=3:sid init 2sid option -lp_set 2 5040 3 0sid startWait for time sync and join | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2Njoin(1, 2) st 2->6Key check: EN joined via FSK | . | 2 | Catch 2 consecutive beacon logs, verify interval ≈ 30240ms (3x) | BCN:pkt rcvd gw_id:<id> ch:<ch> rssi:<rssi> (2 times)Interval ≈ 30240ms ±30msKey check: Beacon interval = 3x 10080 ms (30240ms) | . | 3 | Change beacon interval to 2x:sid option -lp_set 2 5040 2 0Wait for join response | [Rx][0:22F:3:<n>]Njoin(1, 2) st 2->6Key check: Rejoined | . | 4 | Catch 2 consecutive beacon logs, verify interval ≈ 20160ms (2x) | BCN:pkt rcvd gw_id:<id> ch:<ch> rssi:<rssi> (2 times)Interval ≈ 20160ms ±20msKey check: Beacon interval = 2x 10080 ms (20160ms) | . | 5 | Change beacon interval to 1x:sid option -lp_set 2 5040 1 0Wait for join response | [Rx][0:22F:3:<n>]Njoin(1, 2) st 2->6Key check: Rejoined | . | 6 | Catch 2 consecutive beacon logs, verify interval ≈ 10080ms (1x) | BCN:pkt rcvd gw_id:<id> ch:<ch> rssi:<rssi> (2 times)Interval ≈ 10080ms ±10msKey check: Beacon interval = 1x 10080 ms (10080ms) | . | 7 | Switch to profile 1, beacon interval=3:sid option -lp_set 1 3Wait for join response | [Rx][0:22F:3:<n>]Njoin(1, 2) st 2->6Key check: Rejoined, switched to profile 1 | . | 8 | Catch 2 consecutive beacon logs, verify interval ≈ 30240ms (3x) | BCN:pkt rcvd gw_id:<id> ch:<ch> rssi:<rssi> (2 times)Interval ≈ 30240ms ±30msKey check: Beacon interval = 3x | . | 9 | Change beacon interval to 2x:sid option -lp_set 1 2Wait for join response | [Rx][0:22F:3:<n>]Njoin(1, 2) st 2->6Key check: Rejoined | . | 10 | Catch 2 consecutive beacon logs, verify interval ≈ 20160ms (2x) | BCN:pkt rcvd gw_id:<id> ch:<ch> rssi:<rssi> (2 times)Interval ≈ 20160ms ±20msKey check: Beacon interval = 2x | . | 11 | Change beacon interval to 1x:sid option -lp_set 1 1Wait for join response | [Rx][0:22F:3:<n>]Njoin(1, 2) st 2->6Key check: Rejoined | . | 12 | Catch 2 consecutive beacon logs, verify interval ≈ 10080ms (1x) | BCN:pkt rcvd gw_id:<id> ch:<ch> rssi:<rssi> (2 times)Interval ≈ 10080ms ±10msKey check: Beacon interval = 1x | . ", "url": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv05-verify-beacon-interval-can-be-adjusted", "relUrl": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv05-verify-beacon-interval-can-be-adjusted" },"734": { "doc": "13. Power Optimization Test Cases", "title": "Test Case ID: FSK/EP/PWR/OPT/BV/06: Verify beacon interval revert to default after 2nd beacon misses", "content": "| Field | Value | . | Case ID | C103619369 | . | Executable by Customer | Yes | . Preconditions . | GW and EP should be flashed with debug variant build | EP is registered in Sidewalk network | GW is properly communicating with the Cloud | Shielding box available for blocking GW signal | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize FSK stack with profile 2, beacon interval=3:sid init 2sid option -lp_set 2 5040 3mac scfg C 1 <GW_Sidewalk_ID>sid startWait for time sync and join | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 2EVENT SID STATUS LINK MODE: LORA: 0, FSK: 1, BLE: 0Key check: EN joined via FSK, beacon interval=3x (30240ms) | . | 2 | After a beacon received, close shielding box door to block GW signal | BCN:pkt rcvd gw_id:<id> ch:<ch> rssi:<rssi>Key check: Beacon received, shielding box closed | . | 3 | Wait for 2 consecutive beacon misses:- Beacon miss 1 at ~30s- Beacon miss 2 at ~60s | BCN:bcn miss:1BCN:bcn miss:2Key check: 2 beacon misses detected, EN reverts to default interval (10080ms) | . | 4 | Open shielding box door to restore GW signal | Key check: GW signal restored | . | 5 | Check beacon received at ~70s (default interval after 2nd miss) | BCN:pkt rcvd gw_id:<id> ch:<ch> rssi:<rssi>Key check: Beacon received at ~70s using default interval (10080ms) | . | 6 | Check beacon received at ~100s (reverted to user-configured interval 30240ms) | BCN:pkt rcvd gw_id:<id> ch:<ch> rssi:<rssi>Key check: Beacon interval restored to user-configured 3x (30240ms) | . | 7 | Repeat steps 1-6 with beacon interval=2:sid option -lp_set 2 5040 2- Beacon miss 1 at ~20s- Beacon miss 2 at ~40s- Beacon received at ~50s (default)- Beacon received at ~70s (restored to 2x) | BCN:bcn miss:1BCN:bcn miss:2BCN:pkt rcvd (at ~50s)BCN:pkt rcvd (at ~70s)Key check: Same behavior with beacon interval=2x (20160ms) | . ", "url": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv06-verify-beacon-interval-revert-to-default-after-2nd-beacon-misses", "relUrl": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv06-verify-beacon-interval-revert-to-default-after-2nd-beacon-misses" },"735": { "doc": "13. Power Optimization Test Cases", "title": "Test Case ID: FSK/EP/PWR/OPT/BV/07: Verify DUT can still perform uplinks and downlinks normally after a beacon skipped", "content": "| Field | Value | . | Case ID | C103619370 | . | Executable by Customer | Yes | . Preconditions . | GW and EP should be flashed with debug variant build | EP is registered in Sidewalk network | GW is properly communicating with the Cloud | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize FSK stack with profile 2, beacon interval=3, rx_duration=8s:sid init 2sid option -lp_set 2 630 3 8sid startWait for time sync and joinWait for beacon received, record time T | BCN:pkt rcvd gw_id:<id> ch:<ch> rssi:<rssi>Njoin(1, 2) st 2->6Key check: EN joined, beacon received at T=0 | . | 2 | Wait until T ≈ 11s (1 beacon skipped), then send UL and wait for DL:sid send PING | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 2EVENT SID RECEIVED: TYPE: 3, ID: <id>, LEN: <len>, LINK: 2Key check: UL/DL successful after 1 beacon skipped | . | 3 | Wait until T ≈ 22s (2 beacons skipped), then send UL and wait for DL:sid send PING | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 2EVENT SID RECEIVED: TYPE: 3, ID: <id>, LEN: <len>, LINK: 2Key check: UL/DL successful after 2 beacons skipped | . ", "url": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv07-verify-dut-can-still-perform-uplinks-and-downlinks-normally-after-a-beacon-skipped", "relUrl": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-fskeppwroptbv07-verify-dut-can-still-perform-uplinks-and-downlinks-normally-after-a-beacon-skipped" },"736": { "doc": "13. Power Optimization Test Cases", "title": "Test Case ID: LORA/EP/PWR/OPT/BV/01: Verify number of RX windows is limited and can be changed", "content": "| Field | Value | . | Case ID | C103619371 | . | Executable by Customer | Yes | . Preconditions . | GW and EP should be flashed with debug variant build | EP should be flashed with MAC v2 image (sid_dut_v2) | EP is registered in Sidewalk network | GW is properly communicating with the Cloud (receives time sync) | In Device Profile A, after single transmission in Uplink, endpoint should open specified number of RX windows and go to sleep | RX window count: 0~60 (0 is for uplink-only mode) | Window validity period in seconds: 0~300 (0 is for uplink-only mode) | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize LoRa stack with profile A, rx_window=2:sid init 3sid option -lp_set 128 2sid startWait for time sync and join | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4Njoin(1, 4) st 2->6Key check: EN joined via LoRa, rx_window=2 (~10s validity) | . | 2 | Wait 30 seconds for RX windows to close | No RX window eventsKey check: RX windows closed | . | 3 | Send UL (T=0s):sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4Key check: UL sent, T=0 | . | 4 | T = 3s: Send DL from cloud to EN | EVENT SID RECEIVED: TYPE: 3, ID: <id>, LEN: <len>, LINK: 4Key check: DL received within RX window (T=3s < 10s) | . | 5 | T = 15s: Send DL from cloud to EN | No EVENT SID RECEIVED logKey check: DL not received, RX windows expired (T=15s > 10s) | . | 6 | Change RX windows to 60:sid option -lp_set 128 60Wait for join response | [Rx][0:22F:3:<n>]Njoin(1, 4) st 2->6Key check: Rejoined with rx_window=60 (~300s validity) | . | 7 | Wait 30 seconds for RX windows to close | No RX window events | . | 8 | Send UL (T=0s):sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4Key check: UL sent, T=0 | . | 9 | T = 3s: Send DL from cloud to EN | EVENT SID RECEIVED: TYPE: 3, ID: <id>, LEN: <len>, LINK: 4Key check: DL received | . | 10 | T = 293s: Send DL from cloud to EN | EVENT SID RECEIVED: TYPE: 3, ID: <id>, LEN: <len>, LINK: 4Key check: DL received within extended RX window (T=293s < 300s) | . | 11 | T = 305s: Send DL from cloud to EN | No EVENT SID RECEIVED logKey check: DL not received, RX windows expired (T=305s > 300s) | . ", "url": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-loraeppwroptbv01-verify-number-of-rx-windows-is-limited-and-can-be-changed", "relUrl": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-loraeppwroptbv01-verify-number-of-rx-windows-is-limited-and-can-be-changed" },"737": { "doc": "13. Power Optimization Test Cases", "title": "Test Case ID: LORA/EP/PWR/OPT/BV/02: Verify number of RX windows is reset after sending an additional uplink", "content": "| Field | Value | . | Case ID | C103619372 | . | Executable by Customer | Yes | . Preconditions . | GW and EP should be flashed with debug variant build | EP should be flashed with MAC v2 image (sid_dut_v2) | EP is registered in Sidewalk network | GW is properly communicating with the Cloud | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize LoRa stack with profile A, rx_window=30:sid init 3sid option -lp_set 128 30sid startWait for time sync and join | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4Njoin(1, 4) st 2->6Key check: EN joined via LoRa, rx_window=30 (~150s validity) | . | 2 | Wait 30 seconds for RX windows to close | No RX window eventsKey check: RX windows closed | . | 3 | Send UL (T=0s):sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4Key check: UL sent, T=0, RX windows open for ~150s | . | 4 | T = 73s: Send DL from cloud to EN | EVENT SID RECEIVED: TYPE: 3, ID: <id>, LEN: <len>, LINK: 4Key check: DL received (RX window was reset by additional UL before T=73s) | . | 5 | Send additional UL to reset RX window timer:sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4Key check: UL sent, RX window timer reset to ~150s | . | 6 | T = 222s: Send DL from cloud to EN | EVENT SID RECEIVED: TYPE: 3, ID: <id>, LEN: <len>, LINK: 4Key check: DL received within reset RX window | . ", "url": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-loraeppwroptbv02-verify-number-of-rx-windows-is-reset-after-sending-an-additional-uplink", "relUrl": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-loraeppwroptbv02-verify-number-of-rx-windows-is-reset-after-sending-an-additional-uplink" },"738": { "doc": "13. Power Optimization Test Cases", "title": "Test Case ID: LORA/EP/PWR/OPT/BV/03: Verify RX window termination request stops RX window opened at profile A", "content": "| Field | Value | . | Case ID | C103619373 | . | Executable by Customer | Yes | . Preconditions . | GW and EP should be flashed with debug variant build | EP should be flashed with MAC v2 image (sid_dut_v2) | EP is registered in Sidewalk network | GW is properly communicating with the Cloud | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize LoRa stack with profile A, rx_window=30:sid init 3sid option -lp_set 128 30sid startWait for time sync and join | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4Njoin(1, 4) st 2->6Key check: EN joined via LoRa, profile A, rx_window=30 (~150s validity) | . | 2 | Wait 30 seconds for RX windows to close | No RX window eventsKey check: RX windows closed | . | 3 | Send UL (T=0s):sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4Key check: UL sent, T=0 | . | 4 | T < 5s: Send DL from cloud to EN | EVENT SID RECEIVED: TYPE: 3, ID: <id>, LEN: <len>, LINK: 4Key check: DL received | . | 5 | Execute RX terminate command:sid option -sub_ghz_ctl 1 | CMD: ERR: 0Key check: RX terminate command executed | . | 6 | T = 18s: Send DL from cloud to EN | No EVENT SID RECEIVED logKey check: DL not received, RX windows terminated by sid option -sub_ghz_ctl 1 | . ", "url": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-loraeppwroptbv03-verify-rx-window-termination-request-stops-rx-window-opened-at-profile-a", "relUrl": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-loraeppwroptbv03-verify-rx-window-termination-request-stops-rx-window-opened-at-profile-a" },"739": { "doc": "13. Power Optimization Test Cases", "title": "Test Case ID: LORA/EP/PWR/OPT/BV/04: Verify RX window termination request should not stop RX window opened at profile B", "content": "| Field | Value | . | Case ID | C103619374 | . | Executable by Customer | Yes | . Preconditions . | GW and EP should be flashed with debug variant build | EP should be flashed with MAC v2 image (sid_dut_v2) | EP is registered in Sidewalk network | GW is properly communicating with the Cloud | . Test Steps . | Step | Description | Expected Result | . | 1 | Initialize LoRa stack with profile B (infinite RX):sid init 3sid option -lp_set 129 0sid startWait for time sync and join | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: 4Njoin(1, 4) st 2->6Key check: EN joined via LoRa, profile B (infinite RX windows) | . | 2 | Wait 30 seconds for RX windows to close | No RX window eventsKey check: RX windows closed | . | 3 | Send UL (T=0s):sid send TEST | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: 4Key check: UL sent, T=0 | . | 4 | T < 5s: Send DL from cloud to EN | EVENT SID RECEIVED: TYPE: 3, ID: <id>, LEN: <len>, LINK: 4Key check: DL received | . | 5 | Execute RX terminate command:sid option -sub_ghz_ctl 1 | CMD: ERR: 0Key check: RX terminate command executed | . | 6 | T = 18s: Send DL from cloud to EN | EVENT SID RECEIVED: TYPE: 3, ID: <id>, LEN: <len>, LINK: 4Key check: DL still received, profile B not affected by terminate command | . ", "url": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-loraeppwroptbv04-verify-rx-window-termination-request-should-not-stop-rx-window-opened-at-profile-b", "relUrl": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html#test-case-id-loraeppwroptbv04-verify-rx-window-termination-request-should-not-stop-rx-window-opened-at-profile-b" },"740": { "doc": "13. Power Optimization Test Cases", "title": "13. Power Optimization Test Cases", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/power-optimization-test-cases.html" },"741": { "doc": "8.1 Power up", "title": "8.1 Power up", "content": ". fig 8.1 Power up . The flow chart specifies the command sequence that shall be exchanged between the Endpoint and the Amazon Sidewalk Cloud to make an Endpoint fully operational. The procedure is as follows: . | STEP 1 - The Endpoint powers up and initializes Amazon Sidewalk SDK with one of the three types of connection modes, i.e. BLE, SubG-CSS or SubG-FSK connection modes. The parameters of the selected connection mode, stored in the Endpoint’s non-volatile memory, are loaded back. These parameters can be modified to desired values by resetting them through Amazon Sidewalk APIs. In the next boot-up, | STEP 2 - Amazon Sidewalk is started through the sid_start instruction. This instruction triggers the protocol to start forming the initial communication link. Depending on the connection mode that the Endpoint is initialized as follows: . | in the case of BLE connection mode, the instruction initializes the components for BLE communication, starts sending out advertisement packages and waits for connection initiation requests from nearby Gateways. The BLE communication link is established via a handshake request by an Amazon Sidewalk Gateway responding to the advertisement package as described in section 6.2; | in the case of the SubG-FSK connection mode, the instruction starts a Beacon Discovery operation as described in section 5.2.1. Upon discovering the Gateway, SubG-FSK connection with the discovered Gateway is established using “Common Slots” schedule as described in 5.5.1.1.1; | in the case of the SubG-CSS connection modes, the instruction initializes the components to send SubG-CSS packets but does not send or receive any packets. | . | STEP 3 - The Endpoint shall establish time synchronization with the Amazon Sidewalk Cloud by using GET_TIME and RESP_TIME command pairs. These commands use counter-based keys (see details in section 4.2, and section 4.5, and further details of this process are described in . The Endpoint proceeds with Step 4 after establishing time synchronization. | STEP 4 - The Endpoint initiates the Amazon Sidewalk join procedure by using set_join_req and resp_join_req command pairs as described in section 8.3. Upon completing this step, the Endpoint reports Amazon Sidewalk Connected state to its app. Once connected, the Endpoint allows uplink and downlink data message flows between application servers and the Endpoint through the Amazon Sidewalk Cloud. | STEP 5 - The Endpoint starts maintaining Amazon Sidewalk connectivity. This maintenance involves: . | link layer connectivity between  and the Endpoint in the connection mode being used including BLE, 900 MHz synchronous or asynchronous modes. | GCS synchronization maintenance through periodic updates as described in section 8.2.1, | Amazon Sidewalk connectivity maintenance through periodic Network Synchronization messages as described in section 5.6. | . | . ", "url": "/specifications/sidewalk-protocol-spec/procedures-and-flow-charts/power-up.html", "relUrl": "/specifications/sidewalk-protocol-spec/procedures-and-flow-charts/power-up.html" },"742": { "doc": "7.5 Protocol Specifications", "title": "7.5 Protocol Specification", "content": "The following are the control and data commands that are supported in this protocol specification for the transport of a blob of file from the application server and network server to the end device. All commands are sent uni-cast to the end device. The diagram below describes the high level messaging flow from Developer to the device. fig 7.3 High Level Messaging Flow from Developer to End Device . All messages follow the Sidewalk application layer message frame formats below refer to Chapter 3 of specification document for more details. fig 7.4 Sidewalk Application Layer Format . 7.5.1 SBDT Commands . All SBDT commands share the same command class . Table 7.1 SBDT Commands . | Mnemonic | Length | Value | Description | . | cmd_class | 12b | 0x03 | This value is common for all sbdt control and data commands | . 7.5.1.1 Application Layer Commands . TLV . Sidewalk TLV format is adopted to encode the command data. The format of the TLV is as below. In TLV encoding, value determines the length, even though type is UINT32, if the value is less than 255 then the length encoded in TLV will be only one byte. Table 7.2 TLV Format 1 . | Value Length | Key | Value | . | 2b | 6b | xB | . Table 7.3 TLV Format 2 . | Value Length(2b) | Length | Comments | . | 0b00 | 1 |   | . | 0b01 | 2 |   | . | 0b10 | 3 |   | . | 0b11 | length encoded in next byte | [2b(11) — 6b key — 1B value length — xB value] | . Table 7.4 TLV Format 3 . | Key | Value (6b) | Size | . | TAG_ID_SBDT_FILE_ID | 0x01 | 4B | . | TAG_ID_SBDT_NUM_OF_BLOCKS | 0x02 | 2B | . | TAG_ID_SBDT_BLOCK_SIZE | 0x03 | 2B | . | TAG_ID_SBDT_BLOCK_ID | 0x04 | 2B | . | TAG_ID_SBDT_LAST_BLOCK_SIZE | 0x05 | 2B | . | TAG_ID_SBDT_CHUNK_MTU | 0x06 | 2B | . | TAG_ID_CHUNK_ID | 0x07 | 1B | . | TAG_ID_SBDT_WINDOW_SIZE | 0x08 | 1B | . | TAG_ID_SBDT_BIT_MASK_SIZE | 0x09 | 4B | . | TAG_ID_SBDT_STATUS | 0x0A | 1B | . | TAG_ID_SBDT_AES_KEY | 0x0B | 16B | . | TAG_ID_SBDT_META_DATA_OFFSET | 0x0C | 1B-2B | . | TAG_ID_SBDT_DATA | 0x0D | 1B-nB | . | TAG_ID_SBDT_START_TIME | 0x0E | 4B | . | TAG_ID_SBDT_SEQUENCE_NUMBER | 0x0F | 2B | . | TAG_ID_SBDT_TIME_REF | 0x10 | 4B | . | TAG_ID_SBDT_CUSTOMER_REASON | 0x11 | 1B | . | TAG_ID_SBDT_ACTUAL_BLOCK_SIZE | 0x12 | 2B | . | TAG_ID_SBDT_NUMBER_OF_CHUNKS | 0x13 | 2B | . Transfer Request . The application transfer request is sent by the application server to the end device to initiate the file transfer session. Below is a description of the frame format. Table 7.5 Command ID . | Mnemonic | Length | Value | Type | command_name | Direction | . | cmd_id | 14b | 0x01 | Write | TRANSFER_APPLICATION_REQUEST | DL | . |   | 14b | 0x03 | Response | TRANSFER_APPLICATION_RESPONSE | UL | . Table 7.6 Command Data - TRANSFER APPLICATION REQUEST . | Mnemonic | Length | Value | TLV | Description | . | sbdt_version | 1B | 0 | fixed | SBDT version | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . | fragment_size | 1B-2B | 1K-8K | 0x03 | user supplied fragment size range from 1K to 8K | . |   | 1B-2B | 1K-8K | 0x43 |   | . | number_of_fragments | 1B-2B | variable | 0x02 | number of fragment size fragments in a file | . |   | 1B-2B | variable | 0x42 |   | . | last_fragment_size | 1B-2B | variable | 0x05 | size of the last fragment of the file | . |   | 1B-2B | variable | 0x45 |   | . | start_time | 4B | variable | 0x8E | time to start the transfer | . | file_descriptor | 1B-32B | variable | 0x0, 0x4, 0x8, 0xc | user supplied file meta data | . Table 7.7 Command Data - TRANSFER APPLICATION RESPONSE . | Mnemonic | Length | Value | TLV | Description | . | sbdt_version | 1B | 0 |   | SBDT version | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . | fragment_id | 1B-2B | variable | 0x04 | current fragment index | . |   | 1B-2B | variable | 0x44 |   | . | sbdt_status | 1B | variable | 0x0A | SBDT error status code | . Transfer File Finalize . The transfer file finalize command is sent by the application server to the end device to exit the file transfer session. Below is a description of the frame format. Table 7.8 Command ID . | Mnemonic | Length | Value | Type | command_name | Direction | . | cmd_id | 12b | 0x21 | Write | TRANSFER_FILE_FINALIZE | DL | . |   | 12b | 0x23 | Response | TRANSFER_FILE_FINALIZE_RESPONSE | UL | . Table 7.9 Command Data - TRANSFER FILE FINALIZE . | Mnemonic | Length | Value | TLV | Description | . | sbdt_version | 1B | 0 |   | SBDT version | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . Table 7.10 Command Data - TRANSFER FILE FINALIZE RESPONSE . | Mnemonic | Length | Value | TLV | Description | . | sbdt_version | 1B | 0 |   | SBDT version | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . | sbdt_status | 1B | variable | 0x0A | SBDT error status code | . Transfer Cancel . The transfer cancel command is sent by the application server to the end device to cancel an ongoing transfer session. Below is a description of the frame format. Table 7.11 Command ID . | Mnemonic | Length | Value | Type | command_name | Direction | . | cmd_id | 12b | 0x2D | Write | TRANSFER_CANCEL | DL | . |   | 12b | 0x2F | Response | TRANSFER_CANCEL_RESPONSE | UL | . |   | 12b | 0x2E | Notify | TRANSFER_CANCEL_NOTIFY | UL | . Table 7.12 Command Data - TRANSFER CANCEL . | Mnemonic | Length | Value | TLV | Description | . | sbdt_version | 1B | 0 |   | SBDT version | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . Table 7.13 Command Data - TRANSFER CANCEL RESPONSE . | Mnemonic | Length | Value | TLV | Description | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . | sbdt_status | 1B | variable | 0x0A | SBDT error status code | . Table 7.14 Command Data - TRANSFER CANCEL NOTIFY . | Mnemonic | Length | Value | TLV | Description | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . | sbdt_status | 1B | variable | 0x0A | SBDT error status code | . | cancel_reason | 1B | variable | 0x11 | cancel reason | . 7.5.1.2 Network Layer Commands . Transfer Request . The transfer request command is sent by the network server to the end device to initiate the file transfer session. Below is a description of the frame format. Table 7.15 Command ID . | Mnemonic | Length | Value | Type | command_name | Direction | . | cmd_id | 12b | 0x05 | Write | TRANSFER_REQUEST | DL | . |   | 12b | 0x07 | Response | TRANSFER_RESPONSE | UL | . Table 7.16 Command Data - TRANSFER REQUEST . | Mnemonic | Length | Value | TLV | Description | . | sbdt_version | 1B | 0 |   | SBDT version | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . | fragment_size | 1B-2B | 1K-8K | 0x03 | user supplied fragment size range from 1K to 8K | . |   | 1B-2B | 1K-8K | 0x43 |   | . | chunk_size | 1B-2B | variable | 0x06 | size of link mtu chunks | . |   | 1B-2B | variable | 0x46 |   | . | window_size | 1B | variable | 0x08 | size of fragment window | . Table 7.17 Command Data - TRANSFER RESPONSE . | Mnemonic | Length | Value | TLV | Description | . | sbdt_version | 1B | 0 |   | SBDT version | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . | fragment_size | 1B-2B | 1K-8K | 0x03 | user supplied fragment size range from 1K to 8K | . |   | 1B-2B | 1K-8K | 0x43 |   | . | fragment_id | 1B-2B | variable | 0x04 | current fragment index | . |   | 1B-2B | variable | 0x44 |   | . | number_of_fragments | 1B-2B | variable | 0x02 | number of fragment size fragments in a file | . |   | 1B-2B | variable | 0x42 |   | . | chunk_size | 1B-2B | variable | 0x06 | size of link mtu chunks | . |   | 1B-2B | variable | 0x46 |   | . | window_size | 1B | variable | 0x08 | size of fragment window | . | number_of_chunks | 1B-2B | variable | 0x13 | number of chunks per fragment | . |   | 1B-2B | variable | 0x93 |   | . | sbdt_status | 1B | variable | 0x0A | SBDT error status code | . Transfer Request Finalize . The transfer request finalize command is sent by the network server to the end device to finish the transfer request handshaking to initiate the file transfer session. Below is a description of the frame format. Table 7.18 Command ID . | Mnemonic | Length | Value | Type | command_name | Direction | . | cmd_id | 12b | 0x09 | Write | TRANSFER_REQUEST_FINALIZE | DL | . |   | 12b | 0x0B | Response | TRANSFER_REQUEST_FINALIZE_RESPONSE | UL | . Table 7.19 Command Data - TRANSFER REQUEST FINALIZE . | Mnemonic | Length | Value | TLV | Description | . | sbdt_version | 1B | 0 |   | SBDT version | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . | chunk_size | 1B-2B | variable | 0x06 | size of link mtu chunks | . |   | 1B-2B | variable | 0x46 |   | . | window_size | 1B | variable | 0x08 | size of fragment window | . Table 7.20 Command Data - TRANSFER REQUEST FINALIZE RESPONSE . | Mnemonic | Length | Value | TLV | Description | . | sbdt_version | 1B | 0 |   | SBDT version | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . | sbdt_status | 1B | variable | 0x0A | SBDT error status code | . Transfer Block . The transfer block command is sent by the network server to the end device to transport a fragment of the file. Below is a description of the frame format. Table 7.21 Command ID . | Mnemonic | Length | Value | Type | command_name | Direction | . | cmd_id | 12b | 0x15 | Write | TRANSFER_BLOCK_DATA | DL | . |   | 12b | 0x17 | Response | TRANSFER_BLOCK_DATA_RESPONSE | UL | . Table 7.22 Command Data - TRANSFER BLOCK DATA . | Mnemonic | Length | Value | TLV | Description | . | header | 1B |   |   | block header info | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . | chunk_id | 1B-2B | variable | 0x07, 0x47 | current chunk index | . | fragment_id | 1B-2B | variable | 0x04 | current fragment index | . | seq_num | 12B | variable | 0x4F | fragment sequence number | . | chunk_data | 1B-nB | variable | 0x0D, 0x4D, 0x8D, 0xCD | file payload | . Table 7.23 Command Data - TRANSFER BLOCK DATA RESPONSE . | Mnemonic | Length | Value | TLV | Description | . | header | 1B |   |   | block header info | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . | fragment_id | 1B-2B | variable | 0x04 | current fragment index | . | seq_num | 12B | variable | 0x4F | fragment sequence number | . | bitmask_size | 1B-4B | variable | 0x09, 0x49, 0x89, 0xC9 | bitmask size | . | sbdt_status | 1B | variable | 0x0A | SBDT error status code | . | bitmask | 1B-nB | variable |   | received data bitmask | . Transfer Exit . The transfer exit command is sent by the network server to the end device to exit the transfer session on a completed transfer. Below is a description of the frame format. Table 7.24 Command ID . | Mnemonic | Length | Value | Type | command_name | Direction | . | cmd_id | 12b | 0x36 | Notify | TRANSFER_FILE_EXIT | DL | . Table 7.25 Command Data - TRANSFER FILE EXIT . | Mnemonic | Length | Value | TLV | Description | . | file_id | 4B | 0 | 0x81 | unique file id crc32 of file | . 7.5.2 Status . The following lists the status information returned by SBDT. Table 7.26 SBDT Status Information . | Value | Definition (FuotaDeviceStatus) | Description | . | 0x00 | Successful | Success | . | 0x01 | Wrong_descriptor | Generic Error | . | 0x02 | Wrong_descriptor | Version mismatch | . | 0x03 | Package_Not_Supported | File too Big | . | 0x04 | Not_enough_memory | No Memory | . | 0x05 | Low_Battery | Low Battery | . | 0x06 | Security_Error | Block Verification Failed | . | 0x07 | MissingFrag | Missing Chunks | . | 0x08 | File_System_Error | Write Failed | . | 0x09 | Security_Error | File Verification Failed | . | 0x0A | Restart_Transfer | Restart | . | 0x0B | Already_Available | File Exists | . | 0x0C | Link_Not_Supported | Unsupported Link | . | 0x0D | Internal_Error | Invalid File ID | . | 0x0E | Internal_Error | Invalid Block Size | . | 0x0F | MissingFrag | Invalid Block ID | . | 0x10 | Initial | Ready Status | . | 0x11 | InProgress | InProgress | . ", "url": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/protocol-specification.html#75-protocol-specification", "relUrl": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/protocol-specification.html#75-protocol-specification" },"743": { "doc": "7.5 Protocol Specifications", "title": "7.5 Protocol Specifications", "content": " ", "url": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/protocol-specification.html", "relUrl": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/protocol-specification.html" },"744": { "doc": "5.1 Protocol Stack Layers and Structure", "title": "5.1 Protocol Stack Layers and Structure", "content": "The protocol stack is illustrated in figure 5.1. fig 5.1 Protocol stack . A detailed description of each layer’s functions, supported features, and frame format can be found in the following chapter and subsections: . | The Application Layer is described in Chapter 3 Application. This chapter includes application commands format definition, a detailed description of available commands, and flow charts showing the base scenarios with command usage. | The Presentation Layer is described in section 5.1.1. This subsection provides information on how application commands are included in the layer. This subsection also defines the format of diagnostic data that may be included in a command or response. | The Network Layer is described in section 5.1.2. This subsection describes the network security settings of the message. | The Link Layer is described in section 5.1.3. This subsection defines the Beacon frame format and message frame format and their functions. | The Physical Layer is described in section 5.1.4. This subsection defines the RF frame format, configuration and airtime values. This subsection also includes considerations of the time drift aspects. | . 5.1.1 Presentation Layer . The Presentation Layer supports exchange of Application Layer commands between two entities. The Presentation Layer also supports Application Layer security including encryption and frame size randomization. Presentation Layer frames may also contain diagnostic data that are typically sent by an Endpoint in the uplink direction. 5.1.1.1 Presentation Layer Frame format . The frame is divided into three main blocks as follows: . | The first block is the “Application Support Layer header”. This block provides information for decoding and interpreting the frame. | The second block is “Network diagnostic data”. This block contains two main parts. The first part contains diagnostic data. The second part contains padding bytes. | The third block is “Application command”. This block contains the application command and its payload. | . fig 5.2 Presentation layer - Blocks . 5.1.1.1.1 Application Support Layer (ASL) header . The Application Support Layer header includes flags indicating the presence or absence of fields in the rest of the frame, the encryption status of the rest of the Network Diagnostic and Application Command blocks, and the Application Support Layer header version number. The Application Support Layer header version has an impact on whether a received message is processed or rejected. The last value in the Application Support Layer header is related to the uplink or downlink message number that allows control of the correct sequence of data transmit and receive. 5.3 Presentation layer - ASL header . | Application version number flag (version_inc) . | Mnemonic | Presence M/O/C | Length | Value |   | . | ver_inc | M | 1b | Bit value | Description | . | ver_inc | M | 1b | 0 | version number field not included | . | ver_inc | M | 1b | 1 | version number field included | . The value of the Application version number flag indicates whether the “Application frame version number” field is included in the frame. | The Application version number is optional for messages exchanged with the Amazon Sidewalk Cloud. | The Application version number shall be included in all destination addresses that are not in the cloud. | . | Response request flag (resp_req) . | Mnemonic | Presence M/O/C | Length | Value |   | . | resp_req | M | 1b | Bit value | Description | . | resp_req | M | 1b | 0 | response not requested | . | resp_req | M | 1b | 1 | response requested | . The value of the response request flag indicates whether the sender requests a response from the destination. | Sequence number flag (seqn_inc) . | Mnemonic | Presence M/O/C | Length | Value |   |   | . | seq_num_inc | M | 1b | Bit value | Description |   | . | seq_num_inc | M | 1b | Bit value | 0 | sequence number field not included | . | seq_num_inc | M | 1b | Bit value | 1 | sequence number included | . The value of the Sequence number flag indicates whether the “Sequence number” field is included in the frame. | Application level encryption flag (app_enc_ema) . | Mnemonic | Presence M/O/C | Length | Value |   | . | encr_ena | M | 1b | Bit value | Description | . | encr_ena | M | 1b | 0 | encryption disabled | . | encr_ena | M | 1b | 1 | encryption enabled | . The value of the Application level encryption flag indicates whether the “Application command” block is encrypted with application level encryption. | Status header flag (status_hdr_inc) . | Mnemonic | Presence M/O/C | Length | Value |   | . | status_hdr_inc | M | 1b | Bit value | Description | . | status_hdr_inc | M | 1b | 0 | status header field not included | . | status_hdr_inc | M | 1b | 1 | status header field included | . The value of the Status header flag indicates whether the “Status code” and/or “Additional application data” fields are included in the frame. | Network diagnostic data flag (nw_data_blob_inc) . | Mnemonic | Presence M/O/C | Length | Value |   | . | diag_data_inc | M | 1b | Bit value | Description | . | diag_data_inc | M | 1b | 0 | diagnostic data not included | . | diag_data_inc | M | 1b | 1 | diagnostic data included | . The value of the Network diagnostic data flag indicates whether the “Network diagnostic data” block is included in the frame. | Application frame version number (version) . | Mnemonic | Presence M/O/C | Length | Value |   | . | app_ver_nb | C version_inc is set to 1 | 1B | Bit number | Description | . | app_ver_nb | C version_inc is set to 1 | 1B | 8:7 | ASL version | . | app_ver_nb | C version_inc is set to 1 | 1B | 6:4 | command class version - major part | . | app_ver_nb | C version_inc is set to 1 | 1B | 3:1 | command class version - minor part | . The value of the Application frame version number indicates the version of the Application Support Layer. This identifies the revision of the command class that is in use. The meaning of selected parts of the field is as follows: . | ASL version: specifies the ASL header format. One format is specified. The value indicating the specified ASL header is 0x0. | Command class version - major part: indicates significant changes introduced in the command class. All commands from a command class that have different major versions are not backward compatible. Devices that can only support major versions that are lower than the received command class version shall reject the incoming message. | Command class version - minor part: indicates small changes introduced to the command class. Devices supporting only lower minor versions shall accept an incoming message and process only the parts of the command that can be understood. Fields that cannot be understood by the device shall be ignored. | . | Sequence number (seqn) . | Mnemonic | Presence M/O/C | Length | Value | . | seq_num | Cseqn_inc is set to 1 | 1 to 2 B | counter value | . The value of the Sequence number indicates the sequence number of the message. The field contains two parts: . | the 2 most significant bits of the first byte specify the size of the field in bytes | the remaining bits are the sequence number: . | 1 B size: remaining 6 bits allow a sequence number range between 0 and 63 | 2 B size: remaining 14 bits allow a sequence number range between 0 and 16383 | . | . | . 5.1.1.1.2 Network diagnostic data (nw_data_blob) . The Network diagnostic data field contains information related to signal conditions and message timing. Network diagnostic data are grouped in several formats by Format ID. Each Format ID indicates the type of diagnostic data that are included in the frame. The Format ID also informs whether padding bytes may be included in this part of the frame. The number of padding bytes is random. Adding padding bytes randomizes the packet size. Randomizing the packet size prevents an attacker from using statistical analysis to deduce the message type. fig 5.4 Presentation layer - Network diagnostic data . fig 5.5 Presentation layer - Network diagnostic data - Format ID 0 . | Network diagnostic data header (diag_data_hdr) . | Mnemonic | Presence M/O/C | Length | Value |   |   | . | diag_data_hdr | C | diag_data_inc is set to 1 | 1B | Bit number | Description | . | diag_data_hdr | C | diag_data_inc is set to 1 | 1B | 8:5 | Format ID | . | diag_data_hdr | C | diag_data_inc is set to 1 | 1B | 4:1 | nw_data_blob_size | . The Network diagnostic data header contains the Format ID of the network diagnostic data. The Network diagnostic data header also contains the nw_data_blob_size. The nw_data_blob_size indicates the total size of the nwk_diag_data and padding fields. | Diagnostic data (nwk_diag_data) . | Mnemonic | Presence M/O/C | Length | Value | . | nwk_diag_data | Cdiag_data_inc is set to 1 Format ID > 0 | see NOTE | diagnostic data | . The Diagnostic Data field contains additional diagnostic data. The data length and presence are Format ID-dependent. The following table shows supported Format IDs. | Format ID number | Diagnostic data presence | Format ID size format_id_size | . | 0 | not present | 0 | . | 3 | present | length of total TLV | . Based on the Format ID, the length will be different. The length of Format ID 0 is 0 as it does not include any ”Diagnostic data”. | Format ID 0 No diagnostic data. | Format ID 3 Diagnostic data of this format is encoded in the format of TLV. | TLV key name | TLV key ID | TLV length | Description | . | Synchronization request | 0x01 | 1B | Value of TLV is not used. | . | . | Padding (padding) . | Mnemonic | Presence M/O/C | Length | Value | . | padding | Cdiag_data_inc is set to 1 (see NOTE 1) | padding_size | padding bytes | . The padding field contains additional padding bytes to randomize the packet size. Randomizing the packet size improves packet security against size tracking. 1: The presence of the field is based on Format ID. The padding field presence is mandatory for Format ID 0. The length of the padding field is padding_size. The receiver calculates the number of padding bytes based on the Format ID of the network diagnostic data and nw_data_blob_size. Both values are provided in diag_data_hdr in the received message. The receiver shall use the following formula based on the Format ID: . | Format ID 0 . All bytes in the “Network diagnostic data” block shall be padding bytes. The number of padding bytes is calculated using the formula: . padding_size = nw_data_blob_size * 2 . | . The sender calculation of padding_size is more complex and is constrained as follows: . | The total number of bytes included in the “Network diagnostic data” block (format_id_size) and Presentation Layer (frame_pld_size) shall not exceed max_packet_size. max_packet_size has different values for synchronous and asynchronous link modes. | Connection mode | maximum application payload size | . | SubG-CSS | 19 | . | SubG-FSK | 200 | . | BLE | 255 | . | . | . The first step in calculating the padding field size is to check that packet_size does not exceed max_packet_size: packet_size = format_id_size + frame_pld_size If padding bytes may be added, then the initial random length of padding field is calculated: rand_pad = rand()%( max_packet_size - packet_size ) + packet_size next the number of padding bytes is calculated as a multiple of padding_block_size: pad_mod = rand_pad MOD padding_block_size If pad_mod is not a multiple of padding_block_size then pad_mod is recalculated: IF pad_mod != 0 THEN pad_mod = padding_block_size - pad_mod Next, the number of allowed bytes in the frame is taken into account using the following formula: total_size = MIN( rand_pad + pad_mod,max_packet_size) Then, the initial value of the padding bytes length is calculated: padding_size = total_size - packet_size The length of padding field is limited by max_padding_size: padding_size = MIN(padding_size,max_padding_size) Finally, the sum of padding_size and format_id_size is divided by 2: IF (padding_size + format_id_size) MOD 2 != 0 THEN padding_size = padding_size - 1 The nw_data_blob_size included in the frame shall be calculated from the following formula: nw_data_blob_size = ( padding_size + format_id_size)/2 . 5.1.1.1.3 Application command . The format of the “Application command” part of the frame is determined by the presence of the “Status code”, “Additional application data” and “Command” fields as follows: . | Case 1A: “Status code”, “Additional application data” and “Command” fields are included in the frame (see figure 5.6) | Case 1B: “Status code” and “Additional application data” are included in the frame (see figure 5.7) | Case 2A: “Additional application data” and “Command” fields are included in the frame (see figure5.8) | Case 2B: Only “Additional application data” is included in the frame (see figure 5.9) | Case 3A: “Status code” and “Command” fields are included in the frame (see figure 5.10) | Case 3B: Only “Status command” field is included in the frame (see figure 5.11) | Case 4A: Only “Command” field is included in the frame (see figure 5.12) | Case 4B: No “Status code”, “Additional application data” and “Command” fields are included in the frame (see figure 5.13) | . fig 5.6 Presentation layer - Application command - CASE 1A . fig 5.7 Presentation layer - Application command - CASE 1B . fig 5.8 Presentation layer - Application command - CASE 2A . fig 5.9 Presentation layer - Application command - CASE 2B . fig 5.10 Presentation layer - Application command - CASE 3A . fig 5.11 Presentation layer - Application command - CASE 3B . fig 5.12 Presentation layer - Application command - CASE 4A . fig 5.13 Presentation layer - Application command - CASE 4B . | Status code flag (status_code_inc) . | Mnemonic | **Presence M/O/C ** | Length | Value |   | . | status_code_inc | Cstatus_hdr_inc is set to 1 | 1b | Bit value | Description | . | status_code_inc | Cstatus_hdr_inc is set to 1 | 1b | 0 | status code not included | . | status_code_inc | Cstatus_hdr_inc is set to 1 | 1b | 1 | status code is included | . The value of the status code flag indicates whether the frame includes the status_code field. | Additional data flag (add_app_data_inc) . | Mnemonic | Presence M/O/C | Length | Value |   | . | add_app_data_inc | Cstatus_hdr_inc is set to 1 | 1b | Bit value | Description | . | 0 | additional application data not included |   |   |   | . | 1 | additional application data included |   |   |   | . The value of the Additional data flag indicates whether the frame includes the add_app_data field. | Status code (status_code) . | Mnemonic | Presence M/O/C | Length | Value | . | status_code | Cstatus_hdr_inc is set to 1 status_code_inc is set to 1 | 6b | status code | . The value of status code indicates the status code of the operation. Only selected types of messages may contain a status code, as follows: . | Response type messages shall always include a status code. | Notification type messages may or may not include a status code. | . The status code is not applicable to read or write type messages, so the status code field shall not be present in “Application command header”. Values of status codes can be found in 3.1 describing the application level frame format. | Additional application data (add_app_data) . | Mnemonic | Presence M/O/C | Length | Value | . | add_app_data | Cstatus_hdr_inc is set to 1 additional_app_data_inc is set to 1 | 1 to 63B | application additional data | . The additional application data field contains additional application information which may be included by a device’s Application Layer. Additional data shall not be added if the resulting frame exceeds the MTU size. The 6 least significant bits of the first byte represents the length of the application additional data. The 2 most significant bits of the first byte shall be encoded using the following rules: . | If “Status code” is included, the bits shall be set to 0. | If “Status code” is not included, the bits contain the value of “Status code flag” and “Additional data flag”. | . | Operation Code (opc) . | . | Mnemonic | Presence M/O/C | Length | Value |   |   | . | opc | M | 2b | Bits | Bits | Description | . | opc | M | 2b | 0 | 0 | read from destination | . | opc | M | 2b | 0 | 1 | write to destination | . | opc | M | 2b | 1 | 0 | notify destination with data from sender | . | opc | M | 2b | 1 | 1 | respond to previous read/write from destination (possibly includes data in response) | . The value of “Operation Code” indicates the operation code that identifies the application command type. The application command type can be: get, set, notify, or respond. For more information, see section 3.2. | Command encode (cmd_enc) . | Mnemonic | Presence M/O/C | Length | Value | . | cmd_enc | M | 6b | 0x0 - 0x3F | . The value of the Command encode field indicates the coding format of the command class; the coding format of the command ID; whether the Command field is included in the Presentation layer frame; and the size of the Command field. The Command encode field is interpreted as follows: . | 0x0 to 0x3B - cmd field is not included. Command class and command ID are encoded in 6 bits. | 0x3C to 0x3F - cmd field is included in the frame. The value indicates the size of the Command field as follows: . | 0x3C indicates 1B size | 0x3D indicates 2B size | 0x3E indicates 3B size | 0x3F indicates 4B size | . | . | Command (cmd) . | Mnemonic |   | Length | Value | . | cm | Ccmd_enc > 0x3B | 1 to 4B | command class and command ID | . The Command field contains the command class and command ID. For more information see section 3.1. | Payload (frame_pld) . | Mnemonic | Presence M/O/C | Length | Value |   | . | frame_pld | O | see NOTE | Data to be written, arguments for a read, notify payload data | or response data | . The Payload field contains command data. For more information, see section 3.1. | . NOTE: The field does not contain an explicit payload length. Length can be derived using the following formula: Payload length = Total payload received over the air – ASL header with optional additional application data and/or optional network diagnostic data header . 5.1.2 Network Layer . 5.1.2.1 Network Layer overview . The Network Layer supports the network level security aspects of the frame, like authentication, encryption, and security type. 5.1.2.2 Network Layer Frame format . The Network Layer frame is divided into three main blocks. The first block is “Frame control”. The Frame control block contains information that provides information for decoding the rest of the frame. Frame control also contains information related to network security aspects and frame fragmentation. The second block is “Authentication”. The Authentication block includes information used in the authentication process. The third block is “Frame payload”. The Frame payload block contains higher layer data. fig 5.14 Network layer - Blocks . 5.1.2.2.1 Network Layer Frame Control Fields . fig 5.15 Network layer - Frame control . | Packet fragmentation flag (is_fragment) . | Mnemonic | Presence M/O/C | Length | Value |   | . | is_fragment | M | 1b | Bit | Description | . | is_fragment | M | 1b | 0 | not fragmented | . | is_fragment | M | 1b | 1 | fragmented | . The value of the Packet fragmentation flag indicates whether or not the Network Layer frame is fragmented. NOTE: The current release of the protocol does not support frame fragmentation. The field shall be set to 0. | Payload type flag (frame_pld_type) . | Mnemonic | Presence M/O/C | Length | Value |   | . | frame_pld_type | M | 1b | Bit | Description | . | frame_pld_type | M | 1b | 0 | reserved | . | frame_pld_type | M | 1b | 1 | Presentation Layer frame | . The value indicates the type of payload available in the field frame_pld . | . NOTE: The current release of the protocol supports one payload type only and this is the Presentation Layer frame. This bit shall be set to 1 by default. | Encryption flag (encr_ena) . | Mnemonic | Presence M/O/C | Length | Value |   | . | encr_ena | M | 1b | Bit | Description | . | encr_ena | M | 1b | 0 | encryption disabled | . | encr_ena | M | 1b | 1 | encryption enabled | . The value indicates whether the network frame payload (frame_pld) field is encrypted. | Authentication code size (auth_code_size) . | Mnemonic | Presence M/O/C | Length | Value |   |   |   | . | auth_code_size | M | 3b | Bit | Bit | Bit | Description | . | auth_code_size | M | 3b | 0 | 0 | 0 | no auth code | . | auth_code_size | M | 3b | 0 | 0 | 1 | 2 B | . | auth_code_size | M | 3b | 0 | 1 | 0 | 4 B | . | auth_code_size | M | 3b | 0 | 1 | 1 | 8 B | . | auth_code_size | M | 3b | 1 | 0 | 0 | 12 B | . | auth_code_size | M | 3b | 1 | 0 | 1 | 16 B | . | auth_code_size | M | 3b | 1 | 1 | 0 | reserved | . | auth_code_size | M | 3b | 1 | 1 | 1 | reserved | . The value indicates the size of the authentication code field (auth_code). The maximum allowed size is: . | 16 B when ext_hdr is set to 1 and sec_ref is set to 0 | 12 B when ext_hdr is set to 1 and sec_ref is set to 1 | 16 B when ext_hdr is set to 0. | . | Network security topology (sec_top) . | Mnemonic | Presence M/O/C | Length | Value |   | . | sec_top | M | 1b | Bit | Description | . | sec_top | M | 1b | 0 | reserved | . | sec_top | M | 1b | 1 | WAN security topology | . The value indicates the security topology. NOTE: The current release of the protocol supports only one security topology. This bit shall be set to 1 by default. | Extended header flag (ext_hdr) . | Mnemonic | Presence M/O/C | Length | Value |   | . | ext_hdr | M | 1b | Bit | Description | . | ext_hdr | M | 1b | 0 | sec_ref field is not present | . | ext_hdr | M | 1b | 1 | sec_ref field is present | . The value indicates extended configuration of the “Authentication” part of the network frame. When ext_hdr is set to 0, then the GCS security reference shall be used. When ext_hdr is set to 1, then the GCS security reference is indicated by sec_ref field. | Fragmentation info (fragment_info) . | Mnemonic | Presence M/O/C | Length | Value | . | fragment_info | Cis_fragment is set to 1 | 1B | reserved | . The value indicates the fragment number and the total number of fragmented packets. | . NOTE: The current release of the protocol does not support frame fragmentation. The field is_fragmented shall be set to 0 so fragment_info is not included in the network frame format. 5.1.2.2.2 Authentication fields . “Authentication” part of the frame may have three different formats based on the configuration included in the “Frame control” block and also the sec_ref field which is included only in case ext_hdr is set to 1. It is possible for the “Authentication” part not to be included in the Network Layer. The possible configurations are as follows: . | ext_hdr is set to 0 and: . | auth_code_size > 0 then the configuration includes auth_code field only in “Authentication” block (see fig 5.16). | auth_code_size is set to 0 then the configuration excludes the whole “Authentication” block from the Network Layer frame. | . | ext_hdr is set to 1, auth_code_size > 0 this configuration applied in “Frame control” indicates the presence of sec_ref in the “Authentication” block. This configures the final format of the “Authentication” block: . | sec_ref is set to 0 then the configuration includes auth_code field (see fig 5.17). | sec_ref is set to 1 then the configuration includes counter_val and auth_code fields (see fig 5.18). | . | . fig 5.16 Network layer - Authentication - Authentication code . fig 5.17 Network layer - Authentication - Security reference GCS . fig 5.18 Network layer - Authentication - Security reference COUNTER . | Authentication code (auth_code) . | Mnemonic | Presence M/O/C | Length | Value | . | auth_code | Cext_hdr is set to 0 auth_code_size >0 | see auth_code_size field | authentication code | . The field contains the value of the authentication code. | Security reference information (sec_ref) . | Mnemonic | Presence M/O/C | Length | Value |   |   | . | sec_ref | C ext_hdr is set to 1 | 1B | Bit number | Bit value | Description | . | sec_ref | C ext_hdr is set to 1 | 1B | 7 | 0 | security reference GCS | . | sec_ref | C ext_hdr is set to 1 | 1B | 7 | 1 | security reference COUNTER | . | sec_ref | C ext_hdr is set to 1 | 1B | 0 to 6 |   | reserved | . The field indicates the security reference configuration. The default value of the GCS security reference is 0. | Counter value (counter_value) . | Mnemonic | Presence M/O/C | Length | Value | . | counter_val | Cext_hdr is set to 1 auth_code > 0 sec_ref is set to 1 | 4B | counter value | . The field contains the counter value. | . 5.1.2.2.3 Network Layer Frame payload field (frame_pld) . fig 5.19 Network layer - Payload . | Mnemonic | Presence M/O/C | Length | Value | . | frame_pld | M | 1 — 221B | Presentation layer frame | . The field contains Presentation Layer frame data. NOTE: The current release of the protocol shall have the Presentation Layer frame included in the Network Layer payload. 5.1.2.2.4 Network Layer configuration . Three generic formats of the Network Layer are possible based on the “Frame control” part: . | The security information is not included in the frame: auth_code_size = 0, ext_hdr = 0. The frame contains only “Frame control” and “Frame payload” parts (see figure 5.20). fig 5.20 Network layer - Frame format - Case 1 . | The security information is included but an extended header is not present: auth_code_size > 0, ext_hdr = 0. The frame contains the following parts: “Frame control” , “Authentication” and “Frame payload” (see figure 5.21). fig 5.21 Network layer - Frame format - Case 2 . | The security information is included in the extended header: auth_code_size > 0, ext_hdr = 1. Additionally sec_ref configures the format of “Authentication” block.figure 5.22 shows the case when sec_ref is set to 0 and figure 5.23 shows the case when sec_ref is set to 1. The frame contains all parts: “Frame control”, “Authentication” and “Frame payload”. fig 5.22 Network layer - Frame format - Case 3A . fig 5.23 Network layer - Frame format - Case 3B . | . 5.1.3 Link Layer . The Link Layer is involved in Gateway discovery, maintenance, and link establishment for message exchange between two Endpoints. These functions are handled by two separate frame formats: Beacon frame format and message frame format. The Beacon frame format is used for broadcasting status, and for broadcasting radio configuration parameters. Endpoints use the information in the Beacon frame to choose a Gateway. Information from the Beacon frame is used for maintenance of the Gateway-Endpoint connection, such as power control or channel hopping. The Beacon frame also informs about the state of the Gateway - for example, indicating congestion. The message frame format is used for data exchange and data reception acknowledgement at the Link Layer level. The frame used for data exchange includes higher layer frames. The frame used for acknowledgement is terminated at the Link Layer level and does not contain a frame payload. Acknowledgements are sent between a Gateway and an Endpoint. Acknowledgements are only used with synchronous transmission. Asynchronous transmission type shall not use Acknowledgements. 5.1.3.1 Beacon Frame format . The frame is divided into different parts containing the Beacon-specific information as depicted in figure 5.24. The first one is “Frame control”, that provides information that allows correct decoding and interpretation of the frame. “Source address” and “Destination address” identify the sender of the Beacon and the PAN ID, which are part of the Gateway’s owner identification. “Connection status” provides information related to Gateway connection status to the cloud, its load, operation mode (synchronous/asynchronous or synchronous only) and roaming settings. “Power control” provides information on the antenna and power settings used by the Gateway. “Hopping parameters” contain values needed for calculation of an active channel used for uplink or downlink transmission. “Data and Security control” identifies the presence of optional “Data” part and also data size included in “Security”. “Data” is a container of all optional data that could be transmitted by the Gateway. “Security” contains a tag authenticating the Gateway for devices registered to the Gateway owner’s account. fig 5.24 Link layer - Beacon - Blocks . 5.1.3.1.1 Link Layer Frame Control Fields . fig 5.25 Link layer - Beacon - Frame control . | Frame type (frame_type) . | Mnemonic | Presence M/O/C | Length | Value |   |   |   | . | frame_type | M | 3b | Bit | Bit | Bit | Description | . | frame_type | M | 3b | 0 | 0 | 0 | no auth code | . The value indicates the frame type. | Protocol Version (prot_ver) . | Mnemonic | Presence M/O/C | Length | Value |   |   |   |   | . | prot_ver | M | 4b | Bit | Bit | Bit | Bit | Description | . | prot_ver | M | 4b | 0 | 1 | 0 | 0 | Halo 2.0 protocol version | . The value of the protocol version indicates the Amazon Sidewalk Protocol version number. An Endpoint that receives the Beacon frame with a protocol version which is different from the supported one shall neither decode the frame nor join to the Gateway. | SubG-FSK version (hdr_ver) . | Mnemonic | Presence M/O/C | Length | Value | . | hdr_ver | M | 1B | 0x0 | . The value of the SubG-FSK version indicates the version of SubG-FSK supported by the Gateway. SubG-FSK version identifies the Beacon, hopping pattern and PHY version supported by the Gateway. | . 5.1.3.1.2 Beacon Source address field (src) . fig 5.26 Link layer - Beacon - Source address . | Mnemonic | Presence M/O/C | Length | Value | . | src | M | 5B | global device ID | . The value indicates the device ID of the Gateway that is sending the Beacon. 5.1.3.1.3 Beacon Destination address field (dst) . “” . fig 5.27 Link layer - Beacon - Destination address . | Mnemonic | Presence M/O/C | Length | Value | . | dst | M | 5B | PAN ID | . The value indicates the globally unique PAN ID. 5.1.3.1.4 Beacon Connection status fields . fig 5.28 Link layer - Beacon - Connection status . | Roaming Support (roam_opt) . | Mnemonic | Presence M/O/C | Length | Value |   | . | roam_opt | M | 1b | Bit value | Description | . | roam_opt | M | 1b | 0 | roaming forbidden | . | roam_opt | M | 1b | 1 | roaming allowed | . The value of the roaming support indicates whether the Gateway transfers packets between roaming Endpoints and the Amazon Sidewalk Cloud. | . NOTE: An Endpoint device that is roaming shall not attempt to connect to a Gateway that does not support roaming. If a Gateway has roaming disabled, then the Gateway can recognize roaming devices and drop packets from roaming devices. | Cloud connection indicator (cloud_conn) . | Mnemonic | Presence M/O/C | Length | Bit value | Description |   | . | cloud_conn | M | 2b | 0 | 0 | disconnected | . | cloud_conn | M | 2b | 0 | 1 | experiencing recent intermittent disconnects | . | cloud_conn | M | 2b | 1 | 0 | connected in “Distress Gateway” mode | . | cloud_conn | M | 2b | 1 | 1 | connected | . The value of the cloud connection indicator indicates the Gateway-cloud connection condition. Endpoints may use this indicator while selecting a Gateway. For more information on the “Distress Gateway” mode, see section 5.6.5. | Load indicator (load_ind) . | . | Mnemonic | Presence M/O/C | Length | Bit value | Bit value | Description | . | load_ind | M | 2b | 0 | 0 | light traffic | . | load_ind | M | 2b | 0 | 1 |   | . | load_ind | M | 2b | 1 | 0 |   | . | load_ind | M | 2b | 1 | 1 | heavy traffic | . The value of the load indicator indicates the traffic load of the Gateway. | Gateway operation mode (op_mode) . | Mnemonic | Presence M/O/C | Length | Bit value | Description | . | op_mode | M | 1b | 0 | synchronous and asynchronous mode | . | op_mode | M | 1b | 1 | synchronous mode | . The value of the Gateway operation mode indicates the modes of communication actively supported by the Gateway. The Gateway may be in synchronous transmission mode and not supporting asynchronous transmission mode, or the Gateway may be in preamble cycling mode. In preamble cycling mode, the Gateway cycles between synchronous and asynchronous transmission modes. (See section 5.2 and section 5.3.) . | . 5.1.3.1.5 Beacon Power control fields . fig 5.29 Link layer - Beacon - Power control . | SubG-FSK downlink EIRP (hdr_dl_erp) . | Mnemonic | Presence M/O/C | Length | Value | . | hdr_dl_erp | M | 4b | 0x0 – 0xF | . The value of the power control fields indicates the effective isotropic maximum radiated power of the Gateway used for the current Beacon round. EIRP in dBm = hdr_dl_erp * 4 . | SubG-FSK uplink power adjustment (hdr_ul_adj) . | Mnemonic | Presence M/O/C | Length | Value | . | hdr_ul_adj | M | 4b | 0x0 – 0xF | . The value of the SubG-FSK uplink power adjustment indicates the offset from ideal sensitivity in dB due to interference the Gateway is receiving. Adjustment in dB = hdr_ul_adj * 4 . | . 5.1.3.1.6 Beacon Hopping parameters fields . fig 5.30 Link layer - Beacon - Hopping parameters . | Hopping seed . | Mnemonic | Presence M/O/C | Length | Value | . | hdr_hop_seed | M | 4B | 0x0 – 0xFFFFFFFF | . The Hopping seed field contains the value of the seed used in the channel hopping algorithm, described in section 5.2.4. | Hopping sequence number . | Mnemonic | Presence M/O/C | Length | Value | . | hdr_hop_sequence_num | M | 2B | 0x0 – 0xFFFF | . The value of the Hopping sequence number field contains the value of the sequence number used in the channel hopping algorithm, described in section 5.2.4. | . 5.1.3.1.7 Beacon Data and Security control fields . fig 5.31 Link layer - Beacon - Data and Security control . | Data flag (data_inc) . | Mnemonic | Presence M/O/C | Length | Value |   | . | data_inc | M | 1b | Bit value | *Description | . | data_inc | M | 1b | 0 | Data is not included | . | data_inc | M | 1b | 1 | Data is included | . The value of the Data flag indicates the existence of optional data in the frame. | PAN authentication tag length (auth_tag_len) . | . | Mnemonic | Presence M/O/C | Length | Bit value | Description |   | . | auth_tag_len | M | 2b | 0 | 0 | 4B | . | auth_tag_len | M | 2b | 0 | 1 | 8B | . | auth_tag_len | M | 2b | 1 | 0 | 12B | . | auth_tag_len | M | 2b | 1 | 1 | 16B | . The value indicates the size of pan_auth_tag in the Security part of the frame. 5.1.3.1.8 Beacon Data fields . fig 5.32 Link layer - Beacon - Data - Case 1 . fig 5.33 Link layer - Beacon - Data - Case 2 . | Data length (data_len) | . | Mnemonic | Presence M/O/C | Length | Bit value | Description |   | . | data_len | Cdata_inc is set to 1 | 2b | 0 | 0 | 1B | . | data_len | Cdata_inc is set to 1 | 2b | 0 | 1 | 2B | . | data_len | Cdata_inc is set to 1 | 2b | 1 | 0 | 4B | . | data_len | Cdata_inc is set to 1 | 2b | 1 | 1 | data size is indicated in data_len_ext field | . The value of Data length indicates the size of the data_val field. | Data type (data_type) . | Mnemonic | Presence M/O/C | Length | Value | Description | . | data_type | Cdata_inc is set to 1 | 6b | 0x1 | SubG-FSK-synchronous CS schedule | . The value of the Data type field indicates the data type included in the data_val field. | Data length extension (data_len_ext) . | Mnemonic | Presence M/O/C | Length | Value | . | data_len_ext | Cdata_inc is set to 1 data_len is set to 0x3 | 1B | size of data_val field | . The value of the Data length extension field indicates the size of the data_val field. | Data value (data_val) . | Mnemonic | Presence M/O/C | Length | Value | . | data_val | Cdata_inc is set to 1 | see data_len or data_len_ext | optional data values | . The value of the Data value field contains the optional data value. The length of the field is indicated in data_len or data_len_ext. The field value for “SubG-FSK-Synchronous CS schedule” for the ad hoc access model is coded as follows: . 1B:  offset . 1B:  periodicity . 1B: CS-DL offset . 1B: CS-DL periodicity . | . 5.1.3.1.9 Beacon Security field (pan_auth_tag) . fig 5.34 Link layer - Beacon - Security . | Mnemonic | Presence M/O/C | Length | Value | . | pan_auth_tag | M | see auth_tag_len field | authentication tag value | . The security field contains the value of the authentication tag. 5.1.3.2 Message frame format . The frame format has the following components: . | “Frame control” provides information that allows decoding of the frame and also controls the frame reception acknowledgment. | “Source address” and “Destination address” identify both ends of the communication link. | “Sequence number” contains the uplink or downlink message number that allows control of the correct sequence of data transmission and reception. | “Frame payload” contains data from upper layers. | . fig 5.35 Link layer - Message - Blocks . 5.1.3.2.1 Message Frame Control Fields . fig 5.36 Link layer - Message - Frame control . | Frame type (frame_type) | . | Mnemonic | Presence M/O/C | Length | Bit value | Bit value | Bit value | Description | . | frame_type | M | 3b | 0 | 0 | 1 | Data | . | frame_type | M | 3b | 0 | 1 | 0 | Network Data | . | frame_type | M | 3b | 0 | 1 | 1 | ACK | . The value of Frame type indicates the frame type. Based on this parameter, other fields in the frame may be optional or not present. | Epoch frame flag (epoch_bit/reserved) | . | Mnemonic | Presence M/O/C | Length | Bit value | Description | . | epoch_bit/reserved | M | 1b | Asynchronous mode uplink only: | Asynchronous mode uplink only: | . | epoch_bit/reserved | M | 1b | 0 | Non-Epoch frame | . | epoch_bit/reserved | M | 1b | 1 | Epoch frame | . |   |   |   | Synchronous uplink or downlink and asynchronous downlink mode: | Synchronous uplink or downlink and asynchronous downlink mode: | . | epoch_bit/reserved | M | 1b | 0 | reserved | . The Epoch frame flag field is valid for the data frame format, with uplink direction in asynchronous mode only. The Epoch frame flag indicates whether the frame is used for the Endpoint to provide a time reference to the Gateway to synchronize Target Transmission Times. The field is reserved and should be set to 0 for all other cases. Specifically: . | Data frame format in synchronous mode and asynchronous mode in the downlink direction. | Network Data frame format for synchronous mode and asynchronous mode. | ACK frame format. | . NOTE: The Epoch frame flag field shall always be set to 0 for synchronous mode. | Protocol version (prot_ver) . | Mnemonic | Presence M/O/C | Length | Bit value | Description |   |   |   | . | prot_ver | M | 4b | 0 | 1 | 0 | 0 | Halo 2.0 protocol version | . The Protocol version value indicates the Amazon Sidewalk Protocol version number. | . NOTE: The current version of the specification supports only one protocol version. | Source field format (src_frmt) . The Source field format value indicates the sender of the data packet and additionally gives information about the src field format. | . | Mnemonic | Presence M/O/C | Length | Bit value | Description |   | . | src_frmt | M | 2b | 0 | 0 | cloud | . | src_frmt | M | 2b | 0 | 1 | global device ID | . | src_frmt | M | 2b | 1 | 0 | reserved | . | src_frmt | M | 2b | 1 | 1 | reserved | . | Destination field format (dst_frmt) | . | Mnemonic | Presence M/O/C | Length | Bit value | Description |   | . | dst_frmt | M | 2b | 0 | 0 | cloud | . | dst_frmt | M | 2b | 0 | 1 | global device ID | . | dst_frmt | M | 2b | 1 | 0 | reserved | . | dst_frmt | M | 2b | 1 | 1 | reserved | . The Destination field format value indicates the recipient of the data packet and gives information about the dst field format. When the cloud is the target, the Link Layer ACK response is sent by the Gateway. The message reception confirmation done by the cloud is handled in higher layers. | Network frame flag (nwk_frame_ctrl) . | Mnemonic | Presence M/O/C | Length | Bit value | Description | . | nwk_frame_ctrl | M | 1b | 0 | frame_pld field is not present | . | nwk_frame_ctrl | M | 1b | 1 | frame_pld field is present | . This Network frame flag field indicates whether the Link Layer frame includes the Network Layer frame. The field is valid for “Data” and “Network Data” frame types only and shall be set to 1. ACK frame type shall always be set to 0. Acknowledgement does not transport any data from higher layers. | Message acknowledge request (ack_req) . | Mnemonic | Presence M/O/C | Length | Value |   | . | ack_req | M | 1b | Bit value | Description | . | ack_req | M | 1b | 0 | ACK not requested | . | ack_req | M | 1b | 1 | ACK requested | . The Message acknowledge request field indicates whether a Link Layer acknowledgement of the message reception is requested. The acknowledgement may be requested for messages sent in synchronous connection mode only. The field shall always be set to 0 in messages sent in asynchronous connection mode. The Message acknowledge request field is valid for data and network data frame formats only. The Message acknowledge request field is set to 1 by default for the following destinations: cloud and global device ID. ACK frame type should always be set to 0 and has no meaning in this case. | . 5.1.3.2.2 Message Source address field (src) . fig 5.37 Link layer - Message - Source address . | Mnemonic | Presence M/O/C | Length | Value | . | src | M | 1 – 5B | 3 most significant bits of the first byte specify the field size. | . The Source address field contains the source address of the frame. The Source address format is indicated by the src_frmt field. 5.1.3.2.3 Message Destination address field (dst) . fig 5.38 Link layer - Message - Destination address . | Mnemonic | Presence M/O/C | Length | Value | . | dst | M | 1 – 5B | 3 most significant bits of the first byte specify the field size. | . The Destination address field contains the destination address of the frame. The Destination address format is indicated by the dst_frmt field. 5.1.3.2.4 Message Sequence number field (seq_num) . fig 5.39 Link layer - Message - Sequence number . | Mnemonic | Presence M/O/C | Length | Value | . | seq_num | M | 1 – 3B | 2 most significant bits of the first byte specify the field size. | . The sequence number field indicates the sender’s packet sequence number. The ACK frame type shall have a seq_num copy of the frame where acknowledgement was requested. 5.1.3.2.5 Message Link Layer Frame payload field (frame_pld) . fig 5.40 Link layer - Message - Frame payload . | Mnemonic | Presence M/O/C | Length | Value | . | frame_pld | Cnwk_frame_ctrl is set to 1 | 0 – 240B | Network Frame bytes | . This field contains the frame payload which includes the Network Layer Frame. This field can be included only if nwk_frame_ctrl is set to 1. This field is not present in the ACK frame format. 5.1.4 Physical layer . The Amazon Sidewalk protocol uses a sub-GHz UHF band, ITU [1] ISM band 9 for signal transmission. Two modulation techniques in sub-GHz are defined by 802.15.4 standard [2] as follows: . GFSK (Gaussian Frequency Shift Keying) modulation is used in SubG-FSK, and LoRa [3] modulation is used in SubG-CSS. For more information, see section 5.7. In both cases, half-duplex (HDX) transmission schemas are implemented to allow multi-user access. In both cases, the RF frame consists of preamble, sync word, header, payload (Link Layer Frame) and optional Frame Check Sequence (FCS). fig 5.41 RF frame . The RF frame length is limited by regional certification authority requirements for airtime occupation. See ETSI EN 300 220-2 and FCC part 15.247 for details. Allowed airtime and power levels depend on the region and operating bands. For more information, see section 5.7. An additional timing correction path is implemented because transmitter and receiver clocks are not synchronized and their frequencies drift. For more information, see section 5.1.4.3. 5.1.4.1 Data order . Bit order: i.e. byte ’e’ (0x65, 01100101 B) is presented at the baseband bus timeline as data sequence (see fig 5.42). 5.42 Bits order . Byte order: Little endian is defined in the PHY frame [2]. 5.1.4.2 RF frame formats . The physical frame is built as follows: The physical header (optionally precoded) is attached to a predefined preamble. Then, RF channel code is specified then the buffered data packet is channel encoded. The Frame Check Sequence is calculated and attached to the end of the frame. The baseband RF frame is sent to the modulator and up-converted to the preselected RF channel. NOTE: Preamble, channel coding and FCS calculation are HW implemented. Four steps are necessary for proper RF data reception. First, the receiver must synchronize its demodulator with preamble signal. The next step is to demodulate and decode header to gather information regarding receiving frame. Then, payload can be properly received. Correctness of transmission is confirmed by calculation of Frame Check Sequence at the end. After FCS evaluation link layer data content can be passed for further processing or discarded. RF frame consists of five segments: . | Preamble - for bit synchronization, can be repeated for improving receiver synchronization and probability of reception (due to physical aspects: time drift, multipath effect, etc.); | Sync Word - mark for start of data block; | PHY Header - contains PHY data control bits; | PHY payload - Link Layer Frame; | FCS (Frame Check Sequence) - data block checksum. | . The content and length of each segment depends on predefined modulation scheme. 5.1.4.2.1 Sub-G FSK frame format details . Bit ’1’ is represented as positive frequency shift (+dev/2 Hz), bit ’0’ - as negative frequency shift against center frequency F0. The SubG-FSK PHY frame format follows IEEE 802.15.4. Preamble is followed with PHY layer header and data field. The frame is completed with a Frame Check Sequence (FCS). The field description details are as follows: . | Preamble . Preamble consists of multiple bytes: 0x55, 01010101 B. Preamble can be extended for time drift compensation. | Synchronization Word . Synchronization Word (defined in [2] as SFD - Start Frame Delimiter). SFD is 2 B length. | FEC disabled 0x904E (default value). | . | PHR PHY header . PHY header consists of 16 bits (2 B). | 0-2 RSVD (0 default); | 3 FCS type: 0-32 bits, default value: 1-16bit; | 4 Data whitening: 0- disabled; 1-PN9 sequence with 0xF as starting condition is used (default value); | 5-15 PSDU length (only 251 B are available in the present version of the specification). | . | Payload . The payload length is defined by PSDU length of PHY header, the payload is scrambled if Data whitening of PHY header is set. The maximum payload length is 251 B. | FCS Frame check sequence . | FCS type 1: Polynomial x16+x12+x5+1 (CCITT) is used for 16 bit FCS, default value; | FCS type 0: In case of 32bit FCS then ANSI X3.66-1979 shall be used. | . | . 5.1.4.2.2 SubG-FSK Airtime summary . RF data rate is: 50 kbps, Application layer MTU size is up to 200 B; . PHY frame length is up to 251 B, < 55.12ms (14ms preamble). 5.1.4.2.3 SubG-CSS frame format details . LoRa symbols are used for SubG-CSS. LoRa symbols are composed of chirps. Detailed LoRa uplink PHY frame format is described in Application Note AN1200.22 [3]. Preamble is followed by PHY layer header (PHDR), then calculated PHDR_CRC is placed. The next data field is attached. Uplink frame is completed with a CRC. With current implementation, only SF11 with Coding Rate (CR) 4/5 is used. The field description details are as follows: . | Preamble . The number of preamble symbols is programmable. Downlink Preamble can vary between 8 - 23 symbols in order to compensate for any timing error. Uplink Preamble contains 16 symbols. | Synchronization Word contains value 0x34. | PHY header . PHDR - contains 6 symbols. PHDR_CRC - 16 bit CRC. PHY header is protected by 4/8 CRC. | PHY Payload . PHY payload - contains encapsulated higher layer frame. Max Payload size is 44 B for SF 11. | CRC . Polynomial x16+x12+x5+1 is used for 16 bit CRC calculation. If 8 bit CRC is used, then last 8 bits of 16 bit CRC are used. The default value for CRC is 16 bits. | . Upchirps are used in the uplink, downchirps in the downlink. In the downlink, the symbols are IQ inverted. This is done to achieve orthogonality between uplink and downlink signals. 5.1.4.2.4 SubG-CSS Airtime summary . RF data rate is < 1760 bps, PDU size up to 44 B; . Uplink PHY frame duration is: 279.552 ms (preamble 16 symbols, data 44 B); . Downlink PHY frame duration is: 246.784 ms (preamble 8 symbols, data 44 B), 308,224 ms (preamble 23 symbols, data 44 B). 5.1.4.3 Time drift . In synchronous mode the transmitter chooses timing of packet’s preamble in accordance with expected receivers listening window. fig 5.43 No timedrift . Due to oscillator (XO) frequency offsets and drifts multiplied by MCU clock generator internally calculated in Endpoint RF frame timings can be biased with error which exceed system requirements. When frequency disparity between two nodes exceeds the specifications of +/-100 ppm, the Endpoint may not have enough preamble symbols, resulting in a packet loss. The time drift between the nodes is impacted by calibration errors between the hardware and temperature-dependent oscillation frequency variations. The Amazon Sidewalk SDK provides two mechanisms for bounding the drift: . | Temperature compensation: Internal Endpoint RTC compensation based on calibration table and measuring circuit temperature in 10 s intervals. Procedure is valid for each state of connection (asynchronous and synchronous). | Link layer offset compensation: Compensate for any timing error between the Gateway and the Endpoints. Measured drift constitutes time offset to apply for an Endpoint’s upcoming link layer operations. | . For SubG-CSS, TX drift compensation is implemented (additional 30 ms preamble length is added). RX window size must cover possible worst case scenarios: 30 ms TX time advance due to clock rushing out and 30 ms additional TX time extension due to extended preamble. fig 5.44 Timedrift compensation . ", "url": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/protocol-stack-layers-and-structure.html", "relUrl": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/protocol-stack-layers-and-structure.html" },"745": { "doc": "2. Purpose", "title": "2. Purpose", "content": "The purpose of the feature is to abstract the connection establishment and connection maintenance behavior of the links supported by Amazon Sidewalk stack to the developer of the Amazon Sidewalk stack. The developer is provided with varied degrees of flexibility to control not only the behavior of the connection of the links but also the transfer of messages over the links. ", "url": "/app-notes/multi-link/purpose.html", "relUrl": "/app-notes/multi-link/purpose.html" },"746": { "doc": "Qualification Process", "title": "On Amazon Sidewalk qualification process", "content": "There are two types of On Amazon Sidewalk qualification. | On Amazon Sidewalk end-product qualification A design receives this qualification when it meets all requirements for the On Amazon Sidewalk qualification. | On Amazon Sidewalk subsystem qualification A design receives this qualification when it only partially meets the requirements for the On Amazon Sidewalk qualification. | . A new Sidewalk end-product can inherit some of it’s functionality from an existing design that’s qualified for use with Amazon Sidewalk. This qualification only indicates that a design doesn’t implement the required functionality to be used as an end-product. It can also add new parts to the already existing functionality. A design that has an On Amazon Sidewalk end-product qualification can be reused as part of another qualification listing. For more information, see Donor qualification listing. ", "url": "/qualification/on-amazon-sidewalk/qualification-works-path.html#on-amazon-sidewalk-qualification-process", "relUrl": "/qualification/on-amazon-sidewalk/qualification-works-path.html#on-amazon-sidewalk-qualification-process" },"747": { "doc": "Qualification Process", "title": "Steps to Amazon Sidewalk qualification", "content": "For your designs to be qualified, each design can follow a unique path, either by inheriting some or all tests from a donor certification, or by using different test facilities, or by taking advantage of different test specification waivers. The following steps outline the process for qualification: . | Define a product that requires capabilities of the Sidewalk network. It can be either a new product, or adding functionality to an existing product. | Download the Sidewalk protocol specifications, test specifications, and the qualification requirements documents. Agree to the Sidewalk Developer Terms. | Choose a Silicon provider from the list of Silicon providers. Visit the Silicon provider’s website and sign up for support. | Purchase a development kit and download the Sidewalk SDK from the Silicon provider. | Create a prototype product. Register the prototype as a development platform and obtain the development keys. | The designer verifies that the device complies with the Sidewalk requirements as detailed in Sidewalk test specifications. This step is done by the developer to avoid unnecessarily repeating tests at a test facility. | Click here to submit a qualification request. If you don’t already have a Sidewalk360 login, click here to Signup and we will get you set up with an account. | Contact the Amazon test facility to ship three test samples. Work with the test facility to pass the qualification tests for the Sidewalk functionality that the product implements. | Submit the qualification fee and test evidence, and then obtain the On Amazon Sidewalk qualification badge. | . Currently the Sidewalk Qualification process does not require payment of a fee. ", "url": "/qualification/on-amazon-sidewalk/qualification-works-path.html#steps-to-amazon-sidewalk-qualification", "relUrl": "/qualification/on-amazon-sidewalk/qualification-works-path.html#steps-to-amazon-sidewalk-qualification" },"748": { "doc": "Qualification Process", "title": "Qualification Process", "content": " ", "url": "/qualification/on-amazon-sidewalk/qualification-works-path.html", "relUrl": "/qualification/on-amazon-sidewalk/qualification-works-path.html" },"749": { "doc": "8. References and Appendix", "title": "8. References", "content": ". | Amazon Sidewalk Manufacturing documentation: docs.sidewalk.amazon/manufacturing/ | Amazon Sidewalk Protocol Specification, sections 4.1.2 (Certificate chain) and 4.3.2 (Sidewalk Manufacturing Serial Number (SMSN)) of that document | Amazon Sidewalk Program Security Requirements: docs.sidewalk.amazon/sidewalk-terms-and-agreements/security-program-requirements.html | AWS IoT Core Developer Guide, Bulk provisioning devices with AWS IoT Core for Amazon Sidewalk: docs.aws.amazon.com/iot/latest/developerguide/sidewalk-bulk-provisioning.html | SDK interfaces: sid_serial_registration.h, sid_serial_ifc.h, sid_on_dev_cert_cli.h | Amazon Sidewalk 360 portal: 360.sidewalk.amazon | Amazon Sidewalk SID API Developer Guide, Section 2.15 (Build configuration for factory-registered Endpoints and lite variants) | . ", "url": "/app-notes/registration-over-wire/references-and-appendices.html#8-references", "relUrl": "/app-notes/registration-over-wire/references-and-appendices.html#8-references" },"750": { "doc": "8. References and Appendix", "title": "9. Appendix", "content": " ", "url": "/app-notes/registration-over-wire/references-and-appendices.html#9-appendix", "relUrl": "/app-notes/registration-over-wire/references-and-appendices.html#9-appendix" },"751": { "doc": "8. References and Appendix", "title": "9.1 Device states and registration lifecycle", "content": "device onboard performs four stages in one session on the host interface. The device is fully written before any call to the Amazon Sidewalk cloud. | Manufacturing data. The device derives its SMSN and generates CSRs (ED25519 and P256R1). The CSRs are signed with the product DAK in the YubiHSM, and the resulting Sidewalk certificate chains are written back to the device. | Control log. The SMSN, APID and Sidewalk certificate chains are submitted to the Amazon Sidewalk cloud. | Provisioning. The wireless device record is created in AWS IoT Core for Amazon Sidewalk, identified by the SMSN. | Registration. The encrypted registration handshake completes, and the device is factory-registered. | . These stages map onto the Sidewalk device lifecycle described in the Amazon Sidewalk Manufacturing documentation: the control log stage reaches the device created state, the provisioning stage reaches the device associated with account state, and the registration stage reaches the device registered state. For a factory-registered device, the registered state is reached on the factory line rather than in the field. In the field, the device performs field activation automatically on first contact with the network over BLE, FSK or LoRa, with no action from the end user. Field activation requires Amazon Sidewalk coverage at the deployment site. Never attempt mobile application or FFN registration on a factory-registered device. ", "url": "/app-notes/registration-over-wire/references-and-appendices.html#91-device-states-and-registration-lifecycle", "relUrl": "/app-notes/registration-over-wire/references-and-appendices.html#91-device-states-and-registration-lifecycle" },"752": { "doc": "8. References and Appendix", "title": "9.2 Troubleshooting", "content": "The following table lists the most common failures that are not caused by the firmware. Firmware bring-up errors are described in Section 6.1.5. | Symptom | Likely cause | Resolution | . | LWA login denied: ... (lwa-invalid-parameter-bad-redirect-uri-vendor ...) | http://localhost:8000/ is not registered under Allowed Return URLs on the security profile | Add http://localhost:8000/ to Allowed Return URLs (Section 3.2) | . | LWA login denied: ... invalid parameter : scope at the browser login, or LWA client_credentials returned 400: ... at the first control log upload | The security profile is not yet allow-listed for the named scope (Section 3.3) | Complete Section 3.3 with Amazon Sidewalk support, and wait for confirmation | . | no LWA tokens cached on a device command | The browser login was skipped during configure, or the cached refresh token has expired | Run sid-mfg-tool configure again and complete the browser login (Chapter 4) | . | /StartFactoryRegistration returned HTTP 403: '' (empty body), and the device was provisioned with a prototype device profile | ROW is not supported for prototype devices. A prototype device profile has no factory support or APID, so authorization always fails | Create a production device profile, complete factory support (Section 3.5), and provision devices against it | . | /StartFactoryRegistration returned HTTP 403: '' (empty body) on the first attempt, with factory support already enabled | Your vendor or LWA application is not yet authorized for the APID of your product | Contact Amazon Sidewalk support to complete vendor onboarding (Section 3.3) before the factory run | . | could not resolve AWS profile in configure | The named AWS CLI profile is missing or expired. The tool does not fall back to the default credential chain | Fix the profile in ~/.aws, then run aws sts get-caller-identity --profile <name> | . | HSM connector error or connection refused | yubihsm-connector is not running, or the connector URI in the configuration is wrong | Start the connector, run curl <connector>/connector/status, and check configure --show | . | HSM authentication failed -- the PIN may be wrong. | Wrong DAK PIN | Run configure again and enter the DAK PIN from the HSM handoff | . | failed to open HSM session: Can't find the Signer with <tag> | The configured product name does not match the product tag of the DAK in this HSM | Run configure again and enter the product tag from the HSM handoff | . | SEGGER J-Link software not found | The tool drives the J-Link probe through the JLinkARM library of the SEGGER J-Link Software pack, which is not installed on the line PC | Install the J-Link Software and Documentation Pack in its standard location (Chapter 4) and run the command again | . | J-Link with serial <N> is not connected (connected probes: ...) | --address does not match the serial number of an attached probe; the message lists the probes found | Use the serial number printed on the probe or development kit, and check its connection to the line PC | . | cannot open J-Link <N>: ... | Another program owns the probe | Close J-Link RTT Viewer, J-Link Commander, RTT Logger and Simplicity Studio; a probe serves one host program at a time | . | transport 'rtt' needs jlink_device | The tool is run with --transport rtt or with rtt as the default transport, but no J-Link device name is configured | Run configure again, choose transport rtt and enter the J-Link device name of the MCU | . | RTT control block not found within 5.0s | The device is not powered or not running, the image is not an RTT image of the Factory Diagnostic Firmware, or jlink_device names a different MCU | Power-cycle the device, confirm the flashed image, and check jlink_device with configure --show | . ", "url": "/app-notes/registration-over-wire/references-and-appendices.html#92-troubleshooting", "relUrl": "/app-notes/registration-over-wire/references-and-appendices.html#92-troubleshooting" },"753": { "doc": "8. References and Appendix", "title": "10 Change History", "content": "| Version | Summary of Changes | . | Protocol Stack 1.0, Document Revision A | First release of the Registration over Wire Application Note. Supersedes the sid-mfg-tool ROW Customer Onboarding Guide. | . ", "url": "/app-notes/registration-over-wire/references-and-appendices.html#10-change-history", "relUrl": "/app-notes/registration-over-wire/references-and-appendices.html#10-change-history" },"754": { "doc": "8. References and Appendix", "title": "Glossary", "content": "| Term | Definition | . | Amazon FFS | Amazon Frustration-Free Setup: the Amazon program whose developer console hosts control log onboarding. Distinct from Sidewalk FFS, the registration path over FSK (Section 6.2) | . | APID | Advertised Product ID: 4-character alphanumeric product identifier, linked to the device profile by Amazon as part of factory support | . | BLE | Bluetooth Low Energy (Bluetooth LE); Sidewalk link type 1 | . | CM | Contract Manufacturer | . | Control log | Manufacturing record (SMSN, APID and Sidewalk certificate chains) ingested by the Amazon Sidewalk cloud | . | DAK | Device Attestation Key: certificate authority key for a device type, stored in the YubiHSM for production devices | . | DeviceTypeId | Device type identifier vended by Amazon together with the HSM; an input to the SMSN | . | DSN | Device Serial Number: unique per-device serial number assigned by the device maker | . | DUT | Device Under Test: the device connected to the line PC during manufacturing | . | Factory Diagnostic Firmware | Firmware flashed on the device during manufacturing that generates the device key pairs and CSRs and, for ROW, runs serial registration | . | Factory registration | Registration of a device on the factory line using ROW, before shipment | . | Factory support | Configuration of a device profile by Amazon for production (APID linkage and production DAK provisioning) | . | FFN | Frustration-Free Networking: touchless in-field registration | . | Field activation | Automatic activation of a factory-registered device on its first contact with the Amazon Sidewalk network, with no end user action | . | FSK | Sub-GHz frequency-shift keying (SubG-FSK), synchronous mode; Sidewalk link type 2 | . | HSM | Hardware Security Module (YubiHSM 2) holding the production DAK | . | J-Link | SEGGER debug probe through which the line PC reaches the MCU over the debug port; built into many development kits, or used as an external unit. ROW uses it for the RTT host interface | . | KV store | Device non-volatile storage for Sidewalk runtime state; at security-level-high, the only copy of the registration credentials | . | Line PC | Computer on the factory line that runs sid-mfg-tool and connects to the DUT | . | LoRa | Sub-GHz chirp spread spectrum (SubG-CSS), asynchronous mode; Sidewalk link type 3 | . | LWA | Login with Amazon: OAuth 2.0 authentication used by sid-mfg-tool | . | Manufacturing page | Non-volatile region holding the factory identity; at security-level-low, also a copy of the registration credentials | . | Product tag | Label identifying the DAK in the HSM (for example RNET_DAK_<PROJECT>), provided by Amazon with the DAK PIN | . | ROW | Registration over Wire | . | RTT | SEGGER Real-Time Transfer: byte channels between the MCU and a J-Link probe, read and written through the debug port. ROW uses channel 0 as the alternative to UART | . | SDK variant | Full (multi-link, sid_api.c) or lite (single link, sid_api_ble.c, sid_api_fsk.c or sid_api_lora.c) build of the Sidewalk SDK | . | Security level | security-level-high or security-level-low: determines where registration credentials are stored and how factory reset behaves; must match the SDK variant | . | SMSN | Sidewalk Manufacturing Serial Number: unique 32-byte device identifier | . ", "url": "/app-notes/registration-over-wire/references-and-appendices.html#glossary", "relUrl": "/app-notes/registration-over-wire/references-and-appendices.html#glossary" },"755": { "doc": "8. References and Appendix", "title": "8. References and Appendix", "content": " ", "url": "/app-notes/registration-over-wire/references-and-appendices.html", "relUrl": "/app-notes/registration-over-wire/references-and-appendices.html" },"756": { "doc": "8. Appendix and References", "title": "8. Appendix — Bring-up checklist", "content": "Follow these steps in order on a qualified development kit. Do not proceed past a step until you see its observable result. | Step | What you do | What you should observe | . | 0 | Confirm that GSK is enabled for your devices, and on which link. No API reports it: ask your Amazon Sidewalk contact, or open an AWS Support case against your AWS IoT Core for Amazon Sidewalk resources, supplying the device identifier, the AWS Region and the regulatory region, the link type and device profile, and the SDK version. | Confirmation of the links GSK is enabled for. | . | 1 | Include sid_gsk_config.h, then initialize with an explicit struct sid_gsk_config. Register on_status_changed, and on_control_event_notify for SID_CONTROL_EVENT_KA_ACK_STATUS (6), which delivers a struct sid_ka_ack_status whose ack_received = false marks a missed keep-alive acknowledgement. | The §5 compile-time assertions compile, and sid_init() returns SID_ERROR_NONE (0). | . | 2 | Read the effective keep-alive interval with SID_OPTION_DL_ROUTE_VALIDITY (19), is_set = false, and check idle_timeout_sec against it (§6). | nwsync_time × 60 s > idle_timeout_sec (§4). §6’s 4/3 term is margin on top of that inequality: at the LoRa Profile B default, 5 × 60 s = 300 s clears the 240 s default window, so a session still establishes, but its 60 s of slack for application traffic is short of the 25 % Figure 6.1 asks for. | . | 3 | Register the device and bring up a sub-GHz link, with a Gateway in range. | sid_get_status() reports state == SID_STATE_READY (0) and the link network-synchronized (Glossary). | . | 4 | Stop application traffic on the sub-GHz link for longer than idle_timeout_sec, in Gateway range. | SubG-CSS: a transition out of SID_STATE_READY and back, within several minutes of the lull — the idle window first, then the establishment itself (§2.1, §7) — unless the application selected MDR (§2.1), which leaves the reported status unchanged. SubG-FSK: no change in the reported status, so a working session is not visible at this step. On a SubG-CSS device that shows nothing, apply Figure 6.1, lower idle_timeout_sec and repeat from step 2; if that changes nothing, return to step 0. | . Table 8.1: GSK bring-up checklist. ", "url": "/app-notes/gateway-session-key/references-and-appendix.html#8-appendix--bring-up-checklist", "relUrl": "/app-notes/gateway-session-key/references-and-appendix.html#8-appendix--bring-up-checklist" },"757": { "doc": "8. Appendix and References", "title": "References", "content": ". | Gateway Session Key (GSK) Application Note | Keep-Alive (KA) Application Note | Amazon Sidewalk Registration over Wire — Application Note | Gateway Discovery and Selection Application Note | Sidewalk Internationalization Application Note | Amazon Sidewalk Location Library Developer Guide | Amazon Sidewalk Specification — https://docs.sidewalk.amazon/specifications/ | Amazon Sidewalk Sid API Developer Guide — https://docs.sidewalk.amazon/sid-api-dg/ | . ", "url": "/app-notes/gateway-session-key/references-and-appendix.html#references", "relUrl": "/app-notes/gateway-session-key/references-and-appendix.html#references" },"758": { "doc": "8. Appendix and References", "title": "Glossary", "content": "| Term | Definition | . | Ack-requested uplink | An uplink the stack transmitted having asked for an end-to-end response — your request_ack = true messages and several the stack sends on its own. Not GSK-specific; what the desync detector counts while a session is active (§2.2). | . | Desync fallback | Discarding the session after app_ack_miss_threshold consecutive ack-requested uplinks went unacknowledged, and running in non-GSK mode until the next establishment retry (§2.2) | . | GSK | Gateway Session Key: a symmetric session key an Endpoint and a Gateway share, used in place of Cloud-supplied authentication material to authenticate the sender of the Endpoint’s sub-GHz uplinks at the Gateway. The network key stays in use, and end-to-end protection of the application payload is unchanged. | . | Idle timeout | The quiet window required before an establishment starts (§2.2); sid_gsk_config.idle_timeout_sec | . | Keep-alive (KA) | A periodic, always ack-requested uplink the stack sends on a network-synchronized sub-GHz link to keep the downlink route valid; its interval is application-settable (§4). | . | LDR | Low data rate (SID_LINK3_DATA_RATE_LDR). The lower-data-rate, longer-range sub-GHz LoRa mode; its parameters are per-region. The Amazon Sidewalk Sid API Developer Guide calls it the default data rate. | . | MDR | Medium data rate (SID_LINK3_DATA_RATE_MDR), which the Amazon Sidewalk Sid API Developer Guide calls the higher data rate. The higher-data-rate, shorter-range sub-GHz LoRa mode, and the only LoRa mode that carries a GSK session. Not available in the EU. | . | Network synchronization | A link has joined the Amazon Sidewalk network and holds network time: SID_STATUS_REGISTERED (0), SID_STATUS_TIME_SYNCED (0) and the link’s bit set in link_status_mask | . | Non-GSK mode | Operation without a Gateway Session Key. Your traffic is carried normally: the same keys, the same sid_get_mtu() value and the same APIs. On SubG-CSS the link runs the region’s low data rate unless the application selected MDR, with link-layer acknowledgement and retries off (§2.1). No public API reports whether a session is in use. | . | Session | The period during which a single Gateway Session Key is in use | . ", "url": "/app-notes/gateway-session-key/references-and-appendix.html#glossary", "relUrl": "/app-notes/gateway-session-key/references-and-appendix.html#glossary" },"759": { "doc": "8. Appendix and References", "title": "8. Appendix and References", "content": " ", "url": "/app-notes/gateway-session-key/references-and-appendix.html", "relUrl": "/app-notes/gateway-session-key/references-and-appendix.html" },"760": { "doc": "B Regional Parameters", "title": "B Regional Parameters", "content": " ", "url": "/specifications/sidewalk-protocol-spec/glossary/regional-parameters.html", "relUrl": "/specifications/sidewalk-protocol-spec/glossary/regional-parameters.html" },"761": { "doc": "B Regional Parameters", "title": "Appendix B", "content": " ", "url": "/specifications/sidewalk-protocol-spec/glossary/regional-parameters.html#appendix-b", "relUrl": "/specifications/sidewalk-protocol-spec/glossary/regional-parameters.html#appendix-b" },"762": { "doc": "B Regional Parameters", "title": "B.1 Parameters for SubG-FSK connection mode with 50 kbps data rate", "content": "Parameters introduced in 5.2. | Name | Value | Description | . | slot_int | 63 ms | The time interval between two subsequent Target Transmission Times. | . | bcn_interval | 10080 ms | The time interval between start of the transmission of two subsequent beacons. | . | nb_slot | 160 | The number of Target Transmission Times (counted from 0 to 159). The number of Target Transmission Times is equal to the number of slots. | . | ul_dl_nb_slot | 156 | The number of Target Transmission Times that may be used for uplink and downlink scheduling.ul_dl_nb_slot = nb_slot - 4The number of Target Transmission Times that are reserved for the Beacon broadcasting is equal to 4 (slot number 159, 0, 1, 2). These cannot be used for Endpoint uplink, downlink transmission. | . | last_ul_dl_nb_opp_index | 3 | The index of the first UL/DL opportunity within a bcn_interval. | . | first_ul_dl_nb_opp_index | 158 | The index of the last UL/DL opportunity within a bcn_interval. | . | nb_opp | 160 | The number of opportunities (counted from 0 to 159). | . | tr_det_listening | 0.64 ms | Time period used for the preamble detection. | . | ch_change | 1.36 ms | The time period used for channel change during the Beacon discovery. | . | nb_channels | 69 | The total number of channels used for SubG-FSK communication (counted from 0 to 68). | . | bcn_prm_dur | 140 ms | The Beacon preamble duration. | . | nb_bcn_channels | 69 | The number of random channel indexes of selected channels for each Beacon hopping sequence. Each Beacon hopping sequence utilizes all available channels used in SubG-FSK communication (nb_channels). | . | nb_neighb_bcn | 2 | The number of channels used in before and after the current channel for the Beacon transmission. | . | nb_ul_dl_channels | 64 | The number of random channel indexes of selected channels for each uplink and downlink hopping sequence.nb_ul_dl_channels = nb_channels - 2*nb_neighb_bcn - 1 | . | sub_slot_nb | 6 | The number of sub-slots in the contention window. | . | sub_slot_time | 2 ms | The duration of a sub-slot in the contention mechanism. | . | contend_time | 12 ms | The contention window duration in the contention mechanism.contend_time = sub_slot_nb * sub_slot_time | . | nb_tx_retry | 3 | The default number of transmission retries in the contention mechanism. | . | CS-UL | offset 8, period 50 | The common slot schedule defined by Sidewalk GWs in uplink direction. | . | CS-DL | offset 9, period 50 | The common slot schedule defined in Sidewalk GWs in downlink direction. | . ", "url": "/specifications/sidewalk-protocol-spec/glossary/regional-parameters.html#b1-parameters-for-subg-fsk-connection-mode-with-50-kbps-data-rate", "relUrl": "/specifications/sidewalk-protocol-spec/glossary/regional-parameters.html#b1-parameters-for-subg-fsk-connection-mode-with-50-kbps-data-rate" },"763": { "doc": "B Regional Parameters", "title": "B.2 Parameters for SubG-CSS connection with 2 kbps data rate", "content": "Parameters introduced in 5.3. | Name | Value | Description | . | ul_separation | 367 ms | Separation of uplink Target Transmission Times. | . | dl_separation | 5 s | Separation of downlink Target Transmission Times. The value of the parameter is also defined in Section 5.2 | . | nb_ul_slot | 8 | The number of uplink slots. | . | nb_slot | 9 | The total number of downlink and uplink slots in a dl_separation period.nb_slot = nb_ul_slot + 1 | . | nb_dl_slot | 5, 10, 15, 20, infinite | The number of downlink slots after the last uplink.Numbers 5, 10, 15, 20 are applicable for Profile A.Infinite value is applicable for Profile B.The same as dl_slot_nb defined in Section 3.2.2.3. | . Parameters introduced in 5.5 . | Name | Value | Description | . | ul_sync_interval | 5 min | The maximum value of the time since last uplink for sending the synchronization packet with Epoch bit set. | . | ul_sync_guard_interval | 1 min | Time interval within which uplink packets shall be used for downlink synchronization. Data packet in uplink direction within ul_sync_interval. | . | nb_dl_slot | 5, 10, 15, 20, infinite | See description of nb_dl_slot. | . ", "url": "/specifications/sidewalk-protocol-spec/glossary/regional-parameters.html#b2-parameters-for-subg-css-connection-with-2-kbps-data-rate", "relUrl": "/specifications/sidewalk-protocol-spec/glossary/regional-parameters.html#b2-parameters-for-subg-css-connection-with-2-kbps-data-rate" },"764": { "doc": "B Regional Parameters", "title": "B.3 Parameters for use in security", "content": "Parameters introduced in 4.2. | Name | Value | Description | . | gcs_ret_num | 3 | The number of GET_TIME commands that are sent with the constant interval in case no response is received from the Sidewalk Cloud. | . | gcs_resp_timeout | 30 s, 3, 5, 8, 10, 15 min | The interval between subsequent GET_TIME commands in case there is no response is received from the Sidewalk Cloud.The first interval value 30 s is used max retry count times.Time intervals 3, 5, 8, 10 are used once. 15 min is used till the moment the RESP_TIME is received. | . | gcs_sync_int | 2 h | The time interval between two GET_TIME commands when the clock is synchronized on the Endpoint side. It is used for clock synchronization maintenance. | . | gcs_clock_drift | 60 s | The maximum allowed clock drift on the Endpoint side. | . Parameters introduced in 4.7.2. | Name | Value | Description | . | T_IV_ref | 60 s | The validity of the reference time in Initialization Vector (IV). | . ", "url": "/specifications/sidewalk-protocol-spec/glossary/regional-parameters.html#b3-parameters-for-use-in-security", "relUrl": "/specifications/sidewalk-protocol-spec/glossary/regional-parameters.html#b3-parameters-for-use-in-security" },"765": { "doc": "3. Required Log Patterns", "title": "Required Log Patterns", "content": "| Pattern Name | Log Example | Description | . | SID_LAST_STATUS | EVENT SID STATUS: State: <s>, Reg: <r>, Time: <t>, Link_Mask: <m>EVENT SID STATUS LINK MODE: LORA: <n>, FSK: <n>, BLE: <n> | EN current status: registration state, time sync state, and active link mask. | . | SID_STATUS_TIME_SYNC_COMPLETED | EVENT SID STATUS: State: 0, Reg: 0, Time: 0, Link_Mask: <n> | EN completed time sync. Link_Mask shows active links. | . | TIME_REQUEST_SEQ | Sent time req [<n>] to CldID | EN sent time sync request to cloud (sequence number). | . | TIME_RESPONSE_TR_STORE | tr_store: tr from:(radio\\|spi\\|stack), c_cls:0x0000, c_id:0x108(rsp)... | EN stored time response from cloud. | . | TIME_UPDATED | Updated time: | EN successfully updated its clock from cloud time. | . | TIME_FROM_THE_CLOUD | Received time from the cloud round trip | EN received time from cloud and completed round trip. | . | BLE_CONNECTED | EVENT SID STATUS: ..., Link_Mask: 1EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 1 | BLE connection established (Link_Mask: 1). | . | BLE_DISCONNECTED | EVENT SID STATUS: ..., Link_Mask: 0EVENT SID STATUS LINK MODE: LORA: 0, FSK: 0, BLE: 0 | BLE connection dropped (Link_Mask: 0). | . | SID_UPLINK_EVENT | EVENT SID SEND STATUS: SID ERR: 0, TYPE: 2, ID: <id>, LINK: <link> LINK_MODE: 0 | EN successfully sent an uplink packet to cloud. | . | SID_DOWNLINK_EVENT | EVENT SID RECEIVED: TYPE: 3, ID: <id>, LEN: <len>, LINK: <link>, LINK_MODE: 0, ACK: 1 Data: <data> | EN received a downlink packet from cloud. | . | JOIN_TERMINATE_SUCCEED | Njoin(<n>, <n>) st <n>->6 | EN completed join procedure, FSK/LoRa link established. | . | SID_STATUS_REGISTERED | Reg: 0 | EN is registered with Sidewalk network. | . | SID_STATUS_NOT_REGISTERED | Reg: 1 | EN is NOT registered (deregistered). | . | FAILED_COMMAND | CMD: ERR: -<n> | EN command failed with error code (e.g. -40 = no connection available). | . | CAPABILITY_ACK_RECV | DEC: M:15 [0:2:3] | EN received ACK for capability response sent to cloud. | . | GWD_SCAN_CONNECTED | GWD(<n>) st <n>->6 | GW discovery scan completed, GW found and connected. | . | TX_DONE_APP_LAYER_DST_ID | FskTx:TxDone sqn:<sqn> dst_id:0x<id> ch:<ch> pktlen:<len> tx_st:0 | FSK/LoRa TX packet sent to cloud (dst_id=0x4101). | . | TX_UUID | TXID: 0x<uuid> | EN current TX UUID. Used to verify UUID rotation every 15 minutes. | . | CAPABILITY_NTFY_SENT | ENC: M:15 [0:2:2] | EN sent capability notification to cloud. | . | CAPABILITY_WRITE_RECV | DEC: M:15 [0:2:1] | EN received capability write (configuration) from cloud. | . | TRAFFIC_THRESHOLD_EXCEED | TRAFFIC THRESHOLD RATE EXCEEDED | EN exceeded configured traffic rate limit. | . | SEND_METRICS | ENC: M:15 [B:E:2] | EN sending endpoint metrics to cloud via uplink. | . | NDB_METRICS | MET: NDB5 st:0 | Remaining metrics queued for piggybacking on next uplink. | . | FILE_TRANSFER_COMPLETED_COMMAND | DEC: M:15 [3:D:2] | File transfer (SBDT) completed successfully. | . | FILE_TRANSFER_SENDING_BLOCKS | DEC: M:15 [3:5:1] | File transfer block data being received. | . | BEACON_RECEIVED | BCN:pkt rcvd gw_id:<id> ch:<ch> rssi:<rssi> | EN received a FSK beacon from GW. | . | AUTO_CONNECT_LOG | ACM: Connect <link> for <n> sec err 0 | Auto-connect manager attempting to connect on specified link. | . | MLM_CONNECT_LOG | MLM: Connect <link> for <n> sec err 0 | Multi-link manager attempting to connect on specified link. | . | AC_TERMINATE | ACM(<n>) st <n>->0 | Auto-connect manager terminated, all retry attempts exhausted. | . | SID_SDK_VERSION | SID_SDK_VERSION: <version> | EN SDK version string. | . | BLE_POLICY | CMD: ERR: 0 BLE conn policy <n> | BLE connection policy set (0=Default, 1=LongLived, 2=OptimalAdv). | . | BLE_CONFIG_ADV | CMD: ERR: 0 BLE adv, fast_int <n>(<ms>ms), fast_to <n>, slow_int <n>(<ms>ms), slow_to <n> | BLE advertisement interval parameters configured. | . | BLE_CONFIG_PARAM | CMD: ERR: 0 BLE conn, min_int: <n>(<ms>ms), max_int <n>, sl <n>, timeout <n> | BLE connection interval parameters configured. | . | BLE_INACTIVITY_TIMEOUT | CMD: ERR: 0 BLE inactivity timeout <n>s | BLE inactivity timeout configured. | . ", "url": "/specifications/sidewalk-compliance-test-guide/required-log-patterns.html#required-log-patterns", "relUrl": "/specifications/sidewalk-compliance-test-guide/required-log-patterns.html#required-log-patterns" },"766": { "doc": "3. Required Log Patterns", "title": "3. Required Log Patterns", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/required-log-patterns.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/required-log-patterns.html" },"767": { "doc": "4. Sidewalk Bulk Data Transfer Status Codes", "title": "4. Sidewalk Bulk Data Transfer Status Codes", "content": "For the values of the Sidewalk Bulk Data Transfer status codes see 4.1. For the description of the Sidewalk Bulk Data Transfer status codes see 4.2. For the FuotaDeviceStatus of the Sidewalk Bulk Data Transfer status codes see 4.3. ", "url": "/sid-api-dg/sbdt-status-codes.html", "relUrl": "/sid-api-dg/sbdt-status-codes.html" },"768": { "doc": "4. Sidewalk Bulk Data Transfer Status Codes", "title": "4.1 Values of the Sidewalk Bulk Data Transfer Status Codes", "content": "| Sidewalk Bulk Data Transfer Status Code | Value | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_NONE | 0x00 | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_GENERIC | 0x01 | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_VERSION_MISMATCH | 0x02 | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_FILE_TOO_BIG | 0x03 | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_NO_SPACE | 0x04 | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_LOW_BATTERY | 0x05 | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_FRAGMENT_VERIFICATION_FAILED | 0x06 | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_MISSING_CHUNKS | 0x07 | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_WRITE_FAILED | 0x08 | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_FILE_VERIFICATION_FAILED | 0x09 | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_TRANSFER_RESTART | 0x0A | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_FILE_ALREADY_EXISTS | 0x0B | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_LINK_NOT_SUPPORTED | 0x0C | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_INVALID_FILE_ID | 0x0D | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_INVALID_FRAGMENT_SIZE | 0x0E | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_INVALID_FRAGMENT_ID | 0x0F | . ", "url": "/sid-api-dg/sbdt-status-codes.html#41-values-of-the-sidewalk-bulk-data-transfer-status-codes", "relUrl": "/sid-api-dg/sbdt-status-codes.html#41-values-of-the-sidewalk-bulk-data-transfer-status-codes" },"769": { "doc": "4. Sidewalk Bulk Data Transfer Status Codes", "title": "4.2 Description of the Sidewalk Bulk Data Transfer Status Codes", "content": "| Sidewalk Bulk Data Transfer Status Code | Description | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_NONE | Success | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_GENERIC | Generic Error | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_VERSION_MISMATCH | SBDT version mismatch | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_FILE_TOO_BIG | File Too Big | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_NO_SPACE | No Space | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_LOW_BATTERY | Battery power low | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_FRAGMENT_VERIFICATION_FAILED | Fragment Verification Failed | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_MISSING_CHUNKS | Missing Chunks | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_WRITE_FAILED | Write Failed | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_FILE_VERIFICATION_FAILED | File Verification Failed | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_TRANSFER_RESTART | Restart Transfer | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_FILE_ALREADY_EXISTS | File already exists | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_LINK_NOT_SUPPORTED | Link type not supported | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_INVALID_FILE_ID | Invalid File ID | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_INVALID_FRAGMENT_SIZE | Invalid fragment Size | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_INVALID_FRAGMENT_ID | Invalid fragment ID | . ", "url": "/sid-api-dg/sbdt-status-codes.html#42-description-of-the-sidewalk-bulk-data-transfer-status-codes", "relUrl": "/sid-api-dg/sbdt-status-codes.html#42-description-of-the-sidewalk-bulk-data-transfer-status-codes" },"770": { "doc": "4. Sidewalk Bulk Data Transfer Status Codes", "title": "4.3 FuotaDeviceStatus of the Sidewalk Bulk Data Transfer Status Codes", "content": "| Sidewalk Bulk Data Transfer Status Code | FuotaDeviceStatus | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_NONE | Successful | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_GENERIC | Wrong_descriptor | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_VERSION_MISMATCH | Wrong_descriptor | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_FILE_TOO_BIG | Package_Not_Supported | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_NO_SPACE | Not_enough_memory | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_LOW_BATTERY | Low_Battery | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_FRAGMENT_VERIFICATION_FAILED | Security_Error | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_MISSING_CHUNKS | MissingFrag | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_WRITE_FAILED | File_System_Error | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_FILE_VERIFICATION_FAILED | Security_Error | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_TRANSFER_RESTART | Restart_Transfer | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_FILE_ALREADY_EXISTS | Already_Available | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_LINK_NOT_SUPPORTED | Link_Not_Supported | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_INVALID_FILE_ID | Internal_Error | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_INVALID_FRAGMENT_SIZE | Internal_Error | . | SID_BULK_DATA_TRANSFER_STATUS_ERROR_INVALID_FRAGMENT_ID | MissingFrag | . ", "url": "/sid-api-dg/sbdt-status-codes.html#43-fuotadevicestatus-of-the-sidewalk-bulk-data-transfer-status-codes", "relUrl": "/sid-api-dg/sbdt-status-codes.html#43-fuotadevicestatus-of-the-sidewalk-bulk-data-transfer-status-codes" },"771": { "doc": "1. Scope", "title": "1. Scope", "content": "This application note is intended for device makers and contract manufacturers (CMs) who want to register Amazon Sidewalk endpoints on the factory line. This application note does the following: . | Explains Registration over Wire (ROW), a mass production flow in which each Sidewalk endpoint is provisioned and registered during manufacturing over a wired connection to the line PC, either UART or SEGGER RTT through a J-Link debug probe | Describes the one-time onboarding, line PC setup and per-device steps required to run ROW with the sid-mfg-tool host tool | Defines the integration contract for the Factory Diagnostic Firmware and the production firmware, including the security level and factory reset behavior of factory-registered devices | . This document does not attempt to discuss the details of Amazon Sidewalk features and functionality, or repeat the existing mass production flow. Those are documented in the Amazon Sidewalk Manufacturing documentation, the Amazon Sidewalk Protocol Specification and the feature-specific application notes (see Chapter 8). ROW requires a pre-production or production device profile with factory support enabled (see Section 3.5). Prototype device profiles are not supported, and their registration requests are rejected. ", "url": "/app-notes/registration-over-wire/scope.html", "relUrl": "/app-notes/registration-over-wire/scope.html" },"772": { "doc": "1. Scope", "title": "1. Scope", "content": "This document explains the implementation of the Gateway Discovery and Selection feature in the Amazon Sidewalk endpoint stack and describes how the feature behaves under different Gateway Discovery and Selection policy settings configured through the SID API. This feature provides APIs for Amazon Sidewalk stack developers to configure Gateway Discovery and Selection behavior for the SubG-FSK link. Developers can select predefined parameters optimized for various applications or define custom parameters for gateway selection. The document describes the gateway discovery procedure, the gateway selection algorithm using specified criteria, and how to monitor connected gateway parameters. For comprehensive coverage of Amazon Sidewalk features and functionality, refer to feature-specific application notes, specifications, developer guides, and the Amazon Sidewalk white paper. ", "url": "/app-notes/gateway-discovery-selection/scope.html", "relUrl": "/app-notes/gateway-discovery-selection/scope.html" },"773": { "doc": "1. Scope", "title": "1. Scope", "content": "This application note is intended for application developers who want to build their IoT solution using Amazon Sidewalk. This application note does the following: . | Explains device profiles supported by the Amazon Sidewalk sub-GHz protocol | Enables developers to make an educated choice of the profile and the corresponding profile parameters to suit their application needs | Provides APIs and configuration settings for developers to change the profile and the corresponding parameters | . ", "url": "/app-notes/sub-ghz-device-profile/scope.html", "relUrl": "/app-notes/sub-ghz-device-profile/scope.html" },"774": { "doc": "1. Scope", "title": "1. Scope", "content": "The scope of this document is to explain the implementation of the multi-link feature in the Amazon Sidewalk end point stack. The document also explains the behavior of the feature for different multi-link policy settings exercised through the SID API. This document does not attempt to discuss the details of Amazon Sidewalk features and functionality. Detailed explanation of Amazon Sidewalk features and functionality is documented by feature specific application notes, specifications, developer guides and the Amazon Sidewalk white paper. ", "url": "/app-notes/multi-link/scope.html", "relUrl": "/app-notes/multi-link/scope.html" },"775": { "doc": "1. Scope", "title": "1. Scope", "content": "This application note is intended for application developers building an IoT solution on Amazon Sidewalk for North America, Europe, or both. A device’s operating region determines its sub-GHz radio behaviour: the frequency band, the spreading factor and channel plan, the transmit power limit, and the channel-access rules the device must observe. A gateway detects its own region. On an end device the application supplies the region, both to configure the radio and to report it during setup (§4.2). This note describes how the region value reaches each class of device, what the application developer is responsible for in each case, and how a device behaves when a region has not yet been set or is not supported. Only the sub-GHz layers are region-specific. The application, security, and Bluetooth Low Energy layers do not vary by region. §2.2 lists the countries each region supports. Whether a particular product is offered in a given country is decided per product. ", "url": "/app-notes/internationalization/scope.html", "relUrl": "/app-notes/internationalization/scope.html" },"776": { "doc": "1. Scope", "title": "1. Scope", "content": "This application note is intended for application developers building an IoT solution on Amazon Sidewalk. On the sub-GHz LoRa link (SubG-CSS), an Endpoint reaches the medium data rate (MDR) either by holding a Gateway Session Key (GSK) session or by setting link3_data_rate to SID_LINK3_DATA_RATE_MDR at initialization. Where MDR is offered, it raises the uplink data rate, cuts airtime and allows the 500 ms asynchronous RX-window separation; link-layer acknowledgement with retries needs a session. MDR is not available in the EU region (§2.1). On the sub-GHz FSK link (SubG-FSK), a session lets the Gateway that received the uplink authenticate its sender locally with the shared session key — the Gateway derives this Endpoint’s authentication material from the session key and resolves the device address itself, instead of obtaining that material from the Amazon Sidewalk Cloud. The keys protecting your traffic are unchanged: frame authentication and payload encryption still use the network and application keys. Nothing else on that link changes; what you design for is the transition (§2.1, §2.2). This note covers what a session unlocks and costs on each sub-GHz link (§2.1), the lifecycle your application observes (§2.2), the three settings you own and how to size them (§3, §6), plus troubleshooting and bring-up (§7, §8). GSK is first available in Amazon Sidewalk SDK 2.0.0; read your version from sid_sdk_version.h. On an earlier SDK, sid_gsk_config.h and sid_config.gsk_config do not exist, so code referencing either fails to compile (§5). Whether GSK is enabled for your devices is settled out of band, not in code: the Amazon Sidewalk network decides it per sub-GHz PHY, and no public API reports it (§7, §8 step 0). Terminology . | Link types. SID_LINK_TYPE_1 (1) is Bluetooth Low Energy (Bluetooth LE). SID_LINK_TYPE_2 (2) is the 900 MHz FSK link, SubG-FSK (synchronous), with profiles SID_LINK2_PROFILE_1 (0x01) and SID_LINK2_PROFILE_2 (0x02). SID_LINK_TYPE_3 has the value 4, is the 900 MHz LoRa link, SubG-CSS (asynchronous), with profiles SID_LINK3_PROFILE_A (0x80), SID_LINK3_PROFILE_B (0x81) and SID_LINK3_PROFILE_C (0x82). A “type 3” link is not a “profile 3”. | Other recurring terms — session, non-GSK mode, ack-requested uplink, keep-alive and network synchronization — are in the Glossary. | . ", "url": "/app-notes/gateway-session-key/scope.html", "relUrl": "/app-notes/gateway-session-key/scope.html" },"777": { "doc": "1. Scope", "title": "1. Scope", "content": "The scope of this document is to explain the usage of the Amazon Sidewalk Application Programming Interface (API) for an application developer. This document does not attempt to discuss the details of Amazon Sidewalk features and functionality. Detailed explanation of Amazon Sidewalk features and functionality is documented by feature specific application notes, specifications, developer guides and the Amazon Sidewalk white paper. ", "url": "/sid-api-dg/scope.html", "relUrl": "/sid-api-dg/scope.html" },"778": { "doc": "7.4 Security and Privacy", "title": "7.4 Security and Privacy", "content": "The data payloads transported using the Sidewalk File Transfer protocol are encrypted and authenticated using the Application layer key and the network layer keys. The application layer file fragments are encrypted with the per device application layer key and the network layer payload chunks are encrypted with the per device network keys. This allows for added security even in cases where an end-device might been physically compromised. The protocol also uses a hash integrity checking at the application layer to ensure the overall integrity of the file delivered. The diagram below describes the security flow of the file fragmented payloads transported between the cloud and the device. The File is initially fragmented into fragment_size fragments and encrypted by AWS IoT using the per device application keys. A hash of the fragment is also calculated and passed to the network Server. The network server further splits each fragment into MTU size chunks and also encrypts each chunk with the per device network layer keys and sends each chunk to the gateway to the end device. The received chunks on the end nodes are decrypted and re-assembled into a fragment and decrypted and integrity validated using the hash sent from AWS IoT. Upon successful validation, the fragment is sent to the user application to write to flash and re-assemble the file. fig 7.2 File Fragmentation Flow from AWS IoT to End Device . ", "url": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/security-and-privacy.html", "relUrl": "/specifications/sidewalk-protocol-spec/sidewalk-bulk-data-transfer/security-and-privacy.html" },"779": { "doc": "7. Security Levels and Factory Reset", "title": "7. Security Levels and Factory Reset", "content": " ", "url": "/app-notes/registration-over-wire/security-levels-and-factory-reset.html", "relUrl": "/app-notes/registration-over-wire/security-levels-and-factory-reset.html" },"780": { "doc": "7. Security Levels and Factory Reset", "title": "7.1 Supported security level configurations", "content": "The security level is defined by three settings that must all agree: the SDK variant, the firmware macro and the tool configuration. Choose one column and use it consistently. |   | security-level-low | security-level-high (default) | . | SDK variant | Lite (single link) | Full (multi-link) | . | Firmware macro (Section 6.2) | SID_SDK_CONFIG_SECURITY_LEVEL_LOW | SID_SDK_CONFIG_SECURITY_LEVEL_HIGH | . | Tool security_level key (Chapter 4) | low | high | . | register commit_keys | Sent: credentials are copied from the KV store to the manufacturing page | Skipped: credentials are stored in the KV store only | . | Registration credentials are stored in | The KV store and the manufacturing page | The KV store only | . | KV store erased | Restored at the next boot from the manufacturing page. Safe only before the device operates on the network | Registration is lost. Never erase the KV store (Section 7.2) | . | Factory reset (sid_set_factory_reset() or cloud-initiated) | The device stays registered. The live network key and time synchronization counters are saved before the wipe and re-applied after the manufacturing page restore, so the authentication material does not change | The device becomes unregistered by design, and re-registers over the air (mobile application, FFN or Sidewalk gateway) | . | security-level-low is required for lite variants. They have no over-the-air registration stack, so without the manufacturing page copy any loss of the KV store permanently de-registers the device. Other combinations of security level and SDK variant are not supported. | Registration over the LoRa link is not supported. A full-variant device (security-level-high) that can only reach the network over LoRa cannot re-register after a factory reset. | A factory reset notifies the application through the on_factory_reset callback. If the credentials cannot be saved before the wipe, the factory reset is refused rather than risking stale credentials. | . ", "url": "/app-notes/registration-over-wire/security-levels-and-factory-reset.html#71-supported-security-level-configurations", "relUrl": "/app-notes/registration-over-wire/security-levels-and-factory-reset.html#71-supported-security-level-configurations" },"781": { "doc": "7. Security Levels and Factory Reset", "title": "7.2 Factory reset", "content": "To clear the Sidewalk state of a device, use sid_set_factory_reset(). Do not erase the KV store directly. At security-level-high, never delete or erase the KV store after factory registration. The KV store holds the only copy of the registration keys (the manufacturing page carries none), so deleting it permanently de-registers the device. A direct KV store erase is safe only in the following cases: . | Between provisioning and registration, in any configuration. | At security-level-low, in the production firmware reflash immediately after registration. | . Once the device has operated on the network: . | At security-level-high, a direct erase permanently removes the registration, and the device must be registered again. Use sid_set_factory_reset() when clearing is intended. | At security-level-low, a direct erase is not supported. The manufacturing page copy is fixed at registration time, so a boot-time restore would bring back an outdated network key and older time synchronization counters, which the network may no longer accept. Only sid_set_factory_reset() carries the live values across the wipe. | . ", "url": "/app-notes/registration-over-wire/security-levels-and-factory-reset.html#72-factory-reset", "relUrl": "/app-notes/registration-over-wire/security-levels-and-factory-reset.html#72-factory-reset" },"782": { "doc": "7. Security Levels and Factory Reset", "title": "7.3 Key material", "content": ". | The DAK private key never leaves the YubiHSM. On the line PC, the DAK PIN is stored only in secrets.toml (file mode 0600). | The other credentials in use are the LWA tokens (one per scope, cached and refreshed automatically) and the named AWS CLI profile. | Handle all private cryptographic key material in accordance with the Amazon Sidewalk Program Security Requirements. | . ", "url": "/app-notes/registration-over-wire/security-levels-and-factory-reset.html#73-key-material", "relUrl": "/app-notes/registration-over-wire/security-levels-and-factory-reset.html#73-key-material" },"783": { "doc": "Amazon Sidewalk Program Security Requirements", "title": "Amazon Sidewalk Program Security Requirements", "content": "Any terms not defined here will have the meaning set forth in the AWS Customer Agreement or the AWS Service Terms. You agree that you and your Amazon Sidewalk Devices shall comply with the following: . | You will implement all reasonable security measures to ensure that no third party may gain unauthorized access from your Amazon Sidewalk Device to Amazon Sidewalk, any Amazon Sidewalk Content, or any data intended for or delivered by Amazon Sidewalk; . | You will not use Amazon Sidewalk, the Services, or Amazon Sidewalk Devices for the purpose of monitoring, and will not monitor, the availability, performance, or functionality of any of our products or services; . | You will implement in your Amazon Sidewalk Devices the Amazon Sidewalk Content that we may require for firmware update, reporting, or debugging purposes and will report such metrics or data to us; . | You must ensure the Amazon Sidewalk Device firmware is updated to fix known security vulnerabilities; . | Your Amazon Sidewalk Devices will use a supported version of the Amazon Sidewalk Software Development Kit (Long Term Support (LTS) SDK), and if we notify developers of an update to the minimum LTS SDK version (including by website publication and/or e-mail), you will upgrade to such updated LTS SDK (or later version), within a period of 120 days of such notice; . | You will not remove, disable, modify, circumvent, or interfere with any of the features or functionality we make available through Amazon Sidewalk; . | You will not facilitate or attempt to gain access to Amazon Sidewalk through any means other than through the provisioning and secure authentication methods we specify, and you will not disable, modify, circumvent, or avoid any security mechanism or protocol of Amazon Sidewalk or the Services; . | You will design update mechanisms so that they are secure; . | You will promptly (and in any event within any timeframes we expressly specify) update your Amazon Sidewalk Devices with any updates we might require to any Amazon Sidewalk Content incorporated into your Amazon Sidewalk Devices and you will enable and not prevent or interfere with any over-the-air updates we require to such Amazon Sidewalk Content; . | You will protect the secrecy of any Amazon Sidewalk Content consisting of private cryptographic keys and solely handle and install those private cryptographic keys onto an Amazon Sidewalk Device by following our technical security requirements for private cryptographic keys; . | You must immediately contact us via e-mail if you become aware that any Amazon Sidewalk Content consisting of one or more private cryptographic keys were actually, may have been, or may in the future be exposed, compromised, inadvertently disclosed, or otherwise handled in a manner inconsistent with our technical requirements published on the Amazon Sidewalk Documentation. | If you suspect or become aware of any security vulnerability related to Your Content or Amazon Sidewalk Devices that may adversely affect Amazon Sidewalk or End Users’ use of or access to Amazon Sidewalk, then you will immediately notify us and will take all appropriate steps to remedy such vulnerability, including cooperating with us. | . ", "url": "/sidewalk-terms-and-agreements/security-program-requirements.html", "relUrl": "/sidewalk-terms-and-agreements/security-program-requirements.html" },"784": { "doc": "Set up an Amazon Echo as a Sidewalk Gateway in a non-U.S. Location", "title": "Setting up an Amazon Echo as a Sidewalk Gateway in a non-U.S. Location", "content": "IMPORTANT: Amazon Sidewalk is available in multiple regions. Outside of the supported regions, Sidewalk gateway functionality may only be used for Amazon Sidewalk end device development and testing purposes. Operating Amazon Sidewalk outside of the supported regions may violate local regulations. Developers are solely responsible for ensuring compliance with all applicable local regulations, including those related to VPN use. We recommend that you consult with your local regulatory body and operate Amazon Sidewalk devices only within shielded chambers or using another method that prevents wireless signals from exiting your testing environment. To enable Sidewalk operation outside of the supported regions for development purposes, you need to use a VPN router that supports OpenVPN Client functionality, in conjunction with a cloud VPN service provider. Please refer to the following sections for more details. Prerequisites: . | An active Amazon account. | The Amazon Alexa app installed on your mobile device and logged into your Amazon account. | A compatible Echo device with Sidewalk turned on. See here for gateway compatibility information and here for more details on changing the Sidewalk setting. The Amazon Echo Show 15 (2nd Gen) is generally recommended for development purposes. | . Steps: . | Buy a Wi-Fi router that supports OpenVPN. Not all routers support OpenVPN. Other VPN protocols such as L2TP, PPTP are not supported. | Sign up for a VPN service supporting OpenVPN. A free trial is probably suitable for testing a given VPN service, but a paid service is generally recommended. | Configure your Wi-Fi router as a VPN client using your VPN service account credentials and enable the VPN feature on the router. Select a VPN server located in one of the Sidewalk supported countries (see Supported Countries below). | Connect your mobile device via Wi-Fi to the SSID broadcast by the VPN router. | Set up your Echo device, using the Alexa app for devices without screens and using the screen for Echo Show devices. See here for details. | Connect your Echo device via Wi-Fi to the SSID broadcast by the VPN router. | . Unsupported: . | VPN client running on a mobile device. | VPN client running on a laptop. | Using any other VPN protocol such as L2TP, PPTP. | . Supported Countries: . | Sidewalk is currently available in the following countries. When configuring your VPN (Step 3), select a server located in one of these countries. | NA (North America) | . | . | Country | Country Code | . | United States | US | . | Canada | CA | . | Mexico | MX | . | EU (Europe) | . | Country | Country Code | . | United Kingdom | GB | . | Germany | DE | . | Italy | IT | . | Ireland | IE | . | Netherlands | NL | . | Spain | ES | . | France | FR | . | Austria | AT | . | Belgium | BE | . | Denmark | DK | . | Finland | FI | . | Norway | NO | . | Sweden | SE | . ", "url": "/getting-started/setup-an-amazon-echo-as-a-sidewalk-gateway-in-a-non-us-location.html#setting-up-an-amazon-echo-as-a-sidewalk-gateway-in-a-non-us-location", "relUrl": "/getting-started/setup-an-amazon-echo-as-a-sidewalk-gateway-in-a-non-us-location.html#setting-up-an-amazon-echo-as-a-sidewalk-gateway-in-a-non-us-location" },"785": { "doc": "Set up an Amazon Echo as a Sidewalk Gateway in a non-U.S. Location", "title": "Set up an Amazon Echo as a Sidewalk Gateway in a non-U.S. Location", "content": " ", "url": "/getting-started/setup-an-amazon-echo-as-a-sidewalk-gateway-in-a-non-us-location.html", "relUrl": "/getting-started/setup-an-amazon-echo-as-a-sidewalk-gateway-in-a-non-us-location.html" },"786": { "doc": "Components of Amazon Sidewalk", "title": "Components of Amazon Sidewalk", "content": "The key components of Amazon Sidewalk are described below. Sidewalk gateways (also known as Sidewalk bridges) Sidewalk gateways route data between Sidewalk devices and the cloud. Gateways are Amazon devices, such as the Echo (4th Gen) device or the Ring Floodlight Cam, that support the following physical layer communication protocols for wireless communication: . | SubG-CSS | SubG-FSK | Bluetooth LE (BLE) | . Sidewalk endpoints Sidewalk endpoints roam on Amazon Sidewalk by connecting to Sidewalk gateways. Endpoints are low-bandwidth, low-power smart products, such as: . | Smart utility meters | Environmental sensors (temperature, humidity, light level etc.) ‘ | Sidewalk-enabled lights | Leak sensors or door locks | Products that in certain cases can be attached to objects for identifying their location (asset trackers) | . Sidewalk Network Server The Sidewalk Network Server is the backbone of Sidewalk. It is responsible for verifying that the incoming packets are coming from authorized Sidewalk devices, routing packets to the desired destination (an Application Server, Sidewalk Endpoint, or Sidewalk Gateway), and keeping the network time-synchronized. The Sidewalk Network Server is operated by Amazon. Application server Application servers host Sidewalk endpoints and implement the business logic for the user experience and the desired product functionality. Application servers are managed by the Sidewalk Endpoint manufacturer, which can be Amazon or a third party. Packets Packets (or messages) are exchanged between the application server and Sidewalk endpoints using Sidewalk gateways and the Sidewalk Network Server. Packets are sent from (to) the Sidewalk Endpoints to (from) the ApplicationServer (through the Gateway and Sidewalk Network Server). Similar to a letter in the mail, the letter insidethe envelope (or packet) contains information needed to perform a service (for example, the command,“Turn on light.”) Like the post office, the Sidewalk Network Server reads the routing information on theoutside of the envelope to direct the packet to the correct Endpoint and Application Server. The Sidewalk Network Server reads the routing information of the packet and directs the packet to the correct Sidewalk endpoint and the application server. For more information about the network architecture and protocols, see Amazon Sidewalk specifications. ", "url": "/introduction/sidewalk-concepts.html", "relUrl": "/introduction/sidewalk-concepts.html" },"787": { "doc": "Sidewalk device lifecycle", "title": "Sidewalk device lifecycle", "content": "The Sidewalk devices that you want to onboard to AWS IoT Core for Amazon Sidewalk can be in either of the following three stages: . Prototype devices Prototype devices are primarily used for testing purposes and to explore the Amazon Sidewalk onboarding workflow. You can use the prototyping flow to create up to 1,000 Sidewalk prototype devices. You can provision one Sidewalk device at a time since the prototyping flow doesn’t support bulk-provisioning to onboard Sidewalk devices . Production devices Production devices are devices that are manufactured in large quantities without any device limit using the mass production flow. These devices can be manufactured after Sidewalk qualification is obtained. The following diagram shows the various stages in the lifecycle of your Sidewalk prototype, pre-production, or production devices. Device created Sidewalk devices can be created either using the prototyping flow or the mass production flow. | In the prototyping flow, you manually flash the manufacturing page (a binary representation of the certificate data from AWS IoT console) onto the Sidewalk device for authentication. | In the mass production flow, the contract manufacturer (CM) ingests the device data into Amazon’s device provisioning system either via EDI or SFTP, after which the devices are created. If the device data cannot be authenticated, the device entry will be rejected with a notification to the CM to correct the data. | . Device associated with account In this stage, associate your Sidewalk device in the required AWS account to let the device access other AWS IoT Core features. Device registered During device registration, a device presents device certificates to the Sidewalk cloud. If the device is successfully authenticated, then a secure channel is formed between the device and the Sidewalk cloud and then device and application server to establish mutual network and application session keys respectively. These session keys are used for device communication until it is de-registered. A device can be registered using an Amazon Sidewalk gateway, or a mobile application that integrates the Sidewalk Mobile SDK. Device de-registered De-registration process, also triggered by the end customer, leads to removal of device and end customer association at the cloud partner end. Sidewalk continues to own the same mapping from creation between the device and cloud partner. De-registration also leads to removal of all the keys established as part of registration process in the cloud and device. De-registration and registration cycle can occur multiple times in the life-cycle of a device. Device blocked The validity of a device on the network is derived from authenticity of the chain of trust. Under unusual circumstances, Amazon Sidewalk can revoke certificates for a particular device or device type which would inhibit that device from communicating with the application server. The developer can also revoke established permission between their own device and cloud partner account. ", "url": "/manufacturing/sidewalk-device-lifecycle.html", "relUrl": "/manufacturing/sidewalk-device-lifecycle.html" },"788": { "doc": "Sidewalk Gateways", "title": "Amazon Sidewalk Gateways", "content": "Sidewalk Gateways (sometimes referred to as Sidewalk Bridges) are Amazon devices like select Echo and Ring devices that support the Sidewalk protocol. These gateways route data between the Sidewalk endpoint devices and the Sidewalk Network Server. When using a Sidewalk gateway, a small portion of the user’s internet bandwidth is shared with the community to provide connectivity to a group of Sidewalk-enabled devices. For Ring devices, support for Sidewalk can be enabled or disabled from the Ring app (or Ring Website). And for Echo devices, support for Sidewalk can be enabled or disabled from the Alexa app. For more information, see Setting up a Sidewalk gateway . Echo devices (like the Echo Show 15 (2nd Gen)) and Ring devices (like the Ring Bridge (2nd Gen)) have the capability to act as Sidewalk Gateways, with all protocols available (BLE, SubG-CSS and SubG-FSK). The table below provides a list of Sidewalk Gateway devices, and their supported communication protocols. Regional Restrictions: The Sidewalk Network is available only in the United States of America. In order to ensure compliance with regional spectral regulations, Echo and Ring devices have been designed to disable Sidewalk gateway functionalities in all countries except the United States of America. ", "url": "/introduction/sidewalk-gateways.html#amazon-sidewalk-gateways", "relUrl": "/introduction/sidewalk-gateways.html#amazon-sidewalk-gateways" },"789": { "doc": "Sidewalk Gateways", "title": "List of Sidewalk Gateways", "content": "| Sidewalk-enabled Gateways | BLE | SubG-CSS | SubG-FSK | . | Echo Studio (Gen 5) | Yes | No | No | . | Echo Dot Max (Gen 6) | Yes | No | No | . | Echo Show 8 (Gen 4) | Yes | No | No | . | Echo Show 11 (Gen 2) | Yes | No | No | . | Echo Dot (5th Gen) | Yes | No | No | . | Echo Dot with clock (5th Gen) | Yes | No | No | . | Amazon Echo Spot (2024 release) | Yes | No | No | . | Echo Pop | Yes | No | No | . | Echo Show 5 (3rd Gen) | Yes | No | No | . | Echo Show 5 (3rd Gen) Kids | Yes | No | No | . | Echo Show 8 (3rd Gen) | Yes | No | No | . | Echo Show 15 (2nd Gen) | Yes | Yes | Yes | . | Echo Show 21 | Yes | Yes | Yes | . | Echo Hub | Yes | Yes | No | . | Ring Bridge (2nd Gen) | Yes | Yes | Yes | . | Ring Floodlight Cam Wired Plus | No | Yes | Yes | . | Ring Wired Doorbell Pro (2021) | Yes | Yes | Yes | . | Ring Wired Doorbell Pro 4k | No | Yes | Yes | . | Ring Alarm Pro Base Station | No | No | Yes | . | Ring Outdoor Cam Pro | No | Yes | Yes | . | Ring Floodlight Cam | No | Yes | Yes | . | Ring Floodlight Cam Wired 4K | Yes | Yes | Yes | . | Ring Spotlight Cam Wired | No | Yes | Yes | . | Echo (4th Gen) | Yes | Yes | Yes | . | Echo Dot (4th Gen) | Yes | No | No | . | Echo Show 5 (2nd Gen) | Yes | No | No | . | Echo Show 8 (2nd Gen) | Yes | No | No | . | Echo Show 10 (3rd Gen) | Yes | Yes | Yes | . | Echo Show 15 | Yes | No | No | . | Echo Dot with Clock (4th Gen) | Yes | No | No | . | Echo Show 5 | Yes | No | No | . | Echo Show 8 | Yes | No | No | . | Echo Flex | Yes | No | No | . | Echo Studio (Gen 6) | Yes | No | No | . | Echo (3rd Gen) | Yes | No | No | . | Echo Dot (3rd Gen) | Yes | No | No | . | Echo Dot with Clock (3rd Gen) | Yes | No | No | . | Echo Input | Yes | No | No | . | Echo Spot | Yes | No | No | . | Echo Dot (2nd Gen) | Yes | No | No | . | Echo Plus (2nd Gen) | Yes | No | No | . | Echo Show (2nd Gen) | Yes | No | No | . | Echo Plus (1st Gen) | Yes | No | No | . ", "url": "/introduction/sidewalk-gateways.html#list-of-sidewalk-gateways", "relUrl": "/introduction/sidewalk-gateways.html#list-of-sidewalk-gateways" },"790": { "doc": "Sidewalk Gateways", "title": "Sidewalk Gateways", "content": " ", "url": "/introduction/sidewalk-gateways.html", "relUrl": "/introduction/sidewalk-gateways.html" },"791": { "doc": "Step 1: Setting up the host", "title": "Setting up the host", "content": "This section shows how the CM must set up the host for mass manufacturing Sidewalk devices. See Required toolkit and Pre-requisites. Important The steps in this section need to be performed by the CM who will manufacture your Sidewalk devices for mass production, using the Sidewalk device CLI and the Sidewalk signing tool. Topics . | Step 1: Choose mode of setup | Step 2: Install YubiHSM SDK | Step 3: Install OpenSSL | Step 4: Install Sidewalk signing tool | Step 5: Generate certificates for mutual authentication (networked setup) | Step 6: Install Nginx on signing server (networked setup) | . ", "url": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#setting-up-the-host", "relUrl": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#setting-up-the-host" },"792": { "doc": "Step 1: Setting up the host", "title": "Step 1: Choose mode of setup", "content": "Depending on how you want to manufacture your devices, you can use a local or a networked setup. A local setup has both the signing tool and the YubiHSM connector running on the same machine. A networked setup moves the connector component into a server PC that is accessible through the local area network. If an HSM attached to a the signing server can support multiple line PCs, we recommend using a networked setup. Using a local setup requires every line PC to be associated with an HSM. This table shows more about the two modes of setup and the tools that must be installed on the hosts. Local and networked setup . ", "url": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#step-1-choose-mode-of-setup", "relUrl": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#step-1-choose-mode-of-setup" },"793": { "doc": "Step 1: Setting up the host", "title": "Step 2: Install YubiHSM SDK", "content": "Visit the YubiHSM2 libraries and tools page for additional information and support on HSM. You can see a list of all available downloads ordered by version, starting with the most recent version on the YubiHSM2 releases page. Select to download the SDK for your Windows or Ubuntu system environment, and follow the YubiHSM2 Usage Guide for installing the YubiHSM 2 tools and software . ", "url": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#step-2-install-yubihsm-sdk", "relUrl": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#step-2-install-yubihsm-sdk" },"794": { "doc": "Step 1: Setting up the host", "title": "Step 3: Install OpenSSL", "content": "To use the line PC, you must have OpenSSL installed. On an Ubuntu machine, OpenSSL is available with the default installation. For more information, see OpenSSL. On a Windows machine, you can install OpenSSL from the OpenSSL binaries page. ", "url": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#step-3-install-openssl", "relUrl": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#step-3-install-openssl" },"795": { "doc": "Step 1: Setting up the host", "title": "Step 4: Install Sidewalk signing tool", "content": "The Sidewalk signing tool accepts and takes the CSR, and outputs the encoded signed Sidewalk certificate chain. To use the Sidewalk signing tool. | First contact Amazon Sidewalk support to get the latest version of the signing tool, sidewalk-signing-tool.py. | After you receive the tool, install it by following the instructions in the README.md document. | To install the required Python dependencies for using the signing tool, such as the Python interpreter, run the requirements file, requirements.txt contained in the signing tool. It will then install the required Python dependencies using pip. pip3 install -r requirements.txt . | . ", "url": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#step-4-install-sidewalk-signing-tool", "relUrl": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#step-4-install-sidewalk-signing-tool" },"796": { "doc": "Step 1: Setting up the host", "title": "Step 5: Generate certificates for mutual authentication (networked setup)", "content": "This step is required only if you’re using the networked setup. When using a networked setup, the HSM and the Sidewalk signing tool are located in different machines. To secure traffic over the network and use a secure connection between the two machines, we recommend that you use mutually authenticated TLS for the client and server to authenticate each other. | Generate a local signing authority . Generate a local signing authority that will be used to endorse both the client and server certificates. When you run this command, you’ll be prompted to enter a passphrase, and any phrase can be used. openssl req -new -x509 -subj \"/CN=Sidewalk CA/\" -keyout ca.key -out ca.pem -days 365 . You must securely store the key, ca.key. It must not be visible to the line PC or the signing server. | Generate server certificate . Generate the server certificate that the server will present to the Sidewalk signing tool when setting up a connection. The certificate is signed by the Local Signing Authority. To generate the server certificate. | First create a V3 extension file, v3_server.ext. authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth . | Then create the server certificate. # Create the Certificate Signing Request openssl req -new -newkey rsa:2048 -sha256 -nodes \\ -keyout server.key -out server.csr # Generate the certificate signed by the CA openssl x509 -req -days 365 -CA ca.pem -CAkey ca.key -CAcreateserial \\ -in server.csr -sha256 -out server.pem -extfile v3_server.ext # Enter the passphase provided when generating the local signing authority # Enter the IP/domain address of the server when asked for the \"Common Name\" (e.g. server FQDN or IP) . | . | Generate client certificate . Generate the client certificate for the signing tool that will be presented to the server during authentication. You create the client certificate similar to how you created the server certificate. | First create a V3 extension file, v3_client.ext . authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment extendedKeyUsage = clientAuth . | Then create the client certificate. # create a certificate signing request openssl req -new -newkey rsa:2048 -sha256 -nodes -keyout client.key -out client.csr # create the client certificates signed with the Certificate Authority openssl x509 -req -days 365 -CA ca.pem -CAkey ca.key \\ -CAcreateserial -in client.csr -sha256 -out client.pem -extfile v3_client.ext . | . | . ", "url": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#step-5-generate-certificates-for-mutual-authentication-networked-setup", "relUrl": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#step-5-generate-certificates-for-mutual-authentication-networked-setup" },"797": { "doc": "Step 1: Setting up the host", "title": "Step 6: Install Nginx on signing server (networked setup)", "content": "This step is required only if you’re using the networked setup. Nginx is a web server that you install on the signing server for mutual authentication between the signing server and line PC. To install and configure Nginx, perform the following steps. | Install Nginx . Go to the Nginx website and install the tool by following the platform-specific instructions as described in the Installing Nginx open source documentation. [ Windows ] . On a Windows machine, you can download the prebuilt Nginx binary from the Nginx for Windows web page. Unzip the binary file into the C:\\nginx folder and then run it to install Nginx. [ Ubuntu ] . On an Ubuntu machine, you can install Nginx using apt. sudo apt install -y nginx . | Configure Nginx . Configure Nginx depending on the platform that you’re running it from. [ Windows ] . On a Windows machine, edit the configuration file at c:\\nginx\\conf\\nginx.conf directly and replace the section server with the following configuration similar to the Ubuntu section. In this example: . | log_path is the path where the Nginx log is stored, such as C:/nginx. | cert_path is the path where the certificate is stored. | . server { listen 8081 ssl; listen [::]:8081 ssl; access_log C:/nginx/reverse-access.log; error_log C:/nginx/reverse-error.log; ssl_certificate <path>/server.pem; ssl_certificate_key <path>/server.key; ssl_client_certificate <path>/ca.pem; ssl_verify_client on; ssl_verify_depth 1; location / { if ($ssl_client_verify != SUCCESS) { return 403; } proxy_pass http://127.0.0.1:12345; } } . [ Ubuntu ] . On an Ubuntu machine, perform the following steps to configure and enable Nginx. | Create a configuration file, /etc/nginx/sites-available/reverse-proxy.conf, with these contents for the server configuration. In this example: . | log_path is the path where the Nginx log is stored, such as /var/log/nginx. | cert_path is the path where the certificate is stored. | . server { listen 8081 ssl; listen [::]:8081 ssl; access_log /var/log/nginx/reverse-access.log; error_log /var/log/nginx/reverse-error.log; ssl_certificate <path>/server.pem; ssl_certificate_key <path>/server.key; ssl_client_certificate <path>/ca.pem; ssl_verify_client on; ssl_verify_depth 1; location / { if ($ssl_client_verify != SUCCESS) { return 403; } proxy_pass http://127.0.0.1:12345; } } . | Enable the config by running the following command. sudo ln -s /etc/nginx/sites-available/reverse-proxy.conf /etc/nginx/sites-enabled/reverse-proxy.conf . | . | Enable Nginx . Run the following platform-specific commands to enable Nginx. [ Windows ] . On a Windows machine, run this command to enable Nginx. C:\\nginx>start nginx . [ Ubuntu ] . On an Ubuntu machine, run this command to restart and run Nginx. sudo systemctl restart nginx . | . Next Step: Provisioning with CSR and Sidewalk Signing tool . ", "url": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#step-6-install-nginx-on-signing-server-networked-setup", "relUrl": "/manufacturing/manufacture-provision/sidewalk-host-installation.html#step-6-install-nginx-on-signing-server-networked-setup" },"798": { "doc": "Step 1: Setting up the host", "title": "Step 1: Setting up the host", "content": ". ", "url": "/manufacturing/manufacture-provision/sidewalk-host-installation.html", "relUrl": "/manufacturing/manufacture-provision/sidewalk-host-installation.html" },"799": { "doc": "How Amazon Sidewalk Works", "title": "How Amazon Sidewalk works", "content": "Eligible Amazon Echo and Ring devices can act as gateways (or Sidewalk bridges) and connect Sidewalk devices to the cloud. Certain Sidewalk Bridges such as the Echo Show 10 and the Ring Floodlight Cam have built-in sub-GHz LoRa or frequency-shift keying (FSK), which can accept signals from Sidewalk devices that are within a larger wireless range. A Sidewalk device (endpoint) can roam and automatically connect to any nearby Sidewalk Gateway. When the Sidewalk Gateway receives the signals from an endpoint device, it uses a small portion of the home network’s internet bandwidth to route the message received from the Sidewalk endpoint to the cloud, which further routes the message to the desired destination. ", "url": "/introduction/sidewalk-how-works.html#how-amazon-sidewalk-works", "relUrl": "/introduction/sidewalk-how-works.html#how-amazon-sidewalk-works" },"800": { "doc": "How Amazon Sidewalk Works", "title": "Amazon Sidewalk network architecture", "content": "The following diagram shows a simple overview of the Amazon Sidewalk network architecture. The Amazon Sidewalk network comprises millions of gateways and is designed to support billions of end devices. For more information about Amazon Sidewalk and Sidewalk-enabled devices, see the Amazon Sidewalk Webpage webpage. ", "url": "/introduction/sidewalk-how-works.html#amazon-sidewalk-network-architecture", "relUrl": "/introduction/sidewalk-how-works.html#amazon-sidewalk-network-architecture" },"801": { "doc": "How Amazon Sidewalk Works", "title": "Amazon Sidewalk limits", "content": "Amazon caps the amount of bandwidth shared to reduce the chances of any degradation in a customer’s home network performance. The maximum bandwidth of a Sidewalk Gateway to the Sidewalk Network Server is 80Kbps, which is about 1/250th of the bandwidth used to stream a typical 4k video. Sidewalk’s data cap is set at 0.15% of average US household internet use, assessed annually. Today, the total monthly data used by Sidewalk-enabled devices is capped at 0.15% of average US household internet use, which is less than streaming about 10 minutes of 4K video. For more information, please refer to the Amazon Sidewalk Privacy and Security whitepaper . The Amazon Sidewalk network was designed for the community benefit and targeting low power applications. For best performance, we recommend limiting the traffic rate of your devices when using any of the supported PHYs (Bluetooth LE, FSK or LoRa). For more information on the protocol design parameters, please look at the Amazon Sidewalk Protocol Specification . ", "url": "/introduction/sidewalk-how-works.html#amazon-sidewalk-limits", "relUrl": "/introduction/sidewalk-how-works.html#amazon-sidewalk-limits" },"802": { "doc": "How Amazon Sidewalk Works", "title": "Sidewalk End Device Maximum Uplink Traffic Rates", "content": "The Amazon Sidewalk network enforces uplink maximum traffic rates for endpoints. These are the principles governing the traffic rate enforcement policy: . | End devices are categorized as either static (does not move) or mobile. Different rate thresholds apply. | For Sub-1 GHz CSS there are two modes: normal and burst. Burst mode is not applicable for Bluetooth LE and FSK | Traffic rates are checked daily | Traffic in either normal or burst mode accrue towards a single maximum number of packets per day | . Rates are summarized in the following table: . | PHY type | Static/Mobile | Normal mode rate | Burst mode rate | Max packet per day | . | Sub-1 GHz CSS | Static | 1 packet every 15 min | 1 packet every 5 min | 96 | . | Sub-1 GHz CSS | Mobile | 1 packet every 6 min | 1 packet every 1 min | 250 | . | FSK | Either static or mobile | 700 packets per min | Not applicable | 1,008,000 | . | Bluetooth LE | Either static or mobile | 600 packets per min | Not applicable | 864,000 | . ", "url": "/introduction/sidewalk-how-works.html#sidewalk-end-device-maximum-uplink-traffic-rates", "relUrl": "/introduction/sidewalk-how-works.html#sidewalk-end-device-maximum-uplink-traffic-rates" },"803": { "doc": "How Amazon Sidewalk Works", "title": "How Amazon Sidewalk Works", "content": " ", "url": "/introduction/sidewalk-how-works.html", "relUrl": "/introduction/sidewalk-how-works.html" },"804": { "doc": "Components of Amazon Sidewalk manufacturing", "title": "Components of Amazon Sidewalk manufacturing", "content": "The following section describes the key components of Amazon Sidewalk manufacturing process. Topics . | Device attestation key (DAK) | Sidewalk certificates | Hardware Security Module(HSM) | Getting an HSM Provisioned | Advertised product ID (APID) | . ", "url": "/manufacturing/sidewalk-manufacturing-components.html", "relUrl": "/manufacturing/sidewalk-manufacturing-components.html" },"805": { "doc": "Components of Amazon Sidewalk manufacturing", "title": "Device attestation key (DAK)", "content": "A Device Attestation Key acts as a certificate authority for a device type. It is used to endorse the device certificate for Sidewalk device authentication with the Sidewalk network server. For prototype devices, the cloud maintains a Prototype DAK which is used to sign the prototype device certificates. For devices that are manufactured in the Contract Manufacturer (CM), the Production DAK is provided in a Hardware Security Module (HSM). The DAK is tied to the Sidewalk device profile created with AWS IoT Core for Amazon Sidewalk. ", "url": "/manufacturing/sidewalk-manufacturing-components.html#device-attestation-key-dak", "relUrl": "/manufacturing/sidewalk-manufacturing-components.html#device-attestation-key-dak" },"806": { "doc": "Components of Amazon Sidewalk manufacturing", "title": "Sidewalk certificates ", "content": "Sidewalk certificate chain . The Sidewalk certificate chain is a collection of certificates which consists of Amazon Root Certificate Authority (CA), multiple intermediate CAs including DAK and to sign and issue device certificates during device provisioning and manufacturing. It provides a chain of trust to the Amazon Root CA. When manufacturing your devices, the entire public certificate chain from device to root is uploaded during control log ingestion. See Amazon Sidewalk protocol specification, section 4.1.2 Certificate chain for more details. Application service key pair . This key pair is unique to each application server. It authenticates the application server with the Sidewalk device. Devices that connect to the same application server use the same application server key pair. The public key is located in the manufacturing data storage on your Sidewalk device. Sidewalk network server certificate . This certificate is used to authenticate the Sidewalk network server with the device. All Sidewalk devices use the same Sidewalk network server certificate. This certificate is located in the Sidewalk SDK on your device. ", "url": "/manufacturing/sidewalk-manufacturing-components.html#sidewalk-certificates-", "relUrl": "/manufacturing/sidewalk-manufacturing-components.html#sidewalk-certificates-" },"807": { "doc": "Components of Amazon Sidewalk manufacturing", "title": "Hardware Security Module (HSM)", "content": "The HSM is a hardened, tamper-resistant hardware device, allowing secure key management. To enable device manufacturing, the Amazon Sidewalk team provisions the DAK certificate, including the DAK private key onto the HSM. HSM is used during the provisioning process at the CM to orchestrate signing of the device certificates without exposing the DAK private key. HSM also includes the full intermediate public certificate chain up to Amazon Root. HSMs can be purchased from the YubiHSM webpage . ", "url": "/manufacturing/sidewalk-manufacturing-components.html#hardware-security-module-hsm", "relUrl": "/manufacturing/sidewalk-manufacturing-components.html#hardware-security-module-hsm" },"808": { "doc": "Components of Amazon Sidewalk manufacturing", "title": "Getting an HSM Provisioned to Support Mass Production of your Sidewalk Endpoint Device ", "content": "When you are ready to start mass production, you will send a physical HSM(s) to the Amazon Sidewalk team for provisioning. Please submit the below information for the new Sidewalk device you have created to your Amazon Sidewalk Support contact: . | AWS account ID associated with the Sidewalk product | Device Profile ID for the Sidewalk product | Number of YubiHSMs to be provisioned. Please purchase HSMs directly from the YubiHSM webpage and ship them to us. Please contact us for the shipping address. | Contact email for sending encrypted email with DAK PIN | PGP public key for encrypting DAK PIN . | If you don’t have one, refer here for instructions (you can use defaults) | To send the keys, please use the procedure here | . | Return Shipping Address including name and contact phone number | Shipping provider e.g. UPS, Fedex, DHL and account number | . ", "url": "/manufacturing/sidewalk-manufacturing-components.html#getting-an-hsm-provisioned-to-support-mass-production-of-your-sidewalk-endpoint-device-", "relUrl": "/manufacturing/sidewalk-manufacturing-components.html#getting-an-hsm-provisioned-to-support-mass-production-of-your-sidewalk-endpoint-device-" },"809": { "doc": "Components of Amazon Sidewalk manufacturing", "title": "Advertised Product ID (APID)", "content": "The APID parameter is an alphanumeric string which is needed during manufacturing. APID is located in the manufacturing data storage on your Sidewalk device. After receiving HSM key from Sidewalk, you can obtain APID information from the AWS IoT console, or using the GetDeviceProfile API operation, or the get-device-profile CLI command that’s provided by AWS IoT Core for Amazon Sidewalk. If you already have an APID (by interacting with other Amazon systems), Amazon can link it to your Amazon Sidewalk device profile for pre-production or production purposes. If you don’t already have an APID, Amazon will generate one and associate it with the device profile you provide. For prototype devices, the DeviceTypeId must be used instead of the APID. The APID must be used only for production or pre-production devices. ", "url": "/manufacturing/sidewalk-manufacturing-components.html#advertised-product-id-apid", "relUrl": "/manufacturing/sidewalk-manufacturing-components.html#advertised-product-id-apid" },"810": { "doc": "Amazon Sidewalk manufacturing setup and workflow", "title": "Amazon Sidewalk manufacturing setup and workflow", "content": "This section describes how Amazon Sidewalk manufacturing works. You’ll learn the setup required before taking your devices to factory to production, and how you can use this information to bulk provision your Sidewalk devices. Topics . | Setup for Amazon Sidewalk manufacturing | Mass production flow for Amazon Sidewalk | How Amazon Sidewalk manufacturing works | . ", "url": "/manufacturing/sidewalk-manufacturing-setup-works.html", "relUrl": "/manufacturing/sidewalk-manufacturing-setup-works.html" },"811": { "doc": "Amazon Sidewalk manufacturing setup and workflow", "title": "Setup for Amazon Sidewalk manufacturing", "content": "To prepare your Sidewalk-enabled products for production, you’ll need the following hardware to generate the device key pairs on it. For more information, see Setting up the host. | A computer, also known as line PC, used for provisioning, | A device under test (DUT) to which the line PC is connected to, | A debugging interface, such as JLink, provided with the DUT, and | The HSM issued by Amazon Sidewalk Team for your Sidewalk products. | . ", "url": "/manufacturing/sidewalk-manufacturing-setup-works.html#setup-for-amazon-sidewalk-manufacturing", "relUrl": "/manufacturing/sidewalk-manufacturing-setup-works.html#setup-for-amazon-sidewalk-manufacturing" },"812": { "doc": "Amazon Sidewalk manufacturing setup and workflow", "title": "Mass production flow for Amazon Sidewalk", "content": "The mass production flow follows the steps described below to issue Sidewalk certificates and upload the corresponding record into Sidewalk cloud services. The CM is expected to implement the Line PC script. | Factory Diagnostic Firmware is flashed into DUT and generates a set of public-private key pairs for the device. There is a key pair for each supported elliptic curves (EC) : ED25519 and P256R1 to authenticate the encryption keys. | Line PC script communicates with Factory Diagnostic Firmware and passes the generated Sidewalk certificate signing request (CSR) to the Sidewalk Signing Tool to generate the device certificates. The HSM signs the device certificate with the DAK private key. | Sidewalk Signing Tool constructs the full Sidewalk Certificate Chain which includes the newly created device certificates and outputs a Sidewalk control log. | Line PC script passes the certificate chain to Factory Diagnostic Firmware, which writes it to the device. After that, the device can be flashed with production firmware. | Line PC script saves the control logs generated by the Sidewalk Signing Tool in CM’s database or internal storage. | CM collects and uploads the control logs that contain the Sidewalk Certificate Chain and the device related information via EDI system or SFTP endpoint. | . ", "url": "/manufacturing/sidewalk-manufacturing-setup-works.html#mass-production-flow-for-amazon-sidewalk", "relUrl": "/manufacturing/sidewalk-manufacturing-setup-works.html#mass-production-flow-for-amazon-sidewalk" },"813": { "doc": "Amazon Sidewalk manufacturing setup and workflow", "title": "How Amazon Sidewalk manufacturing works", "content": "This flowchart shows how bulk provisioning works. The following procedure illustrates the different steps in the manufacturing process. | Create an AWS IoT device profile . When your devices are ready for mass production, you can use an existing device profile or Create a device profile to enable factory support for your device production. | Enable factory support . The Amazon Sidewalk team can link your APID to your device profile. We will update your device profile with the production DAK, and provision it along with the Sidewalk certificate chain onto the HSM key you provide, for using AWS IoT Core for Amazon Sidewalk and bulk provisioning your Sidewalk devices. Contact Amazon Sidewalk support for more details and shipping instructions of sending your HSM to the Amazon Sidewalk team for provisioning. | Send HSM key to contract manufacturer (CM) . After HSM provisioning is complete, we will return the HSM to you, and provide the DAK PIN via encrypted email for your HSM access. You can then send the HSM to your contract manufacturer to enable them to start the manufacturing process for your Sidewalk devices. | Manufacture devices and send control logs and serial numbers . The CM manufactures the devices for production, generates control logs, and ingests the logs to into Amazon’s device provisioning system via EDI or SFTP. The Amazon’s system will process the uploaded log, validate its content and send a notification to the CM. The CM also provides you a CSV file that contains a list of manufactured devices and their Sidewalk manufacturing serial numbers (SMSNs). The following code shows a sample control log. It contains the serial number of the device, the APID, and the public device certificates. See the Amazon Sidewalk Specification, section 4.3.2 Sidewalk Manufacturing Serial Number (SMSN) for more details. { \"controlLogs\": [ { \"version\": \"4-0-1\", \"device\": { \"serialNumber\": \"d4c4975ef82728e1e56333b657515a136166afd956aa69745c3efe243660fafe\", \"productIdentifier\": { \"advertisedProductId\": \"abCD\" }, \"sidewalkData\": { \"SidewalkED25519CertificateChain\": \"...\", \"SidewalkP256R1CertificateChain\": \"...\" } } }] } . | Bulk provision to onboard your Sidewalk devices in AWS IoT . You can bulk provision your Sidewalk devices by creating and using import tasks to onboard a large number of your devices to AWS IoT Core for Amazon Sidewalk. Follow steps on Provisioning Sidewalk devices using import tasks. | . ", "url": "/manufacturing/sidewalk-manufacturing-setup-works.html#how-amazon-sidewalk-manufacturing-works", "relUrl": "/manufacturing/sidewalk-manufacturing-setup-works.html#how-amazon-sidewalk-manufacturing-works" },"814": { "doc": "Amazon Sidewalk MCU SDK Migration Guide", "title": "Amazon Sidewalk MCU SDK Migration Guide", "content": "This guide covers migration from Amazon Sidewalk MCU SDK 1.19 to Amazon Sidewalk MCU SDK 2.0. ", "url": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html", "relUrl": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html" },"815": { "doc": "Amazon Sidewalk MCU SDK Migration Guide", "title": "Table of Contents", "content": ". | 1. Introduction | 2. Scope | 3. If you only read one section | 4. New features in 2.0 | 5. Stack configuration changes | 6. SID API changes | 7. PAL interface changes | 8. Migration checklist | 9. References | 10. Glossary | 11. Change history | . ", "url": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#table-of-contents", "relUrl": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#table-of-contents" },"816": { "doc": "Amazon Sidewalk MCU SDK Migration Guide", "title": "1. Introduction", "content": "Amazon Sidewalk MCU SDK 2.0 adds registration over a wired serial link, keep-alive payloads and acknowledgement events, a medium data rate (MDR) on the SubG-CSS (LoRa) link, Bluetooth LE (BLE) bonding, FSK beacon events, Gateway Session Key (GSK) security, regulatory-region reporting, an extended Location Library with GPS-assisted positioning, and a security-level build setting. Registration over Wire also introduces three lite build variants. This guide uses the short forms BLE, FSK (SubG-FSK) and LoRa (SubG-CSS). Most of these additions are optional. A small number of changes alter existing types or defaults and require action. This guide lists every change an application or platform developer must make to move an SDK 1.19 integration to SDK 2.0. ", "url": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#1-introduction", "relUrl": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#1-introduction" },"817": { "doc": "Amazon Sidewalk MCU SDK Migration Guide", "title": "2. Scope", "content": "This guide covers the Amazon Sidewalk Endpoint MCU SDK and applies to: . | Application developers using the Sid API (sid_ifc/ headers) on an endpoint. | Platform developers maintaining an endpoint Platform Abstraction Layer (PAL) port (sid_pal_ifc/ headers). | . Out of scope: the Amazon Sidewalk Gateway MCU SDK (including the gateway configuration header and radio co-processor interfaces), the Amazon Sidewalk Gateway SDK, the Amazon Sidewalk Mobile SDK, and cloud-side configuration. Error codes (sid_error.h) are unchanged between 1.19 and 2.0. The SDK version string is set by the release build. Read it from your SDK package or from the build information embedded in the library (strings libsidewalk_sdk.a | grep SID_SDK_.*_VERSION), not from this document. Each change in this guide carries one of three labels: . | Label | Meaning | . | Breaking (compile) | SDK 1.19 code fails to build unchanged. | . | Breaking (behavior) | Code builds, but runtime behavior or data layout differs. | . | Additive (optional) | New symbols only. No action unless you adopt the feature. | . A struct that gains a trailing field is Additive when you use designated initializers (.field = value) and Breaking (compile) or Breaking (behavior) when you use positional initializers. Each affected struct is called out below. ", "url": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#2-scope", "relUrl": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#2-scope" },"818": { "doc": "Amazon Sidewalk MCU SDK Migration Guide", "title": "3. If you only read one section", "content": "| Change | Who | Label | What you do | . | SID_SDK_CONFIG_RF_POWER_TABLE and SID_SDK_CONFIG_RF_POWER_MAX_TABLE removed | App / platform | Additive (removal; no runtime effect) | Delete any -D override or #define. See §5.2. | . | SID_SDK_CONFIG_ENABLE_GSK defaults to 1 | App | Breaking (behavior) | Decide whether to keep GSK enabled; zero-initialize struct sid_config (new gsk_config pointer); LoRa links run at MDR while a GSK is active. See §4.6, §5.1, §6.1.1. | . | sid_msg_desc_tx_attributes.resolve_location is now a uint8_t flag mask | App (Location) | Breaking (behavior) | Replace true with SID_TX_LOCATION_LINK_RESOLVE. See §6.3.1. | . | sid_dlrv_config.nwsync_time widened to uint16_t | App (FSK/LoRa) | Breaking (behavior) | Re-check any code that stores or compares it as uint8_t. See §6.3.2. | . | Location Library result and run-config structs reshaped; SID_LOCATION_METHOD_BLE_GATEWAY renamed; sid_location_update_almanac() removed | App (Location) | Breaking (compile) | Follow §6.3.4. | . | SID_BULK_DATA_TRANSFER_FILE_DESCRIPTOR_MAX_SIZE 128 → 200 | App (SBDT) | Breaking (behavior) | Resize buffers sized by this constant. See §6.3.5. | . | sid_pal_radio_is_channel_free() signature changed; two LoRa helper functions removed | Platform | Breaking (compile) | Follow §7.1. | . | sid_pal_radio_data_rate_t values renumbered | Platform | Breaking (behavior) | Rebuild any table indexed by data rate. See §7.1. | . | Region reporting (SID_DEVICE_INFO_TYPE_REGION) | App | Additive (optional); gates sub-GHz bring-up in sid_start() once you report a region | See §6.2.3. | . | request_fast_adv in struct sid_pal_ble_adapter_interface | Platform (BLE PAL) | Breaking (compile) for positional initializers; Breaking (behavior) otherwise | Append request_fast_adv as the final member; implement it as a one-shot force-fast latch; the PAL now owns the fast→slow transition. See §7.2.1. | . | Everything else (registration over wire and lite builds, keep-alive payload/ACK, MDR, BLE bonding, beacon events, GSK config, GPS assist) | App / platform | Additive (optional) | Adopt as needed. See §4. | . ", "url": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#3-if-you-only-read-one-section", "relUrl": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#3-if-you-only-read-one-section" },"819": { "doc": "Amazon Sidewalk MCU SDK Migration Guide", "title": "4. New features in 2.0", "content": "Each feature below has its own application note or developer guide. This section states what the feature is and which public symbols it adds; the referenced documents describe how to use it. 4.1 Registration over Wire and Factory-Registered Devices . An Endpoint can now be registered at the factory over a serial connection, using the new wired link type SID_LINK_TYPE_8 and the serial registration API (sid_serial_registration_init, sid_serial_registration_start, sid_serial_registration_process, sid_serial_registration_deinit). The wired link is brought up by that API, not by sid_init/sid_start, and is required in the diagnostics firmware used at the factory. A device registered this way is factory-registered and is field-activated by the Amazon Sidewalk stack on its first contact with the network. Three lite build variants (SID_SDK_CONFIG_BUILD_BLE_ONLY, SID_SDK_CONFIG_BUILD_FSK_ONLY, SID_SDK_CONFIG_BUILD_LORA_ONLY) restrict the stack to one link type and rely on factory registration: in these variants sid_init returns SID_ERROR_NOSUPPORT if the device is neither registered nor factory-registered, and a factory reset returns the device to the factory-registered state instead of the pre-registration state. For details, please refer to Sections 2.3.4, 2.15 and 3.30 to 3.33 of the Amazon Sidewalk API Developer Guide and to the Amazon Sidewalk Registration over Wire Application Note. Supplementary notes: . | New headers: sid_serial_ifc.h (transport callbacks the application provides) and sid_serial_registration.h (sid_serial_registration_init(), _start(), _process(), _deinit()). | SID_LINK_TYPE_8 = 1 << 7 is documented as “Wired (serial/UART) link.” Do not include it in sid_config.link_mask: sid_init() and sid_start() do not bring up a wired link. | Platform obligation: the manufacturing store must persist eight new credential records (SID_PAL_MFG_STORE_* values 4001 – 4008) so a factory-registered device keeps its registration across a reflash of the key-value store. See §7.4. | The three lite build variants are CMake options (default OFF, mutually exclusive; configuring more than one is a CMake error). In such a build sid_init() also returns SID_ERROR_NOSUPPORT for any link_mask other than exactly that link, and APIs that have no meaning for the link return SID_ERROR_NOSUPPORT. | Breaking (behavior) for products that ship a lite build: the factory reset wipes the persisted Sidewalk state and session keys, then restores the factory-provisioned credentials, so the device keeps its registration and can rejoin without a new registration flow. A product that relies on a factory reset to de-register the device must account for this. | . Reference: Amazon Sidewalk Registration over Wire Application Note (overview, factory diagnostic firmware, production firmware, security levels); SID API Developer Guide, serial registration API section; https://docs.sidewalk.amazon/manufacturing/. 4.2 Keep-alive payload and acknowledgement status . On the SubG-FSK link, and on the SubG-CSS (LoRa) link in Profile B or Profile C, the application can attach up to SID_KA_PAYLOAD_MAX_SIZE (19) bytes to each keep-alive frame and is told whether the keep-alive was acknowledged. SID_KA_PAYLOAD_MAX_SIZE (19) is the largest keep-alive payload that fits on both sub-GHz links; it equals the LoRa link MTU. | struct sid_sub_ghz_links_config has a new trailing member struct sid_ka_payload_config ka_payload (const uint8_t *data; uint8_t len;, in sid_900_cfg.h). Set it in the configuration passed to sid_init(). The stack does not copy the buffer; it reads it on every keep-alive, so the buffer must stay valid until sid_deinit(). You may change the buffer, data or len at run time; the next keep-alive uses the new values. data == NULL or len == 0 sends the default payload. sid_init() returns SID_ERROR_INVALID_ARGS if len exceeds SID_KA_PAYLOAD_MAX_SIZE. | SID_CONTROL_EVENT_KA_ACK_STATUS delivered through on_control_event_notify; event_data points to struct sid_ka_ack_status { enum sid_link_type link_type; bool ack_received; }. This event is emitted only for the SubG-FSK link and for the SubG-CSS (LoRa) link in Profile B or Profile C. | sid_dlrv_config.nwsync_time now also sets the FSK keep-alive interval, up to MAX_FSK_KA_INTERVAL_MINS (1440). See §6.3.2. | . Reference: SID API Developer Guide, keep-alive payload and control events sections. 4.3 LoRa medium data rate (MDR) and RX-window interval . The application can request a medium data rate on the LoRa link. MDR is honored only in regions that support it; otherwise the link runs at the low data rate (LDR). No error is returned and no public API reports the active data rate when MDR is not honored. | enum sid_link3_data_rate { SID_LINK3_DATA_RATE_LDR = 0, SID_LINK3_DATA_RATE_MDR = 1 } and sid_sub_ghz_links_config.link3_data_rate (trailing field; default LDR). | sid_device_profile_unicast_params.l3_mdr_rx_window_interval_ms (trailing field) selects the RX-window interval in MDR mode. Accepted values: 0 (no MDR-specific interval; the link uses its default; continuous RX cannot be requested through this field, use Profile C), SID_LINK3_RX_WINDOW_SEPARATION_5 (500 ms), SID_LINK3_RX_WINDOW_SEPARATION_2 (1000 ms) and SID_LINK3_RX_WINDOW_SEPARATION_3 (5000 ms); other values make sid_option(SID_OPTION_900MHZ_SET_DEVICE_PROFILE) return SID_ERROR_INCOMPATIBLE_PARAMS. SID_LINK3_RX_WINDOW_SEPARATION_4 (10000 ms) is declared in the enum but is not accepted for this field. | . Reference: Gateway Session Key (GSK) Application Note (LoRa data rate and RX-window interval); SID API Developer Guide, LoRa data rate section. 4.4 Bluetooth LE bonding . | Build flag: SID_SDK_CONFIG_ENABLE_BLE_BONDING (default 0). | SID_LINK_MODE_BONDED = 1 << 2 is reported in sid_status_detail::supported_link_modes when the connected mobile peer is the bonded owner. It is status-only and must not be used as a send-mode selector. | SID_BLE_BOND_TRIGGER_UUID (sid_ble_config_ifc.h): a characteristic whose encrypted value forces the peer to pair. | PAL: optional bond_control and get_advertiser_addr entries in struct sid_pal_ble_adapter_interface, and bond_callback in sid_pal_ble_adapter_callbacks_t. See §7.2. | . 4.5 FSK beacon events . SID_CONTROL_EVENT_BEACON_RECEIVED = 4 and SID_CONTROL_EVENT_BEACON_MISSED = 5 report FSK (Link Type 2) beacon reception through on_control_event_notify. These are distinct from SID_SDK_CONFIG_ENABLE_BEACON_DATA (default 0), which controls a Bluetooth LE connectionless beacon payload. Reference: Gateway Discovery and Selection Application Note, control events section. 4.6 Gateway Session Key (GSK) . GSK lets an endpoint and the gateways in its area share a session key, so a gateway can verify the sender of an uplink locally. Payload encryption and authentication keys are unchanged. GSK establishment is governed by the Amazon Sidewalk Cloud; the application only tunes three parameters (two timeouts and one threshold). | Build flag: SID_SDK_CONFIG_ENABLE_GSK (default 1). See §5.1. | Configuration: struct sid_gsk_config in sid_gsk_config.h, passed through sid_config.gsk_config. NULL, or a field set to 0, selects the defaults. See §6.1.1. | . | Field | Type | Range | Default | Meaning | . | idle_timeout_sec | uint32_t | 10 – 600 s | 240 | TX and RX idle window before GSK establishment is attempted. | . | app_ack_miss_threshold | uint32_t | 3 – 10 | 6 | Consecutive uplinks sent with an acknowledgement request that go unacknowledged while GSK is active; reaching the threshold falls back to legacy security. The count resets when any downlink is received under GSK. | . | retry_interval_sec | uint32_t | 43200 – 129600 s (12 – 36 h) | 86400 (24 h) | Minimum time after a fallback before GSK establishment is attempted again; the attempt itself still waits for the idle window (idle_timeout_sec). | . Values outside a range are clamped. No other GSK parameter is exposed through the public API. On the LoRa link an active GSK runs the link at the medium data rate (MDR, §4.3) even if the application configured LDR, and a later GSK fallback restarts the LoRa link, which the application observes as a link status change through on_status_changed. Reference: Gateway Session Key (GSK) Application Note (per-link effects and lifecycle, configuration fields, interacting settings, sizing); SID API Developer Guide, GSK configuration section. 4.7 Regulatory region reporting . sid_device_information.h adds SID_DEVICE_INFO_TYPE_REGION = 4, enum sid_device_region, and sid_device_information_is_region_registerable(). The SDK calls the latter from sid_start(); when the module is not initialized or the application reports no region, it returns true and 1.19 behavior is preserved. See §6.2.3. Reference: Sidewalk Internationalization Application Note (region values, configuring and reporting a region, unsupported regions); SID API Developer Guide, device information section. 4.8 Location Library: typed results, effort levels L5/L6, GPS assist . The Location Library now returns typed Wi-Fi and GNSS results, accepts a caller-ordered list of effort levels, adds FSK-gateway and LoRa multilateration methods, and supports cloud-initiated GPS-assisted positioning. | Build flags: SID_SDK_CONFIG_ENABLE_GNSS, SID_SDK_CONFIG_ENABLE_WIFI, SID_SDK_CONFIG_ENABLE_GPS_ASSIST (all default 0). | sid_msg_desc_tx_attributes.resolve_location becomes a flag mask (SID_TX_LOCATION_LINK_RESOLVE, SID_TX_LOCATION_GPS_ASSIST). See §6.3.1. | New PAL header sid_pal_gps_assist_ifc.h, required only when SID_SDK_CONFIG_ENABLE_GPS_ASSIST = 1. See §7.5. | Existing 1.19 location code requires changes. See §6.3.4. | . Reference: SID API Developer Guide, Location Library and location-resolution sections. Effort levels in 2.0: L1 BLE gateway, L2 FSK gateway, L3 Wi-Fi scan, L4 GNSS scan, L5 LoRa multilateration, L6 GPS assist. 4.9 Security level . SID_SDK_CONFIG_SECURITY_LEVEL advertises the endpoint security level to the cloud. Values: SID_SDK_CONFIG_SECURITY_LEVEL_HIGH (0, default) or SID_SDK_CONFIG_SECURITY_LEVEL_LOW (1). Override at build time, for example -DSID_SDK_CONFIG_SECURITY_LEVEL=SID_SDK_CONFIG_SECURITY_LEVEL_LOW. The SDK headers do not define the criteria for each level; keep the default unless your qualification process directs otherwise (see the Amazon Sidewalk Registration over Wire Application Note, security levels section). ", "url": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#4-new-features-in-20", "relUrl": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#4-new-features-in-20" },"820": { "doc": "Amazon Sidewalk MCU SDK Migration Guide", "title": "5. Stack configuration changes", "content": "5.1 New SID_SDK_CONFIG_* flags — Additive (optional), except ENABLE_GSK . sid_sdk_config.h adds the following flags. Only SID_SDK_CONFIG_ENABLE_GSK changes default behavior. | Flag | Default | Effect | . | SID_SDK_CONFIG_ENABLE_GSK | 1 | Gateway Session Key support. Breaking (behavior): a 1.19 application rebuilt on 2.0 advertises GSK capability and establishes a GSK when the cloud enables it. On LoRa an active GSK runs the link at MDR (§4.3) and a later GSK fallback restarts the LoRa link. Set to 0 to keep 1.19 behavior. | . | SID_SDK_CONFIG_ENABLE_BLE_BONDING | 0 | BLE adapter exposes bond_control and fires bond_callback. | . | SID_SDK_CONFIG_ENABLE_BEACON_DATA | 0 | Connectionless beacon data payload in BLE advertisements. | . | SID_SDK_CONFIG_ENABLE_GNSS | 0 | Location Library GNSS capability. | . | SID_SDK_CONFIG_ENABLE_WIFI | 0 | Location Library Wi-Fi capability. | . | SID_SDK_CONFIG_ENABLE_GPS_ASSIST | 0 | Cloud-initiated GPS-assisted location; requires the GPS-assist PAL (§7.5). | . | SID_SDK_CONFIG_SECURITY_LEVEL | SID_SDK_CONFIG_SECURITY_LEVEL_HIGH (0) | Endpoint security level advertised to the cloud; SID_SDK_CONFIG_SECURITY_LEVEL_LOW is 1. | . // Updated (2.0) — sid_sdk_config.h #ifndef SID_SDK_CONFIG_ENABLE_GSK #define SID_SDK_CONFIG_ENABLE_GSK 1 #endif #define SID_SDK_CONFIG_SECURITY_LEVEL_HIGH 0 #define SID_SDK_CONFIG_SECURITY_LEVEL_LOW 1 #ifndef SID_SDK_CONFIG_SECURITY_LEVEL #define SID_SDK_CONFIG_SECURITY_LEVEL SID_SDK_CONFIG_SECURITY_LEVEL_HIGH #endif . 5.2 Removed RF power tables — Additive (removal, no runtime effect) . SID_SDK_CONFIG_RF_POWER_MAX_TABLE and SID_SDK_CONFIG_RF_POWER_TABLE are removed. The 1.19 stack did not read them (only a developer command-line tool did), so a build that still defines them compiles and nothing changes at runtime. // Previous (1.19) — removed in 2.0 #ifndef SID_SDK_CONFIG_RF_POWER_MAX_TABLE #define SID_SDK_CONFIG_RF_POWER_MAX_TABLE { 20, 20, 20, 20, 20, 20 } #endif #ifndef SID_SDK_CONFIG_RF_POWER_TABLE #define SID_SDK_CONFIG_RF_POWER_TABLE { 20, 20, 20, 20, 20, 20 } #endif . What you do: delete any override of these macros. Transmit power is configured through sid_sub_ghz_links_config.link2_max_tx_power_in_dbm / link3_max_tx_power_in_dbm and the radio PAL configuration, as in 1.19. 5.3 Lite build options — Additive (optional) . See §4.1. 5.4 Exported utility headers — Additive (optional) . The SDK now installs utility headers under sid_utility_ifc/ (event queue, clock, list, endian and memory-pool helpers, among others). Several PAL headers include them. If your build already includes same-named headers from a private copy, remove the private copy to avoid duplicate definitions. No application call site changes. ", "url": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#5-stack-configuration-changes", "relUrl": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#5-stack-configuration-changes" },"821": { "doc": "Amazon Sidewalk MCU SDK Migration Guide", "title": "6. SID API changes", "content": "6.1 Data structures added . | # | Item | Header | Description | Label | . | 1 | struct sid_gsk_config | sid_gsk_config.h | GSK tunables (§4.6). | Additive | . | 2 | enum sid_msg_desc_tx_location_flags | sid_api.h | SID_TX_LOCATION_NONE = 0, SID_TX_LOCATION_LINK_RESOLVE = 1u << 0, SID_TX_LOCATION_GPS_ASSIST = 1u << 1. | Additive | . | 3 | struct sid_ka_payload_config, SID_KA_PAYLOAD_MAX_SIZE, sid_sub_ghz_links_config.ka_payload, struct sid_ka_ack_status | sid_900_cfg.h (payload), sid_api.h (ACK status) | Keep-alive payload configuration and ACK status (§4.2). | Additive | . | 4 | enum sid_link3_data_rate | sid_900_cfg.h | SID_LINK3_DATA_RATE_LDR = 0, SID_LINK3_DATA_RATE_MDR = 1. | Additive | . | 5 | enum sid_device_region | sid_device_information.h | UNSET = 0, NORTH_AMERICA = 1, EUROPE = 2, JAPAN = 3, AUSTRALIA_NZ = 4, NOT_SUPPORT = 0xFF. | Additive | . | 6 | struct sid_serial_registration_config, struct serial_ifc_context and callback typedefs | sid_serial_registration.h, sid_serial_ifc.h | Registration over Wire (§4.1). | Additive | . | 7 | Location result types: enum sid_location_result_type, struct sid_location_wifi_result, struct sid_location_gnss_result, union sid_location_data, struct sid_location_wifi_ap, struct sid_location_gnss_info, struct sid_location_gnss_pseudorange, struct sid_location_gnss_pseudoranges | sid_location.h | Typed location payloads (§6.3.4). | Additive | . | 8 | SID_BLE_BOND_TRIGGER_UUID | sid_ble_config_ifc.h | Bonding trigger characteristic UUID (§4.4). | Additive | . 6.1.1 Pass sid_gsk_config through sid_config . sid_api.h does not include sid_gsk_config.h, and the sid_api CMake target does not propagate its include directory. Include the header yourself and link the sid_gsk_config CMake interface target (or add sid_ifc/sid_gsk_config to your include path). // Updated (2.0) — struct sid_config tail const struct sid_time_sync_config *time_sync_config; /** * Gateway Session Key (GSK) configuration; see struct sid_gsk_config for the * individual tunables. If not provided (NULL), defaults are used. */ const struct sid_gsk_config *gsk_config; }; . Breaking (behavior) for non-zeroed configs: with SID_SDK_CONFIG_ENABLE_GSK = 1, sid_init() reads gsk_config whenever it is not NULL. A struct sid_config built field by field on a non-zeroed stack object leaves the new trailing pointer uninitialized and sid_init() dereferences it. Zero-initialize the struct (designated initializer or memset) or set .gsk_config = NULL explicitly. #include <sid_gsk_config.h> static const struct sid_gsk_config gsk_cfg = { .idle_timeout_sec = 240, .app_ack_miss_threshold = 6, .retry_interval_sec = 86400, }; struct sid_config config = { /* ... existing fields ... */ .gsk_config = &gsk_cfg, /* or NULL for defaults */ }; sid_error_t err = sid_init(&config, &handle); if (err != SID_ERROR_NONE) { /* handle error */ } . 6.2 APIs added . | # | API | Header | Description | Label | . | 1 | sid_serial_registration_init(), sid_serial_registration_start(), sid_serial_registration_process(), sid_serial_registration_deinit() | sid_serial_registration.h | Factory registration over a serial transport (§4.1, §6.2.4). on_registration_done runs inside the receive path and must only set a flag. | Additive | . | 2 | sid_device_information_is_region_registerable() | sid_device_information.h | Returns whether the reported region permits radio bring-up (§6.2.3). | Additive | . | 3 | sid_location_parse_wifi(), sid_location_parse_gnss(), sid_location_parse_pseudoranges(), sid_location_send_pseudoranges(), sid_location_send_pseudoranges_raw() | sid_location.h | Typed result parsers and GPS-assist pseudorange uplink (§6.3.4). | Additive | . | 4 | SID_CONTROL_EVENT_BEACON_RECEIVED = 4, SID_CONTROL_EVENT_BEACON_MISSED = 5, SID_CONTROL_EVENT_KA_ACK_STATUS = 6 | sid_api.h | New control events (§4.2, §4.5). | Additive | . 6.2.1 Set a keep-alive payload . static uint8_t ka_buf[SID_KA_PAYLOAD_MAX_SIZE] = { /* ... */ }; static struct sid_sub_ghz_links_config sub_ghz_cfg = { /* ... existing members ... */ .ka_payload = { .data = ka_buf, .len = sizeof(ka_buf) }, }; /* pass &sub_ghz_cfg as sid_config.sub_ghz_link_config */ sid_error_t err = sid_init(&config, &handle); if (err != SID_ERROR_NONE) { /* SID_ERROR_INVALID_ARGS if len > SID_KA_PAYLOAD_MAX_SIZE */ } . To change the payload later, edit ka_buf or sub_ghz_cfg.ka_payload; the next keep-alive uses the new values. 6.2.2 Handle new control events . Extend your on_control_event_notify handler. Unknown event types should still be ignored, as before. case SID_CONTROL_EVENT_KA_ACK_STATUS: { const struct sid_ka_ack_status *s = data->event_data; /* s->link_type, s->ack_received */ break; } case SID_CONTROL_EVENT_BEACON_RECEIVED: case SID_CONTROL_EVENT_BEACON_MISSED: break; . 6.2.3 Report the regulatory region (optional) . Report SID_DEVICE_INFO_TYPE_REGION through the device information API. Once you report a region, sid_start() consults sid_device_information_is_region_registerable(). SID_DEVICE_REGION_NORTH_AMERICA, SID_DEVICE_REGION_EUROPE and SID_DEVICE_REGION_AUSTRALIA_NZ are accepted; SID_DEVICE_REGION_UNSET, SID_DEVICE_REGION_JAPAN and SID_DEVICE_REGION_NOT_SUPPORT are refused. When the region is refused, sid_start() drops the sub-GHz links from the requested mask and starts Bluetooth LE only; if no Bluetooth LE link was requested it returns SID_ERROR_INVALID_STATE. Applications that report no region keep 1.19 behavior. See the Sidewalk Internationalization Application Note for the regions supported by a given release. 6.2.4 Serial registration APIs . Factory registration over a wired link (SID_LINK_TYPE_8): . struct sid_serial_registration_config { const struct serial_ifc_context *ifc; /* application serial transport, already initialized */ void (*on_registration_done)(void *ctx); /* completion callback; may only set a flag */ void *ctx; }; sid_error_t sid_serial_registration_init(const struct sid_serial_registration_config *cfg); sid_error_t sid_serial_registration_start(void); void sid_serial_registration_process(void); sid_error_t sid_serial_registration_deinit(void); . These APIs do not use sid_init()/sid_start(). Please refer to Sections 2.3.4 and 3.30 to 3.33 of the Amazon Sidewalk API Developer Guide. 6.3 Updates to existing data structures . 6.3.1 sid_msg_desc_tx_attributes.resolve_location — Breaking (behavior) . // Previous (1.19) struct sid_msg_desc_tx_attributes { /* ... */ uint16_t ttl_in_seconds; bool resolve_location; }; // Updated (2.0) struct sid_msg_desc_tx_attributes { /* ... */ uint16_t ttl_in_seconds; uint8_t resolve_location; /* bit mask of enum sid_msg_desc_tx_location_flags */ }; . What you do: replace .resolve_location = true with .resolve_location = SID_TX_LOCATION_LINK_RESOLVE. true still evaluates to SID_TX_LOCATION_LINK_RESOLVE (1), so existing code keeps working, but any code that reads the field as a bool must treat it as a mask. Add SID_TX_LOCATION_GPS_ASSIST only with SID_SDK_CONFIG_ENABLE_GPS_ASSIST = 1. 6.3.2 sid_dlrv_config.nwsync_time — Breaking (behavior) . // Previous (1.19) struct sid_dlrv_config { uint16_t time; uint8_t nwsync_time; /* LoRa Profile B NW sync time, mins */ bool is_set; }; // Updated (2.0) struct sid_dlrv_config { uint16_t time; uint16_t nwsync_time; /* KA / NW-sync interval, mins. LoRa Profile B: 1-240. FSK: up to 1440. 0 = link default. */ bool is_set; }; . What you do: update any variable, storage record or comparison that assumed an 8-bit value. 0 (SID_NWSYNC_TIME_NOT_SET) now means “use the link default”. sizeof(struct sid_dlrv_config) changes. 6.3.3 sid_sub_ghz_links_config and sid_device_profile_unicast_params — Additive (trailing fields) . // Updated (2.0) — trailing members struct sid_sub_ghz_links_config { /* ... existing fields ... */ struct sid_link_type_2_registration_config registration_config; enum sid_link3_data_rate link3_data_rate; /* new, default LDR */ struct sid_ka_payload_config ka_payload; /* new, default keep-alive payload */ }; struct sid_device_profile_unicast_params { /* ... existing fields ... */ uint32_t l2_rx_duration_sec; enum sid_link3_rx_window_separation_ms l3_mdr_rx_window_interval_ms; /* new */ }; . Zero-initialized or designated-initialized instances keep 1.19 behavior. Positional initializers must add the new members. 6.3.4 Location Library — Breaking (compile) . Any 1.19 application that uses the Location Library must change: . | 1.19 symbol | 2.0 replacement | . | SID_LOCATION_METHOD_BLE_GATEWAY | SID_LOCATION_METHOD_GATEWAY (same value 1u << 0). | . | sid_location_run_config.buffer, .size | .payload_type (enum sid_location_result_type) + .payload (union sid_location_data); the library copies the bytes during sid_location_run(). New optional .levels[SID_LOCATION_MAX_LEVELS] / .num_levels (0 keeps 1.19 behavior). | . | sid_location_result.payload[], .size, .raw_gnss_data[], .raw_gnss_data_size | .result_type + .parsed (union sid_location_data); pointers are valid only during on_update. Use sid_location_parse_wifi() / sid_location_parse_gnss() to decode. | . | sid_location_update_almanac() | Removed. No replacement in the public API. | . | SID_LOCATION_EFFORT_INVALID (5), SID_LOCATION_EFFORT_DEFAULT (6) | Now 7 and 8; SID_LOCATION_EFFORT_L5 and SID_LOCATION_EFFORT_L6 are inserted. Do not persist or compare these numerically. | . // Previous (1.19) struct sid_location_run_config { enum sid_location_effort_mode mode; enum sid_location_run_type type; uint8_t *buffer; size_t size; }; // Updated (2.0) struct sid_location_run_config { enum sid_location_effort_mode mode; enum sid_location_run_type type; enum sid_location_result_type payload_type; union sid_location_data payload; enum sid_location_effort_mode levels[SID_LOCATION_MAX_LEVELS]; uint8_t num_levels; }; . // Previous (1.19) struct sid_location_result { enum sid_location_status status; sid_error_t err; enum sid_location_effort_mode mode; enum sid_link_type link; uint8_t payload[SID_LOCATION_MAX_PAYLOAD_SIZE]; size_t size; uint8_t raw_gnss_data[SID_LOCATION_MAX_PAYLOAD_SIZE]; size_t raw_gnss_data_size; }; // Updated (2.0) struct sid_location_result { enum sid_location_status status; sid_error_t err; enum sid_location_effort_mode mode; enum sid_link_type link; enum sid_location_result_type result_type; union sid_location_data parsed; }; . sid_location_config gains a trailing void *gps_assist_pal_config (additive). New method bits SID_LOCATION_METHOD_FSK_GATEWAY = 1u << 3 and SID_LOCATION_METHOD_LORA_MLAT = 1u << 4 are included in SID_LOCATION_METHOD_ALL. 6.3.5 SID_BULK_DATA_TRANSFER_FILE_DESCRIPTOR_MAX_SIZE — Breaking (behavior) . The constant grows from 128 to 200. Buffers and structures sized by it grow by 72 bytes. Re-check static allocations and any persisted layout. 6.3.6 sid_config.gsk_config — Additive (trailing field) . See §6.1.1. 6.3.7 sid_device_dyn_info.region — Additive (new union member) . See §6.2.3. 6.4 Enumerator additions — Additive . | enum sid_link_type: SID_LINK_TYPE_8 = 1 << 7 (wired; not used with sid_init() / sid_start()). | enum sid_link_mode: SID_LINK_MODE_BONDED = 1 << 2 (status-only). | enum sid_link3_rx_window_separation_ms: SID_LINK3_RX_WINDOW_SEPARATION_2 = 1000, _4 = 10000 (declared; not accepted for l3_mdr_rx_window_interval_ms), _5 = 500. | enum sid_dl_route_validity_time_mins: DEF_DL_ROUTE_VALIDITY_TIME_MINS_FSK = 1080. | enum sid_link3_profile_b_nw_sync_time_mins: SID_NWSYNC_TIME_NOT_SET = 0, MAX_FSK_KA_INTERVAL_MINS = 1440. | enum sid_on_dev_cert_print_fileds: SID_ODC_PRINT_SMSN. | SID_CONTROL_EVENT_LAST moves accordingly. enum sid_option is unchanged from 1.19. | . ", "url": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#6-sid-api-changes", "relUrl": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#6-sid-api-changes" },"822": { "doc": "Amazon Sidewalk MCU SDK Migration Guide", "title": "7. PAL interface changes", "content": "7.1 Radio PAL (sid_pal_radio_ifc.h, sid_pal_radio_lora_defs.h) — Breaking (compile and behavior) . Every radio PAL port must change. Signature change: . // Previous (1.19) int32_t sid_pal_radio_is_channel_free(uint32_t freq, int16_t threshold, uint32_t delay_us, bool *is_channel_free); // Updated (2.0) struct sid_phy_multi_channel_data { int16_t threshold; /* RSSI threshold in dBm */ uint32_t delay_us; /* per-sub-band sense time in microseconds */ uint8_t scan_num; /* number of frequencies in freq */ const uint32_t *freq; /* array of scan_num frequencies in Hz */ }; int32_t sid_pal_radio_is_channel_free(const struct sid_phy_multi_channel_data *scan_data, bool *is_channel_free); . The channel is busy if any sub-band’s RSSI exceeds the threshold. A single-channel check is a one-element sweep (scan_num = 1). Removed functions: sid_pal_radio_lora_mod_params_to_data_rate() and sid_pal_radio_lora_data_rate_to_mod_params(). Remove their implementations and any callers. Renumbered enum — Breaking (behavior): . | Enumerator | 1.19 | 2.0 | . | SID_PAL_RADIO_DATA_RATE_1_76KBPS | — | 6 (new) | . | SID_PAL_RADIO_DATA_RATE_5_47KBPS | — | 7 (new) | . | SID_PAL_RADIO_DATA_RATE_12_5KBPS | 6 | 8 | . | SID_PAL_RADIO_DATA_RATE_CUSTOM | 7 | 9 | . | SID_PAL_RADIO_DATA_RATE_MAX_NUM | 7 | 9 | . Rebuild any table indexed by sid_pal_radio_data_rate_t and any array sized by SID_PAL_RADIO_DATA_RATE_MAX_NUM. Do not persist these values. Other additions: SID_PAL_RADIO_RC_ANZ = 4 (so SID_PAL_RADIO_RC_MAX is now 5; region tables grow by one); RADIO_ERROR_FW_NOT_UP_TO_DATE (-11) and RADIO_ERROR_FW_TYPE_NOT_SUPPORTED (-12); trailing field sid_pal_radio_packet_cfg_t.side_sf_enabled; in sid_pal_radio_lora_defs.h, SID_PAL_RADIO_LORA_SF_INVALID 0x0, trailing fields sid_pal_radio_lora_modulation_params_t.side_sf and sid_pal_radio_lora_rx_packet_status_t.side_detect. The 2.0 headers do not document the semantics of side_sf, side_detect and side_sf_enabled; zero them unless your radio PAL vendor documents otherwise. Each struct gains a one-byte trailing member and sizeof changes. 7.2 BLE adapter PAL (sid_pal_ble_adapter_ifc.h) — Additive (optional) . Two optional entries are appended to struct sid_pal_ble_adapter_interface after get_mac_addr. The SDK also adds bond_callback to the sid_pal_ble_adapter_callbacks_t it passes to your set_callback: . typedef void (*sid_pal_ble_bond_callback_t)(bool bonded, uint8_t *addr); enum sid_pal_ble_bond_cmd { SID_PAL_BLE_BOND_CMD_ENABLE = 0, SID_PAL_BLE_BOND_CMD_DISABLE, SID_PAL_BLE_BOND_CMD_DELETE_ALL, SID_PAL_BLE_BOND_CMD_DELETE_PEER, SID_PAL_BLE_BOND_CMD_IS_BONDED, SID_PAL_BLE_BOND_CMD_IS_CONN_BONDED }; /* struct sid_pal_ble_adapter_interface, appended: */ sid_error_t (*bond_control)(enum sid_pal_ble_bond_cmd cmd, void *data, size_t size); sid_error_t (*get_advertiser_addr)(uint8_t *addr); /* sid_pal_ble_adapter_callbacks_t (populated by the SDK), appended: */ sid_pal_ble_bond_callback_t bond_callback; . The SDK checks bond_control for NULL before calling it; get_advertiser_addr is not called by the stack. Implement them or leave them NULL; return SID_ERROR_NOSUPPORT if your platform does not support an operation. Ports using positional initializers for struct sid_pal_ble_adapter_interface must append the new members. When a bonding procedure completes or fails, call callbacks->bond_callback(bonded, addr) (addr = NULL on failure); the SDK always sets this pointer, and with SID_SDK_CONFIG_ENABLE_BLE_BONDING = 0 it is a no-op. 7.2.1 Advertising phase: request_fast_adv — Breaking (compile) for positional initializers; Breaking (behavior) otherwise . Before 2.0, the SAL selected the BLE advertising phase on every start, and re-hinted on every TX-ID rotation (every ADV_ROTATION_TIMEOUT_SEC, 900 s). A device that had settled into the slow phase could be pulled back into a periodic fast burst on each rotation — a power and discoverability-latency regression, and on some platforms a correctness bug (see the Nordic note below). 2.0 inverts this ownership. The SAL now only forces the fast phase on a genuine discoverable event — fresh start, reconnect, connection request, factory reset, GCS time request, D2D config — and never on a TX-ID rotation restart. The PAL owns the fast→slow transition through its own fast-window timer, and must preserve its phase across a stop/start. That is why the hint is now one-way (force fast) with a void return rather than a bool fast selector: the SAL has no view of the PAL’s fast-window deadline and must not reset a device mid-transition. A wrong phase is a power/latency matter, not a functional one, so the hint is advisory. // Updated (2.0) — one-way force-fast hint, appended as the FINAL interface member /** * Request that advertising (re)enter the FAST phase now. Optional (may be * NULL); when NULL start_adv keeps its default behavior of always beginning * fast. The SAL calls this only on an external \"make me discoverable\" event * (fresh start, reconnect, connection request, factory reset, GCS time * request, D2D config) -- never on a TX-ID rotation restart. */ void (*request_fast_adv)(void); . The member is appended last in struct sid_pal_ble_adapter_interface (after get_advertiser_addr, §7.2), consistent with the ABI-stability rule for this struct: new members always go last, so a prebuilt SAL module or an out-of-tree positional-initializer PAL does not call the wrong vtable slot. In-tree PALs use designated initializers (.request_fast_adv = ...) and compile unchanged if you don’t adopt it — Additive. Ports using positional initializers for struct sid_pal_ble_adapter_interface must append the new member — Breaking (compile) for them. The SAL checks request_fast_adv for NULL before calling it; a NULL member keeps the default “always begin fast” behavior at start_adv. The contract. A conforming PAL honors three invariants: . | request_fast_adv forces the fast phase for the next start_adv. Implement it as a one-shot latch consumed and reset by start_adv — do not leave it latched across subsequent starts. | The PAL owns the fast→slow transition: arm your own fast-window timer and step the device from fast to slow yourself. The SAL will not hint slow and will not re-hint on rotation. | Preserve the phase across a PAL-internal stop/start. Any restart the PAL does on its own — a disconnect-while-advertising re-advertise, a config-update restart — bypasses the SAL hint, so the PAL must set the force-fast latch itself if (and only if) that restart is a genuine come-up-discoverable event. A plain rotation restart must not force fast. | . Make the PAL self-contained on deinit/init: reset the phase state on deinit to the cold-boot default (fast), matching first-boot behavior, so a deinit→init cycle does not inherit the last rotation’s phase. A single-mode PAL that has no slow phase (for example, a port delegating to a fixed-interval adapter) should implement request_fast_adv as an explicit, documented no-op rather than leaving it NULL, so the interface is visibly complete across all ports. Per-platform notes. Each in-tree PAL carries the fast→slow transition in its own mechanism: . | PAL | Fast→slow mechanism | Notes | . | Nordic (ble_adapter_native.c) | SDK ble_advertising module FAST→SLOW→IDLE ladder | Correctness-critical: requesting SLOW with ble_adv_slow_enabled == false degrades straight to IDLE while ble_advertising_start() still returns NRF_SUCCESS — advertising goes dark while the adapter reports success. Select FAST whenever slow is disabled so a real fallback ladder is always underneath. Phase state lives in ctx (ctx.start_adv_fast). | . | Nordic IoT-BLE (ble_adapter_iot_ble.c) | None — single advertising mode via Amazon FreeRTOS BTBleAdapter (pxStartAdv) | No fast/slow phase; request_fast_adv is an explicit no-op. Always effectively fast. | . | Silabs (ble_adapter.c) | fast_timeout timer | — | . | TI (ble_adapter.c) | enableSlowIntvAdv + last_set_adv_interval, stepped in sid_pal_ble_adapter_handle_adv_terminated_cb | No FAST→SLOW→IDLE ladder; a slow request puts the radio on air at the slow interval unconditionally (sid_pal_set_adv_param + pxStartAdv), so it cannot hit the Nordic silent-stop. | . | Telink (sid_ble_adapter.c) | fast-window work item | sid_ble_advert_start consumes and resets the force-fast latch within itself on every start. | . 7.3 GNSS and Wi-Fi PAL (sid_pal_gnss_ifc.h, sid_pal_wifi_ifc.h) — Additive . sid_pal_gnss_config and sid_pal_wifi_config gain a trailing struct sid_event_queue *event_queue (may be NULL). Both headers now include sid_event_queue_ifc.h from sid_utility_ifc/; make sure that directory is on the include path. 7.4 Manufacturing store PAL (sid_pal_mfg_store_ifc.h) — Additive, with a collision check . Eight value identifiers 4001 – 4008 and their sizes are added above SID_PAL_MFG_STORE_CORE_VALUE_MAX (4000), in the range the 1.19 header described as available to applications: . | Identifier | Value | Size | . | SID_PAL_MFG_STORE_WAN_MASTER_KEY | 4001 | 16 | . | SID_PAL_MFG_STORE_WAN_KEY_PARAMS | 4002 | 6 | . | SID_PAL_MFG_STORE_APP_MASTER_KEY | 4003 | 16 | . | SID_PAL_MFG_STORE_APP_KEY_PARAMS | 4004 | 2 | . | SID_PAL_MFG_STORE_TSYNC_COUNTER_SEED | 4005 | 4 | . | SID_PAL_MFG_STORE_TX_UUID_PARAMS | 4006 | 2 | . | SID_PAL_MFG_STORE_CONFIGURATION_COMPLETE | 4007 | 1 | . | SID_PAL_MFG_STORE_SIDEWALK_ID | 4008 | 7 | . What you do: if your application already uses identifiers 4001 – 4008, move them. If you use Registration over Wire, your manufacturing store must be able to write and read these records; the set is treated as complete only when all eight are present. No existing identifier or size changed. 7.5 GPS-assist PAL (sid_pal_gps_assist_ifc.h) — New, opt-in . Required only when SID_SDK_CONFIG_ENABLE_GPS_ASSIST = 1. Implement sid_pal_gps_assist_init(), _deinit(), _inject_ephemeris(), _start_acquisition(), _abort_acquisition(), _get_pseudoranges() and _get_power_state(); configure through struct sid_pal_gps_assist_config (event callback, acquisition timeout, event queue, memory pool, platform config). See the Amazon Sidewalk Location Library Developer Guide. ", "url": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#7-pal-interface-changes", "relUrl": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#7-pal-interface-changes" },"823": { "doc": "Amazon Sidewalk MCU SDK Migration Guide", "title": "8. Migration checklist", "content": "Application: . | Delete any SID_SDK_CONFIG_RF_POWER_TABLE / SID_SDK_CONFIG_RF_POWER_MAX_TABLE definitions (§5.2). | Decide on SID_SDK_CONFIG_ENABLE_GSK (default 1). Make sure struct sid_config is zero-initialized or set .gsk_config = NULL explicitly (NULL selects defaults); optionally include sid_gsk_config.h, link the sid_gsk_config target and point gsk_config at a struct sid_gsk_config (§6.1.1). LoRa products: note the MDR and link-restart effects (§4.6). | Replace .resolve_location = true with SID_TX_LOCATION_LINK_RESOLVE; treat the field as a mask (§6.3.1). | Re-check code that handles sid_dlrv_config.nwsync_time as an 8-bit value (§6.3.2). | Location Library users: rename SID_LOCATION_METHOD_BLE_GATEWAY, migrate run_config and result to the typed payload/parsed unions, remove sid_location_update_almanac() calls, stop comparing effort enumerators numerically (§6.3.4). | Bulk data transfer users: resize buffers for SID_BULK_DATA_TRANSFER_FILE_DESCRIPTOR_MAX_SIZE = 200 (§6.3.5). | Convert positional initializers of sid_config, sid_sub_ghz_links_config and sid_device_profile_unicast_params to designated initializers (§6.3.3, §6.3.6). | Optional: set sid_sub_ghz_links_config.ka_payload and handle SID_CONTROL_EVENT_KA_ACK_STATUS, _BEACON_RECEIVED, _BEACON_MISSED (§6.2.1, §6.2.2). | Optional: request MDR with link3_data_rate = SID_LINK3_DATA_RATE_MDR and set l3_mdr_rx_window_interval_ms (§4.3). | Optional: report the regulatory region; note that sid_start() then enforces it (§6.2.3). | Optional: set SID_SDK_CONFIG_SECURITY_LEVEL (§4.9). | Do not pass SID_LINK_TYPE_8 to sid_init() / sid_start(); use the serial registration API instead (§4.1). | . Platform (PAL): . | Update sid_pal_radio_is_channel_free() to the struct sid_phy_multi_channel_data signature; delete sid_pal_radio_lora_mod_params_to_data_rate() / sid_pal_radio_lora_data_rate_to_mod_params() (§7.1). | Rebuild data-rate-indexed tables for the renumbered sid_pal_radio_data_rate_t; add SID_PAL_RADIO_RC_ANZ; handle the new radio error codes; zero the new side_sf / side_detect / side_sf_enabled members unless documented otherwise (§7.1). | Implement bond_control and get_advertiser_addr (or leave them NULL) in struct sid_pal_ble_adapter_interface; invoke callbacks->bond_callback from your bonding event handler (§7.2). | Add sid_utility_ifc/ to the include path; set or NULL the new event_queue fields in GNSS/Wi-Fi configs (§7.3, §5.4). | Check manufacturing-store identifiers 4001 – 4008 for collisions; support them if you use Registration over Wire (§7.4). | GPS assist users: implement sid_pal_gps_assist_ifc.h (§7.5). | Rebuild with the lite build CMake options if you ship a one-link product (§4.1). | Lite builds: review any flow that relies on a factory reset to de-register the device; in these builds a factory reset restores the factory-registered state (§4.1). | Added request_fast_adv(void) in your BLE adapter PAL’s interface initializer (or add the member if your port never implemented the old one); positional initializers must append it as the final member (§7.2.1). | Implement request_fast_adv as a one-shot force-fast latch consumed by start_adv, or leave it NULL to keep “always begin fast” (§7.2.1). | Move your fast-window timer into the PAL so it carries the device fast→slow; stop expecting a slow hint from the SAL on rotation (§7.2.1). | Preserve the advertising phase across a PAL-internal stop/start; force fast only on a genuine discoverable restart, never on a rotation restart (§7.2.1). | Reset the phase state in deinit to the fast cold-boot default so the PAL is self-contained across a deinit→init cycle (§7.2.1). | Single-mode BLE PALs: implement request_fast_adv as an explicit no-op, not NULL (§7.2.1). | Nordic BLE PAL: select FAST when slow is disabled to avoid the SLOW→IDLE silent-stop (§7.2.1). | . 8.1 Retest after migrating . | LoRa: data rate actually in use and RX-window interval after setting a device profile; link restart behavior when a GSK is established or falls back. | FSK: keep-alive interval (DLRV minus 5 minutes unless set through sid_dlrv_config.nwsync_time); beacon events. | Keep-alive payload from sid_sub_ghz_links_config.ka_payload (including a run-time change to the buffer) and SID_CONTROL_EVENT_KA_ACK_STATUS handling. | Bulk data transfer with descriptors up to 200 bytes. | Location Library result parsing (result_type / parsed) and effort-level ordering. | BLE status bits, including SID_LINK_MODE_BONDED if bonding is enabled. | Region gate in sid_start() if your application reports a region. | Manufacturing-store identifiers 4001 – 4008 and Registration over Wire, if used. | Factory reset on lite builds: confirm the device returns to its factory-registered state and rejoins. | Fresh BLE advertising start comes up fast, then transitions to slow on the PAL’s own timer and stays slow across rotations (no periodic fast burst). | Reconnect, connection request, factory reset, GCS time request and D2D config each force the BLE advertising phase back to fast. | A disconnect-while-advertising re-advertise comes up fast. | A BLE config-update restart (sid_option(SID_OPTION_BLE_USER_CONFIG...) or a connection-policy change) comes up fast, not a stale slow. | BLE deinit → init behaves like a cold boot (comes up fast), not inheriting the last rotation’s phase. | Nordic: BLE advertising is actually on air with slow_enabled == false (no silent IDLE stop). | . ", "url": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#8-migration-checklist", "relUrl": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#8-migration-checklist" },"824": { "doc": "Amazon Sidewalk MCU SDK Migration Guide", "title": "9. References", "content": ". | Gateway Session Key (GSK) Application Note | Amazon Sidewalk Registration over Wire — Application Note | Gateway Discovery and Selection Application Note | Sidewalk Internationalization Application Note | Amazon Sidewalk Location Library Developer Guide | Amazon Sidewalk SID API Developer Guide — https://docs.sidewalk.amazon/sid-api-dg/ | . ", "url": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#9-references", "relUrl": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#9-references" },"825": { "doc": "Amazon Sidewalk MCU SDK Migration Guide", "title": "10. Glossary", "content": "| Term | Meaning | . | Endpoint | A Sidewalk-enabled device running the MCU SDK. | . | Gateway | A Sidewalk bridge that relays traffic between endpoints and the Amazon Sidewalk Cloud. | . | Uplink | A message from an endpoint toward the cloud. | . | Downlink | A message from the cloud toward an endpoint. | . | GSK | Gateway Session Key: a session key shared between an endpoint and the gateways in its area. | . | KA | Keep-alive frame sent periodically on SubG-FSK links and on SubG-CSS links in Profile B or Profile C. | . | LDR / MDR | Low / medium data rate on the SubG-CSS (LoRa) link. | . | PAL | Platform Abstraction Layer: the hardware interface a platform port implements. | . | SBDT | Sidewalk Bulk Data Transfer. | . ", "url": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#10-glossary", "relUrl": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#10-glossary" },"826": { "doc": "Amazon Sidewalk MCU SDK Migration Guide", "title": "11. Change history", "content": "| Version | Summary of Changes | . | 1 | First release, covering migration from SDK 1.19 to SDK 2.0. | . | 2 | Add BLE advertising phase PAL change (request_fast_adv) in §7.2.1. | . ", "url": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#11-change-history", "relUrl": "/sid-api-dg/sidewalk-mcu-sdk-migration-guide.html#11-change-history" },"827": { "doc": "Amazon Sidewalk Mobile SDK API Reference", "title": "Amazon Sidewalk Mobile SDK API Reference", "content": "The Amazon Sidewalk Mobile SDK is bundled as part of the Amazon Sidewalk service and onboard Mobile devices to support Amazon Sidewalk network. For more information on the latest API reference specific to Amazon Sidewalk Mobile SDKs for both Android and iOS, check the following links. | View the Amazon Sidewalk Mobile Android SDK API Reference | View the Amazon Sidewalk Mobile iOS SDK API Reference | . ", "url": "/mobile-sdk/sidewalk-mobile-sdk-api-ref.html", "relUrl": "/mobile-sdk/sidewalk-mobile-sdk-api-ref.html" },"828": { "doc": "Amazon Sidewalk Mobile SDK Release Notes", "title": "Amazon Sidewalk Mobile Release Notes", "content": "Check out the released versions of Amazon Sidewalk Mobile SDK for Android and iOS and download to build apps with Amazon Sidewalk functionalities. Topics . | Android SDK Release Notes | iOS SDK Release Notes | Known Issues in Dependencies | . ", "url": "/mobile-sdk/sidewalk-mobile-sdk-release-notes.html#amazon-sidewalk-mobile-release-notes", "relUrl": "/mobile-sdk/sidewalk-mobile-sdk-release-notes.html#amazon-sidewalk-mobile-release-notes" },"829": { "doc": "Amazon Sidewalk Mobile SDK Release Notes", "title": "Amazon Sidewalk Mobile Android SDK Release Notes", "content": "| Version | Release date | Android release notes | API Reference | . | 1.3.2 | March 26, 2025 | Amazon Sidewalk Mobile Android SDK 1.3.2 is released. New Features . | Introduce compatibility with Amazon Sidewalk MCU SDK 1.18 while maintaining support for previous versions of the Sidewalk MCU SDK. | . Bug Fixes . | Fix BLE connection issue that could occur when calling secureConnect() or secureConnectDevice() to a device right after disconnecting the connection with that device. | . | View | . | 1.2.0 | February 15, 2024 | Amazon Sidewalk Mobile Android SDK 1.2.0 is released. Important Changes . | Introduce new secureConnectDevice / registerDevice / deregisterDevice APIs that consume Sidewalk Manufacturing Serial Number (SMSN) only instead of Sidewalk ID + SMSN. | The automatic deregister & factory reset mechanism in the device registration process has been removed in the new registerDevice API. | . | Improve error handling when performing actions on a device that has already been deregistered but not successfully reset. | . New Features . | Introduce truncatedSmsn and fullSmsn in SidewalkDevice to return the device’s SMSN value. | Introduce a new set of interfaces to support using the device's SMSN for operations, including . | connect: secureConnectDevice(smsn:) | register: registerDevice(smsn:), registerDevice(connection:) | deregister: deregisterDevice(smsn:) | . | Introduce RegistrationDetail enum with alreadyRegistered and registrationSucceeded that comes with the result of the new register APIs. | Introduce uploadDeviceMetrics in SidewalkConnection to support collecting device metrics and upload to Amazon Sidewalk cloud. | . Bug Fixes . | Fix ProGuard rules to prevent obfuscating public classes and functions. | Minor bug fixes in deregistration for legacy devices. | Fix issue on getting device information from Amazon Sidewalk cloud. | . Known issues . | There may be an issue if calling secureConnect() or secureConnectDevice() to a device right after disconnecting the connection with that device. It is suggested to put a delay (e.g. 5 seconds) in between if there is a need to call secure connect API right after disconnection. | . | View | . | 1.1.0 | March 24, 2023 | Amazon Sidewalk Mobile Android SDK 1.1.0 is released. Amazon Sidewalk Mobile Android SDK provides a one-stop solution for everything related to Amazon Sidewalk on Android mobiles. The initial release contains APIs including: . | scan(), secureConnect(), register(), deregister(), and clearAccountCache() in Sidewalk to interact with end devices. | subscribe(), write(), startCoverageTest(), stopCoverageTest(), isAvailable, and disconnect() in SidewalkConnection to perform operations in a connection with an Amazon Sidewalk device. | getToken() in SidewalkAuthProvider to provide LWA token to Amazon Sidewalk Mobile SDK for communication with the Amazon Sidewalk cloud. | log() in SidewalkLogging to receive logs from Amazon Sidewalk Mobile SDK. | . | View | . ", "url": "/mobile-sdk/sidewalk-mobile-sdk-release-notes.html#amazon-sidewalk-mobile-android-sdk-release-notes", "relUrl": "/mobile-sdk/sidewalk-mobile-sdk-release-notes.html#amazon-sidewalk-mobile-android-sdk-release-notes" },"830": { "doc": "Amazon Sidewalk Mobile SDK Release Notes", "title": "Amazon Sidewalk Mobile iOS SDK Release Notes", "content": "| Version | Release date | iOS release notes | API Reference | SDK Download | . | 1.3.0 | February 6, 2025 | Amazon Sidewalk Mobile iOS SDK 1.3.0 is released. New Features . | Introduce compatibility with Amazon Sidewalk MCU SDK 1.18 while maintaining support for previous versions of the Sidewalk MCU SDK. | . | View | Download | . | 1.2.0 | February 15, 2024 | Amazon Sidewalk Mobile iOS SDK 1.2.0 is released. Important Changes . | Introduce new secureConnectDevice / registerDevice / deregisterDevice APIs that consume Sidewalk Manufacturing Serial Number (SMSN) only instead of Sidewalk ID + SMSN. | The automatic deregister & factory reset mechanism in the device registration process has been removed in the new registerDevice API. | . | Improve error handling when performing actions on a device that has already been deregistered but not successfully reset. | . New Features . | Introduce truncatedSmsn and fullSmsn in SidewalkDevice to return the device’s SMSN value. | Introduce a new set of interfaces to support using the device's SMSN for operations, including . | connect: secureConnectDevice(smsn:) | register: registerDevice(smsn:), registerDevice(connection:) | deregister: deregisterDevice(smsn:) | . | Introduce RegistrationDetail enum with alreadyRegistered and registrationSucceeded that comes with the result of the new register APIs. | Introduce uploadDeviceMetrics in SidewalkConnection to support collecting device metrics and upload to Amazon Sidewalk cloud. | . Bug Fixes . | Fix memory deallocation issue in bluetooth connection. | Minor bug fixes in deregistration for legacy devices. | . | View | Download | . | 1.1.0 | March 24, 2023 | Amazon Sidewalk Mobile iOS SDK 1.1.0 is released. Amazon Sidewalk Mobile iOS SDK provides a one-stop solution for everything related to Amazon Sidewalk on iOS mobiles. The initial release contains APIs including: . | scan(), secureConnect(), register(), deregister(), and clearAccountCache() in Sidewalk to interact with end devices. | subscribe(), write(), startCoverageTest(), isAvailable, and disconnect() in SidewalkConnection to perform operations in a connection with an Amazon Sidewalk device. | getToken() in SidewalkAuthProviding to provide LWA token to Amazon Sidewalk Mobile SDK for communication with the Amazon Sidewalk cloud. | log() in SidewalkLogging to receive logs from Amazon Sidewalk Mobile SDK. | . | View | Download | . ", "url": "/mobile-sdk/sidewalk-mobile-sdk-release-notes.html#amazon-sidewalk-mobile-ios-sdk-release-notes", "relUrl": "/mobile-sdk/sidewalk-mobile-sdk-release-notes.html#amazon-sidewalk-mobile-ios-sdk-release-notes" },"831": { "doc": "Amazon Sidewalk Mobile SDK Release Notes", "title": "Known Issues in Dependencies", "content": ". | Amazon Sidewalk MCU SDK 1.17 and above . | Starting with the 1.17 release, the SidewalkConnection.uploadDeviceMetrics() is no longer supported. | . | Amazon Sidewalk MCU SDK 1.16 and above . | Starting with the 1.16 release, the endpoint device beacon that is presented after registration may change again shortly (within 0.2 seconds). To avoid connection failures, please add a delay after registration before performing subsequent actions, allowing the beacon sufficient time to process. | . | Amazon Sidewalk MCU SDK 1.16 and 1.18 . | When running SidewalkConnection.startCoverageTest() with an Amazon Sidewalk endpoint device utilizing Amazon Sidewalk MCU SDK 1.16 or 1.18 in an environment lacking Amazon Sidewalk coverage, the Amazon Sidewalk Mobile SDK will promptly throw a SidewalkError.DeviceError. In contrast, initiating SidewalkConnection.startCoverageTest() with an Amazon Sidewalk endpoint device using Amazon Sidewalk MCU SDK 1.14 or 1.17 is feasible irrespective of the Amazon Sidewalk coverage status in the environment. | . | . ", "url": "/mobile-sdk/sidewalk-mobile-sdk-release-notes.html#known-issues-in-dependencies", "relUrl": "/mobile-sdk/sidewalk-mobile-sdk-release-notes.html#known-issues-in-dependencies" },"832": { "doc": "Amazon Sidewalk Mobile SDK Release Notes", "title": "Amazon Sidewalk Mobile SDK Release Notes", "content": " ", "url": "/mobile-sdk/sidewalk-mobile-sdk-release-notes.html", "relUrl": "/mobile-sdk/sidewalk-mobile-sdk-release-notes.html" },"833": { "doc": "Amazon Sidewalk Mobile SDK Sample App", "title": "Amazon Sidewalk Mobile SDK Sample App", "content": "Amazon Sidewalk Mobile SDK Sample App demonstrates how to integrate Amazon Sidewalk Mobile SDK into your app with basic API call flows. To try out the Amazon Sidewalk Mobile SDK functionalities and to run the sample app, follow the step by step guide given in the link below. | Run the Android sample app | Run the iOS sample app | . ", "url": "/mobile-sdk/sidewalk-mobile-sdk-sample-app.html", "relUrl": "/mobile-sdk/sidewalk-mobile-sdk-sample-app.html" },"834": { "doc": "Setting up a Sidewalk gateway (Optional)", "title": "Setting up a Sidewalk gateway (Optional)", "content": "You can set up a Sidewalk gateway, configure it, and associate your gateway with your Amazon account. Your Sidewalk endpoint will connect to and communicate with the Sidewalk gateway after it’s registered with Amazon Sidewalk. The following steps show you the prerequisites for setting up and how to enable your Echo device as a Sidewalk gateway. ", "url": "/getting-started/sidewalk-onboard-prereq-gateway.html", "relUrl": "/getting-started/sidewalk-onboard-prereq-gateway.html" },"835": { "doc": "Setting up a Sidewalk gateway (Optional)", "title": "Prerequisites", "content": "Before setting up your Sidewalk gateway: . | Make sure that your gateway is opted in to Sidewalk. | Configure your Sidewalk gateway and associate it with your Amazon account. | . ", "url": "/getting-started/sidewalk-onboard-prereq-gateway.html#prerequisites", "relUrl": "/getting-started/sidewalk-onboard-prereq-gateway.html#prerequisites" },"836": { "doc": "Setting up a Sidewalk gateway (Optional)", "title": "Enabling Echo device as Sidewalk gateway", "content": "For example, you can use an Echo device as a Sidewalk gateway and configure it using the Alexa App on your Android or iOS device. You download the app on your device and then follow the instructions in your mobile app. To perform this set up, you must have an Amazon account and your Echo device must be plugged in. The following instructions show you how to configure the latest generation Echo device as a Sidewalk gateway. It also shows you how to configure Sidewalk on an existing Echo device or add a new device and then configure Amazon Sidewalk on that device. For a list of available gateways, see the Amazon Sidewalk website. Topics . | Enabling a new Echo device as a Sidewalk gateway | Enabling Amazon Sidewalk on an existing Echo device | . Enabling a new Echo device as a Sidewalk gateway . If you are setting up a new Echo device, go through the Out Of Box Experience (OOBE) to set up the device in the Amazon Alexa Mobile Application. | Download and open the Alexa app on your Android or iOS device. | Choose More and then choose Add a device. | Choose Amazon Echo and then choose Echo. | Plug in your Echo device and follow the instructions in the app to set up the device. | Choose Enable in the page that provides more information on Sidewalk while setting up your device. | . Enabling Amazon Sidewalk on an existing Echo device . Before you enable Amazon Sidewalk on an existing device, first check your device settings to determine whether your device can act as a Sidewalk gateway. To enable Amazon Sidewalk on the device: . | Open the Alexa app on your Android or iOS device. | Choose More and then choose Settings. | Choose Account Settings. | Choose Amazon Sidewalk and then choose Enable. | . ", "url": "/getting-started/sidewalk-onboard-prereq-gateway.html#enabling-echo-device-as-sidewalk-gateway", "relUrl": "/getting-started/sidewalk-onboard-prereq-gateway.html#enabling-echo-device-as-sidewalk-gateway" },"837": { "doc": "Setting up a Sidewalk gateway (Optional)", "title": "Customize Sidewalk preferences", "content": "If you own an eligible Amazon Echo device, you can update your Amazon Sidewalk preferences from the Control Center in the Alexa app or website. You can update your Amazon Sidewalk preferences from: . | The Account Settings in your Alexa app. | The Preferences section under the Manage Your Content and Devices tab in the Amazon website. | . ", "url": "/getting-started/sidewalk-onboard-prereq-gateway.html#customize-sidewalk-preferences", "relUrl": "/getting-started/sidewalk-onboard-prereq-gateway.html#customize-sidewalk-preferences" },"838": { "doc": "Setting up the hardware development kit", "title": "Setting up the hardware development kit (HDK)", "content": "To easily prototype your Sidewalk-enabled device, first order a hardware development kit (HDK) from the vendor’s website. You can use an HDK from Nordic Semiconductor, Silicon Laboratories, or Texas Instruments. The following shows the supported HDKs for each vendor. To learn how to use the HDK and install the required tools and libraries, see the vendor documentation. We recommend that you follow the chipset vendor documentation to install the software development tools that are required for programming the device. The vendor tools packaging and instructions can change often. For HDK questions and support, contact the HDK vendor. The following shows how to set up the software and hardware development tools for your HDK. Topics . | Nordic Semiconductor | Silicon Laboratories | Texas Instruments | . ", "url": "/getting-started/sidewalk-onboard-prereq-hdk.html#setting-up-the-hardware-development-kit-hdk", "relUrl": "/getting-started/sidewalk-onboard-prereq-hdk.html#setting-up-the-hardware-development-kit-hdk" },"839": { "doc": "Setting up the hardware development kit", "title": "Nordic Semiconductor", "content": "To prototype your application, follow the instructions from your chipset vendor to set up your development environment and create an Amazon Sidewalk prototype using their development tool kit. Development resources Set up and familiarize with the vendor’s development environment and tools. Hardware development To start developing Amazon Sidewalk-enabled devices, order the hardware development kit from Nordic Semiconductor. You can start with the Nordic nRF52840 DK development kit and the Semtech SX1262MB2CAS evaluation board. Software Development Download the software and required tools and applications, as described in the pre-requisites section. If you require any additional software dependencies to start building your application, access Development Resources to download them. | Login or register on the Nordic Semiconductor website, and access and download the Amazon Sidewalk SDK from the chipset vendor’s development resource. | Download the tools that are required for programming the device. | . For more information, see the Nordic Semiconductor documentation. ", "url": "/getting-started/sidewalk-onboard-prereq-hdk.html#nordic-semiconductor", "relUrl": "/getting-started/sidewalk-onboard-prereq-hdk.html#nordic-semiconductor" },"840": { "doc": "Setting up the hardware development kit", "title": "Silicon Laboratories", "content": "To prototype your application, follow the instructions from your chipset vendor to set up development environment and create an Amazon Sidewalk prototype using their development toolkit. Development resources Set up and familiarize with the vendor’s development environment and tools. For more information, see Amazon Sidewalk development tool kit. Hardware development To start developing Amazon Sidewalk-enabled devices, order the hardware development kit from Silicon Laboratories. You can start with the Silabs Pro Kit For Sidewalk development kit . Software Development Download the software and required tools and applications, as described in the pre-requisites section. If you require any additional software dependencies to start building your application, access Development Resources to download them. | To download all board and protocol support SDKs for Amazon Sidewalk, download Simplicity Studio version 5 and login to the IDE. | To program all the EFR parts, download the Simplicity Commander tool, and then go to the Tools pane of the Simplicity Studio IDE after downloading it. | . For more information, see the Silicon Laboratories documentation. ", "url": "/getting-started/sidewalk-onboard-prereq-hdk.html#silicon-laboratories", "relUrl": "/getting-started/sidewalk-onboard-prereq-hdk.html#silicon-laboratories" },"841": { "doc": "Setting up the hardware development kit", "title": "Texas Instruments", "content": "To prototype your application, follow the instructions from your chipset vendor to set up the development environment and create an Amazon Sidewalk prototype using their development toolkit. Development resources Set up and familiarize with the vendor’s development environment and tools. For more information, see Amazon Sidewalk development toolkit. Hardware development To start developing Amazon Sidewalk-enabled devices, order the hardware development kit from Texas Instruments. You can start with the LP-CC1352P7 LaunchPad development kit for SimpleLink multi-band wireless MCU development kit. Software Development Download the software and required tools and applications, as described in the pre-requisites section. If you require any additional software dependencies to start building your application, access Development Resources to download them. | Go to the Texas Instruments website and choose Login/Register, to access and download the Amazon Sidewalk SDK from the chipset vendor’s development resource. | Download the UniFlash tool that’s required for programming the device. | . For more information, see the Texas Instruments documentation. ", "url": "/getting-started/sidewalk-onboard-prereq-hdk.html#texas-instruments", "relUrl": "/getting-started/sidewalk-onboard-prereq-hdk.html#texas-instruments" },"842": { "doc": "Setting up the hardware development kit", "title": "Setting up the hardware development kit", "content": " ", "url": "/getting-started/sidewalk-onboard-prereq-hdk.html", "relUrl": "/getting-started/sidewalk-onboard-prereq-hdk.html" },"843": { "doc": "Amazon Sidewalk Program Requirements", "title": "Amazon Sidewalk Program Requirements", "content": "These program requirements are part of the Policies governing your use of AWS IoT Core for Amazon Sidewalk and/or participation in the On Amazon Sidewalk qualification program. Capitalized terms used, but not defined, in these Amazon Sidewalk Program Requirements have the meanings given in the AWS Customer Agreement or the AWS Service Terms, as applicable. | Your Amazon Sidewalk Devices and your use of Amazon Sidewalk must comply with the Amazon Sidewalk technical requirements published on the Amazon Sidewalk Documentation. | Your Amazon Sidewalk Devices must, at minimum, comply with the Amazon Sidewalk Program Security Requirements. You are responsible for implementing any additional security requirements applicable to your Amazon Sidewalk Devices. | You will not market Amazon Sidewalk in conjunction with your AS Devices in a geographic territory where we have not made Amazon Sidewalk available. | You will not charge any additional fees to any End User for access to or use of Amazon Sidewalk (e.g., extra subscription fees for Amazon Sidewalk access capability in your AS Devices or accompanying applications or services) or any portion thereof, beyond what you charge for your AS Devices. | You will not misrepresent your identity or the origin of your Amazon Sidewalk Devices. | You will comply with any Amazon Sidewalk usage limits and will not mask your usage of Amazon Sidewalk. | You will not provide your account credentials to any third party. | You will display or otherwise provide to End Users, and not otherwise remove, modify or obscure, any attributions, copyright information and other notices, terms and conditions that we may provide to you or that you may be required to provide to End Users including for purposes of collecting and storing End User data or based on your use of third party “open source” software or other third party intellectual property in any of your Amazon Sidewalk Devices. | . ", "url": "/sidewalk-terms-and-agreements/sidewalk-program-requirements.html", "relUrl": "/sidewalk-terms-and-agreements/sidewalk-program-requirements.html" },"844": { "doc": "Step 2: Provisioning with CSR and Sidewalk Signing tool", "title": "Provisioning with CSR and Sidewalk Signing tool", "content": "Each device being manufactured needs to have a unique device certificate. The Sidewalk Signing Tool running on the Line PC will take CSR from the device to generate a Sidewalk certificate and signs it using the Device Attestation Key (DAK) securely stored in the provided Hardware Security Module (HSM). The following steps are involved in provisioning for the manufacturing workflow. Topics . | Step 1: Generate CSRs for Sidewalk signing tool | Step 2: Run the YubiHSM connector in the background | Step 3: Run the Sidewalk signing tool | Step 4: Store the Sidewalk Certificate Chains to the device | . ", "url": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html#provisioning-with-csr-and-sidewalk-signing-tool", "relUrl": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html#provisioning-with-csr-and-sidewalk-signing-tool" },"845": { "doc": "Step 2: Provisioning with CSR and Sidewalk Signing tool", "title": "Step 1: Generate CSRs for Sidewalk signing tool", "content": "Before the Sidewalk signing tool can sign the certificates, a CSR must be generated for each device being manufactured. A device ready to be provisioned is flashed with a special Factory Diagnostic Firmware, which is responsible for the generation of SMSN and device key pairs of that device (and therefore the CSR). A script running on the line PC communicates with the device via a CLI provided by the Factory Diagnostic Firmware. The CSR is passed as an input to the Sidewalk signing tool, and a signed certificate chain is the output. Here is an example of using Factory Diagnostic Firmware to trigger the process of CSR generation. See the documentation release by Sidewalk silicon partners for more details. | Initialize the certificate generation flow and generate SMSN . --> cert init [00595258] <info> app: {CERT BASE64_MTU=32} [00595258] <info> app: {CERT OK} --> cert smsn \"A17XHX23H06INH\" \"SN1234567\" \"pd25\" [00595323] <info> app: {CERT <dwhuv44g0HQYDxoB//JWaI3uaLqpkMNh>} [00595323] <info> app: {CERT <AHDmbIb2/zk=>} [00595323] <info> app: {CERT OK} . The command cert smsn asks the device to generate the SMSN using DeviceTypeId (vended by Amazon Sidewalk team along with the HSM), DSN (Device Serial Number, the unique serial number of the device), and APID. The generated SMSN is then returned in base64-encoded string. As the example shows it is separated into 2 pieces as it’s longer than 32 bytes, and therefore the actual SMSN (encoded in base64) is dwhuv44g0HQYDxoB//JWaI3uaLqpkMNhAHDmbIb2/zk= in this case. | Generate CSR for Ed25519 and P256R1 . --> cert csr \"ed25519\" [00595427] <info> app: {CERT <jfmuHcN1VgVddvWiIFkFdmNaGHgPBKWA>} [00595427] <info> app: {CERT <tlObPtl/n393CG6/jiDQdBgPGgH/8lZo>} [00595427] <info> app: {CERT <je5ouqmQw2EAcOZshvb/OcEGVZ938Jhi>} [00595427] <info> app: {CERT <rSeJq1LAtt6dY6lUWmQ9uvWOfJXQzrfD>} [00595427] <info> app: {CERT <79p9aRTDLxWYd2/Q82b0b9EfUog6jKRF>} [00595428] <info> app: {CERT <omXm0016ngc=>} [00595428] <info> app: {CERT OK} --> --> cert csr \"p256r1\" [00595579] <info> app: {CERT <0W996GnBnJ60Ih6F/xh+WYuxEgzPRnw8>} [00595579] <info> app: {CERT <6CNuD6r+mVX0Zfyl0o98zV/ztfiiSfm/>} [00595579] <info> app: {CERT <DVzXefuvI/DeALsRvnJSlHcIbr+OINB0>} [00595579] <info> app: {CERT <GA8aAf/yVmiN7mi6qZDDYQBw5myG9v85>} [00595579] <info> app: {CERT <aoSJ/V0l5voCEySRFNOadBXxqLnIhD3p>} [00595579] <info> app: {CERT <apQfpxumHpB5hbnvSQG1wxUT5LpDtkO9>} [00595580] <info> app: {CERT <dPnH621qufUR+VIT62un2A==>} [00595580] <info> app: {CERT OK} --> . Commands cert csr \"ed25519\" and cert csr \"p256r1\" make the device generate the key pairs and print out the CSRs for Sidewalk Signing Tools to sign. Again they are separated in chunks of 32 bytes so needed to be concatenated before passing to Sidewalk Signing Tools. | . ", "url": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html#step-1-generate-csrs-for-sidewalk-signing-tool", "relUrl": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html#step-1-generate-csrs-for-sidewalk-signing-tool" },"846": { "doc": "Step 2: Provisioning with CSR and Sidewalk Signing tool", "title": "Step 2: Run the YubiHSM connector in the background", "content": "If you’re using a Windows machine, the YubiHSM connector runs automatically as a service in the background. You don’t have to manually start the connector. On the machine that the HSM is attached to, run the YubiHSM connector in the background. If you’re using the networked setup, the HSM is on the signing server. If you’re using the local setup, run the connector on the line PC. For more information, see Step 1: Choose mode of setup. On an Ubuntu machine, you run the connector using the yubihsm-connector command without any outputs. # yubihsm-connector is running without any outputs here. yubihsm-connector . ", "url": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html#step-2-run-the-yubihsm-connector-in-the-background", "relUrl": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html#step-2-run-the-yubihsm-connector-in-the-background" },"847": { "doc": "Step 2: Provisioning with CSR and Sidewalk Signing tool", "title": "Step 3: Run the Sidewalk signing tool", "content": "The following shows the parameters that the Sidewalk signing tool can accept, some usage examples, and the output of running the tool. Sidewalk signing tool parameters . The following table shows the parameters that the Sidewalk signing tool can accept and their description. For more information about the signing tool parameters, run the following command. sidewalk-signing-tool --help . Signing tool parameters . | Parameter | Description | . | --product | The product tag identifying which DAK in HSM is used for the signing operation. This tag will be provided by Amazon for some specific product and usually starts with prefix ‘PREPROD_DAK’ or ‘RNET_DAK’. | . | --pin | The PIN code to access the HSM. Provided by Amazon along with the product tag. | . | --eddsa_csr and --ecdsa_csr | The base64-encoded CSRs generated from the device containing SMSN and public keys to sign. | . | --device_profile_json (AWS Flow only) | The JSON file downloaded from AWS for the device profile, from which the Sidewalk Signing Tool get the app server key and put it to the output file so provision.py can take use of it. This is only for AWS flow; The main reason of having this input is to pass the application server public key from the device profile to provision.py. In ACS flow the public key will be provided explicitly with the command line argument of provision.py. | . | -o | The filename of the output from the Sidewalk Signing Tool, which contains the device certificate and Sidewalk certificate chains that will be used as input of provision.py | . | --connector | The URL for the singing server, including the information for protocol (http or https), IP\\/domain name, and the port number. If you are using local installation, it should be the URL to the local yubihsm-connector, which is normally “http://localhost:12345” | . | --ca_cert, --client_cert and --client_key | These 3 arguments are mandatory for establishing HTTPS channel with the signing server. | . General usage example . The following command shows an example of how you run the tool. In this example: . | The arguments ca_cert, client_cert, and client_key are only required when you use the networked installation since it requires authentication between the line PCs and the signing server. | . # Usage Example python3 sidewalk_signing_tool.py --product=<model label> --pin=<hsm pin> \\ --eddsa_csr and=<ED25519_CSR> --ecdsa_csr=<P256R1_CSR> \\ --connector=<connector url> \\ -o out.json [--ca_cert=<CA for signing server> --client_cert=<client certificate> --client_key=<client key>] . Local installation example . The following command shows an example of how you run the tool when using local installation. In this example, the tool runs on the line PC. # Example for local installation: python3 sidewalk_signing_tool.py --product=RNET_DAK_PROJNAME --pin=password \\ --eddsa_csr=fmuHcN1VgVddvWiIFkFdmNaGHgPBKWAtlObPtl/n393CG6/jiDQdBgPGgH/8lZoje5ouqmQw2EAcOZshvb/OcEGVZ938JhirSeJq1LAtt6dY6lUWmQ9uvWOfJXQzrfD79p9aRTDLxWYd2/Q82b0b9EfUog6jKRFomXm0016ngc= —ecdsa_csr=0W996GnBnJ60Ih6F/xh+WYuxEgzPRnw86CNuD6r+mVX0Zfyl0o98zV/ztfiiSfm/DVzXefuvI/DeALsRvnJSlHcIbr+OINB0GA8aAf/yVmiN7mi6qZDDYQBw5myG9v85aoSJ/V0l5voCEySRFNOadBXxqLnIhD3papQfpxumHpB5hbnvSQG1wxUT5LpDtkO9dPnH621qufUR+VIT62un2A== \\ --connector=http://localhost:12345 . Networked installation example . The following command shows an example of how you run the tool when using local installation. In this example, the tool runs on the line PC and the YubiHSM connector runs on the signing server so a secure connection is required between the two machines. # Example for networked installation where the signing server is at 192.168.10.100. # In the signing tool, the ca_cert, client_cert and client_key options # can be used to set the certificate and specify the expected certificate authority. python3 sidewalk_signing_tool.py --product=RNET_DAK_PROJNAME --pin=password \\ --eddsa_csr=fmuHcN1VgVddvWiIFkFdmNaGHgPBKWAtlObPtl/n393CG6/jiDQdBgPGgH/8lZoje5ouqmQw2EAcOZshvb/OcEGVZ938JhirSeJq1LAtt6dY6lUWmQ9uvWOfJXQzrfD79p9aRTDLxWYd2/Q82b0b9EfUog6jKRFomXm0016ngc= —ecdsa_csr=0W996GnBnJ60Ih6F/xh+WYuxEgzPRnw86CNuD6r+mVX0Zfyl0o98zV/ztfiiSfm/DVzXefuvI/DeALsRvnJSlHcIbr+OINB0GA8aAf/yVmiN7mi6qZDDYQBw5myG9v85aoSJ/V0l5voCEySRFNOadBXxqLnIhD3papQfpxumHpB5hbnvSQG1wxUT5LpDtkO9dPnH621qufUR+VIT62un2A== \\ --connector=https://192.168.10.100:8081 \\ --ca_cert ca.pem --client_cert client.pem --client_key client.key . Note that the CSRs for --eddsa_csr and --ecdsa_csr are from the output of cert csr \"ed25519\" and cert csr \"p256r1\", respectively. Sidewalk signing tool output . After you run the signing tool using the commands listed below, if the tool runs successfully, the Sidewalk certificate chains will be returned as output. The following code shows a sample output. { \"eD25519\": \"dwhuv44g0HQYDxoB//JWaI3uaLqpkMNhAHDmbIb2/zmN+a4dw3VWBV129aIgWQV2Y1oYeA8EpYC2U5s+2X+ffxxKHdAQ6EIe3UscoBWpmm3UMDq74A24kk8NwS/QmRD5+Yi7fkjzzuCo9CHXAf5RUNr2j8JliufVwGEaUwR31AqMYAD6jIPnd0yKSGVhjIh2U3MSQEmBPm3FUjqZh60xfY6u+3D4B97a439Ern7lZGCSCxw9jKVci5YUArszxwGGWukX8QI+UbHOkoUPsOGuHROGAmiF29XGV8WMJIC6T0Kwve0GocgAeAe2l9tZeGA8vQDTL1ztUU3qpfG1jznKgr/5j9L6trgP8/hI3MjQQ8yKdappcK0PSvrU6Iq9nAKXqq0C/kGUiBSm/Pb5RECHeRfA/HuVI+FNuOhsvSPr3ayXQd05yg37BKMHAHzFPB+QcnBfGz+do1fRXTjTlohjitVDDCyXnI4xHzKG7BjrNc394XQYS3BFgo5CnQ9u129n2sN4G2eHMQmjSyfs+JwyB+EjjV1pEP4nC9yRCVfTPNcG3AqJBzkD0sxqeg11AAADGz+gFBeX/ZNN8VJwnsNfgzj4me1HgVJdUo4W9kvx9cr2jHWkC3Oj/bdBTh1+yBjOC53yHlQK/l1GHrEWiWPPnE434LRxnWkwr8EHD4oieJxC8fkIxkQfj+gHhU79Z+oAAYAAAzsnf9SDIZPoDXF0TdC9POqTgld0oXDl2XPaVD4CvvLearrOSlFv+lsNbC4rgZn23MtIBM/7YQmJwmQ+FXRup6Tkubg1hpz04J/09dxg8UiZmntHiUr1GfkTOFMYqRB+Aw==\", \"p256R1\": \"dwhuv44g0HQYDxoB//JWaI3uaLqpkMNhAHDmbIb2/znRb33oacGcnrQiHoX/GH5Zi7ESDM9GfDzoI24Pqv6ZVfRl/KXSj3zNX/O1+KJJ+b8NXNd5+68j8N4AuxG+clKUUYYxHxPrn0Nrkjb4zrKnL82uwQ2c+RkGfztCacpsPF/Y67b8j1xKFdp931gelFvxX7Hlb8albMoDO/rqtIqpCItgAPpZ+m3Px2bQIhkMcZttKmC5l68NHIotSSZ97qTZihByryD3JbgqMjgw5rQgJTRfJ1NSOMNHx+gsC8jUd/nKXc9qT80S1/EHBz31oCqkqsUslUzKGzSEQ3lKF9/7vKAoh1WHJUq9GVsMtupA4/jSZ4rjHklaNLP63Oxu3av3ISUnx6DIAHglZhhKZMg94z7EuAdPKhaPaCTRBGQBCKSH36KXKOCmq/QZNgjSuwg+KdA5MnJ3tbTNoPLtyjbWmGjxe8KcwsllD4ck12XzopfG/twfU8zInLCye8vqVYnPizbyKgbTBSjiEjdCssRKHh3CRJvDD/y6MPfjMGyw7EkOcMKdEfD4qKIHAHyGS3vWpe2S+E7VR9JrVkP0bomvmBV/qUKR/OAHXB5KPpk9OoydZ/Rzzgf5+A8USggGpcZ4ayCLbjuhqyc6AsdRTSjzQh7+p/URt9QZkRn7Mu/XVTTNtIVOQcfYdEJ5OUiCXxwgCqvNMifoTmF1tv1cYbiwTIWcyazYt+vbrPOVSHUAAALPsP34BS6EzJO5AsS5pC7QTpjBtAbLN9SdXOT9w4H1x8Nkp0ujLxWRN37IEy0V9DrPK2w1g74uqWPfUPnSBjtvM55JnQpmm23WQNvHa1Vr6zmWDjzjHpcNirPbzXyBlKEhkX4xylaSMnm4UrVXtAMaAJ/csC4HPTKr3dazdvEkhwGAAAIFByCjSp/5WHc4AhsyjMvKCsZQiKgiI8ECwjfXBaSZdY4zYsRlO3FC428H1atrFChFCZT0Bqt5LPXD38bMSB+vAUJiP8XqiEdXeqf2mYMJ5ykoDpwkve/cUQfPpjzFQlQfvwjBwiJDANKkOKoNT3bUGz+/f/pyTE+xMRdIUBZ1Bw==\", \"label\": \"production\", \"metadata\": { \"smsn\": \"77086ebf8e20d074180f1a01fff256688dee68baa990c3610070e66c86f6ff39\", \"apid\": \"pd25\" } } . ", "url": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html#step-3-run-the-sidewalk-signing-tool", "relUrl": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html#step-3-run-the-sidewalk-signing-tool" },"848": { "doc": "Step 2: Provisioning with CSR and Sidewalk Signing tool", "title": "Step 4: Store the Sidewalk Certificate Chains and Application server public key to the device", "content": "Once Sidewalk Signing Tool completes the signing, the Sidewalk Certificate Chains of ED25519 and P256R1 for the device are available in the output, fields “eD25519“ and “p256R1’, respectively. These chains have to be stored in the device for onboarding Sidewalk network. Again, use the CLI of Factory Diagnostic Firmware to deliver them to the device. Here is an example: . | Write ED25519 Sidewalk Certificate Chain . --> cert chain start \"ed25519\" [00596233] <info> app: {CERT OK} --> cert chain write \"dwhuv44g0HQYDxoB//JWaI3uaLqpkMNh\" [00596249] <info> app: {CERT OK} --> cert chain write \"AHDmbIb2/zmN+a4dw3VWBV129aIgWQV2\" [00596268] <info> app: {CERT OK} --> cert chain write \"Y1oYeA8EpYC2U5s+2X+ffxxKHdAQ6EIe\" [00596286] <info> app: {CERT OK} --> cert chain write \"3UscoBWpmm3UMDq74A24kk8NwS/QmRD5\" [00596306] <info> app: {CERT OK} ... --> cert chain write \"AYAAAzsnf9SDIZPoDXF0TdC9POqTgld0\" [00596668] <info> app: {CERT OK} --> cert chain write \"oXDl2XPaVD4CvvLearrOSlFv+lsNbC4r\" [00596691] <info> app: {CERT OK} --> cert chain write \"gZn23MtIBM/7YQmJwmQ+FXRup6Tkubg1\" [00596709] <info> app: {CERT OK} --> cert chain write \"hpz04J/09dxg8UiZmntHiUr1GfkTOFMY\" [00596740] <info> app: {CERT OK} --> cert chain write \"qRB+Aw==\" [00596758] <info> app: {CERT OK} --> cert chain commit [00596775] <info> app: {CERT OK} --> . To pass the certificate chain of ED25519 to the device, you use cert chain start \"ed25519\" followed multiple cert chain write with the certificate chain split into 32-byte pieces. After all data is received by the device, use to cert chain commit to finalize it. | Write P256R1 Sidewalk Certificate Chain . --> cert chain start \"p256r1\" [00596885] <info> app: {CERT OK} --> cert chain write \"dwhuv44g0HQYDxoB//JWaI3uaLqpkMNh\" [00596903] <info> app: {CERT OK} --> cert chain write \"AHDmbIb2/znRb33oacGcnrQiHoX/GH5Z\" [00596924] <info> app: {CERT OK} --> cert chain write \"i7ESDM9GfDzoI24Pqv6ZVfRl/KXSj3zN\" [00596941] <info> app: {CERT OK} --> cert chain write \"X/O1+KJJ+b8NXNd5+68j8N4AuxG+clKU\" [00596959] <info> app: {CERT OK} ... --> cert chain write \"BaSZdY4zYsRlO3FC428H1atrFChFCZT0\" [00597469] <info> app: {CERT OK} --> cert chain write \"Bqt5LPXD38bMSB+vAUJiP8XqiEdXeqf2\" [00597486] <info> app: {CERT OK} --> cert chain write \"mYMJ5ykoDpwkve/cUQfPpjzFQlQfvwjB\" [00597502] <info> app: {CERT OK} --> cert chain write \"wiJDANKkOKoNT3bUGz+/f/pyTE+xMRdI\" [00597518] <info> app: {CERT OK} --> cert chain write \"UBZ1Bw==\" [00597537] <info> app: {CERT OK} --> cert chain commit [00597554] <info> app: {CERT OK} --> . The similar process for P256R1 certificate chain expect starting with cert chain start \"p256r1\" instead of cert chain start \"ed25519\" . | Write Application server public key . --> cert app_key start [00597642] <info> app: {CERT OK} --> cert app_key write \"Qv+5ZIOzMxHWlVv0OQ3gh3/3/PM3t8+J\" [00597663] <info> app: {CERT OK} --> cert app_key write \"QnsNvDLpa5k=\" [00597680] <info> app: {CERT OK} --> cert app_key commit [00597697] <info> app: {CERT OK} . The Application server public key can be obtained from AWS IoT console in the Device Profile page. Also, it needs to be encoded into base64 format. | . ", "url": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html#step-4-store-the-sidewalk-certificate-chains-and--application-server-public-key-to-the-device", "relUrl": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html#step-4-store-the-sidewalk-certificate-chains-and--application-server-public-key-to-the-device" },"849": { "doc": "Step 2: Provisioning with CSR and Sidewalk Signing tool", "title": "Step 5: Store all received data and de-initialize the provisioning engine", "content": "--> cert store [00598327] <info> app: {CERT OK} --> cert deinit [00598428] <info> app: {CERT OK} --> . Command cert store tells the devices to save the Sidewalk certificate chains and Application server public key into the storage of the device and complete the provisioning on the device side. Next Step: Constructing and uploading Sidewalk control logs . ", "url": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html#step-5-store-all-received-data-and-de-initialize-the-provisioning-engine", "relUrl": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html#step-5-store-all-received-data-and-de-initialize-the-provisioning-engine" },"850": { "doc": "Step 2: Provisioning with CSR and Sidewalk Signing tool", "title": "Step 2: Provisioning with CSR and Sidewalk Signing tool", "content": " ", "url": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html", "relUrl": "/manufacturing/manufacture-provision/sidewalk-provision-certprofile.html" },"851": { "doc": "Step 3: Constructing and uploading Sidewalk control logs", "title": "Constructing and uploading Sidewalk control logs", "content": "CM follows these steps to construct the control logs from the output of the Sidewalk signing tool with some additional information. They can consolidate the logs if there are multiple devices, and then upload them to the Amazon Sidewalk system for provisioning your Sidewalk devices. Topics . | Step 1: Construct control logs | Step 2: Consolidate control logs | Step 3: Upload control logs | . ", "url": "/manufacturing/manufacture-provision/sidewalk-provision-controllogs.html#constructing-and-uploading-sidewalk-control-logs", "relUrl": "/manufacturing/manufacture-provision/sidewalk-provision-controllogs.html#constructing-and-uploading-sidewalk-control-logs" },"852": { "doc": "Step 3: Constructing and uploading Sidewalk control logs", "title": "Step 1: Construct control logs", "content": "The signing tool can generate the control logs file using a format that can be ingested into Amazon’s device provisioning system via EDI or SFTP endpoints. To generate the control logs and specify the directory where the logs will be generated, use the parameter --control_log_dir when running the Sidewalk signing tool. For more information and how to run the tool, see Sidewalk signing tool parameters . The signing tool will generate a Sidewalk control log file for the device in the specified directory, with a name C_CONTROL_LOG_<date and time in yyyyMMddhhmmss format>.txt. The control logs generated will use a format that complies with the version 4-0-1 and contains the required device information to be uploaded to Amazon Sidewalk, such as the SMSN, APID, and the Sidewalk certificate chains. In this code, the serialNumber and the certificate chains sidewalkED25519CertificateChain and sidewalkP256R1CertificateChain are obtained by running the Sidewalk signing tool. You obtain the APID when creating a Sidewalk profile. { \"controlLogs\": [ { \"version\": \"4-0-1\", \"device\": { \"serialNumber\": \"77086ebf8e20d074180f1a01fff256688dee68baa990c3610070e66c86f6ff39\", \"productIdentifier\": { \"advertisedProductId\": \"pd25\" }, \"sidewalkData\": { \"sidewalkED25519CertificateChain\": \"dwhuv44g0HQYDxoB//JWaI3uaLqpkMNhAHDmbIb2/zmN+a4dw3VWBV129aIgWQV2Y1oYeA8EpYC2U5s+2X+ffxxKHdAQ6EIe3UscoBWpmm3UMDq74A24kk8NwS/QmRD5+Yi7fkjzzuCo9CHXAf5RUNr2j8JliufVwGEaUwR31AqMYAD6jIPnd0yKSGVhjIh2U3MSQEmBPm3FUjqZh60xfY6u+3D4B97a439Ern7lZGCSCxw9jKVci5YUArszxwGGWukX8QI+UbHOkoUPsOGuHROGAmiF29XGV8WMJIC6T0Kwve0GocgAeAe2l9tZeGA8vQDTL1ztUU3qpfG1jznKgr/5j9L6trgP8/hI3MjQQ8yKdappcK0PSvrU6Iq9nAKXqq0C/kGUiBSm/Pb5RECHeRfA/HuVI+FNuOhsvSPr3ayXQd05yg37BKMHAHzFPB+QcnBfGz+do1fRXTjTlohjitVDDCyXnI4xHzKG7BjrNc394XQYS3BFgo5CnQ9u129n2sN4G2eHMQmjSyfs+JwyB+EjjV1pEP4nC9yRCVfTPNcG3AqJBzkD0sxqeg11AAADGz+gFBeX/ZNN8VJwnsNfgzj4me1HgVJdUo4W9kvx9cr2jHWkC3Oj/bdBTh1+yBjOC53yHlQK/l1GHrEWiWPPnE434LRxnWkwr8EHD4oieJxC8fkIxkQfj+gHhU79Z+oAAYAAAzsnf9SDIZPoDXF0TdC9POqTgld0oXDl2XPaVD4CvvLearrOSlFv+lsNbC4rgZn23MtIBM/7YQmJwmQ+FXRup6Tkubg1hpz04J/09dxg8UiZmntHiUr1GfkTOFMYqRB+Aw==\", \"sidewalkP256R1CertificateChain\": \"dwhuv44g0HQYDxoB//JWaI3uaLqpkMNhAHDmbIb2/znRb33oacGcnrQiHoX/GH5Zi7ESDM9GfDzoI24Pqv6ZVfRl/KXSj3zNX/O1+KJJ+b8NXNd5+68j8N4AuxG+clKUUYYxHxPrn0Nrkjb4zrKnL82uwQ2c+RkGfztCacpsPF/Y67b8j1xKFdp931gelFvxX7Hlb8albMoDO/rqtIqpCItgAPpZ+m3Px2bQIhkMcZttKmC5l68NHIotSSZ97qTZihByryD3JbgqMjgw5rQgJTRfJ1NSOMNHx+gsC8jUd/nKXc9qT80S1/EHBz31oCqkqsUslUzKGzSEQ3lKF9/7vKAoh1WHJUq9GVsMtupA4/jSZ4rjHklaNLP63Oxu3av3ISUnx6DIAHglZhhKZMg94z7EuAdPKhaPaCTRBGQBCKSH36KXKOCmq/QZNgjSuwg+KdA5MnJ3tbTNoPLtyjbWmGjxe8KcwsllD4ck12XzopfG/twfU8zInLCye8vqVYnPizbyKgbTBSjiEjdCssRKHh3CRJvDD/y6MPfjMGyw7EkOcMKdEfD4qKIHAHyGS3vWpe2S+E7VR9JrVkP0bomvmBV/qUKR/OAHXB5KPpk9OoydZ/Rzzgf5+A8USggGpcZ4ayCLbjuhqyc6AsdRTSjzQh7+p/URt9QZkRn7Mu/XVTTNtIVOQcfYdEJ5OUiCXxwgCqvNMifoTmF1tv1cYbiwTIWcyazYt+vbrPOVSHUAAALPsP34BS6EzJO5AsS5pC7QTpjBtAbLN9SdXOT9w4H1x8Nkp0ujLxWRN37IEy0V9DrPK2w1g74uqWPfUPnSBjtvM55JnQpmm23WQNvHa1Vr6zmWDjzjHpcNirPbzXyBlKEhkX4xylaSMnm4UrVXtAMaAJ/csC4HPTKr3dazdvEkhwGAAAIFByCjSp/5WHc4AhsyjMvKCsZQiKgiI8ECwjfXBaSZdY4zYsRlO3FC428H1atrFChFCZT0Bqt5LPXD38bMSB+vAUJiP8XqiEdXeqf2mYMJ5ykoDpwkve/cUQfPpjzFQlQfvwjBwiJDANKkOKoNT3bUGz+/f/pyTE+xMRdIUBZ1Bw==\", \"label\": \"production\" } } } ] } . ", "url": "/manufacturing/manufacture-provision/sidewalk-provision-controllogs.html#step-1-construct-control-logs", "relUrl": "/manufacturing/manufacture-provision/sidewalk-provision-controllogs.html#step-1-construct-control-logs" },"853": { "doc": "Step 3: Constructing and uploading Sidewalk control logs", "title": "Step 2: Consolidate control logs", "content": "The control log file generated by the Sidewalk signing tool contains the control log information only for a single Sidewalk device as the certificates are signed only for a single device at a time. If you have multiple Sidewalk devices, their control logs can be consolidated into a single control log file for control log ingestion. To consolidate the control logs, use the tool consolidate_cl.py provided by the Sidewalk signing tool. For example, the following command shows how to run this tool. You can move all the control logs to be consolidated into a single directory and then run the tool from that directory. python3 consolidate_cl.py /tmp/cl/C_CONTROL_LOG_*.txt . In this example, the command reads all control log files that are in the /tmp/cl directory. After the tool runs successfully, it generates a new control log file, for example C_CONTROL_LOG_20221021155511.txt, that will contain the control log content of its inputs in the directory. Processing /tmp/cl/C_CONTROL_LOG_20221018122452.txt Processing /tmp/cl/C_CONTROL_LOG_20221018141057.txt Processing /tmp/cl/C_CONTROL_LOG_20221018141105.txt Processing /tmp/cl/C_CONTROL_LOG_20221018141106.txt Processing /tmp/cl/C_CONTROL_LOG_20221018141108.txt Processing /tmp/cl/C_CONTROL_LOG_20221018141109.txt Processing /tmp/cl/C_CONTROL_LOG_20221018141110.txt ... C_CONTROL_LOG_20221021155511.txt . The consolidated control log file will contain the required information for multiple devices. The following code shows a sample control log file. { \"controlLogs\" : [ { \"version\" : \"4-0-1\", \"device\" : { \"serialNumber\": \"device1SN\", \"productIdentifier\": { \"advertisedProductId\": \"abCD\" }, \"sidewalkData\": { \"sidewalkED25519CertificateChain\": \"ZfZFVIghs+3EJrr...qRB+Aw==\", \"sidewalkP256R1CertificateChain\": \"ZfZFVIghs+3EJrr...BZ1Bw==\", \"label\": \"PRODUCTION / PREPRODUCTION\" } } }, { \"version\" : \"4-0-1\", \"device\" : { \"serialNumber\": \"device2SN\", \"productIdentifier\": { \"advertisedProductId\": \"abCD\" }, \"sidewalkData\": { \"sidewalkED25519CertificateChain\": \"3OJknQsyH949Ism...qRB+Aw==\", \"sidewalkP256R1CertificateChain\": \"3OJknQsyH949Ism...BZ1Bw==\", \"label\": \"PRODUCTION / PREPRODUCTION\" } } } ] } . ", "url": "/manufacturing/manufacture-provision/sidewalk-provision-controllogs.html#step-2-consolidate-control-logs", "relUrl": "/manufacturing/manufacture-provision/sidewalk-provision-controllogs.html#step-2-consolidate-control-logs" },"854": { "doc": "Step 3: Constructing and uploading Sidewalk control logs", "title": "Step 3: Upload control logs", "content": "After you’ve provisioned your Sidewalk device, you must upload the control logs file to Amazon Sidewalk that includes information about the provisioned device. This information includes the device identifier, APID, SMSN, and Sidewalk certificate chain. To upload your control logs, use either of the following approaches: . Topics . | Upload control logs using EDI | Upload control logs using SFTP endpoint | Getting feedback for the uploaded control log file via SFTP | Troubleshooting control log upload errors | Next steps | . Upload control logs using EDI . After a contract manufacturer (CM) has been issued a YubiHSM key, the CM must set up the factory line to provision devices using the Sidewalk certificates. For your Sidewalk devices to connect to the cloud and use other AWS services, the control logs must be uploaded to Amazon. For information about uploading the control logs using Amazon’s electronic data interchange (EDI) system, contact Amazon Sidewalk support. Upload control logs using SFTP endpoint . To upload the control logs using an SFTP endpoint, perform the following steps. | Sign in to your developer account and go to the Frustration-Free Setup (FFS) developer console. | Go to the Control Logs section of the FFS developer console and choose Manage Control Logs. | Enter information about the business you want to onboard, which includes the Company Name, Contact name, Group Email, and Contact phone. Choose Onboard. | Generate a secure RSA key and upload the public key on the portal. | To generate the RSA key, run the following command. ssh-keygen -t rsa -b 2048 -m PEM . | Enter the file name “control_log_key” in which to save the key and the passphrase when prompted. Running this command generates two files control_log_key and control_log_key.pub. | Upload the public key control_log_key.pub on the portal by choosing Choose file and then choose Create. A pair of SFTP endpoints will be generated for sending the control logs and for receiving feedback. | . | . The Upload endpoint is for sending control log to Amazon, and the Feedback endpoint is for receiving responses from Amazon about the uploaded control log. | Choose the control log file that you want to upload. This example uses the control log file that was created in Step 2: Consolidate control logs. | . { \"controlLogs\": [ { \"version\": \"4-0-1\", \"device\": { \"serialNumber\": \"418A07E3811B8CED614BD27BD2445FAE50A7376A3EB9993CA2017F497A87A68F\", \"productIdentifier\": { \"advertisedProductId\": \"vLpm\" }, \"sidewalkData\": { \"sidewalkP256R1CertificateChain\": \"QYoH44EbjO1hS9J70kRfrlCnN2o+uZk8ogF/SXqHpo+brYZmMkXBv4uRdqlI76h2lDlwFRPtDaKCNx4wnbtLxPy50i1v7R/HKlftXYYqHd5F031Ul60gCiUBFilD+bGz5bAEuktyV+IiO37OMwj4ctUmMI9qL+3YqrPWbt8re0OPihdvppJG1pRwn/uoEJy7jHKmyncRzUP3vN/TE1pNiQEOAPq8LXwuG1NtZ73FcCVFL2BGLV+aBWwX5QW768cujyO2LjP3dEc0QmOiESr4IpoZ8hzeOgXdRU5khPpOxyD4z60/96exsJUmbByDi3jSg1rpOO+sp0jiTemYs1xzSRyXJ1omEv4R0GiTZ6Np1wB7P+PgtFeHtXosMKBPtQvBXzoiOADXAHgCh5Bb/CJT2V3tUA2Sc4swmGggv2KHa/44s4hHtYURlomTw4DTS9WhHjG2Bx2O5jpDuXnzgP2ogf46KwA3o8bczrhzh+kAOgJ7Qu2VY9uupDkvQF63zPDwRiEObHe+hSdDYPccf+ZVJiXOv1Xdd0H2g/efg7hZnxlCKib8//mR1wDPAHyVtZg7AK5NSfOcL6JTw58K0LyK4n8FmpQuRkkqLBRpjbP0sf4Yr26FQxYcjDPnEG4bDw9oMJw0vmRNv8Zc0f5WQxPoqrq/7tQM2UnCF7IFd2pqsCH/QgCM9tD5NgOakB5NUKmxBkkiv8G9n4gZCLRsFS47GAbAfubjcGHgJmBQtnUAAALPsP34BS6EzJO5AsS5pC7QTpjBtAbLN9SdXOT9w4H1x8Nkp0ujLxWRN37IEy0V9DrPK2w1g74uqWPfUPnSBjtvM55JnQpmm23WQNvHa1Vr6zmWDjzjHpcNirPbzXyBlKEhkX4xylaSMnm4UrVXtAMaAJ/csC4HPTKr3dazdvEkhwGAAAIFByCjSp/5WHc4AhsyjMvKCsZQiKgiI8ECwjfXBaSZdY4zYsRlO3FC428H1atrFChFCZT0Bqt5LPXD38bMSB+vAUJiP8XqiEdXeqf2mYMJ5ykoDpwkve/cUQfPpjzFQlQfvwjBwiJDANKkOKoNT3bUGz+/f/pyTE+xMRdIUBZ1Bw==\", \"sidewalkED25519CertificateChain\": \"QYoH44EbjO1hS9J70kRfrlCnN2o+uZk8ogF/SXqHpo+vSnWG/O1S3JGmJI05w5WzKzoc2qsxIoWXOYnD+O4nfSrWb5tPENmKqXrvEVCwb3ctGyAdh7l7IqB+5MJFYNuoHBGM7E5vas/bdB9K8wc5PJmM981pSzSAdD7Gxwh0QAMBDQD6ztjDszbA7PExBCnaTDCxiasDIB+zbDHbXHDLg/BuUwlKyiAHZuVhTcsHhJZ2I+ZriyKiVw94cygt3Ho6Rq3Q2p4vmKJc5+BY6QkiywGDi5GvL1qkaJtRI1HZwt55i9sDANgAeLEEIQOLF30faw/kYhUbbNcEkiVD5LhGgrm7IxWzhyhvQW2jbSvlKddKgFD+B4Ko/aJzmusXOMcMty09XFXVysUEGJngunFMQu5A26SF04J5+SsEkZidAAdzvVjYH24FBADQAHyZnTAM5V/SciHcAlBTsXb5lXKnnTbl+8rxt5KwdsfKdEfyUbpASLiBH53wm+UHJ1+4nrzQ1B0pPeDkY+hapWp7jXRwd4FZFJhQgOMpW/A2RR/m7HMJZCMKgeSeO+c3hgx1AAADGz+gFBeX/ZNN8VJwnsNfgzj4me1HgVJdUo4W9kvx9cr2jHWkC3Oj/bdBTh1+yBjOC53yHlQK/l1GHrEWiWPPnE434LRxnWkwr8EHD4oieJxC8fkIxkQfj+gHhU79Z+oAAYAAAzsnf9SDIZPoDXF0TdC9POqTgld0oXDl2XPaVD4CvvLearrOSlFv+lsNbC4rgZn23MtIBM/7YQmJwmQ+FXRup6Tkubg1hpz04J/09dxg8UiZmntHiUr1GfkTOFMYqRB+Aw==\" } } }, {}, ... ] } . | To upload the control logs, perform the following steps. | First start the SFTP endpoint. sftp --oIdentityFile={path_to_key_file}/control_log_key \\ --oHostKeyAlgorithms=+ssh-dss sftp://{upload_endpoint without :22}/To_Amazon . | Next upload the control log file to the endpoint. # Display local directory listing. sftp> lls # Upload control log file name. sftp> put <control_log_filename> # Exit out of the SFTP connection. sftp> exit . | . It takes few minutes for the control log to be processed and feedback to be received. Once completed, an email will be sent to the email address provided in the onboarding phase in step 3 where you specified the onboarding business information for control logs, or the feedback file can be retrieved by SFTP. | . Getting feedback for the uploaded control log file via SFTP . Feedback must be downloaded and deleted within 30 minutes. Connect via SFTP to the feedback endpoint . sftp --oIdentityFile={path_to_key_file}/control_log_key --oHostKeyAlgorithms=+ssh-dss \\ sftp://{Feedback endpoint without :22}/From_Amazon . Download the feedback file: . # List the files for feedback. sftp> ls # Download control log feedback file. sftp> get {feedback_file_name} # Delete the feedback file sftp> rm {feedback_file_name} # Exit out of the SFTP connection. sftp> exit . Troubleshooting control log upload errors . When you retrieve the feedback file for your uploaded control logs, you may encounter errors for some or all devices in the batch. This section describes common errors and the recommended actions to resolve them. missing_feedback . You may see the following error in the feedback file: . \"Feedback yet to be received from downstream provider\" . This error does not indicate that control log processing has failed. It means that the feedback was not yet available at the time the scheduled poll ran. This typically occurs when a large number of control logs are uploaded simultaneously, which can cause processing delays. To resolve this error, do not re-upload the control log. Instead, poll the feedback endpoint again after a few minutes. The feedback will become available once downstream processing completes. Next steps . Once the control log feedback file in CSV format has been retrieved by email or downloaded from SFTP, you can use AWS IoT Core for Amazon Sidewalk to provision these devices to AWS IoT in bulk. The CSV file summarizes the control log upload status, as shown below. SMSN values from this file will be used to provision the Sidewalk devices in bulk using AWS IoT Core for Amazon Sidewalk. For more information, see Bulk provisioning devices with AWS IoT Core for Amazon Sidewalk in the AWS IoT Core developer guide. You may also wish to consider using the CDK-based bulk management solution here. ", "url": "/manufacturing/manufacture-provision/sidewalk-provision-controllogs.html#step-3-upload-control-logs", "relUrl": "/manufacturing/manufacture-provision/sidewalk-provision-controllogs.html#step-3-upload-control-logs" },"855": { "doc": "Step 3: Constructing and uploading Sidewalk control logs", "title": "Step 3: Constructing and uploading Sidewalk control logs", "content": " ", "url": "/manufacturing/manufacture-provision/sidewalk-provision-controllogs.html", "relUrl": "/manufacturing/manufacture-provision/sidewalk-provision-controllogs.html" },"856": { "doc": "Qualification Concepts", "title": "On Amazon Sidewalk qualification concepts", "content": "The following shows some key concepts of Amazon Sidewalk qualification. Topics . | Types of Sidewalk devices . | End-products | Subsystem | Prototype devices | . | Development keys and platforms | Donor qualification listing | Software updates on end-products | . ", "url": "/qualification/on-amazon-sidewalk/sidewalk-qualification-concepts.html#on-amazon-sidewalk-qualification-concepts", "relUrl": "/qualification/on-amazon-sidewalk/sidewalk-qualification-concepts.html#on-amazon-sidewalk-qualification-concepts" },"857": { "doc": "Qualification Concepts", "title": "Types of Sidewalk devices", "content": "There are three types of Amazon Sidewalk products. End products . An end product is the final product of an On Amazon Sidewalk qualified design. End products may be sold, hired or otherwise transferred to end users. Qualified end products may be used on the Amazon Sidewalk network. End products are Sidewalk Endpoints that connect to Gateways using the Amazon Sidewalk protocol. The end products may be produced by Amazon or other developers. Subsystem . A subsystem implements part of the On Amazon Sidewalk qualification requirements. It doesn’t implement the functionality of a complete Amazon Sidewalk end product. Examples of subsystems include: a system on a chip (SoC), a module, a hardware development kit (HDK), or a software development kit (SDK). Prototype devices . Prototyping is undertaken for experimental or test purposes. A prototype is a device that is used during product development as a preliminary version. Important A prototype is intended for use by a developer, and is not intended for sale, hire, or other transfer to a customer end user. These devices may be produced by Amazon or a third party. The prototype devices don’t have to be Amazon Sidewalk-qualified. However, prototype devices may contain subsystems that are Amazon Sidewalk-qualified. ", "url": "/qualification/on-amazon-sidewalk/sidewalk-qualification-concepts.html#types-of-sidewalk-devices", "relUrl": "/qualification/on-amazon-sidewalk/sidewalk-qualification-concepts.html#types-of-sidewalk-devices" },"858": { "doc": "Qualification Concepts", "title": "Development keys and prototypes", "content": "Amazon may provide Development Keys to enable development of Amazon Sidewalk Endpoints. The keys must be used only for development and debugging purposes. A Development Key is time-limited and grants temporary access to the Amazon Sidewalk network, so it must be used in accordance with all applicable Amazon terms. Amazon reserves the right to revoke Development Keys if their use disrupts operation of the Amazon Sidewalk Network, therefore developers should conduct early stage development in an isolated environment. Amazon expects that Development Keys will only be issued for Development prototypes. A different type of Key is used for end products that are mass-produced. Limitations on development prototypes . Development prototypes may be granted time-limited access to the Amazon Sidewalk network for testing purposes. In most cases, development prototypes will be based on qualified designs and no testing will be required for time-limited access. Amazon reserves the right to require developers to submit a subset of On Amazon Sidewalk qualification test evidence to ensure that development devices do not negatively impact Amazon Sidewalk network capabilities. For example, a completely new platform that’s not based on existing designs may be required to demonstrate correct behavior using a test Gateway. ", "url": "/qualification/on-amazon-sidewalk/sidewalk-qualification-concepts.html#development-keys-and-prototypes", "relUrl": "/qualification/on-amazon-sidewalk/sidewalk-qualification-concepts.html#development-keys-and-prototypes" },"859": { "doc": "Qualification Concepts", "title": "Donor qualification listing", "content": "A donor qualification listing is an Amazon Sidewalk qualification listing that can be used as part of another qualification listing. A donor qualification listing donates functionality to another listing. Examples of donor qualification listings include: . Topics . | A certified partial product integrated into an end product design | An end product reused to provide additional capabilities | A listing that is re-registered for new end product listing | . A certified partial product integrated into an end product design . A certified partial product that implements a subset of the Amazon Sidewalk requirements can act as a donor to be integrated into end products. For example, a Silicon Vendor can produce an Amazon Sidewalk chip or module that can be integrated into an end product. In this case, the module doesn’t implement all the required functionality to be an end product. Tests corresponding to the changed functionality as part of the integration must be added for a certified end product design. An end product reused to provide additional capabilities . A full end product can act as a donor by reusing it in a qualification listing to add extra functionality. In this case, if some tests are unchanged between versions and the functionality to pass those tests is also unchanged in the device, then those tests are not required to be repeated on each new qualification and instead can be inherited from the unchanged parts of the donor qualification listing. A donor qualification listing could also be a complete implementation of a consumer end product that is being reused in a listing to provide additional functionality. For example, an Amazon Sidewalk Endpoint that supports a version of the Amazon Sidewalk specification could act as a donor qualification listing, providing functionality to another Endpoint that supports a newer version of the specification. In this case, if certain tests are unchanged between versions and the functionality to pass the tests is also unchanged, then the tests corresponding to the unchanged parts are not required to be repeated and can be inherited from the donor listing. Certain RF or security tests might still need to be rerun. To determine the tests that must be run, see the test specifications document, or contact the test facility for details on tests that can be inherited. A listing that is re-registered for new end-product listing . A donor qualification listing can be a listing that’s re-registered unchanged because a complete Sidewalk system is reused in a different product. For example, Company A designs a Sidewalk system that can be attached to different switches or sensors. Company B licenses that design to attach to a sensor and qualifies their product. In this case, the Sidewalk functionality is unchanged, and so it wouldn’t require any retesting. To qualify your end-product, you’ll only need to create a new qualification listing with the contact details and information about Company B’s end-product. ", "url": "/qualification/on-amazon-sidewalk/sidewalk-qualification-concepts.html#donor-qualification-listing", "relUrl": "/qualification/on-amazon-sidewalk/sidewalk-qualification-concepts.html#donor-qualification-listing" },"860": { "doc": "Qualification Concepts", "title": "Software updates on end-products", "content": "Endpoint manufacturers are required to have a software maintenance update strategy that specifically defines how updates will be created and distributed. Manufacturers with designs that are based on the Amazon Sidewalk Protocol stack receive security updates, and manufacturers are responsible for integration and distribution of those updates into End-products. For each vulnerability, Amazon provides a time window for updates. The default window is 90 days for critical and high severity vulnerabilities and six months for medium severity updates, as defined by NIST CVSSv2. Updates for low severity vulnerabilities should be prioritized in future updates where feasible and applicable. ‘Manufacturer’ means the company identified in the qualification, not a contract manufacturer. Important Manufacturers shall release security updates for a minimum period of time that is no less than 4 years from the last shipping date of the device. For a device that cannot be upgraded over the air (OTA), manufacturers shall commit to making upgraded hardware available in the event of a critical security update. The upgrade path is defined by the manufacturer, with options including: . | Users purchase replacement hardware | Users are provided with free replacement hardware | Users trade in existing hardware for reconditioned upgraded hardware | Users are provided with an alternative path for upgrading hardware. For example, using a non-Sidewalk secure protocol to upgrade. | . For a device that cannot be upgraded over the air, manufacturers shall make the upgrade period and upgrade mechanism known at the time of purchase. If a manufacturer fails to create and distribute a software maintenance update within the periods defined above, after discovery of a vulnerability, Amazon reserves the right to restrict access to Amazon Sidewalk network services for those end-products. Amazon also reserves the right to deny new products from that manufacturer access to the On Amazon Sidewalk qualification. If a manufacturer has mitigating circumstances that make updates within the default window for updates impractical, they may apply to Amazon for an extension of the required update period. Applications for extensions to the required update period shall be routed through support channels (for end product manufacturers, applications are routed through the silicon provider). ", "url": "/qualification/on-amazon-sidewalk/sidewalk-qualification-concepts.html#software-updates-on-end-products", "relUrl": "/qualification/on-amazon-sidewalk/sidewalk-qualification-concepts.html#software-updates-on-end-products" },"861": { "doc": "Qualification Concepts", "title": "Qualification Concepts", "content": " ", "url": "/qualification/on-amazon-sidewalk/sidewalk-qualification-concepts.html", "relUrl": "/qualification/on-amazon-sidewalk/sidewalk-qualification-concepts.html" },"862": { "doc": "Qualification FAQs", "title": "On Amazon Sidewalk qualification FAQs", "content": "Topics . | How do I apply for On Amazon Sidewalk qualification? | What happens during qualification testing? | What happens if I don’t want to release information about my product before the product launch? | What happens if I don’t submit my design for On Amazon Sidewalk qualification? | If I don’t need to retest every end product, why do I have to qualify end products with On Amazon Sidewalk? | . ", "url": "/qualification/sidewalk-qualification-faq.html#on-amazon-sidewalk-qualification-faqs", "relUrl": "/qualification/sidewalk-qualification-faq.html#on-amazon-sidewalk-qualification-faqs" },"863": { "doc": "Qualification FAQs", "title": "How do I apply for On Amazon Sidewalk qualification?", "content": "To apply for On Amazon Sidewalk qualification: . | Login to Amazon Sidewalk qualification portal. If you don’t already have a Sidewalk360 login, click here to Signup and we will get you set up with an account. | Fill in details of your Amazon Sidewalk product, company, and contact information, and then submit the form. | . The Amazon Sidewalk qualification team will then contact you with details of how to ship your test samples to the qualification test team. ", "url": "/qualification/sidewalk-qualification-faq.html#how-do-i-apply-for-on-amazon-sidewalk-qualification", "relUrl": "/qualification/sidewalk-qualification-faq.html#how-do-i-apply-for-on-amazon-sidewalk-qualification" },"864": { "doc": "Qualification FAQs", "title": "What happens during qualification testing?", "content": "The following steps happen during qualification testing. | When Amazon Sidewalk has accepted your qualification submission request, we’ll email you details for shipping your test samples to the On Amazon Sidewalk test facility. | You can download the test cases from the Amazon Sidewalk test case specification document. Our engineers require three samples with instructions for how to operate the samples. The samples should have a control interface that allows a test engineer to carry out the test cases. | . Some test cases require packets to be sent and received from the associated AWS Cloud account. For these tests, the On Amazon Sidewalk test facility will set up a call with your engineers, so that your engineers can use the AWS Management Console interface to send and receive packets from the AWS Cloud. | When your design has passed the On Amazon Sidewalk qualification tests and you comply with with the On Amazon Sidewalk Qualification Guidelines, your design can be added to the On Amazon Sidewalk listings, provided they meet the no-retesting requirements outlined above. | . If you then make a product that implements your On Amazon Sidewalk qualified design, that product can also be added to the On Amazon Sidewalk qualification listings. ", "url": "/qualification/sidewalk-qualification-faq.html#what-happens-during-qualification-testing", "relUrl": "/qualification/sidewalk-qualification-faq.html#what-happens-during-qualification-testing" },"865": { "doc": "Qualification FAQs", "title": "What happens if I don’t want to release information about my product before the product launch?", "content": "Optionally, you can have a private listing. Give the On Amazon Sidewalk qualification team the date of your product launch and your qualification information will not be published until the launch date. If your launch date changes, just notify the team to change the publication date. To change the launch date, notification must be given at least five working days before the previously provided launch date. ", "url": "/qualification/sidewalk-qualification-faq.html#what-happens-if-i-dont-want-to-release-information-about-my-product-before-the-product-launch", "relUrl": "/qualification/sidewalk-qualification-faq.html#what-happens-if-i-dont-want-to-release-information-about-my-product-before-the-product-launch" },"866": { "doc": "Qualification FAQs", "title": "What happens if I don’t submit my design for On Amazon Sidewalk qualification?", "content": "Only qualified devices get access to the security keys needed to access the Amazon Sidewalk network, so if you don’t pass the On Amazon Sidewalk qualification, your device will not be able to use the Amazon Sidewalk network. ", "url": "/qualification/sidewalk-qualification-faq.html#what-happens-if-i-dont-submit-my-design-for-on-amazon-sidewalk-qualification", "relUrl": "/qualification/sidewalk-qualification-faq.html#what-happens-if-i-dont-submit-my-design-for-on-amazon-sidewalk-qualification" },"867": { "doc": "Qualification FAQs", "title": "If I don’t need to retest every end product, why do I have to qualify end products with On Amazon Sidewalk?", "content": "Amazon Sidewalk qualification is required for you to use the On Amazon Sidewalk Badge on the product packaging and advertising. This is a valuable branding tool to communicate the added value that Amazon Sidewalk functionality brings to your product. Qualified end products have contact details that allow Amazon to contact manufacturers and service providers, so that Amazon can encourage developers’ smooth rollout of regular updates. ", "url": "/qualification/sidewalk-qualification-faq.html#if-i-dont-need-to-retest-every-end-product-why-do-i-have-to-qualify-end-products-with-on-amazon-sidewalk", "relUrl": "/qualification/sidewalk-qualification-faq.html#if-i-dont-need-to-retest-every-end-product-why-do-i-have-to-qualify-end-products-with-on-amazon-sidewalk" },"868": { "doc": "Qualification FAQs", "title": "Qualification FAQs", "content": " ", "url": "/qualification/sidewalk-qualification-faq.html", "relUrl": "/qualification/sidewalk-qualification-faq.html" },"869": { "doc": "Qualification Waiver", "title": "On Amazon Sidewalk qualification waiver policy", "content": "Amazon Sidewalk qualification uses tests or self-declaration to check that a design correctly implements the requirements to operate on a Amazon Sidewalk network. If your Amazon Sidewalk devices are used only for prototyping, they don’t have to be Amazon Sidewalk-qualified. Qualification is required before you can use your Amazon Sidewalk devices for manufacturing or bulk production. If a design doesn’t pass qualification, and you believe that the design should be allowed to proceed to volume production, you can apply for a qualification waiver. If Amazon agrees that the design should have volume production devices on the Amazon Sidewalk network, then the qualification waiver will be granted to you for a specific period of time. When a qualification waiver is in use, any design can use the waiver and its associated tests in place of any affected test case. The following contains more information about the requirements and how to obtain a qualification waiver. Topics . | Qualification waiver requirements | Waiver contents | Waiver format | Waiver processing | . ", "url": "/qualification/sidewalk-qualification-waiver.html#on-amazon-sidewalk-qualification-waiver-policy", "relUrl": "/qualification/sidewalk-qualification-waiver.html#on-amazon-sidewalk-qualification-waiver-policy" },"870": { "doc": "Qualification Waiver", "title": "Qualification waiver requirements", "content": "Qualification waivers may be granted by Amazon Sidewalk for several possible reasons, such as when: . | A test case has an error and is not correctly testing a Amazon Sidewalk requirement. | An Amazon Sidewalk requirement has an error, and cannot be implemented. | An Amazon Sidewalk requirement may not be applied correctly for all use cases. | The test evaluates a method that’s different from the method that the design uses for meeting the requirements. In this case, the design meets the requirements but doesn’t pass the qualification test. | A test cannot be performed because the test case equipment isn’t fully ready. | . Amazon Sidewalk, in its sole discretion, reserves the right to amend the reasons for granting or denying a qualification waiver at any time. ", "url": "/qualification/sidewalk-qualification-waiver.html#qualification-waiver-requirements", "relUrl": "/qualification/sidewalk-qualification-waiver.html#qualification-waiver-requirements" },"871": { "doc": "Qualification Waiver", "title": "Waiver contents", "content": "To apply for a qualification waiver, provide a document that contains information about why your design should be qualified and how it fails qualification. The document must contain: . | Details of the product for which you are requesting a qualification waiver. | If the waiver is associated with a qualification submission, provide the qualification ID of the submission. | If the waiver is applied before qualification, provide details of your product and your contact details. The contact details must include your name, job title, company name and address, email address, and phone number information. | . | Tests or self-declaration checks that are failing qualification. | Reasons why your design must pass qualification and the corrections that are required to allow your design to pass. For example: . | For test case errors, provide information about why the test doesn’t match the Amazon Sidewalk requirements, and what changes can be applied to correct the test. | For requirement errors, provide details of why the requirement isn’t correct, and what changes need to be applied to the requirement and its associated test cases. | For requirements that are applied incorrectly, provide details as to why the requirement shouldn’t be applied, and what changes are required to the requirements and its associated test cases. | For tests that use a method that’s different from the design for evaluating the requirements, describe why your design meets the requirements but fails the test, and suggest an alternative testing method that evaluates your design correctly. | For tests that can’t be performed, provide details as to why the test cannot be performed. If possible, provide alternative evidence that shows the product meets requirements. | . | Evidence that a test or self-declaration failure will pass if the suggested change is applied. While you can initially provide informal evidence, to obtain a waiver, you must provide test case evidence that’s supported by an On Amazon Sidewalk test facility. | . ", "url": "/qualification/sidewalk-qualification-waiver.html#waiver-contents", "relUrl": "/qualification/sidewalk-qualification-waiver.html#waiver-contents" },"872": { "doc": "Qualification Waiver", "title": "Waiver format", "content": "The waiver request is submitted as a PDF document. A template can be downloaded here: Amazon Sidewalk qualification waiver template . ", "url": "/qualification/sidewalk-qualification-waiver.html#waiver-format", "relUrl": "/qualification/sidewalk-qualification-waiver.html#waiver-format" },"873": { "doc": "Qualification Waiver", "title": "Waiver processing", "content": "The following steps detail how qualification waivers are processed: . | The waiver request is submitted to the qualification database by your test facility. The qualification team is automatically notified of the waiver. | The qualification team assembles a review panel with relevant expertise to process the waiver. | The qualification team reviews the waiver and continues processing, if approved. If the waiver is not approved, the decision is communicated to the reviewer and the status is set to Not granted. | The approved waiver grant is then communicated to the submitter. If the waiver is associated with a qualification, then it can be applied to that qualification. | An anonymous version of the waiver is then published on the qualification database. It will contain information about the test cases that failed qualification, any alternative test case procedures that are required, and the waiver validity duration. Any qualification can use the waiver for this duration. | . ", "url": "/qualification/sidewalk-qualification-waiver.html#waiver-processing", "relUrl": "/qualification/sidewalk-qualification-waiver.html#waiver-processing" },"874": { "doc": "Qualification Waiver", "title": "Qualification Waiver", "content": " ", "url": "/qualification/sidewalk-qualification-waiver.html", "relUrl": "/qualification/sidewalk-qualification-waiver.html" },"875": { "doc": "3. Changes to Amazon Sidewalk Stack Configuration", "title": "3. Changes to Amazon Sidewalk stack configuration", "content": "struct sid_gsk_config, declared in sid_gsk_config.h, carries the GSK tunables: pass a pointer to it in sid_config.gsk_config and call sid_init(). All three fields apply to sub-GHz links only. gsk_config is not conditionally excluded and is read even when both SID_SDK_CONFIG_ENABLE_LINK_TYPE_2 and SID_SDK_CONFIG_ENABLE_LINK_TYPE_3 are 0, but no link then exists that could carry a session. In a build with SID_SDK_CONFIG_ENABLE_GSK (sid_sdk_config.h, default 1) set to 0, none of the three fields is read at all, no session is ever established, and nothing in this note applies; see the Gateway Session Key configuration section of the Amazon Sidewalk Sid API Developer Guide. | Field | Range and default | Meaning | . | idle_timeout_sec (uint32_t, seconds) | 10–600 s (SID_GSK_IDLE_TIMEOUT_MIN_SEC, SID_GSK_IDLE_TIMEOUT_MAX_SEC); 0 = 240 s default (SID_GSK_IDLE_TIMEOUT_DEFAULT_SEC). | The quiet window required on sub-GHz message traffic, both directions, before an establishment starts (§2.2). It is a floor on how long the lull must last, not a deadline: the actual wait can be longer. The keep-alive interval caps any usable value (§4, §6). | . | app_ack_miss_threshold (uint32_t, count) | 3–10 (SID_GSK_APP_ACK_MISS_MIN, SID_GSK_APP_ACK_MISS_MAX); 0 = 6 default (SID_GSK_APP_ACK_MISS_DEFAULT). | Consecutive ack-requested uplinks transmitted but never acknowledged end to end, after which the session is discarded and the link continues in non-GSK mode. §2.2 gives what feeds the counter, what resets it, and what the counted uplinks cost. | . | retry_interval_sec (uint32_t, seconds) | 43200–129600 s, that is 12–36 h (SID_GSK_RETRY_INTERVAL_MIN_SEC, SID_GSK_RETRY_INTERVAL_MAX_SEC); 0 = 86400 s default, one day (SID_GSK_RETRY_INTERVAL_DEFAULT_SEC). | How long the Endpoint stays in non-GSK mode after a fallback before it retries establishment. The wait repeats until one succeeds, and each attempt still waits for the idle window (§2.2). | . Table 3.1: Fields of struct sid_gsk_config. Rules: . | A NULL gsk_config pointer selects all three defaults — 240 s, 6 and 86400 s; a field value of 0 selects that field’s default independently. | Out-of-range values are silently clamped to the nearest bound, so sid_init() never fails because of gsk_config, and no API reads back the applied value. Assert your values against the SID_GSK_* macros at compile time (§5). | No sid_option retunes any of the three fields: call sid_deinit(), then sid_init() again. | sid_gsk_config.h includes only <stdint.h> and sid_api.h does not include it, so include it yourself. With the SDK’s CMake targets, link the header-only sid_gsk_config target for its include path; sid_api does not expose it. | . What a retune costs. sid_deinit() does not discard the stored session, so the following sid_init() reloads it exactly as a reboot does (§2.2): if it is no longer usable, the Endpoint spends up to one retry_interval_sec in non-GSK mode. Retune only in good coverage, and prefer a compile-time constant. sid_stop() and sid_start() do not move the session lifecycle. ", "url": "/app-notes/gateway-session-key/stack-configuration-changes.html#3-changes-to-amazon-sidewalk-stack-configuration", "relUrl": "/app-notes/gateway-session-key/stack-configuration-changes.html#3-changes-to-amazon-sidewalk-stack-configuration" },"876": { "doc": "3. Changes to Amazon Sidewalk Stack Configuration", "title": "3. Changes to Amazon Sidewalk Stack Configuration", "content": " ", "url": "/app-notes/gateway-session-key/stack-configuration-changes.html", "relUrl": "/app-notes/gateway-session-key/stack-configuration-changes.html" },"877": { "doc": "5.7 Sub-GHz physical layer modulations", "title": "5.7 Sub-GHz physical layer modulations", "content": "The sub-GHz ISM band has two physical layer modulation techniques: CSS and GFSK. The modulation process consists of two stages: digital modulation and analog modulation. During digital modulation, the data payload (link layer frame) is attached to preamble and the CRC is placed at the end. The frame layout is defined by IEEE in 802.15.4 [1]. For more information, see section 5.1.4. The analog part of modulation is applied afterwards (CSS or FSK respectively). During this process, data bits are assigned to symbols according to a modulation scheme. The result is analog signal in baseband. For more information on CSS modulation, see section 5.7.2; for more information on FSK modulation, see section 5.7.3. The next step is to upconvert the baseband (BB) signal to either the working RF channel (in case of single channel mode SubG-CSS) or to the scheduled channel allocated (for SubG-FSK). For more information on frequency hopping, see section 5.7.1. Finally, the RF-modulated signal is amplified and filtered to achieve the required RF power spectrum. The RF signal must be compliant with normative requirements for bandwidth and power density. The Normative requirements are defined by relevant administrative bodies: ETSI for ITU Region 1, FCC for ITU Region 2., and others for ITU Region 3. Available channel lists with modulation parameters and duty cycles are shown in Table 5.5 and Table 5.6 for ITU Region 2. Table 5.5 SubG-CSS Channel allocation for Region 2 . | Modulation | Channel | Frequency | Signal Bandwidth | SF | Duty cycle | . | SubG-CSS 2 kbps | 0 | 902.5 MHz | 500 kHz | 11 | NA | . | … | … | … | … | … | … | . | SubG-CSS 2 kbps | 30 | 926.5 MHz | 500 kHz | 11 | NA | . Channel spacing for SubG-CSS is 800 kHz. Channel 26 is the default working channel. Table 5.6 FSK Channel allocation for Region 2 . | Modulation | Channel | Frequency | Frequency Deviation | Modulation index | BT | . | GFSK 50 kbps | 0 | 902.2 MHz | 25 kHz | 1 | 1 | . | … | … | … | … | … | … | . | GFSK 50 kbps | 128 | 927.8 MHz | 25 kHz | 1 | 1 | . Channel spacing for SubG-FSK is 200 kHz. Sixty-nine channels are used in Amazon Sidewalk. Half-duplex (HDX) transmission modes are implemented in both SubG-CSS and SubG-FSK due to the requirement for multi access on a single channel and limitations for radiated power. Both modulation methods can use any of the available channels available in the regional channel grid. As examples in ITU Region 2. 915 MHz band is available. 5.7.1 Frequency hopping . There are two reasons for developing a frequency hopping system. Firstly, the system becomes more immune against fades and single channel interferences. Secondly, the system fulfills requirements for channel-radiated power density normative limits. Slow frequency hopping is implemented in the Amazon Sidewalk protocol. There is a precalculated hopping pattern based on random seed and table-based seq_id for each entity. An algorithm implements Beacon channel collision avoidance. Details are described in section 5.2.4. 5.7.2 LoRa modulation for SubG-CSS . LoRa modulation is a kind of spread spectrum modulation where a frequency chirp is implemented as a constant envelope frequency sweep within the working channel. Symbol rate (SR) is defined as: . SR = BW / (2^SF) . where BW is signal bandwidth and SF is spreading factor. SF 11 is used in Amazon Sidewalk rel. 1.10. Bit rate (Rb) is calculated as: . Rb = (SF * CR * BW) / (2^SF) [bits/s] . where CR code rate 4/5 … 4/8. Higher SF provides better processing gain per symbol and hence requires less SNR. Furthermore, higher SF provides more immunity to co-channel interference. Frequency tolerance: < +/-90.25kHz @500kHz BW; RX sensitivity: ≤ -128 dBm @ SF11/500kHz BW. [2] . 5.7.3 GFSK modulation for SubG-FSK . In GFSK modulation, a Gaussian filter (pulse shaper with predefined bandwidth) is applied after the FSK modulator. This module reduces the occupied bandwidth of the modulated signal. NOTE: Lower BT increases inter-symbol interference. Occupied bandwidth (OBW) can be estimated as: . OBW = Rb + 2 * Fdev . where Rb is the PHY bitrate, and Fdev is the frequency deviation corresponding to the chosen modulation index. Rb equals symbol rate for GFSK modulation. TX frequency clock accuracy ≤ +/- 40PPM [1],[4]; RX sensitivity: ≤ -107 dBm [3]; . Blocking and selectivity in accordance with local requirements [5]. References: . | IEEE 802.15.4g (GFSK). | Semtech SX 1272/73 application note. | TI CC1070 application note. | TI CC1200 application note. | FCC CFR 47. | . ", "url": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/sub-ghz-physical-layer-modulations.html", "relUrl": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/sub-ghz-physical-layer-modulations.html" },"878": { "doc": "5.3 SubG-CSS connection", "title": "5.3 SubG-CSS connection", "content": "The SubG-CSS mode allows devices to connect to the network using the ALOHA channel access protocol. The frame can be transmitted by an Endpoint when it is needed. section 5.2.3 describes scheduling of transmission and time dependencies between downlink and uplink. 5.3.1.1 contains a detailed description of a randomization algorithm used for scheduling uplink Endpoint activities. Each Endpoint shall communicate with the Amazon Sidewalk network to indicate its presence to the cloud and also give a Target Transmission Time to receive data. The device presence indication may be either frequent, with a specified time interval, or unscheduled, when uplink transmission is executed occasionally. Endpoints may receive data within a regulated period of time with specified intervals after uplink transmission. For more details, see section 5.5. 5.3.1 Downlink and uplink . The device working in SubG-CSS mode may start its transmission randomly. All uplink transmissions are not synchronized. The moments in time when uplink may happen are called uplink Target Transmission Times. These events are separated by a specified time interval called uplink slot separation and its value is ul_separation. Downlink shall happen after uplink transmission only. The Endpoint receive is synchronized. The moments in time when a downlink may happen are called downlink Target Transmission Times. These events are separated by a specified time interval called downlink slot separation and its value is dl_separation. Uplink transmissions are asynchronous with respect to other devices but follow a pseudo-random pattern for each device. 5.58 shows the downlink and uplink slots scheduling. fig 5.58 DL and UL timing . The number of uplink Target Transmission Times followed by downlink has the value nb_ul_opp. The value nb_ul_slot has to be a power of 2 . nb_ul_slot = 2 ^i where i= 0, 1, 2, … . the total amount of downlink and uplink slots nb_slot in dl_separation period is: . nb_slot = nb_ul_opp + 1 . and the time consumed for all nb_slot has to be less than dl_separation time: . nb_slot \\ ul_separation < dl_separation* . The number of downlink slots used for network data reception has the value nb_dl_slot. The number is counted from the last uplink transmission and the Endpoint does not schedule any further downlink when nb_dl_slot is reached. This value and dl_separation are configured by Connection Profile settings (see section 5.5). Each uplink slot has its own index ul_slot_index in the dl_separation period and possible values are as follows: . ul_slot_index = 0, 1, ... , nb_ul_slot - 1 . The method of selection of an uplink slot for a transmission is based on Lehmer’s random number generator and the result of the calculation is ul_slot_index. The index value allows calculation of the offset of an uplink slot from a downlink slot: . ul_offset = (ul_slot_index + 1) \\ ul_separation* . Each uplink transmission is scheduled but not synchronized, so the time drift is not taken into account and the preamble size is constant. 5.59 shows the ul_offset and ul_opp_index values. 5.3.1.1 describes values evaluation. fig 5.59 UL opportunity selection . Downlink slots following an uplink slot are scheduled and synchronized. The synchronization between the Endpoint and the associated Gateway is based on the uplink Epoch frame. The position in time of subsequent downlink slots is based on the uplink transmission. The Endpoint calculates ul_slot_index of the downlink slot used for transmission and ul_offset from the last downlink slot preceding the transmission. The time to the downlink slot is calculated as follows: . dl_offset = dl_separation - ul_offset . 5.60 shows scheduling of downlink slots. fig 5.60 DL opportunity estimation . An Endpoint which has been sleeping for a long time starts its transmission in case data is available to be sent. The first uplink transmission is the base for the calculation of subsequent downlink slots scheduling. Also when additional data transfer is required, the device uses scheduled downlink slots for subsequent uplink estimation. 5.61 shows such a case. fig 5.61 UL and DL scheduling . 5.3.1.1 Uplink offset computation algorithm . Endpoints in close proximity can have data transmitted at a similar time. This leads to a situation where uplink activity of devices can overlap. This causes an uplink collision and a packet loss due to interference, and could happen in the case of tracking devices, for example. The uplink offset computation algorithm provides a mechanism which randomizes scheduling of uplink activities. The algorithm purpose is to calculate the ul_slot_index value which points out an uplink slot used for transmission activity. The algorithm input for variable calculations is seed and seq_id. The seed is the table containing all UUID digits of the Endpoint and the size of the table is equal to nb_uuid of UUID digits. 5.62 shows this table. fig 5.62 Seed table . The seq_id is the Link Layer sequence number of the Epoch frame to be transmitted (see seq_num field in Data Frame format of Link Layer in 5.1.3.2.4). The core of the algorithm is Lehmer’s random number generator. The base equation of the generator is: . x [ n ] = ( a * x [ n - 1 ] + b )  MOD  m . where n indicates the iteration number and x[n] indicates the uplink slot. Parameters m, a and b are common for all iterations. Variable m is equal to nb_ul_slot: . m = nb_ul_slot = nb_slot - 1 . Variables b and a are based on the seed and calculated based on the following equations: . b = (seed[nb_uuid-1]  MOD  m)  OR  1 . a = (seed[nb_uuid-3] + (5 - (seed[nb_uuid-3]  MOD  4)))  MOD  m; . also the initial value x[n] where n = 0 is based on seed and is calculated in the following way: . x[0] = seed[nb_uuid-2]  MOD  m . When UUID is changed, these three variables also need to be recalculated and the algorithm needs to be reinitialized. The Endpoint needs to calculate a number of iterations nb_it which need to be executed for the provided seq_id. This is based on two variables curr_it and prev_it value. Variable prev_it is set to 0 during algorithm initialization: . prev_it = 0 . the value curr_it is always calculated from equation . curr_it = seq_id  MOD  m . as this is an MOD operation; then it could happen that . curr_it < prev_it . so in this case requires recalculation of curr_it in the following way: . curr_it = (seq_id  MOD  m) + m . the number of iterations which needs to be executed for specified seq_id is: . nb_it = curr_it - prev_it . then the n value is increased by 1 up to nb_it in Lehmer’s equation: . n = n + nb_it . so the final x[] value for seq_id is . x[n+nb_it] . where n is the final value of all iterations executed till current seq_id. After this the prev_it is overwritten by curr_it and curr_it and is calculated again for the next seq_id. Each new x[n] value calculated for subsequent seq_id indicates the uplink slot index ul_opp_index so ul_offset and is calculated using the following equation: . ul_offset = (ul_slot_index + 1) \\ ul_separation* . This identifies the uplink slot scheduled for transmission relative to the downlink slot. ", "url": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/subgcss-connection.html", "relUrl": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/subgcss-connection.html" },"879": { "doc": "5.2 SubG-FSK Connection", "title": "5.2 SubG-FSK Connection", "content": "Endpoints working in SubG-FSK mode shall be synchronized with a Gateway before an uplink or downlink transmission is performed. The synchronization mechanism works by searching for a periodic frame sent by Gateways, namely Beacon frames. Endpoints shall detect eligible Gateways by searching and receiving Beacons. In addition to its role in synchronization, Beacon payload carries basic information about the state of the Gateway, such as the Gateway’s cloud connection status, hopping seed or sequence number. The Beacon payload is not encrypted, allowing discovery and connection initiation by all Amazon Sidewalk devices. For a detailed description of the Beacon frame format and information carried by the Beacon, see section 5.1.3.1.section 5.2.1 describes the Beacon discovery mechanism that Endpoints use in initial synchronization with a Gateway. section 5.2.2 describes how Endpoints maintain synchronization with a Gateway. section 5.2.3 describes Endpoints’ data packet transmission scheduling in both directions. section 5.2.4 describes the mechanism of the channel number calculation. section 5.2.5 describes the mechanism that reduces/eliminates over the air collision. 5.2.1 Beacon discovery . The procedure of discovering nearby Gateways through their periodic Beacon transmissions is called the Beacon discovery procedure. The Beacon discovery procedure is based on traversing the channel list and performing a preamble detection on each channel. The Beacon discovery procedure is divided into two phases: preamble detection in the currently selected channel and channel change operation. If a preamble is not detected on a channel, then the Endpoint shall switch to the next channel from the list and repeat the operation. If a preamble is detected, then the Endpoint shall receive the PHY frame and check if the received frame is a Beacon frame from a Gateway eligible for connections. The duration of each phase is defined by the following: . | tr_det_listening - time period used for preamble detection | ch_change - time period used for switching to the next channel from the list | . Note that the Beacon preamble is long enough to ensure detection regardless of the channel on which the Beacon packet is transmitted. The preamble duration is calculated by (nb_channels + 1)*(tr_det_listening + ch_change) and is greater than or equal to prm_dur. The whole PHY frame duration of the Beacon is equal to bcn_dur. The Beacon discovery algorithm schedule is as follows: . | Select channel 0. | Listen to the medium on selected channel for tr_det_listening . | if the preamble is detected, start receiving the PHY frame for a maximum duration of bcn_dur time . | if the whole PHY frame is not received within bcn_dur time, stop receiving and go to bullet 3 | if the whole PHY frame is received within bcn_dur time, then go to (b) | . | frame is checked against being a Beacon and fitting the Beacon criteria . | if the frame is accepted and the Beacon is received, then stop the algorithm | if the frame is not accepted, then go to bullet 3 | . | if traffic is not detected, then go to bullet 3 . | . | Switch to the next channel within the ch_change time . | if all supported channels are used, then go to bullet 1 | if not all supported channels are used, then increment the current channel by 1 and continue from bullet 2 | . | . figure 5.45 shows how the algorithm works. fig 5.45 SubG-FSK connection - Beacon Discovery . 5.2.2 Synchronization maintenance . Based on the channel hopping algorithm, synchronized devices are capable of calculating the channel on which the next Beacon should be transmitted. Additionally, Beacons are broadcast every bcn_interval time interval so a synchronized Endpoint knows the channel and the approximate timing of the next Beacon packet. This leads to less time consumed receiving the Beacon as the synchronized device receives just the tail of the Beacon preamble transmitted by the Gateway. The Endpoint opens a downlink detection slot for each bcn_interval and listens for ongoing transmission for tr_det_listening time. When the transmission is detected, the device starts to receive the whole PHY frame and validate whether the received data is the Beacon.figure 5.46 shows the Beacon reception process on the synchronized Endpoint. fig 5.46 SubG-FSK connection - Beacon reception . If a synchronized Endpoint fails to receive a Beacon, the Endpoint continues Link Layer operations and attempts to receive the next Beacon while the number of consecutive failures is less than 4. The third consecutive failure triggers the Beacon discovery procedure. figure 5.47 shows the Beacon timing from the Gateway, synchronized Endpoint and the device detecting the Beacon. fig 5.47 SubG-FSK connection - Beacon operations . 5.2.3 Uplink and downlink . An Endpoint in SubG-FSK mode shall send and receive data using Target Transmission Times. Target Transmission Times are separated by the time interval slot_int. fig 5.48 SubG-FSK connection - Opportunities . Gateways broadcast Beacons frequently, every bcn_interval. The number of slots can be calculated based on the following equation: . nb_slot = bcn_interval / slot_int . fig 5.49 SubG-FSK connection - Opportunities and Beacon . There is one Target Transmission Time in each slot. Target transmission times can be used for both uplink and downlink. The Gateway further specifies a subset for an uplink, i.e. from an Endpoint to a Gateways, for one or a set of nodes and similarly another subset of slots for downlink transmissions from a Gateway to an Endpoint. The following slots are not used for uplink and downlink slots: 0, 1, 2 and nb_slot - 1. These are reserved for the Beacon broadcasting. Hence, the index of the first and last uplink and downlink opportunities are is 3 and is nb_slot - 2. The subset of slots assigned for each Endpoint’s uplink and downlink transmissions are characterized by two parameters: offset and periodicity. The offset is the number of slots between slot 0 and the first slot that is scheduled for uplink or downlink. The periodicity is the time interval between subsequent slots that are scheduled for uplink or downlink. The maximum number of slots that may be used for uplink or downlink activity has the value ul_dl_nb_slot. This value can be calculated by the following equation: . ul_dl_nb_slot = nb_slot - 4 (number of slots that shall not be used for uplink and downlink slots) . fig 5.50 SubG-FSK connection - DL scheduling . fig 5.51 SubG-FSK connection - UL scheduling . The device starting its transmission shall use a contention mechanism to sense whether the medium is free and uplink transmission may be performed. The Endpoint shall sense the medium for the tr_det_listening duration for each Target Transmission Time and start receiving data if traffic is detected. If traffic is not detected, then the Endpoint may switch off the radio until the next scheduled uplink or downlink Target Transmission Time. Devices working in SubG-FSK mode shall use a channel hopping mechanism for all network activities. 5.2.4 Channel hopping . The channel hopping mechanism calculates a channel number for each transmit and receive activity. The number of supported channels may differ for different regions and the number of supported channels is nb_channels. Transmission that starts in a selected slot on a channel shall finish on the same channel, even if the transmission spans following slots. The channel calculations for the Beacon broadcasting and Endpoint uplink or downlink transmissions are calculated separately. The result of the calculations is a hopping sequence that contains channel numbers for upcoming transmissions. The Beacon hopping sequence contains nb_bcn_channels elements. The uplink or downlink hopping sequence contains nb_ul_dl_channels. The hopping sequence calculations are described in section 5.2.4.3 and section 5.2.4.4. Both sequences are derived from the channel shuffler. The channel shuffler uses a pseudo random number generator. For further details, see section 5.2.4.1. 5.2.4.1 Pseudorandom number generator . The pseudorandom number generator (PRNG) produces pseudorandom values that are used in an iterative process by the channel shuffler and linear feedback shift register (LFSR) is used for that purpose. The lfsr_value[ n ] is produced by the linear-feedback shift register where n = 0, 1, 2, 3, … , nb_channels-1. LFSR is implemented as a feedback polynomial in the following shape: . x16 + x14 + x13 + x11 + 1 . The feedback polynomial is used in an iterative process where output of n-1 step is the base for calculations in step n. The output value of the feedback polynomial can be calculated as follows: . msb = lfsr_value [n-1] XOR . ( lfsr_value [ n - 1 ] >> 2) XOR . ( lfsr_value [ n - 1 ] >> 3 ) XOR . ( lfsr_value [ n - 1 ] >> 5 ) . lfsr_value [ n ] = ( lfsr_value [ n - 1 ] >> 1 ) OR  ( msb << 15) . The LFSR is initialized with seed and seq_id: . | 16 most significant bits of the seed are taken: msb_seed | 16 least significant bits of the seed are taken: lsb_seed | the pseudo-random number generator is initialized as: . lfsr_init = msb_seed XOR lsb_seed XOR seq_id . | . The first feedback polynomial value for n = 0 is calculated based on the following: . msb = lfsr_init XOR . ( lfsr_init >> 2 ) XOR . ( lfsr_init >> 3 ) XOR . ( lfsr_init >> 5 ) . lfsr_value [ 0 ] = ( lfsr_init >> 1) OR  ( msb << 15 ) . The lfsr_value[ 0 ] shall be a non-zero value. In case the lfsr_value[0] value is zero, then 0xACE1 shall be used instead. 5.2.4.2 Channel shuffler . The channel shuffler produces a randomized sequence of nb_channels numbers. The channel shuffler involves a random number generator to randomize the sequence and the randomization algorithm is as follows: . | Initialize RNG with seed, seq_id | Initialize the sequence of numbers with values: 0, 1, 2, 3, …, nb_channels-1 | Initialize the iteration number n with value 0. | Calculate random value: rng_out_value[ n ] = lfsr_value[ n ] MOD nb_channels | Swap numbers from the sequence pointed out by rng_out_value[n] and n indexes | Increase the iteration number n = n + 1 . | if n <= nb_channels-1 continue from bullet 4 | if n > nb_channels-1 stop the algorithm | . | . The schematic process of the sequence randomization is shown in 5.52. fig 5.52 SubG-FSK connection - Channels randomization process . 5.2.4.3 Beacon hopping sequence calculation . Each subsequent Beacon is transmitted on a different channel. The channel number is taken from the channel hopping sequence that contains nb_channels elements. Values in the channel hopping sequence are calculated by the channel shuffler. The channel shuffler input seed is broadcast by the Beacon and can be found in the field hdr_hop_seed (see section 5.1.3.1). The channel shuffler input seq_id indicates the number of channels sequence and is calculated based on two parameters: . | bcn_hop_sequence_num - the value is broadcast in the Beacon section (see 5.1.3.1) | nb_channels - number of supported channels | . The equation for the seq_id is as follows: . seq_id = bcn_hop_sequence_num / nb_channels . The index in the numbers sequence that points out the value indicating the channel of the received Beacon is bcn_hop_sequence_num MOD nb_channels while the upcoming Beacon channel value is pointed out by index (bcn_hop_sequence_num +1) MOD nb_channels. The Beacon channel usage example is shown in figure 5.53. The assumptions for the figure are nb_channels = 69, bcn_hop_sequence_num starts from 0. fig 5.53 SubG-FSK connection - Beacon channels . 5.2.4.4 Uplink or downlink hopping sequence calculation . Subsequent slots that may be used for Endpoint uplink or downlink activity shall have different channels assigned (see section 5.2.3). The channel assignment is defined by the channel hopping sequence list that contains nb_ul_dl_channels elements. Each element indicates the channel number is seen once in the values sequence. Additionally, the channel used by Beacon broadcasting for the current bcn_interval period, channels used for nb_neighb_bcn past and future Beacons shall not be present in the uplink or downlink hopping sequence. The value of nb_ul_dl_channels can be calculated using the following equation: . nb_ul_dl_channels = nb_channels - 2*nb_neighb_bcn - 1 . The base for the uplink or downlink channels sequence calculation is the channel shuffler and the Beacon hopping sequence. The channels sequence calculation starts with the channel shuffler that has two parameters: seed and seq_id. The seed value is broadcast by the Beacon and can be found in the field hdr_hop_seed (see section 5.1.3.1). The seq_id shall be calculated based on four parameters: . | bcn_hop_sequence_num - the value is broadcasted in the Beacon | nb_ul_dl_channels - number of channels used for uplink or downlink activity | nb_slot - number of slots in bcn_interval | slot_nb - slot number (range is from 0 to nb_slot-1) | . The equation for the seq_id is as follows: . seq_id = ((bcn_hop_sequence_num * nb_slot) + slot_nb) / nb_ul_dl_channels . The output of the channel shuffler is the sequence of nb_channels values. The next step is to remove the last three channels used for broadcasting Beacons, nb_neighb_bcn and the next two channels that will be used for broadcasting Beacons, nb_neighb_bcn based on the calculated Beacon hopping sequence returned by the channel shuffler. If the calculation happens during a Beacon slot, that Beacon slot is counted with the last three channels used for broadcasting Beacons. After removing Beacon channels, the final sequence of nb_ul_dl_channels values is the uplink or downlink hopping sequence. The channel value that shall be used for the uplink or downlink slot is given by hop_seq_index value. The channel value indicates the index in the hopping sequence that corresponds to the channel number. The index value can be calculated based on the following equation: . hop_seq_index = ((bcn_hop_sequence_num * nb_slot) + slot_nb) MOD nb_ul_dl_channels . An example of uplink, downlink and the Beacon channel hopping sequence usage is shown in figure 5.54. The example has the following parameters nb_channels = 69, nb_ul_dl_channels = 64, bcn_interval = 10080 ms, slot_int = 63 ms, nb_slot = 160. fig 5.54 SubG-FSK connection - Channel hopping usage . 5.2.5 Contention mechanism . The role of the contention mechanism is to prevent a collision when two or more Endpoints start sending data in the same transmission slot. At a random time slightly before the Target Transmission Time, the device shall check whether the medium is free before transmission is started, and for that purpose a listen-before-transmit solution is used. The transmission activity is forbidden if the channel is busy and the device shall defer the transmission to a later Target Transmission Time. The transmission activity is allowed if the channel is free. The check of medium availability is done in a contention window which precedes the target transmission time. The contention window duration has a value contend_time. The contention window is divided into 6 sub-slots. Each sub-slot has duration sub_slot_time. The number of sub-slots is defined by sub_slot_nb and the duration of each sub-slot is defined by sub_slot_time. The Endpoint has to select one sub-slot randomly. Gateways select deterministically, and always select sub_slot_nb-1. The selected slot is used for the detection of activity from other devices in the network.figure 5.55 shows the timing of contention sub-slots and uplink slots. fig 5.55 SubG-FSK connection - Contention window . If the device does not detect any activity on the selected sub-slot, the device starts transmission. The transmission shall start in a subsequent sub-slot. All the remaining subsequent sub-slots shall be used for transmission of additional preamble symbols prepended to the Physical Layer frame (see section 5.1.4). If sub-slot 0 is used to detect activity, additional preamble symbols shall not be added. The actual Physical Layer frame can be started at the Target Transmission time. figure 5.56 shows when the device can start sending the data. fig 5.56 SubG-FSK connection - Data transmission - Allowed . If the device detects activity on the selected sub-slot, then the device shall not start its transmission. The device shall select the next transmission slot randomly from the set of the next 4 subsequent uplink slots. At the next scheduled transmission slot, the channel availability check process needs to be performed again with a new random sub-slot selection. This process can be repeated up to tr_ret_nb times before transmission failure is concluded.figure 5.57 shows the situation when transmission needs to be deferred to a later time. fig 5.57 SubG-FSK connection - Data transmission - Forbidden . ", "url": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/subgfsk-connection.html", "relUrl": "/specifications/sidewalk-protocol-spec/sub-ghz-protocol-stack/subgfsk-connection.html" },"880": { "doc": "2. Test Execution Summary", "title": "Test Execution Summary", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#test-execution-summary", "relUrl": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#test-execution-summary" },"881": { "doc": "2. Test Execution Summary", "title": "BLE Test Cases", "content": "| Test Case | Executable by Customer | . | CMN/EN/API/INF/BV-01 | Yes | . | BLE/EN/CONN/REG/BV/01 | Yes | . | BLE/EN/CONN/REG/BV/02 | Yes | . | BLE/EN/CONN/REG/BV/03 | Yes | . | BLE/EN/DATA/DL/BV/01 | Yes | . | BLE/EN/DATA/UL/BV/01 | Yes | . | BLE-EP-CONN-EST-BV/01 | Yes | . | BLE/EN/CONN/EST/BV/02 | Yes | . | BLE/EN/CONN/EST/BV/03 | Yes | . | BLE/EN/CONN/DSC/BV/01 | Yes | . | BLE/EN/CONN/DSC/BV/02 | Yes | . | BLE/EN/CONN/DSC/BV/03 | Yes | . | BLE/EN/CONN/DSC/BV/06 | Yes | . | BLE/EN/CONN/DSC/BV/07 | Yes | . | BLE/EN/CONN/BCN/BV/01 | Yes | . | BLE/EN/CONN/BCN/BV/02 | Yes | . | BLE/EN/CONN/BCN/BV/03 | Yes | . | BLE/EN/CONN/BCN/BV/04 | Yes | . | BLE-EP-CONN-DUP-BV/01 | Yes | . | BLE-EP-CONN-DUP-BV/02 | Yes | . | BLE-EP-CONN-DUP-BV/03 | Yes | . | BLE-EP-CONN-DUP-BV/04 | Yes | . | BLE-EP-CONN-DUP-BV/05 | Yes | . | BLE/EN/NW-SYNC/TIME/BV/01 | Yes | . ", "url": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#ble-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#ble-test-cases" },"882": { "doc": "2. Test Execution Summary", "title": "FSK Test Cases", "content": "| Test Case | Executable by Customer | . | FSK/EN/BCN/DISCO/BV-01 | Yes | . | FSK/EN/BCN/DISCO/BV-02 | Yes | . | FSK/EN/BCN/DISCO/BV-03 | Yes | . | FSK/EN/CONN/REG/BV-02 | Yes | . | FSK/EN/CONN/REG/BV-03 | Yes | . | FSK/EN/CONN/SEQ/BV-01 | Yes | . | FSK/EN/CONN/SEQ/BV-02 | Yes | . | FSK/EN/CONN/SEQ/BV-03 | Yes | . | FSK/EN/CONN/SEQ/BV-05 | Yes | . | FSK/EN/CONN/SEQ/BV-06 | Yes | . | FSK-EP-CONN-SEQ-BV-07 | Yes | . | FSK/EN/CONN/SEQ/BV-08 | Yes | . | FSK/EN/CONN/SEQ/BV-09 | Yes | . | FSK/EN/DATA/DL/BV-01 | Yes | . | FSK/EN/DATA/UL/BV-01 | Yes | . | FSK/EN/NW-SYNC/TIME/BV-01 | Yes | . | FSK/EN/NW-SYNC/JOIN/BV-01 | Yes | . | FSK/EN/NW-SYNC/JOIN/BV-02 | Yes | . | FSK/EN/SEC/UUID/BV-01 | Yes | . | FSK/EN/SEC/UUID/BV-02 | Yes | . | FSK/EN/SEC/UUID/BV-03 | Yes | . ", "url": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#fsk-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#fsk-test-cases" },"883": { "doc": "2. Test Execution Summary", "title": "LoRa Test Cases", "content": "| Test Case | Executable by Customer | . | LORA/EN/DATA/DL/BV-01 | Yes | . | LORA/EN/DATA/UL/BV-01 | Yes | . | LORA/EN/SEC/UUID/BV-01 | Yes | . | LORA/EN/SEC/UUID/BV-02 | Yes | . | LORA/EN/SEC/UUID/BV-03 | Yes | . | LORA/EN/CONN/REG/BV-02 | Yes | . | LORA/EN/CONN/LP/BV-01 | Yes | . | LORA/EN/CONN/LP/BV-02 | Yes | . | LORA/EN/CONN/SEQ/BV-01 | Yes | . | LORA/EN/CONN/SEQ/BV-02 | Yes | . | LORA/EN/CONN/SEQ/BV-03 | Yes | . | LORA/EN/CONN/SEQ/BV-05 | Yes | . | LORA/EN/CONN/SEQ/BV-06 | Yes | . | LORA/EN/CONN/SEQ/BV-07 | Yes | . | LORA/EN/CONN/SEQ/BV-08 | Yes | . | LORA/EN/CONN/SEQ/BV-09 | Yes | . | LORA/EN/NW-SYNC/JOIN/BV-02 | Yes | . | LORA/EN/NW-SYNC/JOIN/BV-03 | Yes | . | LORA/EN/NW-SYNC/TIME/BV-01 | Yes | . ", "url": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#lora-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#lora-test-cases" },"884": { "doc": "2. Test Execution Summary", "title": "Multi-link (MLM) Test Cases", "content": "| Test Case | Executable by Customer | . | MULTI-LINK/EP/BLE-AUTO-CONNECT/UL/BI/01 | Yes | . | MULTI-LINK/EP/BLE-AUTO-CONNECT/UL/BV/02 | Yes | . | MULTI-LINK/EP/FSK-AUTO-CONNECT/UL/BI/01 | Yes | . | MULTI-LINK/EP/FSK-AUTO-CONNECT/UL/BV/02 | Yes | . | MULTI-LINK/EP/LoRa-AUTO-CONNECT/UL/BI/01 | Yes | . | MULTI-LINK/EP/LoRa-AUTO-CONNECT/UL/BV/02 | Yes | . | MULTI-LINK/EP/BLE-LoRa-AUTO-CONNECT/UL/BV/01 | No | . | MULTI-LINK/EP/BLE-LoRa-AUTO-CONNECT/UL/BV/02 | No | . | MULTI-LINK/EP/BLE-LoRa-AUTO-CONNECT/UL/BV/03 | No | . | MULTI-LINK/EP/BLE-LoRa-AUTO-CONNECT/UL/BV/04 | No | . | MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/01 | No | . | MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/02 | No | . | MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/03 | No | . | MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/04 | No | . | MULTI-LINK/EP/BLE-FSK-LoRa-AUTO-CONNECT/UL/BV/05 | No | . | MULTI-LINK/EP/MLM-ACTIVE/UL/BV/01 | No | . | MULTI-LINK/EP/MLM-ACTIVE/UL/BV/02 | No | . | MULTI-LINK/EP/MLM-ACTIVE/UL/BV/03 | No | . | MULTI-LINK/EP/MLM-ACTIVE/UL/BV/04 | No | . | MULTI-LINK/EP/MLM-ACTIVE/UL/BV/05 | No | . | MULTI-LINK/EP/MLM-POWER/UL/BV/01 | No | . | MULTI-LINK/EP/MLM-POWER/UL/BV/02 | No | . | MULTI-LINK/EP/MLM-POWER/UL/BV/03 | No | . | MULTI-LINK/EP/MLM-POWER/UL/BV/04 | No | . | MULTI-LINK/EP/MLM-POWER/UL/BV/05 | No | . | MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/01 | No | . | MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/02 | No | . | MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/03 | No | . | MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/04 | No | . | MULTI-LINK/EP/MLM-PERFORMANCE/UL/BV/05 | No | . | MULTI-LINK/EP/MLM-LATENCY/UL/BV/01 | No | . | MULTI-LINK/EP/MLM-LATENCY/UL/BV/02 | No | . | MULTI-LINK/EP/MLM-LATENCY/UL/BV/03 | No | . | MULTI-LINK/EP/MLM-LATENCY/UL/BV/04 | No | . | MULTI-LINK/EP/MLM-LATENCY/UL/BV/05 | No | . | MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/01 | No | . | MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/02 | No | . | MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/03 | No | . | MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/04 | No | . | MULTI-LINK/EP/MLM-RELIABILITY/UL/BV/05 | No | . ", "url": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#multi-link-mlm-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#multi-link-mlm-test-cases" },"885": { "doc": "2. Test Execution Summary", "title": "Multi-Radio Test Cases", "content": "| Test Case | Executable by Customer | . | MULTI/EN/API/INIT/BV-01 | Yes | . | MULTI/EN/CONN/DL/BV-01 | Yes | . | MULTI/EN/CONN/DL/BV-02 | Yes | . | MULTI/EN/CONN/DL/BV-03 | Yes | . | MULTI/EN/CONN/SEND-LINK/BV-01 | Yes | . | MULTI/EN/CONN/SEND-LINK/BV-02 | Yes | . | MULTI/EN/CONN/SEND-LINK/BV-03 | Yes | . | MULTI/EN/CONN/SEND-LINK/BV-04 | Yes | . | MULTI/EN/CONN/SEND-LINK/BV-05 | Yes | . ", "url": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#multi-radio-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#multi-radio-test-cases" },"886": { "doc": "2. Test Execution Summary", "title": "File Transfer Test Cases", "content": "| Test Case | Executable by Customer | . | BLE/EP/API/FILETRANSFER/BV/01 | Yes | . | BLE/EP/API/FILETRANSFER/BV/02 | Yes | . | BLE/EP/API/FILETRANSFER/BV/03 | Yes | . | BLE/EP/API/FILETRANSFER/BV/04 | Yes | . | BLE/EP/API/FILETRANSFER/RECOVERY/BI/01 | Yes | . | BLE/EP/API/FILETRANSFER/RECOVERY/BI/02 | Yes | . | BLE/EP/API/FILETRANSFER/RECOVERY/BI/03 | No | . | BLE/EP/API/FILETRANSFER/RECOVERY/BI/04 | No | . | BLE/EP/API/FILETRANSFER/RECOVERY/BI/05 | Yes | . ", "url": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#file-transfer-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#file-transfer-test-cases" },"887": { "doc": "2. Test Execution Summary", "title": "EP Metrics Test Cases", "content": "| Test Case | Executable by Customer | . | CMN/EP/EPMETRICS/METRICS/BV/01 | No | . | BLE/EP/EPMETRICS/REPORT/BV/01 | No | . | BLE/EP/EPMETRICS/REPORT/BV/02 | No | . | BLE/EP/EPMETRICS/REPORT/BV/03 | No | . | BLE/EP/EPMETRICS/UL/BV/01 | No | . | BLE/EP/EPMETRICS/DL/BV/01 | No | . | BLE/EP/EPMETRICS/CONN-BV-01 | No | . | FSK/EP/EPMETRICS/REPORT/BV/01 | No | . | FSK/EP/EPMETRICS/REPORT/BV/02 | No | . | FSK/EP/EPMETRICS/REPORT/BV/03 | No | . | FSK/EP/EPMETRICS/UL/BV/01 | No | . | FSK/EP/EPMETRICS/DL/BV/01 | No | . | LORA/EP/EPMETRICS/REPORT/BV/01 | No | . | LORA/EP/EPMETRICS/REPORT/BV/02 | No | . | LORA/EP/EPMETRICS/REPORT/BV/03 | No | . | LORA/EP/EPMETRICS/UL/BV/01 | No | . | LORA/EP/EPMETRICS/DL/BV/01 | No | . ", "url": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#ep-metrics-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#ep-metrics-test-cases" },"888": { "doc": "2. Test Execution Summary", "title": "EP Capability Test Cases", "content": "| Test Case | Executable by Customer | . | CMN-EP-CAPABILITY-REPORT-BV-01 | Yes | . | CMN-EP-CAPABILITY-REPORT-BV-02 | Yes | . | CMN-EP-CAPABILITY-REPORT-BV-03 | No | . | CMN-EP-CAPABILITY-REQUEST-BV-01 | No | . | CMN-EP-CAPABILITY-CONFIGURE-BV-01 | No | . | CMN-EP-CAPABILITY-REGISTER-BV-01 | No | . | CMN-EP-CAPABILITY-THRESHOLD-BV-01 | No | . | CMN-EP-CAPABILITY-PERIODICITY-BV-01 | Yes | . | CMN-EP-CAPABILITY-PERIODICITY-BV-02 | Yes | . | BLE-EP-CAPABILITY-THRESHOLD-BV-01 | No | . | FSK-EP-CAPABILITY-THRESHOLD-BV-01 | No | . | LORA-EP-CAPABILITY-THRESHOLD-BV-01 | No | . ", "url": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#ep-capability-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#ep-capability-test-cases" },"889": { "doc": "2. Test Execution Summary", "title": "MAC Address Rotation Test Cases", "content": "| Test Case | Executable by Customer | . | BLE/EP/BCN/MAC/BV/01 | Yes | . | BLE/EP/BCN/MAC/BV/02 | Yes | . | BLE/EP/BCN/MAC/BV/03 | Yes | . | BLE/EP/BCN/MAC/BV/04 | Yes | . | BLE/EP/BCN/MAC/BV/05 | Yes | . | BLE/EP/BCN/MAC/BV/06 | Yes | . | BLE/EP/BCN/MAC/BV/07 | No | . | BLE/EP/BCN/MAC/BV/08 | Yes | . ", "url": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#mac-address-rotation-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#mac-address-rotation-test-cases" },"890": { "doc": "2. Test Execution Summary", "title": "Power Optimization Test Cases", "content": "| Test Case | Executable by Customer | . | FSK/EP/PWR/OPT/BV/01 | Yes | . | FSK/EP/PWR/OPT/BV/02 | Yes | . | FSK/EP/PWR/OPT/BV/03 | Yes | . | FSK/EP/PWR/OPT/BV/04 | Yes | . | FSK/EP/PWR/OPT/BV/05 | Yes | . | FSK/EP/PWR/OPT/BV/06 | Yes | . | FSK/EP/PWR/OPT/BV/07 | Yes | . | LORA/EP/PWR/OPT/BV/01 | Yes | . | LORA/EP/PWR/OPT/BV/02 | Yes | . | LORA/EP/PWR/OPT/BV/03 | Yes | . | LORA/EP/PWR/OPT/BV/04 | Yes | . ", "url": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#power-optimization-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#power-optimization-test-cases" },"891": { "doc": "2. Test Execution Summary", "title": "BLE Connection Policy Test Cases", "content": "| Test Case | Executable by Customer | . | BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-01 | Yes | . | BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-02 | Yes | . | BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-03 | Yes | . | BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-04 | Yes | . | BLE-EP-CONNECTIONPOLICY-DEFAULT-BV-05 | Yes | . | BLE-EP-CONNECTIONPOLICY-LONGLIVED-BV-01 | Yes | . | BLE-EP-CONNECTIONPOLICY-LONGLIVED-BV-02 | Yes | . | BLE-EP-CONNECTIONPOLICY-LONGLIVED-BV-03 | Yes | . | BLE-EP-CONNECTIONPOLICY-LONGLIVED-BV-04 | Yes | . | BLE-EP-CONNECTIONPOLICY-OPTIMALADVERTISING-BV-01 | Yes | . | BLE-EP-CONNECTIONPOLICY-OPTIMALADVERTISING-BV-02 | Yes | . | BLE-EP-CONNECTIONPOLICY-OPTIMALADVERTISING-BV-03 | Yes | . | BLE-EP-CONNECTIONPOLICY-OPTIMALADVERTISING-BV-04 | Yes | . ", "url": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#ble-connection-policy-test-cases", "relUrl": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html#ble-connection-policy-test-cases" },"892": { "doc": "2. Test Execution Summary", "title": "2. Test Execution Summary", "content": " ", "url": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html", "relUrl": "/specifications/sidewalk-compliance-test-guide/test-execution-summary.html" },"893": { "doc": "Testing Sidewalk Outside of the United States", "title": "Testing Sidewalk Outside of the United States (U.S.)", "content": "IMPORTANT: Amazon Sidewalk is available only in the United States of America. Use of Sidewalk gateway functionality outside of the U.S. is limited to ONLY Amazon Sidewalk end device development and testing. Use of Amazon Sidewalk outside of the U.S. may violate local regulations. Developers are solely responsible for ensuring compliance with local regulations. We recommend that you consult with your local regulatory body and operate Amazon Sidewalk devices only within shielded chambers or another method that prevent wireless signals from exiting your testing environment. To enable operation outside of the U.S. for your development, you need to use a VPN router that supports OpenVPN Client functionality, in conjunction with a cloud VPN service provider. Please refer to the following sections for more details. You are also solely responsible for compliance with any local regulations regarding VPN use. In order to test Amazon Sidewalk outside of the U.S., you need to: . | Setting up an Amazon Echo as a Sidewalk Gateway in a non-US Location. | Modify an Amazon Echo for Conducted Operation. | . ", "url": "/getting-started/testing-sidewalk-outside-of-the-united-states.html#testing-sidewalk-outside-of-the-united-states-us", "relUrl": "/getting-started/testing-sidewalk-outside-of-the-united-states.html#testing-sidewalk-outside-of-the-united-states-us" },"894": { "doc": "Testing Sidewalk Outside of the United States", "title": "Testing Sidewalk Outside of the United States", "content": " ", "url": "/getting-started/testing-sidewalk-outside-of-the-united-states.html", "relUrl": "/getting-started/testing-sidewalk-outside-of-the-united-states.html" },"895": { "doc": "5. Usage Examples", "title": "5. Usage examples", "content": "One source tree, several SDK versions. Guard on sid_sdk_version.h (§1). #include <sid_sdk_version.h> #if SID_SDK_MAJOR_VERSION >= 2 #define APP_HAS_GSK 1 #include <sid_gsk_config.h> #endif . Then wrap the sid_gsk_config.h include, both assertions, the app_gsk_config definition and the .gsk_config initializer below in #if APP_HAS_GSK. Configure GSK at initialization. #include <sid_900_cfg.h> #include <sid_api.h> #include <sid_ble_link_config_ifc.h> #include <sid_error.h> #include <sid_gsk_config.h> #include <stddef.h> #define APP_GSK_IDLE_TIMEOUT_SEC 60u #define APP_GSK_ACK_MISS_THRESHOLD 6u /* sid_init() clamps silently, so assert here instead of expecting an error return. */ _Static_assert(APP_GSK_IDLE_TIMEOUT_SEC >= SID_GSK_IDLE_TIMEOUT_MIN_SEC && APP_GSK_IDLE_TIMEOUT_SEC <= SID_GSK_IDLE_TIMEOUT_MAX_SEC, \"idle_timeout_sec out of range\"); _Static_assert(APP_GSK_ACK_MISS_THRESHOLD >= SID_GSK_APP_ACK_MISS_MIN && APP_GSK_ACK_MISS_THRESHOLD <= SID_GSK_APP_ACK_MISS_MAX, \"app_ack_miss_threshold out of range\"); static const struct sid_gsk_config app_gsk_config = { .idle_timeout_sec = APP_GSK_IDLE_TIMEOUT_SEC, .app_ack_miss_threshold = APP_GSK_ACK_MISS_THRESHOLD, }; /* The first three are reached through retained pointers and must not be automatics; dev_ch is * copied. Fill all four in before calling sid_init(); the declarations below are placeholders. */ static struct sid_event_callbacks app_callbacks; static struct sid_ble_link_config app_ble_config; // .create_ble_adapter and .config must be set static struct sid_sub_ghz_links_config app_sub_ghz_config; static struct sid_end_device_characteristics app_dev_ch; static struct sid_handle *app_handle; sid_error_t app_sidewalk_init(void) { struct sid_config config = { // GSK applies to the sub-GHz link in this mask (§2.3). // A LoRa product uses SID_LINK_TYPE_1 | SID_LINK_TYPE_3 instead; nothing else here changes.link_mask = SID_LINK_TYPE_1 | SID_LINK_TYPE_2, .dev_ch = app_dev_ch, .callbacks = &app_callbacks, .link_config = &app_ble_config, .sub_ghz_link_config = &app_sub_ghz_config, .gsk_config = &app_gsk_config, // NULL selects all three defaults (§3) }; sid_error_t err = sid_init(&config, &app_handle); if (err != SID_ERROR_NONE) { return err; } err = sid_start(app_handle, config.link_mask); if (err != SID_ERROR_NONE) { (void)sid_deinit(app_handle); app_handle = NULL; } return err; } . ", "url": "/app-notes/gateway-session-key/usage-examples.html#5-usage-examples", "relUrl": "/app-notes/gateway-session-key/usage-examples.html#5-usage-examples" },"896": { "doc": "5. Usage Examples", "title": "5. Usage Examples", "content": " ", "url": "/app-notes/gateway-session-key/usage-examples.html", "relUrl": "/app-notes/gateway-session-key/usage-examples.html" },"897": { "doc": "2. Usage Guide", "title": "2. Usage Guide", "content": " ", "url": "/app-notes/location-library/usage-guide.html", "relUrl": "/app-notes/location-library/usage-guide.html" },"898": { "doc": "2. Usage Guide", "title": "2.1 Getting Started", "content": "2.1.1 Compilation Configuration . To enable the location library in your project, the following CMake variable definitions must be set: . set(SID_SDK_CONFIG_ENABLE_LOCATION 1) set(SID_SDK_CONFIG_ENABLE_WIFI 1) set(SID_SDK_CONFIG_ENABLE_GNSS 1) add_compile_definitions(SID_SDK_CONFIG_ENABLE_LOCATION=1) add_compile_definitions(SID_SDK_CONFIG_ENABLE_WIFI=1) add_compile_definitions(SID_SDK_CONFIG_ENABLE_GNSS=1) . SID_SDK_CONFIG_ENABLE_LOCATION enables the location library as part of the build. SID_SDK_CONFIG_ENABLE_WIFI and SID_SDK_CONFIG_ENABLE_GNSS are features that can be enabled if available hardware supports WiFi and GNSS scanning. Additional configurations may be required depending on the build system of the target. 2.1.2 Library Overview . The Amazon Sidewalk Location Library provides a set of APIs for configuring, initializing, and uplinking location data to the cloud. The library follows a two-phase programming model. 2.1.2.1 Initialization . The location library must be initialized using sid_location_init() after sid_init() with the appropriate handle and location configuration. | handle: A pointer to the handle returned by sid_init(). | config: Location configuration structure containing your desired location methods, effort levels, and callback function. | . Key configuration fields for the location config: . | sid_location_type_mask: Specifies which location methods to enable (BLE, WiFi, GNSS). | manage_effort: Whether to allow automatic effort level management. | max_effort: Maximum effort level the library can use. | callbacks.on_update: Your callback function to receive location results including scan payloads in the case of WiFi or GNSS. | callbacks.context: Optional user-defined context pointer passed to the callback. | stepdowns: Timeout configurations (in milliseconds) for effort level transitions (only applicable if WiFi or GNSS is enabled). | fragmentation: Settings for message fragmentation handling. Setting timeout to 0 will result in default. | auto_link_pause_resume: When true, automatically pauses Sub-GHz links (Link Type 2 and 3) during GNSS scans to avoid hardware conflicts, and resumes them after scan completion. | . 2.1.2.2 Setting Up the Location Callback . The on_update callback provides an asynchronous notification of location operation results. This callback must be implemented to handle the outcomes of location scanning and uplink operations. Parameters: . | result: Pointer to struct sid_location_result containing operation results. | context: User-defined context pointer (optional, can be NULL). | . The sid_location_result structure . The result structure contains the following fields: . | status: Operation status (enum sid_location_status): . | SID_LOCATION_LVL1_READY: BLE gateway location service is available on current gateway connection after init. | SID_LOCATION_LVL1_UNAVAILABLE: BLE gateway location service is not available on current gateway connection after init. | SID_LOCATION_SEND_ONLY_DONE: Send-only operation completed. | SID_LOCATION_SCAN_ONLY_DONE: Scan-only operation completed. | SID_LOCATION_SCAN_AND_SEND_DONE: Scan-and-send operation completed. | SID_LOCATION_RESOLVE_MSG_SENT: Resolve location message sent to gateway via sid_put_msg(). | SID_LOCATION_RESOLVE_MSG_ACK_RECEIVED: Resolve location message ack received from cloud. | SID_LOCATION_RESOLVE_MSG_TIMEOUT: Resolve location message send failed or timed out. | . | err: Error code indicating success or failure (sid_error_t). | mode: The effort mode used for this operation (enum sid_location_effort_mode). | link: The link type used for uplink (enum sid_link_type). | payload: Scan data buffer (WiFi or GNSS formatted scan results), max size SID_LOCATION_MAX_PAYLOAD_SIZE (106 bytes). | size: Size of the payload data in bytes. | raw_gnss_data: Raw GNSS scan data buffer (GNSS only). | raw_gnss_data_size: Size of the raw GNSS data in bytes. | . Configuring the callback . // Define your callback function void location_callback(const struct sid_location_result *const result, void *context) { // Handle location operation results // Check result->status, result->err, and process result->payload if applicable } static struct sid_location_config cfg = { .sid_location_type_mask = SID_LOCATION_METHOD_ALL, .manage_effort = true, .max_effort = SID_LOCATION_EFFORT_L4, .callbacks = { .on_update = location_callback, .context = &app_ctx, // Optional context pointer }, // ... other configuration fields }; . The function returns SID_ERROR_NONE in case of success. 2.1.2.3 Runtime . Location operations can be executed using sid_location_run() after the Sidewalk loop has been started (sid_start()). This API initiates location scanning and/or uplink operations. sid_error_t sid_location_run(struct sid_handle *handle, struct sid_location_run_config *config, uint32_t delay_s); . Parameters: . | handle: A pointer to the handle returned by sid_init(). | config: Struct containing the configuration for the location request. | delay_s: Delay in seconds to start scan (if applicable) and uplink data. | . Configuration fields in struct sid_location_run_config: . | mode: Effort level for this specific operation (enum sid_location_effort_mode). | type: Operation type (enum sid_location_run_type): . | SID_LOCATION_SEND_ONLY: Send-only operation. | SID_LOCATION_SCAN_ONLY: Scan-only operation. | SID_LOCATION_SCAN_AND_SEND: Combined scan and send operation. | . | buffer: Pointer to buffer for location data (uint8_t *). | size: Size of the buffer (size_t). | . The function returns SID_ERROR_NONE in case of success. If effort mode is NOT managed, SID_LOCATION_EFFORT_DEFAULT cannot be used for the mode. 2.1.2.4 Managed Effort Mode . The manage_effort configuration field controls whether the location library automatically selects and adjusts the effort level used for location operations. When manage_effort is true: . | The application can pass SID_LOCATION_EFFORT_DEFAULT as the mode in sid_location_run(). The library will use its internally tracked effort level. | The library starts at SID_LOCATION_EFFORT_L1 and automatically escalates to higher effort levels if the current level is not supported or returns insufficient results. | After a successful scan at a higher effort level (L3 or L4), the library starts a stepdown timer. When the timer expires, the effort level is reduced back toward L1 based on the configured stepdowns timeouts. | The maximum effort level the library can escalate to is bounded by max_effort. | The application can override the maximum allowed effort at runtime using sid_location_set_max_mode(), for example to limit power consumption during low-battery conditions. | . When manage_effort is false: . | The application must specify an explicit effort level (L1, L2, L3, or L4) in every call to sid_location_run(). Passing SID_LOCATION_EFFORT_DEFAULT will return an error. | No automatic escalation or stepdown occurs. The library uses exactly the effort level requested. | This mode gives the application full control over which location method is used for each operation. | . Effort Level Mapping: . | SID_LOCATION_EFFORT_L1: BLE gateway location trigger (requires opted-in gateway). | SID_LOCATION_EFFORT_L2: LoRa location trigger (requires Link Type 3 network sync). | SID_LOCATION_EFFORT_L3: WiFi scan and uplink (requires WiFi PAL). | SID_LOCATION_EFFORT_L4: GNSS scan and uplink (requires GNSS PAL). | . L2 (LoRa location trigger) can be used explicitly by passing SID_LOCATION_EFFORT_L2 to sid_location_run(). During managed effort escalation, L2 is currently skipped and the library transitions directly between L1 and L3. 2.1.2.5 De-Initialization . The location library must be deinitialized using sid_location_deinit() before calling sid_deinit(). The function takes the following parameter: . | handle: A pointer to the handle returned by sid_init(). | . The function returns SID_ERROR_NONE in case of success. For detailed API documentation including function signatures, parameters, return values, and other available APIs, please refer to the Amazon Sidewalk API Developer Guide. ", "url": "/app-notes/location-library/usage-guide.html#21-getting-started", "relUrl": "/app-notes/location-library/usage-guide.html#21-getting-started" },"899": { "doc": "2. Usage Guide", "title": "2.2 WiFi and GNSS Location Example (LR1110)", "content": "The following example shows how to enable GNSS and WiFi with the location library for use with the LR1110 shield. 2.2.1 Example Platform Configuration . // file: app_location_lr11xx_config.h #include <lr11xx_gnss_wifi_config.h> const lr11xx_gnss_wifi_config_t *get_location_cfg(void); . The GNSS configuration supports two key parameters: . Constellation Type: . | SMTC_MODEM_GNSS_CONSTELLATION_GPS — Use GPS only constellation. | SMTC_MODEM_GNSS_CONSTELLATION_BEIDOU — Use BEIDOU only constellation. | SMTC_MODEM_GNSS_CONSTELLATION_GPS_BEIDOU — Use both GPS and BEIDOU constellations. | . Scan Mode: . | SMTC_MODEM_GNSS_MODE_STATIC — Scanning mode for non-moving objects. | SMTC_MODEM_GNSS_MODE_MOBILE — Scanning mode for moving objects. | . // file: app_location_lr11xx_config.c static lr11xx_gnss_wifi_config_t gnss_wifi_config = { .constellation_type = SMTC_MODEM_GNSS_CONSTELLATION_GPS_BEIDOU, .scan_mode = SMTC_MODEM_GNSS_MODE_MOBILE }; const lr11xx_gnss_wifi_config_t *get_location_cfg(void) { return &gnss_wifi_config; } // Platform parameters setup platform_parameters_t platform_parameters = { .mfg_store_region = sid_mfg_config_get(), .platform_init_parameters.radio_cfg = (radio_lr11xx_device_config_t *)get_radio_cfg(), .platform_init_parameters.gnss_wifi_cfg = (lr11xx_gnss_wifi_config_t *)get_location_cfg(), }; . 2.2.2 Location Library Usage . // Create a location config with user supplied callback void location_callback(const struct sid_location_result *const result, void *context) { // User can pull the payload for WiFi or GNSS in result->payload // Handle different location methods based on result->mode } static struct sid_location_config cfg = { .sid_location_type_mask = SID_LOCATION_METHOD_ALL, .manage_effort = true, .max_effort = SID_LOCATION_EFFORT_L4, .callbacks = { .on_update = location_callback, .context = NULL, }, .stepdowns = { // Timeout (ms) to use before stepping down location level when using managed effort mode.l2_to_l1 = 0, .l3_to_l2 = 0, .l4_to_l3 = 0, }, .fragmentation = { // Fragmentation configurations to use for location payload uplinks .timeout_ms = 0, // 0 indicates use default timeout value .max_retries = 1, }, .auto_link_pause_resume = true, // Pause Sub-1 GHz links during GNSS scans }; // Initialize after sid_init() sid_error_t res = sid_location_init(*app_context->sidewalk_handle, &cfg); // WiFi scan and send uplink struct sid_location_run_config config = { .type = SID_LOCATION_SCAN_AND_SEND, .mode = SID_LOCATION_EFFORT_L3 }; sid_error_t res = sid_location_run(*app_context->sidewalk_handle, &config, 0); // GNSS scan and send uplink config.mode = SID_LOCATION_EFFORT_L4; sid_error_t res = sid_location_run(*app_context->sidewalk_handle, &config, 0); . 2.2.3 Fragmentation Timeout Configuration . If configuring the fragmentation timeout, the timeout_ms parameter should be considered carefully. The current cloud implementation calculates the timeout based on the total message fragmentation requirements and link type characteristics. The timeout will be calculated automatically if set to 0 and follows the following formula that mirrors the cloud algorithm to wait/reassemble fragments: . timeout = (total_size / MTU) × link_type_duration × 2 . Where: . | total_size / MTU determines the number of fragments required. | link_type_duration is the maximum time the specified link type can take to uplink one fragment. | The factor of 2 provides additional margin for retries to reach the cloud. | . Current supported link type durations: . | LoRa: Up to 5 seconds per fragment. | BLE: BLE does not utilize fragmentation for location as the MTU is large enough. These configurations will not apply. | . For example, a message requiring 4 fragments over LoRa would be: 4 × 5000 × 2 = 40000 milliseconds timeout at the cloud. Consider setting timeout_ms appropriately based on your expected use case. Using a timeout independent from the cloud fragmentation timeout may be desirable based on the use case. ", "url": "/app-notes/location-library/usage-guide.html#22-wifi-and-gnss-location-example-lr1110", "relUrl": "/app-notes/location-library/usage-guide.html#22-wifi-and-gnss-location-example-lr1110" },"900": { "doc": "2. Usage Guide", "title": "2.3 BLE-Only Location Example", "content": "The following example shows how to use the location library with just Sidewalk Network Location over BLE. // Create a location config with user supplied callback void location_callback(const struct sid_location_result *const result, void *context) { // User can get the results of the uplink here // Handle the location result based on status } static struct sid_location_config cfg = { .sid_location_type_mask = SID_LOCATION_METHOD_BLE_GATEWAY, .manage_effort = true, .max_effort = SID_LOCATION_EFFORT_L1, .callbacks = { .on_update = location_callback, .context = NULL, }, .stepdowns = { // Stepdowns are not applicable in the BLE-Only mode.l2_to_l1 = 0, .l3_to_l2 = 0, .l4_to_l3 = 0, }, .fragmentation = { // Fragmentation is not applicable in the BLE-Only mode.timeout_ms = 0, .max_retries = 0, }, .auto_link_pause_resume = false, // Not applicable for BLE-only mode }; // Initialize after sid_init() sid_error_t res = sid_location_init(*app_context->sidewalk_handle, &cfg); // Send location request after sid_start() // (requires BLE connection to opted-in gateway) struct sid_location_run_config config = { .type = SID_LOCATION_SCAN_AND_SEND, .mode = SID_LOCATION_EFFORT_DEFAULT }; sid_error_t res = sid_location_run(*app_context->sidewalk_handle, &config, 0); . ", "url": "/app-notes/location-library/usage-guide.html#23-ble-only-location-example", "relUrl": "/app-notes/location-library/usage-guide.html#23-ble-only-location-example" },"901": { "doc": "2. Usage Guide", "title": "2.4 LoRa Location Example", "content": "The following example shows how to use the location library to send a LoRa location trigger (Level 2). This requires Link Type 3 to be enabled and network synced. void location_callback(const struct sid_location_result *const result, void *context) { // result->mode will be SID_LOCATION_EFFORT_L2 for LoRa triggers // result->link will be SID_LINK_TYPE_3 } static struct sid_location_config cfg = { .sid_location_type_mask = SID_LOCATION_METHOD_BLE_GATEWAY, // L1 and L2 do not require WiFi or GNSS .manage_effort = false, // Use explicit effort level .max_effort = SID_LOCATION_EFFORT_L2, .callbacks = { .on_update = location_callback, .context = NULL, }, .stepdowns = {0}, .fragmentation = {0}, .auto_link_pause_resume = false, }; // Initialize after sid_init() sid_error_t res = sid_location_init(*app_context->sidewalk_handle, &cfg); // Send LoRa location trigger after sid_start() // (requires LoRa link to be network synced) struct sid_location_run_config config = { .type = SID_LOCATION_SEND_ONLY, .mode = SID_LOCATION_EFFORT_L2 }; sid_error_t res = sid_location_run(*app_context->sidewalk_handle, &config, 0); . ", "url": "/app-notes/location-library/usage-guide.html#24-lora-location-example", "relUrl": "/app-notes/location-library/usage-guide.html#24-lora-location-example" },"902": { "doc": "2. Usage Guide", "title": "2.5 Platform Abstraction Layers", "content": "If the device supports WiFi and GNSS scanning (levels 3 and 4), the WiFi and GNSS Platform Abstraction Layers (PALs) must be implemented and linked. Reference implementations are provided that utilize the Semtech LoRa Basics Modem middleware APIs. The implementation available in the Sidewalk MCU SDK combines both WiFi and GNSS PALs as they interface with the LoRa Basics Modem and utilize shared resources. ", "url": "/app-notes/location-library/usage-guide.html#25-platform-abstraction-layers", "relUrl": "/app-notes/location-library/usage-guide.html#25-platform-abstraction-layers" },"903": { "doc": "2. Usage Guide", "title": "2.6 Best Practices", "content": ". | Use sid_location_set_max_mode() to limit power consumption during low-power modes. | Configure appropriate stepdown timeouts based on your application requirements. | Always check return values from location API functions. | Handle different status codes in your callback function appropriately. | Allow the library to manage effort levels automatically when possible. | Consider using scan-only operations when immediate uplink is not required. | . ", "url": "/app-notes/location-library/usage-guide.html#26-best-practices", "relUrl": "/app-notes/location-library/usage-guide.html#26-best-practices" },"904": { "doc": "2. Usage Guide", "title": "2.7 Location Resolve via sid_put_msg", "content": "In addition to the explicit location APIs (sid_location_run()), the location library supports requesting location resolution as part of a user message sent via sid_put_msg(). This is done by setting the resolve_location field in the message descriptor’s TX attributes. When resolve_location is set to true, the Sidewalk stack includes a location resolve request with the user’s message. The gateway uses this to resolve the device’s location based on its own known position. This works on both BLE and LoRa links. 2.7.1 Prerequisites . | SID_SDK_CONFIG_ENABLE_LOCATION must be enabled at compile time. | sid_location_init() must have been called successfully. | The Sidewalk stack must be in SID_STATE_READY state. | . 2.7.2 Usage . // Location callback handles both explicit location and resolve_location events void location_callback(const struct sid_location_result *const result, void *context) { switch (result->status) { case SID_LOCATION_RESOLVE_MSG_SENT: // Message with location resolve request sent to gateway break; case SID_LOCATION_RESOLVE_MSG_ACK_RECEIVED: // Transport ack received from cloud (only if request_ack was set) break; case SID_LOCATION_RESOLVE_MSG_TIMEOUT: // Message send failed or timed out break; default: // Handle other location statuses (L1 ready, scan done, etc.) break; } } // Initialize location library with callback static struct sid_location_config loc_cfg = { .sid_location_type_mask = SID_LOCATION_METHOD_BLE_GATEWAY, .manage_effort = true, .max_effort = SID_LOCATION_EFFORT_L1, .callbacks = { .on_update = location_callback, }, }; sid_location_init(handle, &loc_cfg); // Send a message with location resolve request struct sid_msg msg = { .data = payload_data, .size = payload_size, }; struct sid_msg_desc desc = { .type = SID_MSG_TYPE_NOTIFY, .link_type = SID_LINK_TYPE_ANY, .msg_desc_attr = { .tx_attr = { .resolve_location = true, }, }, }; sid_error_t ret = sid_put_msg(handle, &msg, &desc); . With transport ack for confirmed delivery: . struct sid_msg_desc desc = { .type = SID_MSG_TYPE_NOTIFY, .link_type = SID_LINK_TYPE_ANY, .msg_desc_attr = { .tx_attr = { .resolve_location = true, .request_ack = true, .num_retries = 3, .ttl_in_seconds = 60, }, }, }; sid_error_t ret = sid_put_msg(handle, &msg, &desc); // on_update callback will report SID_LOCATION_RESOLVE_MSG_ACK_RECEIVED on success // or SID_LOCATION_RESOLVE_MSG_TIMEOUT on failure . 2.7.3 Delivery Status Notifications . The location library notifies the application of the resolve message delivery status through the on_update callback registered during sid_location_init(). The following status values are used: . | SID_LOCATION_RESOLVE_MSG_SENT: The message with the location resolve request was successfully sent to the gateway (link-layer confirmed). | SID_LOCATION_RESOLVE_MSG_ACK_RECEIVED: The transport acknowledgement was received from the cloud, confirming end-to-end delivery. This status is only reported when request_ack is set to true in the message descriptor. | SID_LOCATION_RESOLVE_MSG_TIMEOUT: The message send failed or timed out (no acknowledgement received within the configured TTL). | . 2.7.4 Error Handling . sid_put_msg() returns the following errors specific to resolve_location: . | SID_ERROR_INVALID_STATE: Location library is not initialized (sid_location_init() not called). | SID_ERROR_NOSUPPORT: SID_SDK_CONFIG_ENABLE_LOCATION is not enabled. | . ", "url": "/app-notes/location-library/usage-guide.html#27-location-resolve-via-sid_put_msg", "relUrl": "/app-notes/location-library/usage-guide.html#27-location-resolve-via-sid_put_msg" },"905": { "doc": "WiFi Scan (L3)", "title": "WiFi Scan (L3)", "content": " ", "url": "/app-notes/location-library/wifi-scan-l3.html", "relUrl": "/app-notes/location-library/wifi-scan-l3.html" },"906": { "doc": "WiFi Scan (L3)", "title": "Introduction", "content": "WiFi scan location has the device scan for nearby WiFi access points and uplink the access points it found (their BSSIDs and signal strengths). Amazon Sidewalk resolves coordinates from that scan against an access-point database. ", "url": "/app-notes/location-library/wifi-scan-l3.html#introduction", "relUrl": "/app-notes/location-library/wifi-scan-l3.html#introduction" },"907": { "doc": "WiFi Scan (L3)", "title": "How the Cloud Resolves the Fix", "content": "Amazon Sidewalk forwards the scanned access points (MAC address and signal strength per access point) to the AWS IoT Wireless GetPositionEstimate service, which returns a position estimate. If the scan cannot be resolved, AWS IoT Wireless reports that it could not solve a position. This is deterministic for a given scan: the same set of access points will not resolve on a retry, so no location is produced for that scan. ", "url": "/app-notes/location-library/wifi-scan-l3.html#how-the-cloud-resolves-the-fix", "relUrl": "/app-notes/location-library/wifi-scan-l3.html#how-the-cloud-resolves-the-fix" },"908": { "doc": "WiFi Scan (L3)", "title": "Accuracy and Constraints", "content": ". | Resolution depends on the scanned access points being present in the access-point database; unknown or sparse access points do not resolve. | Accuracy depends on how many known access points were seen and how densely the area is mapped. | . ", "url": "/app-notes/location-library/wifi-scan-l3.html#accuracy-and-constraints", "relUrl": "/app-notes/location-library/wifi-scan-l3.html#accuracy-and-constraints" },"909": { "doc": "4. Line PC Setup", "title": "4. Line PC Setup", "content": "This chapter is performed by the CM on each line PC. | Install sid-mfg-tool. On macOS or Linux, run: | . curl -fsSL https://github.com/amzn/sid-mfg-tool/releases/latest/download/install.sh | sh . On Windows, download the .exe and verify its SHA-256 checksum. Verify the installation with sid-mfg-tool --version. If the line uses RTT, also install the SEGGER J-Link Software and Documentation Pack from segger.com in its standard location. The tool drives the J-Link probe through the JLinkARM library of that pack, which is not bundled with the tool. The tool and the Factory Diagnostic Firmware are version-paired: deploy the combination listed in the release notes. | Run the YubiHSM connector. The YubiHSM connector communicates with the HSM, as in the existing mass production flow: | . yubihsm-connector -l 127.0.0.1:12345 curl http://127.0.0.1:12345/connector/status . | Configure the tool (once per line PC). Run sid-mfg-tool configure. The tool writes the non-secret settings to ~/.config/sid-mfg-tool/config.toml and the secrets (DAK PIN, LWA client credentials, application server public key) to ~/.config/sid-mfg-tool/secrets.toml with file mode 0600. LWA tokens are cached in ~/.cache/sid-mfg-tool/tokens.json, also with mode 0600. The prompts are described in the following table. | . | Prompt | Value | . | Product name | The product tag from the HSM handoff (Section 3.5). It must match the label of the DAK in the HSM | . | Device type | The DeviceTypeId vended by Amazon with the HSM (Section 3.5) | . | Advertised Product ID (APID) | From the device profile (Section 3.4) | . | HSM signing stage | prod (or preprod) | . | HSM connector URI | For example http://127.0.0.1:12345 | . | Default transport | uart (serial port) or rtt (SEGGER RTT through a J-Link probe). The device commands use this transport unless --transport is given | . | J-Link device name of the target MCU (rtt only) | The J-Link device name of the MCU, stored as jlink_device, as listed by the SEGGER J-Link software | . | IoT Wireless destination | The destination created in Section 3.4. It must already exist | . | Device creation mode | immediate (default) or bulk | . | S3 bucket and import role (bulk only) | The S3 bucket that receives the SMSN CSV for the bulk import task, and the IAM role ARN the import task uses to read it (Section 3.4) | . | Control log delivery | api (default) or sftp. sftp requires device creation mode bulk | . | SFTP upload host and username, SFTP feedback host and username, SSH private key path (sftp only) | The SFTP account used for control log delivery. Uploads go to /To_Amazon and acknowledgements are read from /From_Amazon. The host key must already be in known_hosts, and the key file must have mode 0600 | . | Security level | security-level-high (default, stored as high) or security-level-low (stored as low) in the security_level key. It must match the SDK variant of the production firmware (Section 7.1) | . | AWS profile name | The named AWS CLI profile from Section 3.4 | . | Audit log directory | Accept the default (~/.sid-mfg-tool/audit) | . | HSM PIN (secret) | The DAK PIN, decrypted from Amazon’s encrypted email (Section 3.5) | . | LWA client_id and client_secret (secrets) | From your LWA security profile (Section 3.2) | . | App key (secret) | The application server public key (64 hexadecimal characters) from your device profile (Section 3.4) | . The retention_days setting can only be set in the configuration file. It controls how long processed artifacts are kept (default 90 days). At the end of configure, verify the AWS account that the tool prints and complete the browser login. The tokens are cached and refreshed automatically. To review the configuration at any time, run sid-mfg-tool configure --show. High-volume and offline lines. Two settings allow the cloud steps to be batched: . | Device creation | Control log delivery | Line PC needs network access | Command sequence | . | immediate (default) | api | Yes | device onboard for each device | . | bulk | api | For the control log upload only | device provision, then bulk-provision run, then device register | . | bulk | sftp | No | device provision, then control-log upload, then bulk-provision run, then device register | . ", "url": "/app-notes/registration-over-wire/workstation-setup.html", "relUrl": "/app-notes/registration-over-wire/workstation-setup.html" } }