Beacon Enabled Mode

Introduction

The IEEE 802.15.4 specification defines beacon-enabled mode of operation where the personal area network (PAN) coordinator device transmits periodic beacons to indicate its presence and allows other devices to perform PAN discovery and synchronization. The beacons provide beacon-related information and also mark the start of the new superframe. The beacon has information on the superframe specification, which helps the device intending to join the network to synchronize timing and network related parameters before starting the join process. The beacon helps the existing device in the PAN to maintain the network synchronization. The superframe is divided into an active and an inactive period. During the active period, devices communicate using the CSMA-CA procedure except in 863MHz band where LBT is used for channel access. The inactive period allows the devices in the network to conserve energy.

Background Information

This section gives an outline of how IEEE beacon mode works. If you are already familiar with the spec description you can skip this section.

Figure 52. shows the beacon progression. Here is a chronological overview of the beacon superframe:

../_images/superframe-progression.png

Figure 52. Beacon Superframe

  1. The coordinator transmits the beacon

  2. Contention assessment period (CAP). In this period, nodes can transmit messages using the CSMA-CA mechanism. This mechanism allows any node to try to transmit a message at any time, the node order is not set.

  3. Contention free period (CFP). The contention free period contains assigned slots where only an assigned node can transmit. Please note the TI 15.4-Stack does not implement CFP functionality.

  4. The coordinator can go into an inactive period. During this period all the devices in the network sleep.

  5. After the inactive period the coordinator transmits the next beacon and the cycle is repeated.

Table 3. Stages of the beacon superframe

Stage

Collector action

Node action

Beacon

Transmit beacon

Optional Rx or sleep

CAP

Rx

Optional: Use CSMA-CA to transmit package

CFP

Rx

If applicable: Transmit package in alloted slot

Inactive period

Sleep

Sleep

Beacon Interval

The time between two Beacons is called the beacon interval. According to the IEEE standard it is not possible to directly configure the beacon interval. However, by tweaking other beacon enabled mode settings the beacon interval can be adjusted.

  • Beacon order (BO)

  • Superframe order (SO)

  • Superframe duration which in turn is decided by:
    • Slot duration

    • Number of slots in the superframe

    • Symbol rate

Calculations for the superframe duration is found in the Network Association section.

On the coordinator application, the BO is used to configure the interval between beacon transmissions. On the nodes, it is used to set the beacon order during the joining phase, after the passive scan of beacons and after the device makes the decision on which coordinator to join. The BO must be set to the same value on the coordinator and the nodes. BO is a number between 0 and 15.

The SO configures the length of the active portion of the superframe. On the nodes, this setting is used to set the superframe order during the joining phase, after the passive scan of beacons and after the device makes the decision on which coordinator to join. The SO must be set to the same value on the coordinator and the nodes. SO is a number between 0 and 15.

For developers who wish to configure a beacon enabled network with a target beacon interval, the recommended work flow is outlined below:

  1. Configure all parameters except the BO

    • PHY and symbol rate

    • Superframe order

    • Security settings

  2. Experiment with different BO settings and calculate or measure the resulting beacon order

    • The beacon interval can be calculated based on equations in the IEEE standard

    • Choosing different BO values, the beacon interval can be measured by sniffing the TI 15.4-Stack network.

Beacon Payload

Developers can add a payload to the beacon, to achive this a developer can call use the following code block.

ApiMac_mlmeSetReqUint8(ApiMac_attribute_beaconPayloadLength, sizeOfBuf); //set the beacon payload length
ApiMac_mlmeSetReqArray(ApiMac_attribute_beaconPayload, buf); // set the beacon payload

Attention

The beacon size cannot exceed 56 bytes.

Network Operations

This section describes critical network operations for the beacon-enabled mode of operation.

Network Start-Up

A network is always started by a fully functional device after performing a MAC sublayer reset. The network operates on a single channel (frequency hopping is not available in this configuration, although frequency agility may be implemented by application-specific means). To select the most optimal channel of operation, the fully functional device (before starting the network) can optionally scan for the channels with the least amount of radio interference by first performing the energy-detect scan to identify the list of channels with the least amount of RF energy. When a list of channels is identified, the fully functional device can (optionally) perform active scan to find the channel with the least number of active networks. When the channel with the least RF energy and lowest number of active networks is selected, the PAN coordinator must set its short address (the PAN identifier) beacon payload and turn on the associate permit flag. The network starts upon the following actions:

  • Call to ApiMac_mlmeStartReq() API

    • With the PAN coordinator parameter set to TRUE

    • With the desired superframe configuration

    • Coordinator realignment parameter set to FALSE

Figure 53. shows the interaction between the application and TI 15.4-Stack to start the beacon-enabled network by the PAN coordinator.

../_images/fig-beacon-mode-network-start-up-sequence.png

Figure 53. Beacon Mode Network Start-Up Sequence

Network Association

A device that is intended to join the beacon-enabled network must first perform a passive channel scan. The results of the channel scan can then be used to choose a suitable network. Following the selection of an association network, the application should set the following PIB items:

  • ApiMac_attribute_beaconOrder

    • Set to the value received in the beacon superframe specification of the chosen PAN

  • ApiMac_attribute_superframeOrder

    • Set to the value received in the beacon superframe specification of the chosen PAN

  • ApiMac_attribute_panId

    • PAN identifier of the PAN

  • ApiMac_attribute_coordShortAddress

    • Short address of the PAN coordinator

The next step is to perform beacon synchronization to track the beacon and to detect any pending messages. Synchronization is requested by using the ApiMac_mlmeSyncReq() API call and setting the following parameters:

  • Channel

  • PHY identifier

  • Channel page

  • Setting track beacon to TRUE

To acquire beacon synchronization, the device searches for the maximum time calculated as follows:

aBaseSuperframeDuration* (2n + 1), where n is the value of the beacon order

and

aBaseSuperframeDuration = aBaseSlotDuration X aNumSuperframeSlots = 60*16 = 960 symbols

Note that aBaseSlotDuration and aNumSuperframeSlots are constants. Refer to the IEEE 802.15.4 specification for their definition.

The device must to wait for the previously stated time period for the synchronization process to complete. Alternatively the device can turn off the Auto Request by setting the ApiMac_attribute_autoRequest attribute item to FALSE, which forces the MAC sublayer to send the beacon notification to the upper layer. If the application receives beacon notification indications for the normal beacon and no sync loss indication, it is a good indication that the device has synchronized with the coordinator beacons. TI recommends waiting for at least two beacon notifications before turning on the Auto Request.

When the device is synchronized to the network and is tracking the beacon, the application can perform the network association. The ApiMac_mlmeAssociateReq() API call is used to send the association request message to the coordinator. The association process is successful when the application receives the association confirmation.

Figure 54. shows a device performing the network association.

../_images/fig-beacon-mode-associate-sequence.png

Figure 54. Beacon Mode Device Association Sequence

Data Exchange

The sequence diagram in Figure 55. depicts the various direct data transactions between an always-on (mains powered) device and a coordinator in a beacon-enabled network.

../_images/fig-beacon-mode-direct-data-sequence.png

Figure 55. Beacon Mode Direct Data Exchange Sequence

The sequence diagram in Figure 56. depicts the indirect data transaction in a beacon-enabled network.

../_images/fig-beacon-mode-indirect-data-sequence.png

Figure 56. Beacon Mode Indirect Data Exchange Sequence

Maintaining a Connection for End Nodes

All devices operating on a beacon-enabled PAN must acquire beacon synchronization with a coordinator. Synchronization is performed by receiving and decoding the beacon frame information. The beacon frame contains the super- frame specification which lets the device sync its timing information with the coordinator and detect any pending messages.

During the network association phase, the end device calls the ApiMac_mlmeSyncReq() API with the trackBeacon parameter set to TRUE to acquire beacon and keep track of it (see Figure 57. ). With the track beacon set to TRUE, the MAC sublayer shall enable its receiver at a time before the next expected beacon frame transmission. If the number of consecutive beacons missed by the MAC sub layer reaches the maximum allowed (four beacons), the TI 15.4-Stack makes a callback ApiMac_syncLossIndFp_t() with a status of ApiMac_status_beaconLoss to the application. The application tries to resynchronize with the coordinator by calling ApiMac_mlmeSyncReq() with trackBeacon set to TRUE.

../_images/fig-beacon-mode-sync-loss-sequence.png

Figure 57. Beacon Mode Sync Loss Sequence

Network Disassociation

This section describes three scenarios. The first two scenarios are initiated by the coordinator (one for the mains powered end device and the other for the battery powered end device). In the third scenario, the end device disassociates itself from the network.

When the coordinator application requires an associated device to leave the network, the coordinator application requests that TI 15.4-Stack sends a disassociation notification command by using the ApiMac_mlmeDisassociateReq() call. If the txIndirect parameter is set to TRUE, the TI 15.4-Stack sends the disassociation notification command to the device using indirect transmission; then, the disassociation notification command is added to the list of pending transactions stored on the coordinator and pulled by the device using a data request command (see Figure 58.).

../_images/fig-beacon-mode-indirect-disassociation-sequence.png

Figure 58. Beacon Mode Coordinator Initiated Indirect Disassociation Sequence

If the txIndirect parameter is set to FALSE, TI 15.4-Stack sends the disassociation notification command frame to the device using direct transmission (see Figure 59.). The TI 15.4-Stack layer at the coordinator makes a callback to the application using the registered function pointer of type ApiMac_disassociateCnfFp_t after completion of the disassociation. TI 15.4-Stack at the end-device makes a callback to the application using the registered function pointer of type ApiMac_disassociateIndFp_t on reception of the disassociation notification command frame from the coordinator.

../_images/fig-beacon-mode-direct-disassociation-sequence.png

Figure 59. Beacon Mode Coordinator-Initiated Direct Disassociation Sequence

The end-device application can also initiate the disassociation process as described in Figure 60..

../_images/fig-beacon-mode-device-disassociation-sequence.png

Figure 60. Beacon Mode Device-Initiated Disassociation Sequence

Stack Configuration Knobs

Attribute Configuration

Table 4. lists the attribute configuration for beacon mode.

Table 4. Attribute Configuration for Beacon Mode

Name

Type

Range

API Number

Description

ApiMac_attribute_associatePermit

bool

TRUE, FALSE

0x41

TRUE if a coordinator is currently allowing association

ApiMac_attribute_autoRequest

bool

TRUE, FALSE

0x42

TRUE if a device automatically sends a data request if its address is listed in the beacon frame

ApiMac_attribute_beaconOrder

uint8

0–15

0x47

How often the coordinator transmits a beacon

ApiMac_attribute_RxOnWhenIdle

bool

TRUE, FALSE

0x52

TRUE if the MAC enables its receiver during idle periods

ApiMac_attribute_superframeOrder

uint8

0–15

0x54

This specifies the length of the active portion of the superframe.

The ApiMac_attribute_associatePermit is used by the coordinator application to indicate to the joining devices whether it allows association or not. Setting this attribute item to TRUE by the coordinator indicates to the joining devices in its beacon frame that the coordinator application allows association.

The ApiMac_attribute_RxOnWhenIdle, if set to TRUE, enables the receiver during the idle period.

The ApiMac_attribute_RxOnWhenIdle, if set to TRUE, enables the receiver during the idle in the contention period of the superframe. The coordinator application sets this item to TRUE.

The ApiMac_attribute_beaconOrder item is used by the device application to set the beacon order during the joining phase, after the passive scan of beacons, and after the device makes the decision on which coordinator to join. This attribute shall be set to the selected coordinators beacon order value.

The ApiMac_attribute_superframeOrder item is used by the device application to set the superframe order during the joining phase, after the passive scan of beacons, and after the device makes the decision on which coordinator to join. This attribute shall be set to the selected coordinators beacon order value.

Attention

The ApiMac_beaconType_enhanced beacon type is not supported on 15.4 projects and will not affect project functionality if used.

Configuration Constants

TI 15.4-Stack uses a structure containing various user-configurable parameters (at compile time). This structure, called macCfg_t, is in the mac_cfg.c file. Table 5. describes the configuration elements.

Table 5. Configuration Constants

Name

Description

Range

Default

txDataMax

Maximum number of data frames queued in the transmit data queue.

1–255

2

txMax

Maximum number of frames of all types queued in the transmit data queue.

1–255

5

rxMax

Maximum number of frames queued in the receive data queue.

1–255

2

dataIndOffset

Allocate additional bytes in the data indication for application-defined headers.

0–127

0

appPendingQueue

When TRUE, registered callback of type ApiMac_pollIndFp_t will be made to the application when a data request command frame is received from another device.

TRUE or FALSE

FALSE