Connect Stack Layers#

Physical Layer#

Connect uses what was configured in the radio configurator. For more information on how to use this tool, see AN1253: EFR32 Radio Configurator Guide for Simplicity Studio 5.

However, there are some restrictions when using the radio configurator used with Connect:

• Connect will only use the first configured protocol.

• You should use the Connect profile. This will remove some frame configuration options, because Connect needs the frame's length configuration to be 802.15.4 compatible.

• Above 500kbps bitrate, the hardware-based address filter (which is required by Connect) is not guaranteed to work. Using higher bitrates are only recommended after PER testing.

Connect comes with several preconfigured PHY setups, designed to work within regional regulations as illustrated in the following figure.

1. FCC Regulations, DSSS, and Frequency Hopping

FCC requires steps be taken to "widen" the band that a given application occupies. Connect supports Direct Sequence Spread Spectrum (DSSS) and Frequency-hopping Spread Spectrum (FHSS) to comply with this requirement. Generally, Silicon Labs recommends the use of DSSS.

DSSS is supported by the hardware and requires no extra communication to work. The MAC layer can be fully 15.4-compatible, and

15.4 defines some standard DSSS PHY setups. On the other hand, frequency hopping requires non-15.4-compatible MAC commands and regular message exchange between devices to keep them synchronized.

Setting up a DSSS radio configuration requires some RF knowledge, but Silicon Labs provides three preconfigured setups for 2.4GHz and 915MHz. Frequency hopping does not require a special radio configuration, only a well configured channel spacing and number of channels.

It is possible to set up frequency hopping with a narrower band (and lower bitrate) radio configuration which could yield better sensitivity.

MAC Layer#

The Connect MAC layer is based on RAIL's IEEE 802.15.4-specific API, which provides the interface to the hardware implementation for

• Address filtering

• ACK

• CSMA/CA (Carrier-Sense Multiple Access with Collision Avoidance)

• Data Request/frame pending bit setup

Above the RAIL API, Connect implements an 802.15.4-like MAC. This section describes the implemented features and highlights the deviations from the IEEE 802.15.4-2011 standard.

Acknowledgments#

Acknowledgments are transmitted according to the IEEE 802.15.4 specification. However, acknowledgement timing and retransmit count can deviate from the standard in these ways:

• The turnaround time; that is, the delay between the end of reception and the start of transmission of the acknowledgement—is always 12 symbol time.

• The timeout until a device waits for an ACK packet can be configured with the definition of EMBER_MAC_ACK_TIMEOUT_MS, or with the ackTimeout argument of emberSetMacParams(). The default is 25ms. Silicon Labs recommends fine tuning this parameter after choosing a PHY.

• The number of transmission retries from the sender if it does not receive an ACK can be configured with the maxRetries argument of emberMacSetParams(). The default is 3 defined as a maximum of 4 transmits: 3 retries after the first transmit.

CSMA/CA#

The CSMA/CA parameters can be configured using emberSetMacParams(). The defaults are documented in the API documentation and are essentially the parameters recommended by IEEE 802.15.4 for the 2.4GHz OQPSK PHY. You can also configure the threshold under the Stack Common component configuration.

Device Types#

Devices type is determined based on which API is used to join the network. Some device types are not available in every mode.

Coordinator (Extended Star and MAC Mode)#

Coordinator forms the network with the API emberFormNetwork() or emberMacFormNetwork(). In Extended Star mode, the coordinator performs various tasks to maintain the network: It allocates addresses to joining devices, maintains routing tables, and so on. In MAC mode, it has no specific role, but it will report itself as PAN coordinator. The coordinator always has the short address 0x0000. A coordinator requires the Parent support component.

Range Extender (Extended Star only)#

Range extender is a device that supports routing between the coordinator and end devices. It joins the network using emberJoinNetwork() with the nodeType set to EMBER_STAR_RANGE_EXTENDER. A range extender requires the Parent support component.

End Devices and Sleepy End Devices (Extended Star and Direct Mode only)#

End device is a simple device that can communicate in the network. A sleepy end device is the same, but it turns off its radio when in idle so it can only receive messages through message polling.

End devices join the network using emberJoinNetwork() or emberJoinNetworkExtended() in Extended Star mode and using emberJoinCommissioned() in Direct mode.

All of these have the nodeType parameter which selects the actual device type:

• EMBER_STAR_END_DEVICE

• EMBER_STAR_SLEEPY_END_DEVICE

• EMBER_DIRECT_DEVICE

MAC Mode Device and Sleepy MAC Mode Device (MAC Mode only)#

A MAC mode device can have any role in an 802.15.4 network. A sleepy MAC mode device is the same, but it turns off its radio when in idle, so it can only receive messages through message polling. (This clears the "Receiver On When Idle" bit in the association request command.)

MAC mode devices can join the network with either emberJoinNetwork(), emberJoinNetworkExtended(), or emberJoinCommissioned().

All of these have the nodeType parameter which selects the actual device type:

• EMBER_MAC_MODE_DEVICE

• EMBER_MAC_MODE_SLEEPY_DEVICE

MAC Layer in Extended Star and Direct Mode#

Extended Star and Direct modes use the same MAC implementation, but with a few differences that will be highlighted in the following sections.

Messaging and Addressing#

In MAC mode, Silicon Labs Connect supports all addressing modes available in IEEE 802.15.4. The application can only send data frames. The stack still handles MAC commands, beacons, and ACKs.

Short Address Allocation (Extended Star Mode only)#

Short address allocation is always handled by the coordinator. By default, the coordinator starts assigning addresses with 0x0001. This can be modified in the Parent support component, to reserve part of the address space for manual commissioning.

The allocated address increments from the first assigned address with each new access request. The last assigned address is stored in a token (nonvolatile memory), so the uniqueness of the assigned addresses is preserved even if the coordinator restarts. The coordinator cannot allocate an address which it had previously assigned to a device. Therefore, after it has allocated the (largest) address— 0xFFFD—it will not accept any additional access requests from any device.

Security#

In these modes, Connect supports security very similar to 802.15.4's mode-5 security, but it is not fully-compliant. It uses different endianness and calculates the nonce slightly differently, but these do not impact the security itself.

The frame counter is stored in a token (which is a persistent element Connect provides through one of multiple available non-volatile memory libraries). To further reduce wear on the flash memory, the frame counter is only saved after every 16384 (0x4000) increments. To ensure the frame counter is incremented even after the exact value in RAM is lost by a device reset or power cycle event, at boot Connect will increment the base value stored in the persistent token (which will forfeit/skip any unused remaining increments of the original 16384 in the previous base value).

Non-Standard Command Messages#

Connect uses some non-standard MAC commands:

• 0x7D: Extended association request. Uses secure communication if the requester supports it. For more information, see section Device Joins with Address Selected on the Joining Device.

• 0x7E: Frequency hopping info request. For For more information, see section Frequency Hopping (Extended Star and Direct Mode only).

• 0x7F: Frequency hopping info. For For more information, see section Frequency Hopping (Extended Star and Direct Mode only).

Association (Extended Star Mode only)#

Device Joins Range Extender#

In Extended Star mode, the coordinator allocates the short addresses. So, if a device joins a range extender, the range extender must request a short address from the coordinator. For this, the range extender uses network layer command frames. (For more information, see Network Layer Commands.) This process is depicted in the following figure.

Device Joins Coordinator#

When a (sleepy) end device joins a coordinator, the association process is almost the same as the standard IEEE 802.15.4. See Using Silicon Labs Connect v3.x with IEEE 802.15.4 for a short description. There are, however, are some differences in timing as follows:

• 500ms delay between association request and data request commands is added, as seen in the above figure.

• The active scan duration—the amount of time a joining device is waiting for beacons—is configured according to IEEE 802.15.4 and calculated from symbol time. However, on low-symbol rate PHYs this can slow down the join process significantly. You can configure it with emberSetActiveScanDuration().

Device Joins with Address Selected on the Joining Device#

The joining device can select its own short address. Because the standard association request does not have this requested address field, Connect uses extended association request for this feature. In this case, the joining device is responsible for the uniqueness of the address—the coordinator will not check it. In every other detail, the join process is the same.

If the association was requested from a range extender, it still sends a short address request to the coordinator with the requested address. Although this is basically always approved by the coordinator, this allows for the ability to handle address allocation with address request differently in the future.

Joining Device Receives Multiple Beacons#

If a joining device receives multiple beacons during the join process, it will

• Join to the coordinator, if it received a beacon from a coordinator.

• Join to the first range extender to respond, if a range extender responded.

Note: This only applies to end devices. A range extender can only join to the coordinator.

Selective Joining#

In some cases it is required to select the coordinator/range extender on the joining device. This is enabled in Connect with the selective join payload, configurable with the emberSetSelectiveJoinPayload() and emberClearSelectiveJoinPayload() APIs. When enabled, the association request of the joining device will be only accepted on coordinators and range extenders that have the same join payload configured as the joining device. Because the standard association request does not allow this field, Connect will use extended association requests, even when the address was not requested.

Commissioning (Direct Mode only)#

When commissioning, a device sets up all its parameters (PAN ID, short address, and device type) without any communication to the network. This means that the commissioning device is responsible for ensuring the selected short address is unique.

MAC Layer in MAC Mode#

Messaging and Addressing#

In MAC mode, Silicon Labs Connect supports all addressing modes available in IEEE 802.15.4. The application can only send data frames. The stack still handles MAC commands, beacons, and ACKs.

Short Address Allocation#

All non-sleepy MAC mode devices handle short address allocation. They assign random addresses and the network is responsible for detecting address duplication.

Security#

MAC mode supports the same mode-5 security as other modes of the Connect stack. Security requires the long address of the source to decode a message, so the application should provide address translation when short addressed frames are received. This is handled through a lookup table that can be populated and updated through the API emberMacAddShortToLongAddressMapping().

Association#

Association in MAC mode implements the association described in IEEE 802.15.4. For a short description, see Using Silicon Labs Connect v3.x with IEEE 802.15.4. A MAC mode end device can join any other non-sleepy MAC mode device (coordinator or PAN coordinator).

Extended Association#

The API emberJoinNetworkExtended() works differently compared to Extended Star or Direct mode. It still sends out the standard association request, but it can be only used to request the short address 0xFFFE, which means that the device wants to communicate to the network using its long address.

Commissioning#

When commissioning, a device sets up all of its parameters (PAN ID, short address, and device type) without any communication to the network. This means that the commissioning device is responsible for selecting a unique short address.

Frequency Hopping (Extended Star and Direct Mode only)#

Frequency hopping allows two nodes to communicate while rapidly switching channels in a pseudo-random fashion, thereby reducing channel interference. Frequency hopping is implemented in a client-server model, in which the server coordinates the hopping. The server and the clients must be in the same PAN and must be programmed with the same frequency hopping parameters. These parameters are highlighted with bold text in the following sections.

Frequency Hopping Messages#

Frequency hopping is implemented with the non-standard Frequency hopping info and Frequency hopping info request MAC command messages. A client receiving a Frequency hopping info message will result in synchronization between the server and the client, while Frequency hopping info request requests the info message from the server. After a sleepy end device sends a request, it will wait for an answer, similarly to data polls. These messages are sent without CSMA/CA.

Hopping Sequence#

The hopping sequence is generated when the hopping system is started by the application using emberFrequencyHoppingStartServer() or emberFrequencyHoppingStartClient(). By default, all channels are used between Start channel and End channel and you can remove channels using emberFrequencyHoppingSetChannelMask() before starting the system. Next, the channels are reordered using a pseudo-random sequence generator seeded by the Channel Sequence Generation Seed component parameter as shown in the following figure.

The radio will use these channels in a fixed order for a period specified by Channel duration time—a defining a channel slot. At the start and end of these channel slots, transmission is not allowed for the time configured with Channel Guard Duration to avoid communication problems caused by slightly desynchronized devices as shown in the following figure.

Full Synchronization#

When a client wants to join to an already frequency hopping server (or if a client loses the synchronization), the client starts the full synchronization process: It will start sending Frequency hopping info request messages quickly hopping through the channels in reverse order until it receives a Frequency hopping info, at which point the client is resynchronized with the server. Full synchronization works the same if the client is a sleepy end device as shown in the following figure.

If the client loops through all the channels five times without receiving Frequency hopping info, it will call emberStackStatusHandler() with EMBER_MAC_SYNC_TIMEOUT.

Passive Synchronization#

Passive synchronization is used to keep non-sleepy devices in sync. The server periodically broadcasts a Frequency hopping info message and if a client receives it, the client will adjust its synchronization. The period of these broadcast is configured with Server Broadcast Info Period. However, the period is not exact. The message will always be sent in the middle of the next slot after the period is passed to reach clients that are out of sync by as much as half a Channel duration as shown in the following figure.

If a non-sleepy client does not receive Frequency hopping info messages for Client synchronization timeout, it will call emberStackStatusHandler() with EMBER_MAC_SYNC_TIMEOUT.

Active Synchronization#

Active synchronization is used to keep sleepy devices in sync. If a sleepy client has not received Frequency hopping info message for Client resync period, the next transmit attempt will be preceded by an active synchronization: The client will send a Frequency hopping info request in the middle of the next slot as shown in the following figure.

If the client receives no Frequency hopping info message upon its request, it will trigger a full synchronization.

Server Advertising#

When the server starts, it will start with an advertising period. The goal of this period is to resynchronize clients that are already running. This could happen, for example, if the server restarted after a watchdog reset. This mode is basically the inverse of full synchronization: The server quickly hops through all channels in reverse order, sending a Frequency hopping info message on each channel. The server loops through all channels Server advertisement sequence count times as shown in the following figure.

In the above figure, Client B received the first Info message sent, but Client A did not (for example, because of some interfering signal). Therefore, Client A only synchronizes the next time it matches it channels with the server.

Summary of Component Parameters#

The parameters for the components are as follows:

• Channel Sequence Generation Seed: The seed number which generates the pseudo-random sequence.

• Start channel: The start or minimum of the pseudo-random sequence channel range. Configured inclusively, that is, start channel will be in the sequence.

• End channel: The end or maximum of the pseudo-random sequence channel range. Configured inclusively, that is, end channel will be in the sequence.

• Channel Duration: How long in milliseconds the nodes will spend on each channel.

• Channel Guard Duration: How long in milliseconds the nodes will not transmit when entering and leaving a channel 'slot'. Transmit requests during this time from the application will be deferred until the guard duration is over. The guard duration is inside the channel duration. For example, with 400ms channel duration and 25ms guard duration, a node changes channels, waits 25ms, transmits for 350ms, waits 25ms, and then changes channels again.

• Server Broadcast Info Period: The time in milliseconds after which the server broadcasts the index number of the channel it is on and how long it has been on it. This gives clients that have gotten out of sync with the server the opportunity to re-sync.

• Client Resync Period: The time in seconds after which a sleepy client requests server information if no re-sync happened.

• Client synchronization timeout: The time in seconds after which a non-sleepy client stops and reports hopping sync failure if no re-sync happened.

• Server advertisement sequence count: The number of times the server loops through all the channels at startup to re-synchronize already running children.