- Docs »
- TI 15.4-Stack Overview
This chapter explains in detail the three different network configuration modessupported by the TI 15.4-Stack for application development. Useful information ispresented for developers using TI 15.4-Stack for their custom applicationdevelopment, which lets developers quickly understand the basics of theselected configuration mode and develop their end products with ease. The stackoperating mode can be performed in three different channel bands and atdifferent PHY data rates (200 kbps, 50 kbps, or 5 kbps). The choice ofPHY band and data rate can be made by setting the appropriate PHY Id inApiMac_attribute_phyCurrentDescriptorId PIB attribute. The overall optionsare explained in Table 1.
| PHY ID | PHY Data Rate | Channel 0 Freq | # of Channels | Channel Spacing |
|---|---|---|---|---|
| 1 | 50kbps | 902.2 | 129 | 200KHz |
| 3 | 50kbps | 863.125 | 34 | 200KHz |
| 128 | 50kbps | 403.3 | 7 | 200KHz |
| 129 | 5kbps | 902.2 | 129 | 200KHz |
| 130 | 5kbps | 403.3 | 7 | 200KHz |
| 131 | 5kbps | 863.125 | 34 | 200KHz |
| 132 | 200kbps | 902.4 | 64 | |
| 133 | 200kbps | 863.225 | 17 |
Attention
The 200kbps modes are only supported using a beacon-enabled network for thisrelease.
Beacon Enabled Mode¶
Introduction¶
The IEEE 802.15.4 specification defines beacon-enabled mode ofoperation where the personal area network (PAN) coordinator devicetransmits periodic beacons to indicate its presence and allows other devices toperform PAN discovery and synchronization. The beacons provide beacon-relatedinformation and also mark the start of the new super-frame. The beacon hasinformation on the super-frame specification, which helps the device intendingto join the network to synchronize timing and network related parameters beforestarting the join process. The beacon helps the existing device in the PAN tomaintain the network synchronization. The super-frame is divided into an activeand an inactive period. During the active period, devices communicate using theCSMA/CA procedure except in 863MHz band where LBT is used forchannel access. The inactive period allows the devices in the network toconserve 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 MACsublayer reset. The network operates on a single channel (frequency hopping isnot available in this configuration, although frequency agility may beimplemented by application-specific means). To select the most optimal channelof operation, the fully functional device (before starting the network) canoptionally scan for the channels with the least amount of radio interference byfirst performing the energy-detect scan to identify the list of channels withthe least amount of RF energy. When a list of channels is identified,the fully functional device can (optionally) perform active scan to find thechannel with the least number of active networks. When the channel with theleast RF energy and lowest number of active networks is selected, the PANcoordinator must set its short address (the PAN identifier) beacon payload andturn on the associate permit flag. The network starts upon the followingactions:
- 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 23. shows the interactionbetween the application and TI 15.4-Stack to start the beacon-enabled network bythe PAN coordinator.
Figure 23. Beacon Mode Network Start-Up Sequence
Network Association¶
A device that is intended to join the beacon-enabled network must first performa passive channel scan. The results of the channel scan can then be used tochoose 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 ofthe chosen PAN
ApiMac_attribute_superframeOrder- Set to the value received in the beacon super-frame specification ofthe 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 todetect any pending messages. Synchronization is requested by using theApiMac_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 thesynchronization process to complete. Alternatively the device can turn off theAuto Request by setting the ApiMac_attribute_autoRequest attribute item toFALSE, which forces the MAC sublayer to send the beacon notification to theupper layer. If the application receives beacon notification indications forthe normal beacon and no sync loss indication, it is a good indication that thedevice has synchronized with the coordinator beacons. TI recommends waiting forat least two beacon notifications before turning on the Auto Request.
When the device is synchronized to the network and is tracking the beacon, theapplication can perform the network association. TheApiMac_mlmeAssociateReq() API call is used to send the association requestmessage to the coordinator. The association process is successful when theapplication receives the association confirmation.
Figure 24. shows a device performing thenetwork association.
Figure 24. Beacon Mode Device Association Sequence
Data Exchange¶
The sequence diagram in Figure 25. depictsthe various direct data transactions between an always-on (mains powered)device and a coordinator in a beacon-enabled network.
Figure 25. Beacon Mode Direct Data Exchange Sequence
The sequence diagram in Figure 26.depicts the indirect data transaction in a beacon-enabled network.
Figure 26. Beacon Mode Indirect Data Exchange Sequence
Maintaining a Connection for End Nodes¶
All devices operating on a beacon-enabled PAN must acquire beaconsynchronization with a coordinator. Synchronization is performed by receivingand decoding the beacon frame information. The beacon frame contains the super-frame specification which lets the device sync its timing information with thecoordinator and detect any pending messages.
During the network association phase, the end device calls theApiMac_mlmeSyncReq() API with the trackBeacon parameter set to TRUE toacquire beacon and keep track of it (see Figure 27.). With the track beacon set to TRUE, the MAC sublayer shall enableits receiver at a time before the next expected beacon frame transmission. Ifthe number of consecutive beacons missed by the MAC sub layer reaches themaximum allowed (four beacons), the TI 15.4-Stack makes a callbackApiMac_syncLossIndFp_t() with a status of ApiMac_status_beaconLoss tothe application. The application tries to resynchronize with the coordinator bycalling ApiMac_mlmeSyncReq() with trackBeacon set to TRUE.
Figure 27. Beacon Mode Sync Loss Sequence
Network Disassociation¶
This section describes three scenarios. The first two scenarios are initiatedby the coordinator (one for the mains powered end device and the other for thebattery powered end device). In the third scenario, the end devicedisassociates itself from the network.
When the coordinator application requires an associated device to leave thenetwork, the coordinator application requests that TI 15.4-Stack sends adisassociation notification command by using theApiMac_mlmeDisassociateReq() call. If the txIndirect parameter is setto TRUE, the TI 15.4-Stack sends the disassociation notification command to thedevice using indirect transmission; then, the disassociation notificationcommand is added to the list of pending transactions stored on the coordinatorand pulled by the device using a data request command (seeFigure 28.).
Figure 28. Beacon Mode Coordinator Initiated Indirect Disassociation Sequence
If the txIndirect parameter is set to FALSE, TI 15.4-Stack sends thedisassociation notification command frame to the device using directtransmission (see Figure 29.).The TI 15.4-Stack layer at the coordinator makes a callback to the applicationusing the registered function pointer of type ApiMac_disassociateCnfFp_tafter completion of the disassociation. TI 15.4-Stack at the end-device makes acallback to the application using the registered function pointer of typeApiMac_disassociateIndFp_t on reception of the disassociation notificationcommand frame from the coordinator.
Figure 29. Beacon Mode Coordinator-Initiated Direct Disassociation Sequence
The end-device application can also initiate the disassociation process asdescribed in Figure 30..
Figure 30. Beacon Mode Device-Initiated Disassociation Sequence
Stack Configuration Knobs¶
Attribute Configuration¶
Table 2. lists the attribute configuration forbeacon 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 applicationto indicate to the joining devices whether it allows association or not.Setting this attribute item to TRUE by the coordinator indicates to the joiningdevices in its beacon frame that the coordinator application allowsassociation.
The ApiMac_attribute_RxOnWhenIdle, if set to TRUE, enables the receiverduring the idle period.
The ApiMac_attribute_RxOnWhenIdle, if set to TRUE, enables the receiverduring the idle in the contention period of the super-frame. The coordinatorapplication sets this item to TRUE.
The ApiMac_attribute_beaconOrder item is used by the device application toset the beacon order during the joining phase, after the passive scan ofbeacons, 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 applicationto set the super-frame order during the joining phase, after the passive scanof beacons, and after the device makes the decision on which coordinator tojoin. This attribute shall be set to the selected coordinators beacon ordervalue.
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.cfile. Table 3. describes the configurationelements.
| 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 |
Nonbeacon Mode¶
Introduction¶
The IEEE 802.15.4 specification defines the non-beacon mode of networkoperation where the coordinator does not send out periodic beacons. The non-beacon mode is an asynchronous network mode of operation where the devicescommunicate by using the CSMA/CA mechanism.
Network Operations¶
Network Start-Up¶
A network is always started by a full function device. The procedure to startthe network begins with a MAC layer reset. The application can directly startthe network on a desired channel with a desired or random PAN-ID, or it canfirst check for a channel with lowest RF energy by performing a energy detectscan to select the channel with lowest energy or least interference (seeFigure 31.). The application thenperforms an active scan to detect the existing networks in the area, andselect network parameters for its own network which do not conflict. Afterselecting the channel, the PAN Coordinator application must set the shortaddress and PAN-ID, and then set the beacon payload and (optionally) turnon the associate permit flag if it wants new devices to join the network.The network is then started using the API ApiMac_mlmeStartReq() with thepanCoordinator parameter set to TRUE.
Figure 31. Nonbeacon Mode Network Start-Up Sequence
Network Join¶
When a device is ready to join a non-beacon network, it must first perform anactive scan broadcasting a beacon request. After receiving the beacon request,the non-beacon PAN coordinators in the radio range of the device respond withtheir beacons. When the scan is complete, TI 15.4-Stack calls the registeredcallback of type ApiMac_scanCnfFp_t with the PAN descriptors of the beaconsit has received during the scan to the device application. The deviceapplication examines the PAN descriptors and selects a coordinator.
The next step is to perform the network association (seeFigure 32.). The device application callsthe ApiMac_mlmeAssociateReq() API to send the association requestmessage to the coordinator. The association process is successful when thedevice application receives the association confirmation from the TI15.4-Stack layer.
Figure 32. Nonbeacon Mode Device Association Sequence
Data Exchange¶
The sequence diagram in Figure 33. depictsthe various direct data transactions between a device and a coordinator in anon-beacon network.
Figure 33. Non-beacon Mode Direct Data Exchange Sequence
The sequence diagram in Figure 34. depictsthe indirect data transaction in a non-beacon network.
Figure 34. Non-beacon Mode Indirect Data Exchange Sequence
Maintaining a Connection for End Nodes¶
If the device application receives repeated communication failures followingrequests to transmit data, the device application may conclude that it has beenorphaned and can initiate an orphaned-device realignment procedure.Figure 35. shows the non-beacon mode orphansequence.
In the orphan realignment procedure, the device application requests TI15.4-Stack to perform the orphan scan over a specified set of channels by usingthe ApiMac_MlmeScanReq() API with the scan-type parameter set to orphanscan. For each channel specified, TI 15.4-Stack at the device switches to thechannel and then sends an orphan notification command. After successfullytransmitting the orphan notification command, the MAC layer enables thereceiver for at most ApiMac_attribute_responseWaitTime. If the devicesuccessfully receives a coordinator realignment command, the device terminatesthe scan and calls the registered callback of type ApiMac_scanCnfFp_t. Atthe coordinator side, the reception of the orphan notification command resultsin the call of the registered callback of type ApiMac_orphanIndFp_t by TI15.4-Stack. If the coordinator application finds the record of the device, itsends a coordinator realignment command to the orphaned device by using theApiMac_MlmeOrphanRsp() call.
Figure 35. Nonbeacon Mode Orphan Sequence
Disassociating¶
Two scenarios are described in the following: the first is initiated by thecoordinator and the second is initiated by the device.Figure 36. shows the indirectdisassociation sequence initiated by the non-beacon mode coordinator.
When the coordinator application wants one of the associated devices must leavethe PAN, the coordinator application requests that TI 15.4-Stack send thedisassociation notification command by using theApiMac_mlmeDiassociateReq() call. If the txIndirect parameter is set toTRUE, TI 15.4-Stack sends the disassociation notification command to the deviceusing indirect transmission; then, the disassociation notification command isadded to the list of pending transactions stored on the coordinator and pulledby the device using data request command.
Figure 36. Indirect Disassociation Sequence Initiated by the Non-beacon Mode Coordinator
The end device application can also initiate the disassociation process asdescribed in Figure 37., whichshows the sequence of messages exchanged when the end device initiates thedisassociation process in the non-beacon network.
Figure 37. Disassociation Sequence Initiated by the Nonbeacon Mode Device
Stack Configuration Knobs¶
Attribute Configuration¶
The ApiMac_attribute_associatePermit is used by the coordinator applicationto indicate to the joining devices whether association is allowed or not. Whenthe coordinator sets this attribute item to TRUE, this indicates to the joiningdevices within the beacon frame that association is allowed.Table 4. lists the attribute configurations thatapply to non-beacon mode.
If set to TRUE, the ApiMac_attribute_RxOnWhenIdle enables the receiverduring the idle period.
| Name | Type | Range | Number | Description |
|---|---|---|---|---|
| ApiMac_attribute_associatePermit | Bool | TRUE, FALSE | 0x41 | TRUE if a coordinator is currently allowing association. |
| ApiMac_attribute_RxOnWhenIdle | Bool | TRUE, FALSE | 0x52 | TRUE if the MAC enables its receiver during idle periods. |
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.cfile. Table 5. lists the configurationelements.
| 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 – FALSE | FALSE |
Frequency-Hopping Mode¶
Introduction¶
Applications that are developed using TI 15.4-Stack can be configured tooperate the network in frequency-hopping configuration where the networkdevices hop on different frequencies. TI 15.4-Stack supports an unslottedchannel-hopping feature based on the directed frame exchange (DFE) modeof the Wi-SUN FAN specification v1.0.
Two types of end devices are supported:
- Sleepy End Device: These devices do not change channels by themselvesbut follow that of the collector. All communication to these devices shouldbe made using short addressing.
- Non-Sleepy End Device: These devices can either hop on multiplechannels based on direct hash channel function (DH1CF) or operate on afixed channel based on the channel function configuration. Allcommunication to these devices should be made using extended address mode.
The Collector device can either hop on multiple channels based on direct hashchannel function DH1CF or operate on a fixed channel based onthe channel function configuration.
DH1CF generates a pseudo-random sequence of channels on which to hop based onthe extended address of the node; thus, the pseudo-random sequence of channelsis unique to each node. Each node supports two types of channel-hoppingsequences:
- Unicast
- Broadcast
Frequency hopping for each node is based on the unicast channel hoppingsequence of those nodes (see Figure 38.).
Figure 38. Unicast Hopping Sequence
To enable broadcast transmissions, the coordinator starts a broadcast schedule(see Figure 39.). Every other device follows thebroadcast-hopping sequence received from the PAN coordinator. A device performsunicast hopping until the next broadcast dwell time. Then, the device switchesto the broadcast- hopping channel for the broadcast dwell time and resumesunicast hopping at the end of the broadcast dwell interval.
Figure 39. Broadcast Channel Hopping Sequence
The application can specify the broadcast dwell interval (default is 250 ms),channel hopping function (default is Fixed Channel), and the list of channelsto hop (based on PHY Descriptor ID; for example, the default value of 1represents 129 channels). Additionally, the broadcast interval (default is 4250ms) can be specified on the PAN coordinator. When the hopping function is setto Fixed, the node must stay on the channel set byApiMac_FHAttribute_unicastFixedChannel orApiMac_FHAttribute_broadcastFixedChannel during the unicast and broadcastdwell times, respectively.
Note
The broadcast dwell time can be set to 0 to disable broadcast transmission.This can be especially helpful in saving power on sleepy end devices whenbroadcast transmission are not used in application as the device would nolonger be required to power up during broadcast slots.
Note
A set of channels can also be excluded from the hopping channels by usingthe ApiMac_FHAttribute_unicastExcludedChannels andApiMac_FHAttribute_broadcastExcludedChannels PIBs as defined inStack Configuration Knobs.
A special type of transmission called async transmission is also supported.In frequency-hopping mode, a device transmits any one of the Async frame types(as defined in the Wi-SUN FAN specification) in all of the requested channels(see Wi-SUN FAN Specification). This enables a hopping device to receivesuch a frame irrespective of the hopping sequence. Thus, the async transmissioncan be used to exchange channel-hopping information. This feature is especiallyuseful in initial network formation as explained in Network Join.
When channel-hopping information of a neighbor is received, TI 15.4-Stacktracks the hopping sequences of the neighbor hopping devices and enablessuccessful unicast and broadcast transmissions; thus, hiding the complexitiesof maintaining synchronization from the application and easing the task ofdeveloping applications with frequency hopping feature. To support shortaddress mode the FH_COORD_SHORT_ADDRESS should be configured on end deviceto match the short address of the collector used.
Network Operations¶
In frequency hopping mode, nodes operate as one of the following device types:
- PAN coordinator
- Non-sleepy device
- Sleepy device
A typical star topology has a single PAN coordinator connected to a set ofnon-sleepy or sleepy devices. Each network is identified by a specific networkname, which is an ASCII value of 32 bytes and a 16-bit PAN Identifier. Thenetwork name (NetName) is a unique network identifier that is configured by theapplication using frequency hopping and PAN information base (FH-PIB)attributes. Maintenance of the NetName is beyond the scope of TI 15.4-Stack andis not used to filter frames.
The sections below explain various network operations important to understandwhen developing a frequency hopping-enabled network over TI 15.4-Stack.
Network Start-Up¶
Figure 40. shows how a frequency-hopping network is startedby starting the PAN coordinator in frequency-hopping mode.
Figure 40. Start-Up Sequence of PAN Coordinator
The PIB attributes that are related to frequency-hopping configuration areexplained in Stack Configuration Knobs. The NetName is a 32-bit ASCII value tobe set by the application. The routing cost must be set to zero.
Initially, the PAN size must be set to zero; later, the PAN size must beupdated based upon the number of nodes joined.
Note
This NetName value is not used by the TI 15.4-Stack to make any decision;instead, the value is carried in a PAN Advertisem*nt frame that can beparsed by a receiving application. Similarly, the GTK HASH 0, GTK HASH 1,GTK HASH2, and GTK HASH 3 can be used to determine the validity of GMK keysthat are in use and are beyond the scope of TI 15.4-Stack.
Finally, start MAC using the macStart API, which specifies that the node is acoordinator.
Device Start-Up¶
Figure 41. shows the start-up sequence of the device.
Figure 41. Start-Up Sequence of the Device
Wi-SUN FAN v1.0 does not specify sleep mode operation, but the TI 15.4-Stackimplements a proprietary extension over the behavior defined in the Wi-SUN FANand IEEE 802.15.4 MAC protocols (see Sleep Mode Operation) to enablesleepy devices in the frequency-hopping networks based on TI 15.4-Stack.The channel-hopping function for a sleepy device must be set to Fixed, andthe fixed channel can be set to any desired channel. The security keys can beset at start-up (if the security keys are already pre-configured for thenetwork), or the security keys can be set after obtaining the same through akey exchange. The key exchange protocol must be handled above the MAC layer.
The routing cost must be set to a high value (0xFFFF) to indicate that thedevice has not joined the network; later, it can be updated by the applicationbased on the routing metric used.
Note
The sequence to start the sleepy and non-sleepy devices is the same untilthey join a network. A sleepy device is configured to be sleepy by settingthe MAC PIB (macRxOnWhenIdle) to zero only after it joins the network (seeNetwork Join). In other words, the sleep mode operation useslow-power mode only for data exchange after successfully joining thenetwork.
Network Join¶
To join to a network, a node must go through the two phases described as follows.
Phase 1: Exchange of Channel-Hopping Sequence Information Through Asynchronous Messages¶
Asynchronous messages are sent back-to-back over a specified channel list. Thisaction enables a receiver to receive such frames with high probability,irrespective of the hopping sequence. Four different asynchronous messages aresupported by TI 15.4-Stack as defined in the Wi-SUN FAN specification. Allasynchronous frames are transmitted based on a trickle timer [RFC 6206]. TheImin, Imax, and K for the trickle algorithm are recommended to be set at 1 min,16 min, and 1, respectively.
Brief descriptions of the four types of asynchronous messages follow:
- PAN Advertisem*nt Solicit (PAS):
- PAS messages are used by a device to request a coordinator or otherjoined nodes to transmit a PAN Advertisem*nt frame.
- Upon reception of the PAN Advertisem*nt frame, a joining applicationcan detect the NetName IE in the frame and then use the name todetermine whether or not to reset PA trickle timer.
- PAN Advertisem*nt (PA):
- PA frames can be transmitted by a coordinator or by a joined node toinform neighbors about the PAN size, Routing cost, and PAN ID.
- The trickle timer associated with PA transmissions is programmed to bereset on reception of a PAS frame.
- Upon, reception of the PAS frame, nodes communicate with thetransmitter of the PA frames (note the hopping sequence is carried inthe PA frame).
- The device can choose one of the source nodes of the PA frame as relayto perform an Authentication and Secure Key Exchange protocol thatmust be implemented by the application running over the TI 15.4-Stack.Example applications (collector and sensor) included in TI 15.4- Stackdo not demonstrate this feature.
- PAN Configuration Solicit (PCS):
- When a device has the group master key (GMK) keys used in the network,the device can request the transmission of a PAN Configuration frame.
- PCS messages are transmitted by a node to request neighbors or thecoordinator transmit a PAN Config frame.
- PAN Configuration (PC):
- PC messages are transmitted by the coordinator or a joined node basedon a trickle timer that must be reset upon reception of a PCS frame.
- PC frames carry the broadcast-hopping sequence and the hash values ofthe list of GMK keys that are actively used.
- Upon reception of a PC frame, a device detects that the channel-hoppingexchanges are completed.
When using the frequency-hopping configuration on star-network topology, TI recommends the following:
- The PAN coordinator transmits PA and PC frames based on separate trickletimers. TI recommends that developers refer to the collector exampleapplication implementation located under the examples folder in the TI15.4-Stack installation directory).
- Devices transmit PAS and PCS frames for the purpose of joining; then, thedevices suspend the trickle timer after a successful join. TI recommendsthat developers refer to the sensor example application as a reference onhow to implement this action, or that they use the implementation in thesensor example application as-is as a starting point for customapplications.
- Devices must also implement the suppression mechanism to limit the numberof PAS and PCS frames transmitted. TI recommends developers refer to thesensor example application (examples folder in the TI 15.4-Stackinstallation directory) as a reference for implementing this action, or usethe implementation in the sensor example application as-is as a startingpoint for custom applications.
Phase 2: Proprietary Association Procedure to Inform Coordinator of the Network Join (This is an Optional Step)¶
Because the frequency hopping join procedure (defined by the Wi-SUNspecification) is silent, the PAN coordinator cannot detect if the device hassuccessfully joined the network. The TI 15.4-Stack example applications use anadditional step for network join. The MAC layer association procedure describedin the IEEE 802.15.4 specification is used after the PCS indicates to the PANcoordinator that the device has successfully joined the frequency-hoppingnetwork.
In addition to informing the coordinator that the device has successfullyjoined the network, the optional mechanism allows the PAN coordinator to detectif the joining node is sleepy or always-on through the capability informationfield of the association request message sent by the device to the PANcoordinator. This optional mechanism is required for the PAN coordinatorapplication to determine the following:
- If the application must buffer the message until the device polls for someconfigured amount of time in case the message is for a sleepy device
- If the application must send the message OTA as soon as the message-transmit request is generated
Although this step is not required for data exchange (because EUI addresses areused instead of short addresses for communication in frequency-hopping mode),TI recommends using this optional procedure in the applications using thefrequency-hopping configuration of the TI 15.4-Stack to enable the coordinatorapplication to build the list of joined nodes and to detect if the newly joineddevice is sleepy or is an always-on device.
Note
The association procedure must be started at least 2 seconds afterreception of a PAN configuration frame. Upon failure, the associationprocedure can be independently retried up to the retry limit of theapplication. For a sleepy device, the ApiMac_attribute_RxOnWhenIdleshould be set to zero only after a successful completion of the mac-association procedure.
Figure 42. and Figure 43. shows theprocedure for sleepy and non-sleepy devices, respectively.
Figure 42. Joining Procedure for a Sleepy Frequency-Hopping Device
Figure 43. Joining Procedure for a Nonsleepy Frequency-Hopping Device
Data Exchange¶
Three types of data-exchange mechanisms are supported by the TI 15.4-Stack:
- Unicast data exchange
- Broadcast data exchange
- Asynchronous frame exchange
Destination address mode should be based on end-device being sleepy or non-sleepy. To initiate a unicast or broadcast frame exchange, the APIApiMac_mcpsDataReq should be used. To transmit an asynchronous frame,ApiMac_mlmeWSAsyncReq should be used. The determination of whether themessage is unicast or broadcast is done based on the destination address modeused in the data request parameter type ApiMac_mcpsDataReq_t (seeTable 6.).
| Message Type | Source Address Mode | Destination Address Mode | Destination Address |
|---|---|---|---|
| Unicast (sleepy device) | 2 | 2 | Specified by the application |
| Unicast (non-sleepy device) | 3 | 3 | Specified by the application |
| Broadcast | 3/2 | 0 | Ignored by stack |
Unicast Data Exchange¶
Unicast data exchange in frequency-hopping mode occurs on the channel of thedestination node. A node transmits the frame on the expected receive channel ofthe destination node. The entire frame exchange occurs on the same channel (seeFigure 44.). Subsequent data exchange occurs on the channelon which the receiver is hopping at the time of transmission; this subsequentdata exchange is independent from earlier transmissions.
Figure 44. Data Exchange With TI 15.4-Stack in Frequency-Hopping Configuration
To transmit a unicast frame to a neighbor, the hopping information was receivedby the node in some earlier frame. The hopping information could have beenreceived through the reception of any type of asynchronous frames from thedestination node. Hence, an application should ensure that such a frame isreceived from destination node before initiating a data request.
If a data request is issued to a node whose entry is not in the neighbor table,the error code ApiMac_status_fhNotInNeighborTable (0x64) specifies that thenode that is not in the neighbor table is returned to the application by TI15.4-Stack. Also, an expiry is associated with each neighbor table entry. Thedefault time of the expiry is 2 hours for hopping neighbors. The 2 hour defaultexpiry is set because the hopping information stored in the neighbor table maynot be useful beyond that time limit for a successful data exchange (due to lossin synchronization caused by inherent clock drifts). Any data exchange helps thenode to resynchronize the entry; thus, the entry is considered active for thenext 2 hours. If a data request is sent for an expired neighbor, the message isnot sent to the destination and a status of ApiMac_status_fhExpiredNode(0x6C) is returned to the application. Unicast frames are only transmitted inunicast slots.
Note
The lifetime of a hopping neighbor can be changed to any other desired valuein the range of 5 minutes to 600 minutes (10 hours) by using the PIBattribute, ApiMac_FHAttribute_neighborValidTime, which is specified inminutes.
Broadcast Frame Exchange¶
Broadcast frames are transmitted only during the broadcast dwell interval asshown in Figure 39.. This can lead to situations whereframes are out of order between a unicast and broadcast frame (that is, theorder in which frames are requested to be transmitted by the application couldbe different from the order in which they are transmitted over the air). Thus,the order in which the ApiMac_mcpsDataReq confirm is received may bedifferent from the order in which ApiMac_mcpsDataReq is sent. The msdu-handle should be used to match the request primitive to the correspondingconfirm primitive by the application.
An application on the PAN coordinator can transmit a broadcast frame any timebecause the PAN coordinator starts the broadcast hopping as soon as theapplication is started. All other nodes should wait for the reception of a PANConfiguration frame from the PAN coordinator to start the broadcast-hoppingsequence. An application on these other nodes should wait for the reception ofthe PAN Configuration frames; then the application can set the source address ofthe PAN Configuration frame (if it selects to use that node as a Parent) to theFH_MAC_TRACK_PARENT PIB before issuing a request of broadcast frameexchange. If an application issues a broadcast data request while the node hasnot yet started following a broadcast hopping sequence, the stack returns anApiMac_status_badState (0x19) error code.
Asynchronous Frame Exchange¶
Asynchronous frames are transmitted by a device on the list of channelsspecified by user in the Async request. Figure 45. shows that thedevice deviates from the hopping sequence and performs this operation.
Figure 45. Asynchronous Frame Exchange
The objective of asynchronous frame exchange is to transmit data on allavailable channels (default = 129); thus, asynchronous frame exchange can take afew seconds to complete (worst case is approximately 4 seconds). Suchtransmissions are typically controlled by trickle timers and are not recommendedto be transmitted frequently (refer to References). Optionally, adevice may issue an Async Request with a Stop command, which will stop anongoing Async frame exchange.
Sleep Mode Operation¶
Wi-SUN FAN v1.0 does not define a sleep mode operation. However, TI 15.4-Stacksupports a proprietary sleep mode operation using a mechanism similar to TI15.4Stack non-beacon configuration operation, which uses indirect transmissions.In sleep mode operation the address mode should be set to short address mode.
The sleep mode operation is explained in Figure 46..Because the joining procedure is explained in Network Join, thedata exchange mechanism is emphasized in this section.
After reception of PAN Config frame, the macRxOnWhenIdle should be set to zeroto enable sleep mode operation. The sleepy device transmits frames to the PANcoordinator based on the hopping sequence. TI 15.4-Stack on the sleepy deviceoperates on a fixed channel and will not hop independently.
Figure 46. Sleep Mode Operation in Frequency-Hopping Mode
Maintaining a Connection for End Nodes¶
In a typical star network, the devices have to keep track of unicast andbroadcast timing of Coordinator’s hopping sequences while the coordinator has todo for the unicast timing information of all the connected devices.
The timing information of the unicast and broadcast sequence of a device iscarried in unicast timing and frame type information element (UTT-IE) andbroadcast timing Information element (BT-IE), respectively. All data frames withdestination address mode set to extended or None shall carry UTT-IE and BT-IE.The ACK frames from PAN-Coordinator will contain both the UTT-IE and BT-IEirrespective of address mode, while those from other non-sleepy end devices willcarry UTT-IE alone. The timing information corresponding to the source of thereceived Data/ACK frame is updated based on received frames.
The lifetime of a neighbor table is based on the last time the entry wasupdated. As long as a frame is received from a neighbor once every neighborvalid time, it is kept active. The neighbor valid time for a hopping neighboris set to 2 hours by default. Neighbor valid time can be changed using theMAC_FHPIB_NEIGHBOR_VALID_TIME PIB attribute. After that period the entry isconsidered as expired. Any neighbor table entry is deleted if it is not updatedwithin the last 10 hours.
The period within which at least one data frame should be exchanged to maintainreliable communication depends on the dwell time value used by the PANcoordinator. TI recommends keeping this period for at most 10 minutes or 25minutes, for a PAN coordinator dwell time of 100 ms and 250 ms respectively.
Disassociating¶
The frequency-hopping mode also supports the disassociation command defined inIEEE 802.15.4, similar to the nonfrequency-hopping mode.
Stack Configuration Knobs¶
The frequency-hopping mode features can be controlled through a set of MAC FHPIBattributes. Some of these PIBs affect TI 15.4-Stack operation directly,while others are provided to help applications generate the requiredAsynchronous frames. This section explains the MAC FHPIB attributes.
Parameters Controlling the Unicast Channel-Hopping Sequence of the Node¶
The parameters controlling the unicast hopping must be set after the FH isenabled and before the MAC or FH-start API is called (seeTable 7.). Thesevalues must not be changed after the node starts the hopping sequence. To changethese values the nodes have to be power cycled or reset.
| PIB | PIB ID | Range | Default | Description |
|---|---|---|---|---|
| ApiMac_FHAttribute_unicastDwellInterval | 0x2004 | 15 to 250 (ms) | 250 | Amount of time spent on each channel |
| ApiMac_FHAttribute_unicastChannelFunction | 0x2008 | 0 or 2 | 0 | Whether to hop or not. Only two values are supported:0 – Fixed2 – DH1CF-based hopping |
| ApiMac_FHAttribute_unicastFixedChannel | 0x200C | 0 – maximum channel based on PHY configuration | 0 | The channel to use during unicast hopping when the channel function is fixed |
| ApiMac_FHAttribute_unicastExcludedChannels | 0x2002 | 17 bytes | All zeros | The list of channels to avoid when channel function is 2. Each bit represents a channel, starting from the LSB of the first byte which, represents Channel 0 |
Parameters Controlling the Broadcast Channel-Hopping Sequence¶
These parameters must only be set on the PAN coordinator (seeTable 8.). The parameters must be set after the FHis enabled and before the MAC or FH-start API is called. Other devicesobtain this information on reception of a PC (an Asynchronous message)message from the PAN- Coordinator. Devices then perform their broadcasthopping based on the received configuration. The received configuration canbe read from these PIBs after the reception of a PAN Config frame from theparent of a node.
| PIB | PIB Id | Range | Default | Description |
|---|---|---|---|---|
| ApiMac_FHAttribute_broadcastInterval | 0x2001 | 15 to16777215 ms | 4250 | The interval between two different broadcast dwell interval |
| ApiMac_FHAttribute_broadcastDwellInterval | 0x2005 | 0 to 250 ms | 250 | Amount of time spent during broadcast dwell interval. Setting this value to 0 will disable broadcast transmissions. |
| ApiMac_FHAttribute_broadcastChannelFunction | 0x2009 | 0 or 2 | 0 | Whether to hop or not. Only two values are supported:0 – Fixed2 – DH1CF based hopping |
| ApiMac_FHAttribute_broadcastFixedChannel | 0x200D | 0 – maximum channel based on PHY configuration | 0 | The channel to use during broadcast dwell interval when the channel function is fixed |
| ApiMac_FHAttribute_broadcastExcludedChannels | 0x2003 | 17 bytes | All zeros | The list of channels to avoid when the channel function is 2. Each bit represents a channel, starting from the LSB of the first byte, which represents Channel0. |
Note
A large value of broadcast interval implies a higher delay intransmitting broadcast frames.An application could decide to increase or decrease this interval based onthe perceived requirement for handling broadcast frames.
On the device side, an application must set the source address of the chosenparent to the MAC TRACK PARENT PIB (see Table 9.). FH stackfollows thebroadcast hopping sequence of the chosen parent. An application can choose aparent based on the received source address of the PAN configuration frames.However, performance loss may occur due to loss in broadcast synchronization,which is corrected based on the subsequent PAN Configuration frame received fromthe new parent.
| PIB | PIB Id | Range | Default | Description |
|---|---|---|---|---|
| ApiMac_FHAttribute_trackParentEUI | 0x2000 | Any | 0xFFFFFFFF | Source address of the parent. |
Changing Broadcast Sequence Values in the Middle of Network Operation¶
A PAN coordinator may choose to modify the broadcast interval during a networkoperation. To do so the application of the PAN coordinator must set the valuesas required, and then increment the value of the MAC_FHPIB_BROCAST_SCHED_IDPIB (see Table 10.).
| PIB | PIB Id | Range | Default | Description |
|---|---|---|---|---|
| ApiMac_FHAttribute_broadcastSchedId | 0x200B | 0 to 65535 | 0 | A value representing a given broadcast configuration. It must be incremented when broadcast configurations are changed. |
Transmit PAN Config frames more frequently to enable the dissemination of thisinformation to the network.
Note
The performance of the network may be affected during this change inconfiguration time as it requires some time for the nodes to update their hopping sequences.
Parameters to Control Frequency of the Operation of Hopping Mode¶
The following parameters can be set to control specific functions, as defined inTable 11..
| PIB | PIB Id | Range | Default | Description |
|---|---|---|---|---|
| ApiMac_FHAttribute_clockDrift | 0x2006 | 0 to 255 | 20 | Represents the accuracy of the system clock in ppm. A value of 255 implies that the information is not provided. |
| ApiMac_FHAttribute_timingAccuracy | 0x2007 | 0 to 255 | 0 | Accuracy of provided timing information in 10s of micro seconds. |
| ApiMac_FHAttribute_neighborValidTime | 0x2019 | 5 to 600 (minutes) | 120 | The time in minutes for which a hopping neighbor is considered valid after reception of a Data/ACK from it. |
TI recommends not changing the values listed in Table 11., andusing the default values.
Parameters to Control Neighbor Table Size¶
The amount of heap memory occupied by the FH neighbor table can be controlledthrough FH PIB attributes. The total number of end devices supported must beless than 50. If a deployment only requires a lesser number of devices, a lowernumber of neighbor table entries can be specified, thereby allowing more heapfor the application. When configuring the number of neighbor table entries, bothnon-sleepy and sleepy devices must be changed together withMAC_FHPIB_NUM_NON_SLEEPY_DEVICES set first.
| PIB | PIB Id | Range | Default | Description |
|---|---|---|---|---|
| MAC_FHPIB_NUM_NON_SLEEPY_DEVICES | 0x201b | 0 to 50 | 2 | Total number of non-sleepy neighbors supported. |
| MAC_FHPIB_NUM_SLEEPY_DEVICES | 0x201c | 0 to 50 | 48 | Total number of sleepy neighbors supported. |
Note
The number of non-sleepy and sleepy neighbors can only be configuredbefore issuing a network start or FHAPI_start API. The total number of enddevices supported must be less than 50. When configuring the number ofneighbor table entries, both non-sleepy and sleepy devices must be changedtogether with MAC_FHPIB_NUM_NON_SLEEPY_DEVICES set first.
| PIB | PIB Id | Range | Default | Description |
|---|---|---|---|---|
| MAC_FHPIB_BASE_BACKOFF | 0x201a | 0 to 16 | 8 | Additional back off parameter on target channel to account for interference (ms). |
| MAC_FHPIB_NEIGHBOR_VALID_TIME | 0x2019 | 0 to 65535 (minutes) | 120 | The time in minutes for which a hopping neighbor is considered valid after reception of a Data/ACK from it. |
The MAC_FHPIB_BASE_BACKOFF enables FH devices to mitigate interference, whichcauses a higher delay for packet transmission when interference is observed. Theinterference mitigation feature can be disabled by setting this parameter tozero (although it is not recommended to do so). TI recommends not changing thesevalues and using the default values.
Parameters to Enable Application Generate and Process Asynchronous Frames¶
The following PIB attributes represent different fields of the Asynchronousframes (see Table 14.). The attributes are used to generate therequired IEs when an async request is made by application based on the asyncframe type. The TI 15.4-Stack is responsible for only using these PIBs to encodethe async frames and does not use these values to make any decisions on itsoperation. It is up to the application to use these fields if needed to performany relevant operation.
| PIB | PIB Id | Range | Default | Description |
|---|---|---|---|---|
| ApiMac_FHAttribute_panSize | 0x200E | 0 to 65535 | 0 | The size of PAN network |
| ApiMac_FHAttribute_routingCost | 0x200F | 0 to 255 | 0 | Zero for PAN Coordinator and Non- Zero for other devices. Actual metric used is beyond the scope of MAC. This can be used to choose a parent. |
| ApiMac_FHAttribute_routingMethod | 0x2010 | 0 or 1 | 1 | Specify the type of routing protocol used. Typical values are 0 – MHDS,1 – RPL |
| ApiMac_FHAttribute_eapolReady | 0x2011 | 0 or 1 | 1 | Specify whether the node can support EAPOL to perform authentication and key exchange |
| ApiMac_FHAttribute_fanTPSVersion | 0x2012 | 0 to 255 | 1 | Wi-SUN FAN version number |
| ApiMac_FHAttribute_netName | 0x2013 | 32 bytes | All zeros | Null terminated string |
| ApiMac_FHAttribute_panVersion | 0x2014 | 0 to 65535 | 00000 | Must be incremented whenever a configuration changes such as broadcast information or GTK Hash values are changed. |
| ApiMac_FHAttribute_gtk0Hash | 0x2015 | 8 bytes | All zeros | The Hash value that can be used by the application to decide the validity of an exchanged GMK key with ID 0. |
| ApiMac_FHAttribute_gtk1Hash | 0x2016 | 8 bytes | All zeros | The Hash value that can be used by the application to decide the validity of an exchanged GMK key with ID 1. |
| ApiMac_FHAttribute_gtk2Hash | 0x2017 | 8 bytes | All zeros | The Hash value that can be used by the application to decide the validity of an exchanged GMK key with ID 2. |
| ApiMac_FHAttribute_gtk3Hash | 0x2018 | 8 bytes | All zeros | The Hash value that can be used by the application to decide the validity of an exchanged GMK key with ID 3. |
CC1190 PA/LNA Support¶
CC1190 PA/LNA can be used to enhance the transmit power of the device using theexternal Power Amplifier. If the system uses an external CC1190 external PA/LNA,the stack should be configured to use the appropriate power tables. This can beachieved by setting the PIB attribute ApiMac_attribute_rangeExtender to 1.It is required to set this attribute first before setting the PIB attributeApiMac_attribute_phyTransmitPowerSigned to set the required power level.When CC1190 is enable the following output power values will only be supported:18, 23, 25, 26 and 27 dbm. When other values are requested, a status ofApiMac_status_invalidParameter will be returned. For the OOB TI 15.4-Stackapplications, CC1190 PA/LNA support can be enabled by setting the configurationoption CONFIG_RANG_EXT_MODE to APIMAC_HIGH_GAIN_MODE.
Bluetooth Low Energy Advertiser¶
The TI 15.4-Stack supports Bluetooth Low Energy (BLE) advertisem*nts,specifically, non-connectable undirected advertisem*nts in simultaneousoperation with the TI 15.4 stack. Such simultaneous operation is available onlyon the dual-band devices such as the CC1350.The TI 15.4 stack uses uBLE (pronounced micro BLE) stack subsystem which is atiny light-weight non-connection based protocol stack module that supports onlyBLE Broadcaster role. It does not operate using a separate TI-RTOS stack but isintegrated in the application. This saves memory and overhead required tomaintain a separate RTOS task. Since uBLE supports only BLE Broadcaster role,there is no strict timing constraint. Therefore uBLE radio operation have lowerpriority compared to 15.4 radio operations. This implies that 15.4 radiooperations will preempt uBLE operations.
Note
The BLE advertisem*nt payload is fully modifiable. Any of theout-of-box example sensor applications can be configured to enable BLEadvertisem*nts.
Configuring uBLE Stack¶
FEATURE_BLE: Defining this compile flag in features.h will compile theBLE advertisem*nt feature.:
/*! If defined, builds the image wih BLE Advertiser enabled */#define FEATURE_BLE
CONFIG_BLE_SUPPORT: Apart from FEATURE_BLE this configuration must beset to true in config.h::
/*! Enable BLE advertiser */#define CONFIG_BLE_SUPPORT true
The BLE advertisem*nt interval can be modified as follows in ble_adv.c::
#define DEFAULT_ADVERTISING_INTERVAL 2000Note
The units are in terms of 0.625 milliseconds. Hence setting it to2000 will result in BLE advertisem*nts being sent out every 1.25 seconds.
Security¶
The TI 15.4-Stack supports AES encryption as defined by the IEEE 802.15.4Specification. The application is responsible for management of the keys. Theout-of-box example application of the TI 15.4-Stack demonstrates how to usesecurity with the TI 15.4-Stack.
Configuring Stack¶
The TI 15.4-Stack offers three modes of network operations that follow (and asdiscussed in this chapter):
- Beacon mode
- Nonbeacon mode
- Frequency-hopping mode
- BLE Advertising Mode
The features.h file allows developers to compile-in or compile-out different15.4-Stack features for different applications. TI 15.4-Stack allows support forall three modes or allows user to select just one desired mode of networkoperation. TI 15.4-Stack can be configured in four different modes of operationusing the features.h file. Depending on the mode selection, considerablesavings in the executable-image space can be achieved.Table 15. and Table 16. provide a summaryof Flash and RAM use of the out-of-box Collector and Sensor Example Applicationwith different compile options enabled.
FEATURE_ALL_MODES: When this compile flag is defined, the image iscompiled with all the three modes of operation (frequency-hopping mode,beacon-enabled mode and non-beacon mode) and the configuration fileconfig.hcan be used to select the specific mode for network operation.This feature allows flexibility to select any mode for the device. For theout-of-box collector and sensor example application, this feature isenabled.:/*! If defined, builds the image with all the modes of operation (frequency hopping, beacon mode and non beacon mode) */#define FEATURE_ALL_MODES
FEATURE_FREQ_HOP_MODE: Defining this compile flag will compile only thefrequency hopping mode of operation in the final executable image. For outof box example application, you would need to disable the compile optionFEATURE_ALL_MODESand then enable this compile option as in thefollowing::/*! If defined, builds the image with all the modes of operation (frequency hopping, beacon mode and non beacon mode) */#undef FEATURE_ALL_MODES/*! If defined, builds the image with the frequency mode of operation */#define FEATURE_FREQ_HOP_MODE
FEATURE_BEACON_MODE: Defining this compile flag will compile only thebeacon mode of operation in the final executable image. For out of boxexample application, you would need to disable the compile optionFEATURE_ALL_MODESand then enable this compile option as in thefollowing::/*! If defined, builds the image with all the modes of operation (frequency hopping, beacon mode and non beacon mode) */#undef FEATURE_ALL_MODES/*! If defined, builds the image with beacon mode of operation */#define FEATURE_BEACON_MODE
FEATURE_NON_BEACON_MODE: Defining this compile flag will compile onlythe non-beacon mode of operation in the final executable image.:/*! If defined, builds the image with all the modes of operation (frequency hopping, beacon mode and non beacon mode) */#undef FEATURE_ALL_MODES/*! If defined, builds the image with non beacon mode of operation */#define FEATURE_NON_BEACON_MODE
FEATURE_BLE_SUPPORT: Defining this compile flag will enable BLE operationsin the stack. CONFIG_BLE_SUPPORT will also need to be configured in config.h forthe example application to send out BLE beacons.
In addition to the compile flags listed previously, theFEATURE_FULL_FUNCTION_DEVICE compile flag is required for the PANCoordinator device (see the out-of-box Collector Example Application) to performthe role as a central node in the network.
Also, the FEATURE_MAC_SECURITY compile flag is added in the features.hfile to allow the ability to turn the MAC layer security on and turn off in thecompile executable image. If the mac layer security is turned off, you will needthe version of the stack library with no MAC security.
To build the image with no security, perform the steps that follow:
Select the linker File Search Path option.
Modify to include the
maclib_nosecure.ainstead ofmaclib_secure.alibrary file (shown in Figure 47.).
Figure 47. Changing TI 15.4 Stack library
The PREAMBLE_COMPATIBILITY compile flag allows the stack to be compatiblewith previous versions of TI 15.4-Stack. When this flag is not defined the stackuses a IEEE 802.15.4g compliant preamble. If this flag is enabled, a new versionof the stack library is required.
Similar to the steps above, to change the stack library for compatibility:
- Select the linker File Search Path option.
- Modify to include the
maclib_nosecureLegacy.aormaclib_secureLegacy.alibrary file depending on whether or not securityis enabled or disabled.
| Compile Option Enabled | FLASH (KB) | RAM (KB) |
|---|---|---|
| FEATURE_ALL_MODES | 103 | 15 |
| FEATURE_FREQ_HOP_MODE | 98.1 | 14.6 |
| FEATURE_NON_BEACON_MODE | 84.6 | 13.9 |
| FEATURE_BEACON_MODE | 88.8 | 14.2 |
| Compile Option Enabled | FLASH (KB) | RAM (KB) |
|---|---|---|
| FEATURE_ALL_MODES | 103 | 13 |
| FEATURE_FREQ_HOP_MODE | 104.3 | 12.7 |
| FEATURE_NON_BEACON_MODE | 89.6 | 12.1 |
| FEATURE_BEACON_MODE | 92.1 | 12.1 |
Note
FEATURE_BLE_SUPPORT will add around 6KB of flash and 1.2KB of RAMto any of the modes described above except for FEATURE_ALL_MODES.
