8.3 Join and Network Sync Procedures

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:

1. notifies the Amazon Sidewalk Cloud that the Endpoint is active and connected through Sidewalk Relay or Sidewalk Relays;
2. notifies the Amazon Sidewalk Cloud that it is using a chosen communication mode, profile and parameters indicated through the payload of Join-Req Message;
3. 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:

1. The Endpoint transmits the SET_JOIN_REQ command.
2. The Endpoint waits for the RESP_JOIN_REQ:
   1. if the response from the cloud is received by the Endpoint then it finishes the commands exchange successfully
   2. if the response from the cloud is not received by the Endpoint then
      1. 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
      2. if the number of SET_JOIN_REQ commands sent subsequently is equal to three then go to bullet 3
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.

---