5.5 Amazon Sidewalk Endpoint connection modes

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:

1. Link Connection Establishment Phase, which establishes the connection with a chosen Amazon Sidewalk Gateway;
2. Amazon Sidewalk Connection Establishment Phase, which establishes the connection with the Amazon Sidewalk Cloud; and
3. 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

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:

1. 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.

2. 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.

3. 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.

4. Profile D: Reserved for future use.

Connection profiles in SubG-CSS mode are defined by two parameters:

1. Number of downlink opportunities - dl_opp_nb - the parameter indicates how many downlink opportunities are available after the last uplink transmission.
2. 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:

1. 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.
2. Downlink opportunities separation - dl_separation - the value is constant and is not configurable.

Table 5.2 Profile A parameters

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

1. Number of downlink opportunities - dl_opp_nb - the profile has infinite downlink opportunities which are scheduled continuously with downlink opportunity separation.
2. 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:

1. 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)
2. 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:

1. RX window count - rx_window_count - the profile operates in continuous RX mode with value 0xFF (SID_RX_WINDOW_CONTINUOUS).
2. Downlink opportunities separation - dl_separation - the value is 0 (SID_LINK3_RX_WINDOW_SEPARATION_CONTINUOUS), meaning continuous reception.

Table 5.4 Profile C parameters

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.

---