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 super-frame. The beacon has information on the super-frame 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 super-frame 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.

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 super-frame configuration
  • Coordinator realignment parameter set to FALSE

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

Figure 49. 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 super-frame specification of the chosen PAN
• ApiMac_attribute_superframeOrder
  • Set to the value received in the beacon super-frame 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:

and

Refer to the IEEE 802.15.4 specification for the definition of previous constants.

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 50. shows a device performing the network association.

Figure 50. Beacon Mode Device Association Sequence

Data Exchange

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

Figure 51. Beacon Mode Direct Data Exchange Sequence

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

Figure 52. 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 53. ). 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.

Figure 53. 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 54.).

Figure 54. 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 55.). 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.

Figure 55. Beacon Mode Coordinator-Initiated Direct Disassociation Sequence

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

Figure 56. Beacon Mode Device-Initiated Disassociation Sequence

Stack Configuration Knobs

Attribute Configuration

Table 3. lists the attribute configuration for beacon mode.

Table 3. 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 super-frame. 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 super-frame 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.

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 4. describes the configuration elements.

Table 4. 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