Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.
- 1 RemoTI Developer’s Guide
- 2 Overview
- 3 Topology and node types
- 4 Node configuration
- 5 Medium Sharing
- 6 Data transmission
- 7 Profiles
- 8 Binding
- 9 ZRC Features
- 10 Power savings
- 11 Security
- 12 Frequency Agility
RemoTI Developer’s Guide
Acronyms and Definitions
|Device||A physical object consisting of an IEEE 802.15.4 radio|
|Node||A device containing RF4CE functionality.|
|Originator||The node from which a GDP transmission is sent.|
|Recipient||The node to which a GDP transmission is directed.|
|Binding Originator||An RF4CE Controller node or RF4CE Target node that initiates the binding process with a discovery request.|
|Binding Recipient||An RF4CE Target node that receives a discovery request and participates in the binding process by responding with a discovery response.|
|Target||A Node that implements the Target functionality as defined in the RF4CE specification ( for example, a TV )|
|Controller||A Node that implements the Controller functionality as defined in the RF4CE specification ( for example, a remote control )|
|CERC||Consumer Electronics for Remote Controls, the standard application profile defined by the RF4CE consortium|
|ZRC||ZigBee Remote Control, the standard remote control application profile defined by the ZigBee RF4CE consortium|
|GDP||Generic Device Profile, a profile to support compatibility, as well as collect common functionality, between current and future profiles.|
|SoC||System-on-chip, an IC consisting of micro-controller as well as the radio transceiver like the CC253x devices.|
|UART||Universal Asynchronous Receiver/Transmitter|
|SPI||Serial Peripheral Interface|
|API||Application Programming Interface|
|RNP||RemoTI Network Processor. An application configuration of the RemoTI stack that configures the CC253x device as a network processor|
|RCN||RF4CE Network Layer|
|RTI||RemoTI Application Framework|
|RNP||RemoTI Network Processor. An application configuration of the RemoTI stack that configures the CC253x device as a network processor|
|OS||Operating system ( software )|
|PHY||Physical layer ( layer 1 of a communication protocol stack )|
|MAC||Medium Access Control ( layer 2 of a communication protocol stack )|
|PAN||Personal Area Network|
|STB||Set top box|
|IEEE||Institute of Electrical and Electronics Engineers|
|ZigBee RF4CE Specification Version 1.01 ( ZigBee Alliance document 094945r00ZB )|
|ZigBee RF4CE CERC Profile Specification ( ZigBee Alliance document 094946r00ZB )|
|ZigBee RF4CE ZRC Profile Specification Errata Version 1.00 ( ZigBee Alliance document 095275r10ZB )|
|ZigBee RF4CE ZRC2.0 Profile Specification (ZigBee Alliance document 13-0442-23, http://www.zigbee.org/zigbee-for-developers/applicationstandards/zigbee-remote-control/)|
|ZigBee RF4CE Generic Device Profile Version 2.0|
|ZRC Profile Action Banks Version 1.0.0 ( ZigBee Alliance document )|
|IEEE Std. 802.15.4-2006, Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs).|
|CC253x Users Guide, SWRU191, http://www.ti.com/lit/SWRU191 -|
|RemoTI API document, SWRA268, can be found in the installation folder of RemoTI|
|OSAL API document, SWRA194, can be found in the installation folder of RemoTI|
|HAL Driver API document, SWRA193, can be found in the installation folder of RemoTI;|
|RemoTI Network Processor Interface Specification, can be found in the installation folder of RemoTI|
|RemoTI Sample Applications User’s Guide, SWRU201, http://www.ti.com/lit/SWRU201|
|RemoTI SimpleApp App Note, SWRA286, http://www.ti.com/lit/SWRA286|
|RemoTI Power Consumption App Note, SWRA263, http://www.ti.com/lit/SWRA263|
|RemoTI Coexistence Testing App Note, SWRA285, http://www.ti.com/lit/SWRA285|
|RemoTI Network Layer API, SWRA268, can be found in the installation folder of RemoTI|
RF4CE (Radio Frequency for Consumer Electronics) is an industry consortium that was formed to create a new protocol standard for RF-based remote control applications in the consumer electronics segment. The consortium was founded by Sony, Philips, Samsung and Panasonic with Texas Instruments, Freescale and OKI Semiconductor as the contributing members.
The first version of the network specification and application profile was completed in December’08. Later, in March’09, the RF4CE consortium merged with the ZigBee Alliance for the purpose of maintaining the specification going forward and managing the certification of platforms and products that conform to the specification.
The name of the specification is now ZigBee RF4CE. For more information, see http://www.zigbee.org/rf4ce
The RF4CE protocol stack architecture is illustrated in Figure 1. It is based on the IEEE 802.15.4-2006 standard.
The PHY layer is a 250kbps DSSS (direct sequence spread spectrum) radio operating in the 2.4-GHz band. The 2.4-GHz band is an unlicensed ISM band and is available worldwide. This makes it an attractive choice for consumer electronics applications as they are usually targeted for global markets. The spread spectrum modulation scheme provides a robust wireless link that is resistant to fading and interference.
There are 16 channels available at the 2.4-GHz band for 802.15.4 operation. These are numbered 11 through 26 and the center frequency of each channel is Fc = 2405 + 5 (k – 11) MHz, for k = 11, 12, …, 26. The RF4CE protocol has selected 3 of those channels (channels 15, 20 and 25) for operation. These channels were selected to minimize interference from WiFi networks.
The MAC layer provides a scheme for transmission and acknowledgment of packets up to 128 bytes in length. It uses a CSMA-CA (carrier sense multiple access with collision avoidance) mechanism for channel access and packet transmission. This allows multiple devices to coexist in the same vicinity and share the same radio spectrum. On top of that is the network layer that contains the core RF4CE functionality. These include
- Node discovery mechanism
- Pairing features to allow simple, foolproof way of connecting appropriate nodes together
- Power savings features to maximize battery life on remote controls and minimize standby power consumption on appliances
- Frequency agility mechanism to dynamically detect and avoid interference
- Security features
- Reliable packet transfer with multiple options and ability to carry standard and vendor-specific profile commands
The application framework contains a standard application profile called ZRC that defines most of the commands used in simple remote control applications and is also extensible with vendor-specific commands. It is also possible for users to define their own private profile with fully proprietary commands.
The ZigBee Alliance has put in place a test and certification program for RF4CE products. There are two kinds of certifications available – Platform certification and Product certification. The platform certification is for suppliers of RF4CE hardware and software. It includes testing of the network layer and below for compliance to the specification as well as interoperability with other implementations. It is intended so that developers who use or evaluate RF4CE platforms from various suppliers can be assured of the technical features supported by the platform and over-air interoperability with platforms from other suppliers.
The product certification is an optional step for manufacturers of end products incorporating RF4CE functionality. The purpose of this certification is to ensure that end products made by different vendors will inter-operate with each other. It is necessary to start with a certified platform and use a standard application profile in order to achieve this certification. More details on the certification program can be ZigBee website.
RemoTI is a complete hardware and software development kit from Texas Instruments for developing RF4CE-compliant applications. It is based on the CC253x devices, true SoC (System-On-Chip) solutions for 2.4-GHz 802.15.4 applications [R5].
The CC253x devices combine an 802.15.4 RF transceiver, micro-controller, up to 256-KB of in-system programmable flash memory, up to 8-KB of RAM and a full range of peripherals.
The RemoTI software package includes an RF4CE-compliant protocol stack, the ZRC2.0 and GDP2.0 profiles, sample application code and PC tools. The RemoTI hardware and software package is a RF4CE Certified Platform. It is also a Golden Unit for compliance testing and certification, which means that other implementations of the RF4CE stack have to be tested against it before being issued compliance certification.
Stack architectureFigure 2. It consists of the following software components.
This is a simple operating system environment for the SoC. It includes features for task management, message passing, queuing, memory management, timers etc. This component is included as source code. The API and additional details are available in the OSAL API document [R8].
Hardware abstraction layer (HAL)
This component provides an abstract interface to the hardware available on chip and on the board. It includes firmware for the UART, I2C and SPI communication interfaces, Keypad on the remote control, LED’s and IR generation. This code is included in source to allow the user to modify to suit the hardware available on their product. The API and additional details are available in the HAL Driver API document [R9].
This is the core RF4CE stack and includes the RF4CE network layer, the IEEE 802.15.4 MAC layer and the radio firmware. This component in included as an object code library. More details including the API are available in the RemoTI API document [R15].
This is an implementation of the RF4CE profiles; GDP2.0 and ZRC2.0. It includes the pairing mechanism defined in ZRC profile. There are also additional test mode features available. This component is included as source code. More details including the API are available in the RemoTI API document [R7].
These consist of sample code demonstrating how to easily build different applications with the RemoTI stack.
The AdvancedRemote sample application implements the features of advanced programmable RF4CE remote with motion sensors (3-axis accelerometer and 3-axis gyroscope), enabling air mouse functionality with Movea's motion sensing SW. For more details please see the Advanced Remote User's Guide.
The NetworkProcessor application implements either a Originator or Recipient node that communicates with a host processor over UART or SPI interface.
The serial boot-loader feature is available with the NetworkProcessor application and can be used to upgrade the firmware on the Target node from the host processor.
More details on the sample applications are available in the RemoTI Sample Applications User’s Guide document [R10].
The RemoTI software API is described in detail in [R7]. Note that the API is exposed at both the RCN and RTI layers. The application developer can choose to develop to either of them.
The RTI layer includes the ZRC application profile as well as the test mode features. So it is easier and quicker for the user to develop a complete solution.
The RCN layer exposes the full functionality of the RF4CE network layer specification and thus provides more features and flexibility for the application developer. However, it is best if the developer has access to the network layer API as defined in the specification [R1] to effectively use all these features. However, the user would have to implement mechanisms for features like pairing etc. that are included with RTI.
Topology and node types
Logical node type
There are two logical nodes types in RF4CE – Target and Controller. The logical node type determines the role and functionality of the node in the RF4CE communication paradigm. Figure 3 illustrates the mapping of the end product functionality to the logical node types.
The Target node type is intended to be used in end products like TV, STB etc. This node type is capable of establishing its own network and can allow other nodes to establish pairing links with it.
A Target node implements Frequency Agility function and can change its operating channel as necessary based on local interference conditions. Since this node is usually the recipient of the application data packets, its radio is placed in the “receive” state when the node is idle (except when it is placed in a special “standby” mode where the radio receiver is duty-cycled to conserve power consumption). So, it is typically used in main-powered nodes (like TV, STB etc.).
The Controller node type is intended for use in applications like remote controls etc. A Controller node will typically establish pairing links with one or more Target nodes in its neighborhood and send application data packets. This node is usually the initiator of transmissions, so its radio may be turned off when in idle state. So this node type is suitable for battery operated nodes.
RF4CE is a fully peer-to-peer system with direct communications between nodes. Figure 4 show some possible example topologies. Note that the nodes shown in the topologies should not be considered to be part of a single network. Instead, it is more accurate to consider each node as a free-standing entity with the ability to communicate with other nodes that are within its radio range.
All 802.15.4 devices must have a 64-bit IEEE address (also called as extended address or 64-bit address).
These addresses are globally unique and are assigned and maintained by the IEEE organization, they are fixed for the life of the device. More information on these addresses is available at the following website http://standards.ieee.org/regauth/oui/index.shtml.
Each CC253x device comes pre-programmed with its own unique 64-bit IEEE address. This is located within the flash information page of the chip. So the user is not mandate to procure or program the IEEE address.
In some situations, the user may wish to use their own IEEE address in their end products. The RemoTI stack contains provisions for allowing this by reserving a fixed flash location, the 8 bytes starting at offset 0x7E8 on the last flash page, for this purpose (note that this location is just before the flash lock bits, see [R6]).
The user can program their own IEEE address at this location in little-endian order. If the user does not wish to use this feature, this location must be filled with the default all 0xFF’s value. Upon start-up, the RemoTI stack will first check the reserved location above for a valid IEEE address. If it finds any value other all 0xFF’s, it will use that as the device IEEE address. If that location is filled with all 0xFF’s, then the stack will use the IEEE address programmed in the CC253x information page.
When operating in an 802.15.4 network, a device may use a shorter 16-bit address to reduce overhead in packet transmissions. This is called the short address. This address is only unique among devices that are on that network.
In RF4CE, the Target nodes automatically assign themselves a short address when first initialized. This is in the ShortAddress state attribute. The Controller nodes are assigned a different short address by each of the Target nodes they are paired with. This is stored in the nwkAddress field of the pairing entry. The Controller uses the appropriate short address when communicating with each Target. This is automatically taken care of by the RemoTI stack.
The RF4CE network layer may be initialized in either a “warm” start or a “cold” start mode. A “warm” start-up is when a node was previously operational in an RF4CE network and is restarting operation with the same setup. This is usually the case when the node undergoes a reset either accidentally or due to battery change etc. In this case, it is expected that the node will operate exactly as before by restoring pairing tables and network information from non-volatile memory. A “cold” start-up is when a node is starting operation for the first time. In some cases, the node may have been previously started but the application does not want to restore the previous state and instead wants to perform a fresh start. In this case also, a “cold” start may be used. In this case, any saved network layer information will be ignored. When using the RTI interface, the start mode can be chosen via the StartupOption configuration parameter.
Target Cold Start
When a Target is first initialized, it first does a scan of the channels (channel numbers 15, 20 and 25) for energy levels as well as existing 802.15.4 systems. It selects the channel with the lowest energy level as the operational channel (CurrentChannel state attribute). It then selects a random 16-bit value as the network identifier (PAN ID in 802.15.4 MAC terminology) and also allocates itself a random 16-bit number as the short address. It then starts an 802.15.4 PAN. The Target will also allocate short addresses to any node that pairs with it. The PAN ID is random, but not equal to any of the other PANs discovered during the initial scan phase. All Target nodes must respond with its PAN ID to a Beacon Request, which is what the Target node transmits during the scan phase.
For this reason it is highly recommended that a Target performs a cold start when the device is deployed at its final destination, in other words when the device has reached its final destination. It is possible to enable a cold start at any time, so a network can be created at several production stages. This is, as an example, useful if communication is required on the factory floor.
In the RemoTI implementation a cold start is requested by setting the startup flag to
CLEAR_STATE before calling
. uint8 startupFlg = CLEAR_STATE; // Set startup flag to CLEAR_STATE to enable cold start. RTI_WriteItemEx(RTI_PROFILE_RTI, RTI_CP_ITEM_STARTUP_CTRL, 1, &startupFlg); // Then call initialize stack RTI_InitReq();
Typical node start-up sequence using RTI interface
Most RF protocols employ some sort of medium sharing. For centralized systems, such as mobile networks, medium sharing is organized by a central node, e.g. a base station, which may allocate time slots or as in LTE resource elements (both time and frequency). In decentralized systems, that are designed to operate in the same frequency band, such as RF4CE, it is very common to use a "listen before talk" method.
As RF4CE builds on 802.15.4 the underlying transmission is based on CSMA-CA, which stands for "Carrier Sense Multiple Access with Collision Avoidance". What this means is that before you are allowed to transmit you need to listen for a given period to make sure nobody else is transmitting. If you sense something, then you need to wait. There's an algorithm defining how you should wait, or back off as it is called, and this is the "Collision Avoidance" part of the algorithm. If all nodes back off the same way then it would not make much sense, as you are likely to be attempting to transmit at the same time, after you both found the medium available. Instead the algorithm is such that you back off a random duration. This random duration will increase between attempts by a an exponent, simply called a back off exponent.
There are different ways you can sense if the medium is busy. The most conservative, or friendly, is to check for energy only. You can also define how friendly you want to be by setting the CCA threshold. CCA stands for Clear Channel Assessment. By default RemoTI is very friendly in that the threshold is set to -84dBm.
In RemoTI-1.3.1 (and older) this threshold is configurable compile time via
int8 rcnCCATh = RCN_CCA_TH_FROM_RSSI(-84);
For embedded solutions it is also runtime configurable simply by setting
rcnCCATh to a different value
In RemoTI-1.4.0 this threshold is accessible via
int8 newCCAthreshold = -75; // Set new CCA threshold; -75dBm RTI_WriteItemEx(RTI_PROFILE_RTI, RTI_SA_ITEM_CCA_THRESHOLD, 1, (uint8 *)&newCCAthreshold);
Since it is accessible via
RTI_WriteItemEx() it can be controlled in Network Processor configurations as well.
All communications in RF4CE occur via direct, point-to-point transmissions, or point to multi-points transmissions. There is no relaying or routing capability. Figure 6 shows a sniffer capture of a typical RF4CE packet with a standard profile command. Note that the header overhead added by the network layer varies depending on whether or not security is used etc. But in all cases, the application will have at least 90 bytes of payload available in each packet.
The RF4CE protocol contains several transmission options that are available to the application when requesting a packet transmission to another paired node. These are described in the following section.
This option determines whether the source node should request an acknowledgment (802.15.4 MAC-level acknowledgment) from the destination node upon receipt of the original packet.
This option determines if the packet is transmitted to a specific destination node (unicast) or if it is broadcast to all nodes that are in radio range of the source node.
MultiChannel or SingleChannel
This option determines if the packet is transmitted on a single channel or on all three RF4CE operational channels.
Combinations of transmission options
The combination of these options is summarized in Table 1.
|Unicast/Ack/SC|| The packet is transmitted on a single channel (taken from the pairing entry for the destination node). The packet will be re-transmitted on this channel for up to
||This option can be used to achieve high data throughput if the destination channel is fixed (using application-specific means). The limited retransmissions provide some level of reliability.|
|Unicast/Ack/MC|| The operation is similar to the Unicast/Ack/SC with the exception that, if no acknowledgment is received, the node will continue to re-transmit the packet on all three channels sequentially (e.g., C1-C2-C3-C1-C2…) for up to 1 second (
||This is the most reliable option and it should be used by default.|
|Unicast/NoAck/SC||The packet is transmitted once on a single channel (taken from the pairing entry for the destination node).||This option can be used to achieve even higher data throughputs than the Unicast/Ack/SC mode. The reliability is lower due to lack of retransmissions. The destination channel should be known to the sender for this option to be useful.|
|Unicast/NoAck/MC||The packet is transmitted once on each of the three RF4CE channels.||This is intended for application-specific uses.|
|Broadcast/Ack/MC||This is an invalid combination of options.|
|Broadcast/Ack/ SC||This is an invalid combination of options.|
|Broadcast/NoAck/SC|| The packet is broadcast once on a single channel (set to
||This is used to reach all nodes within radio range on a specific channel.|
|Broadcast/NoAck/MC|| The packet is broadcast once on each of the three RF4CE channels (starting with
||This is used to reach all nodes within radio range.|
To transmit a data packet, use the
The transmission options for each packet transmission are selected via the txOptions parameter in this function. The application must wait for the completion of the packet transmission (i.e., until the
RTI_SendDataCnf() callback is issued by the stack) before issuing another request.
Note that a pairing must have been previously established between the two nodes before the applications can exchange data.
When a Target node is placed in Standby mode, its radio receiver is being duty-cycled (see chapter 8.2 for more details).
Consequently, it can only reliably receive packets that are transmitted with the Unicast/Ack/MC transmission option. Hence, the other transmission options should only be used if the sending node is aware that the destination is in active mode.
The generic device profile implements the generic services used by all RF4CE application profiles. These features includes:
- A validation based binding protocol that enables user validation of an RF4CE pairing link. The validation can be achieved by different methods including interactive user inputs, out-of-band configuration etc.
- Mechanisms to exchange and configure profile attributes with a peer device.
- A key exchange scheme to enable enhanced security link key with a peer device.
- Implements optional Notification Server & Client feature to add the ability to update action mappings throughout the life time.
- Implements the optional Poll server and client to allow bidirectional communication between mains powered and battery operated device.
GDP profile implementation can be found in profiles/GDP folder. The GDP attribute items can be configured by
RTI_WriteItemEx(RTI_PROFILE_GDP, attributeID) and
RTI_ReadItemEx(RTI_PROFILE_GDP, attributeID) functions call. The attribute data structure and attribute ID’s are defined in gdp.h file. The gdp.c acts as interface between RTI layer rti.c and GDP specific processing. At the originator node gdp_originator_task.c handle all GDP profile implementation related event processing and at recipient node GDP event processing is handled in gdp_recipient_task.c file.
The ZRC 2.0 specification defines the application profile support to consumer electronics remote control applications. It is implemented at the top of RF4CE network layer and uses the services and procedures defined in GDP 2.0 application profile.
The profile defines the two type of devices:
- ZRC Originator : a node that can originate the binding procedure and can be realized by either RF4CE controller node (remote control) or target node such as TV , Set Top box etc.
- ZRC Recipient : a node that receives the binding request and can be realized by the RF4CE target node only.
The more detail on ZRC profile specification can be found in [R4]. The default ZRC profile configuration parameters are initialized in
zrc_InitItems() function in zrc.c file. The ZRC configuration parameters can be accessed by
RTI_WriteItemEx() functions by passing
RTI_PROFILE_ZRC and attribute ID of the configuration parameters. The ZRC profile attributes IDs and data structures are defined in zrc_profile.h file.
A pairing is a logical link between two nodes at the application layer.
Binding is logical association between nodes at the profile layer, it involves:
- Pairing the nodes at the RF4CE-NWK layer
- Performing a mutual configuration and validation at the GDP layer.
It is mandatory to make bond between two nodes before they can exchange application level data packets. Typically, a bonding is created between a target and a controller node. However, it is also possible to also create bonding between two target nodes. When a bonding is successful a link is created and the application is given a link identifier.
The application can then send packets to the destination by referring to the link identifier. Note that this identifier has significance only within the node. The RemoTI network layer will store the pairing table entries in non-volatile memory. So when a node is power-cycled, it will be able to restore its previous pairing links along with other network information (assuming it goes through a “warm” start-up).
The binding can be invoked simply by calling
RTI_BindReq() upon receiving a binding trigger on the Originator node which in turn starts the discovery, pairing and profile configuration processing in sequence.
When GDP performs discovery, it specifies the ZRC 1.1 and 2.0 profiles and searches for any device type. This behavior is defined in
configParamTable located in rti.h, and is read at the time of generating a discovery request in the GDP profile
GDP filters the discovered node descriptor by looking at the device type of the node descriptor. The device type list of a node descriptor is compared against the supported target device type list set by a RTI configuration parameter
RTI_CP_ITEM_NODE_SUPPORTED_TGT_TYPES. Supported target types can be set up to six entries. In order to change this behavior, modify the
gdpDoCheckNodeDeviceCapabilities() function. In order to simply increase the maximum number of supported target types, change
RTI_MAX_NUM_SUPPORTED_TGT_TYPES constant in rti.h file and rebuild RTI module: rti.c file.
Once discovery completes with an acceptable node descriptor, a
rcnNlmePairReq_t structure is built and the
RCN_NlmePairReq() function is called to move on with the network layer pairing procedure. See the
gdpPo_SendPairRequest() function for details. Upon reception of successful pairing conformation,
rtiOnNlmePairCnf() function called in rti.c file, binding process moves to the configuration process by calling
The successful configuration procedure will create a temporary pairing with the best pairing candidate and indication of starting of validation process is passed to the originator node. The validation procedure is initiated by calling
gdpBo_StartValidation() at binding originator end. The stack at the originator node will inform the application via
RTI_StartValidationInd() function call.
At this point if the recipient is initiating the validation based binding, it required recipient application to generate the validation key and wait for reception of the correct key from binding originator node. If the push button based paring is initiated, this step is skipped and binding is considered complete. The binding is considered complete upon upon successful validation. Once the validation is complete the pairing table is then stored in NV memory.
When binding successfully completes, the application sets the destination target (
rsaDestIndex, used for destination of any commands till next change) with the newly bound entry in the
RTI_BindCnf() callback function. This RTI callback function is triggered from the GDP profile when validation is successful.
The binding process at binding originator node is shown in figure below.
GDP Validation based bonding
The GDP validation based binding requires explicit user validation at the recipient end to complete the binding. It may involves the recipient node to generate some validation key and reception of validation key from binding originator node. The key code can be received either out of bound or in bound (button press)validation. GDP2.0 application profile defines two validation modes:
- Normal validation mode- The binding recipient waits for
aplcMaxNormalValidationDurationfor completion of validation process
- Extended validation mode - In this mode
aplcMaxNormalValidationDurationto allow enhanced validation if binding originator supports it. The enhance security mode is defined in section 9.2.
These timeout are defined in gdp.h file. For button pressed pin code based validation, the binding originator can transmit the pin code keys using the action command data via calling
RTI_SendDataReq() function. For example application see the
rsaBuildAndSendZrc20Report() function of rsa_point.c file in Advanced Remote Application . At the binding recipient node, the stack function
rtiOnNldeDataInd() passes the received the code keys to recipient application by calling RTI_ReceiveDataInd() function.
The “push-button” binding mechanism established binding between two nodes, without requiring user to enter the pin code at originator node as it requires for validation based bonding.
In this scheme, the user has to “push a button” on each of the two nodes in order to establish pairing. To use this pairing mechanism, the application on the target should issue the
RTI_AllowBindReq() function call while the application on the controller ( or target in case of target-to-target pairing ) should issue the
The functions may be invoked on the nodes in any order. However, there is timeout of 30 seconds specified in ZRC profile to ensure the procedure terminates in case of any error. Refer to the Advanced Remote Application for some example of user application software performing the bonding.
Note that the term “push button” is used figuratively to represent a stimulus to the application to invoke the necessary functions. This stimulus can be via a user action (like a button push) or via some other means. The user application is responsible for detecting the stimulus and invoking the appropriate functions. For example, a target node application may check upon power-up if it is already bonded, and if not, automatically invokes the function.
Pairing table entry
The detailed structure of the pairing table entry should be found from the interface definition files in the software package (see rcn_attribs.h file).
Each pairing entry requires 61 bytes of data memory and non-volatile memory space.
The pairing table entries can be accessed via the
RTI_WriteIndexedItemEx() functions by providing the index to be read.
See [R7] for more information about this API.
Maximum number of entries
The maximum number of pairing links that can be supported by a node is defined by the
MaxPairingTableEntries constant parameter.
This is set to 10 is most of the sample application project. However, some project like the advance remote application sets it to 5. Note that it is possible to have more than 10 table entries, however that will require different software libraries that can support the extra entries.
In order to successfully create a pairing link, it is important that the two nodes have complementary applications. This requires that the
SupportedTargetTypes configuration parameter on the Controller and the
DeviceTypeList configuration parameter on the Target must have at least one common device type.
Bonding with security
If security is enabled for the nodes involved in a bonding, the bonding process will have shorter range due to the key distribution protocol (see chapter 9.2).
Note that ZRC2.0 profile mandates the usage of security.
In some cases, it may be necessary to unbind/unpair an existing link or to delete existing binding entries.
To remove all binding entries in a node, a reset followed by a cold start-up will be sufficient.
To remove a single binding/pairing entry, the entry should be read, modified by setting the
pairingRef member field to an invalid value of
0xFF and then written back.
Note that these methods of removing the pairing table entries will not remove the entry from the corresponding nodes. For a clean unbind/unpair where the nodes at both ends of the pairing link can remove the entry, the RTI implementation of ZRC profile provides a
RTI_UnbindReq() function for unbinding and RCN interface provides a
RCN_NlmeUnpairReq() function for unpair.
Note that the standard ZRC profile does not provide an unbinding/unpairing mechanism.
Actions and Action Banks
An action is a command generated at the originator node as a result of an event such as key press or via any other trigger, and sent to the recipient node to fulfill the requested action. The ZRC application profile defines the standard data format for transaction of such command frames. More detail on action data frame can found in ZRC profile specification [R4]. Based on the type of device action is intended to, the ZRC profile categorizes them into various action banks. The action code is one byte data in action command frame, which specifies the action bank. These categories are:
- HDMI-CEC - The HDMI CEC action bank supports the use of up to 256 different User Control codes for the HDMI CEC class devices.
- HID - This usage page supports 256 action banks to support HID devices such as keyboard, consumer control, pointing devices etc. The HID usage tables that contain more than 256 different usage ID’s, are split over multiple action banks.
- Home automation - The home automation action bank defines 256 commands to support home automation devices.
- Vendor Specific- In addition to standard action banks defined in previous three categories, the ZRC profile reserves three action bank ranges for vendor specific action banks.
- 0xA0-0xBF: Implicit vendor ID, assumed to be equal to the vendor ID of the source.
- 0xC0-0xDF: Implicit, vendor ID assumed to be equal to the vendor ID of the recipient.
- 0xE0-0xFF: Explicitly included in the action data, as a command vendor field.
- The action banks and action classes are defined in zrc_profile.h file. The action banks and action codes are exchanged during the configuration phase of binding process after GDP profile configuration is complete, by calling the
zrcBo_StartProfileConfiguration()function at the originator node. This function is implemented in zrc_configuration_originator.c file. The more detail information regarding HDMI-CEC, HID and HA action banks can be found in [R5].
The action mapping allows a node to program it's available triggers with the action commands defined by its peer node. It involves sending the triggers for mapping by the action mapping client to action mapping server and the action mapping server updating its list of existing mappable actions for this client. An action mapping client is a node that has mappable actions that can be remapped by the Action Mapping Server, it can be a ZRC Originator or ZRC Recipient. An action Mapping Server is a ZRC Originator or ZRC Recipient node that can remap the mappable actions of an Action Mapping Client
The action mapping client and action mapping server can reside either at originator or recipient node. The action mapping client may push a full or partial list of its mappable actions at any time. It also allows the action mapping client to invalidate one of the existing mappable actions on the server by pushing the entry with the corresponding index and setting the action device type for this entry to 0xFF. It also gives to action mapping server the flexibility to update the action mapping at action mapping client any time by sending the client notification command frame with either “Request Action Mapping Negotiation” sub type for a full update or with “Request Selective Action Mapping Update” for partial update.The more detail about action mapping can be found in [R4].
The action mapping client is implemented in zrc_action_mapping_client.c file and action mapping server is implemented in zrc_action_mapping_server.c file. The action mapping can be initiated any time after the successful binding.
For mapping the actions, first mappable actions needs to sent to the recipient node. The action mapping client initiates the action mapping by calling the
RTI_SendMappableActionsReq(mappable actions) function. The action mapping server maps the actions, and then the action mappings are retrieved from the recipient node by calling the
RTI_GetActionMappingsReq() function call. The stack sends each received action mapping from peer node to the application via calling
The bidirectional communication between the nodes is achieved via GDP polling feature.
A node indicate the poll server capability by setting
supportPollServer bit to ‘1’ in the
aplGDPCapabilites attribute, and the other node, involved in the binding process, indicates that it can act as a Poll Client by setting both
supportPollClient bit to ‘1’ in the
The poll client functionality is implemented in gdp_poll_client.c file and poll server functionality is implemented in gdp_poll_server.c file. If one of the nodes involved in binding can provide poll client and the other node serves as poll server functionality, the poll negotiation process is initiated by the node client by calling
RTI_PollConfigReq() function implemented in rti.c file.
This in turn starts pushing the polling constraint by calling
gdpPc_StartPollConfig() function in gdp_poll_client.c file. The poll client pushes the poll constraints to the poll server by calling
RTI_PollConfigReq() function call, which in turn sent to the poll server via network layer. The poll client then pulls the assigned poll configuration from poll server by transmitting a Pull Attributes command frame, containing the
aplPollConfiguration attribute, from the poll server. During poll configuration, the poll client negotiates the use of the GDP Heartbeat method for polling, and poll triggers which can be timer event/key press event/reset or any other event type defined in GDP profile. The poll configuration attribute and triggers are defined in gdp_profile.h.
Once the configuration is complete, it can poll the server on poll triggers by calling
RTI_PollReq() function. If the poll client negotiates the use of the GDP Heartbeat method for polling, it transmits the GDP Heartbeat command on poll trigger timeout.
In the poll server, the reception of the heart-beat command via network layer in
rtiOnNldeDataInd() function is passed to the GDPlayer processing function
gdpNrProcessHeartbeat() inquires for any queued-up message by calling
gdpNrProcessPollRsp() function. If there is any queued messages, it keeps transmitting the messages unless all messages are transmitted. If there no message to transmit, server sends generic response message, which completes the poll cycle.
Polling- Client Identification
If a polling client is realized on battery operated remote control which is bind to a target recipient, the GDP client notification sub type Identify can be used to implement client Identify feature such as 'Find my remote'. The procedure is shown in the figure below.
Polling- Poll Negotiation
If a polling client is realized on a battery operated node such as remote control which is bind to a target recipient node, the GDP client notification sub type Req Poll Negotiation can be used initiate poll configuration any time after binding and initial configuration using GDP polling feature. The message exchange between peer nodes and between application and RTI layer for this procedure is shown in the figure below. The RTI layer also interact with profile layer for intermediate data processing.
Polling- Action Mapping Negotiation
If the action mapping client resides on originator node, it can initiate action any time by calling
RTI_SendMappableActionsReq(mappable actions) to the recipient node. If a recipient node is realized on the target which is bind to the battery operated originator (node such as Remote Control), and is wishing to initiate the action mapping, then it has first check whether the originator node has polling capability. If the originator node has polling capability, then it waits for reception of the originator's polling command. In response to the polling command it sends ClientNotification(RequestActionMappingNegotiation) command frame to initiate action mapping. If the recipient and originator has negotiated the GDP heartbeat polling, the recipient initiated action mapping negotiation procedure is shown in figure below. This message sequence diagram shows over-the-air message exchange between recipient and originator nodes and interaction between RTI layer and application. The RTI layer also interact with profile stack which is shown in shaded.
RemoTI has automatic power savings feature for both target and controller nodes. The power savings include control of the radio as well as the MCU. For detailed measurements of the actual power consumption in various configurations as well as oscilloscope captures, please refer to [R13].
A controller node is normally the originator of a packet transmission. So it has the radio turned off by default. When a packet transmission is initiated, the stack will automatically turn on the radio for the duration of the transmission as well as the reception of any acknowledgment, if necessary. If the application wishes to keep the radio receiver turned on during other times, it has to explicitly control it via the
RTI_RxEnableReq() function. This is usually used when the application transmits a packet and is expecting a response from the destination node (for example, in two-way remote applications).
A target node is normally the recipient of packets. So the radio receiver is turned on by default. However, to conserve power during long periods of inactivity, it is possible to put the node in Standby mode by invoking the
RTI_StandbyReq() function. In this mode, the radio receiver is automatically duty-cycled to reduce power consumption. The stack will keep the receiver turned on for a brief time window periodically. If a packet is detected during that time, the receiver will be kept turned on until the whole packet is received and passed up to the application layer. The node will continue to remain in Standby mode. The application has to explicitly bring the node out of Standby mode, if it chooses to, based on the contents of the received packet. The duty cycling of the Standby mode is shown in Figure below.
The StandBy mode parameters can be configured through the
DefaultStandbyActivePeriod and the
DefaultStandbyDutyCycle configuration parameters. Note that these are only valid for a Target node type. The RF4CE specification requires that the active period is at least 16 milliseconds and that the duty cycle period is at most 1 second. When the target is in this mode, any node that wishes to send data to it has to use the default transmission options ( Unicast/Ack/MC ). This will cause the packet to be retransmitted continuously on all channels and one of the transmissions will overlap with the receiver active period within the duty cycle period. If target power savings is not important, the
DefaultStandbyDutyCycle parameter value can be reduced. This will improve the responsiveness (reduced packet latency) of the target node when it is in StandBy mode.
MCU power control
The RemoTI stack OS has ability to put the CC253x processor in low power mode automatically based on software activity. The MCU sleep mode is controlled by the application via the
RTI_DisableSleepReq() functions. If MCU sleep is enabled, the processor will automatically be put into a low power mode if there are no software events to process. If there is an event(s) scheduled for a future time, the processor will be put in a low power mode with the sleep timer running for the necessary time and then reactivated at the appropriate time. If no future events are scheduled, the processor will be put into a low power mode without the sleep timer operating. In this case, it can be reactivated through an external interrupt (like a button push, host processor control signal etc.). For details on the CC253x devices’ processor and its low power modes and sleep timer, refer to [R6].
MCU sleep with RNP
When using the RNP (RemoTI Network Processor), the MCU power management mechanisms for the host processor and the RNP have to be designed carefully so that communication between the two processors is not lost. The details of the RNP interface with the host processor are available in [R10].
When using the RNP configured with SPI transport, the MCU sleep mode can be permanently enabled. This is because the SPI transport interface is designed to automatically wakeup the RNP (via the MRDY signal) when the host wishes to communicate with it. It also provides for a wakeup signal (SRDY) from the RNP to the host so that the host processor can also enter low power mode and still receive asynchronous communications from the RNP.
If using the RNP configured with UART transport, enabling the MCU sleep mode will disable the UART receiver on the RNP. If the host processor wants to communicate with an RNP that has MCU sleep enabled, it should first transmit a NULL character (
0x00) and then wait to receive a NULL character in return. This exchange will bring the RNP processor out of any low power mode and also disable the MCU sleep mode. After this, regular UART communications can take place with the RNP. The host processor must re-enable the MCU sleep mode if it wishes the RNP processor to enter low power mode at a later point. Note that the RNP assumes that the host processor is always ready to receive to UART communications. Some host processors (like the MSP430 processor family) can automatically come out of low power mode when detecting activity on its UART receiver.
The RF4CE protocol stack provides built in security feature. Since RF transmission is omni-directional unlike IR and can have a larger transmission range, it is possible for a person to exercise RF control from a longer range. This is usually a useful feature; however it can also be misused. To prevent such a scenario, it is recommended that all RF remote control applications should use security. RF4CE supports a network layer security mechanism that is used if the applications on both ends of the pairing link choose to use security. If security is desired, a security key is established automatically during the pairing process. The security mechanism in RF4CE is based on the AES-CCM mode of operation. This is a well-known security scheme that is also used in many other wireless protocols. The security mechanism provides the following features:
- Privacy – The application payload is encrypted to prevent eavesdroppers from reading the contents.
- Message integrity – The application payload is protected with a message integrity check to prevent modification of the contents.
- Replay protection – The packets are stamped with a frame counter to prevent the same packet from being recorded and retransmitted at a later time.
The C253x devices have hardware AES and CCM engines that are used to apply security as well as hardware random number generator that is used to generate random keys.
To setup a security key during the pairing process, use the security capable sub-field of
NodeCapabilities configuration parameter. Security is setup for a pairing link if both nodes have this option enabled. Once security is setup, it can be enabled or disabled on a packet by packet basis. When sending a data packet, security is chosen via the
txOption parameter in the
RTI_SendDataReq() function. If this option is chosen but no security key is setup, an error will result. It is recommended that security is always enabled on a node and for each packet transmission.
The security key distribution occurs within the pairing procedure. The Target node generates the key during the pairing process and distributes it to the Controller node in a number of packets transmitted using low transmit power.
The actual key that will be used for security is automatically generated by the RemoTI network layer. The CC253x hardware random number generator is used to generate the security material.
The optional enhanced security key negotiation feature can be enabled by setting the enhanced security GDP capabilities attribute via
RTI_WriteItemEx with item id
GDP_ITEM_GDP_CAPABILITIES. Once setup, if both nodes support enhanced security, the security key exchange can be initiated by the originator any time after binding. To initiate the key exchange, the originator should call
RTI_KeyExchangeReq with the desired destination index and appropriate flags.
Enhanced Security is based on a "secret" key that both nodes are aware of. By default the stack uses the "Default secret" described in the GDP profile. Note that this value is expected to be widely known, so a Vendor-specific secret should be used. The secret key can be updated via
RTI_WriteItemEx of the
By default enhanced security is enabled and compiled in the stack. To disable, set to
RCN_FEATURE_ENHANCED_SECURITY pre-processor define. A stack library with enhanced security disabled will also be needed.
Note that the RF4CE security scheme has a “window of vulnerability” during the key distribution process. If a malicious user is sniffing the channels at the exact time and location when the pairing link is established, the key can be compromised. This will render all future security useless. It is assumed that the chances of the above happening are quite small and acceptable. If that is not the case for a given application, a more robust, non-standard key distribution scheme should be used.
Secure pairing range
If security is used, the key distribution packets are transmitted using low transmit power ( -22dbm on the CC253x devices ). This means that the pairing process will only succeed if the two nodes are closer to each other than usual. The transmit power for the key distribution packets can be modified by the application developer through the
rcnSecKeyTxPwr parameter in the rcn_config.c file.
If security is enabled, each packet will have an additional security header of about 4 bytes. This will reduce total payload available to the application by the same amount.
Security is only available for unicast packets as the keys are setup in a pair-wise basis. Broadcast packets are transmitted without any security. So users should be careful to use broadcast packets only when necessary. Note that broadcast data frame can only be receive by device paired with the originator device. Alternately, an application may add application level encryption and decryption for specific broadcast packets using non-standard encryption. A security key to be used within a broadcast group may be exchanged using secure links already setup between the nodes. This key can be used to secure the application payload for broadcast packets.
The 2.4-GHz unlicensed band has a lot of interference sources like WiFi networks, microwave ovens, cordless phone and Bluetooth devices. The RF4CE network layer has the frequency agility feature which attempts to ensure that the system is always operating on the best available channel. For details on the actual performance of the RemoTI system in the presence of interference, refer to the RemoTI Coexistence Testing application note [R13]. Note that the performance depends both on the radio performance as well as the protocol stack.
The Target nodes are responsible for continuously measuring the local channel conditions and migrate to a new channel if there is interference on the current channel. The actual algorithm for determining when to migrate to a new channel is out-of-scope of the specification and is left up to to each implementation. The Controller node keeps track of the channel for each of the Target nodes it is paired with (this information is stored in the pairing table entry). When the application transmits a data packet, the network layer will automatically ensure that the channel is changed appropriately. However, it is possible that the Target has moved to a new channel and the information with the Controller is no longer accurate. In this case, if the MultiChannel txOption is used, the Controller will try to transmit the packet on all channels (if the initial transmission was a failure). If it successfully transmits the packet on a different channel, it will update the information accordingly.
It is possible to disable frequency agility. Do so by setting the state attribute
#define DISABLE 0 #define ENABLE 1 #define RTI_SA_ITEM_AGILITY_ENABLE 0x87 #define RTI_PROFILE_RTI 0xFF unsigned char value = DISABLE; // Disable Frequency Agility RTI_WriteItemEx(RTI_PROFILE_RTI, RTI_SA_ITEM_AGILITY_ENABLE, 0, &value); ... // Enable Frequency Agility value = ENABLE; RTI_WriteItemEx(RTI_PROFILE_RTI, RTI_SA_ITEM_AGILITY_ENABLE, 0, &value);
When Frequency Agility is disabled, the RF channel will stay on what it was the instant Frequency Agility was disabled. To check what the current channel is, do
#define RTI_SA_ITEM_CURRENT_CHANNEL 0x61 #define RTI_PROFILE_RTI 0xFF unsigned char currentChannel; // Get current channel RTI_ReadItemEx(RTI_PROFILE_RTI, RTI_SA_ITEM_CURRENT_CHANNEL, 0, ¤tChannel); printf("Current channel is %d", currentChannel); ... // Set current channel (15, 20 and 25 are valid) currentChannel = 15; RTI_WriteItemEx(RTI_PROFILE_RTI, RTI_SA_ITEM_CURRENT_CHANNEL, 0, ¤tChannel);
The Frequency Agility feature is built into the RemoTI network layer and is always operating in Target nodes.The basic operation is as follows (the parameters referred to below are in the rcn_config.c file)
- The network layer continuously measures the energy level on the current channel every 2 milliseconds.
- Among the last
rcnFAMinNumSamples(default 32) samples, the algorithm will verify if at least
rcnFANoisySamplesTh(default 16) have energy level above
rcnFALQIThlevel (default -72dBm)
- If the above condition is met, the channel is determined to be “busy” and the node will move to the next channel. Otherwise, the node will continue to collect new energy level samples and perform the above condition check.
The above algorithm ensures the target node will find the best available channel. However, there is a danger that all channels are “busy” according to the above algorithm and the Target node will be continuously moving between them. To reduce this problem, there is a second level algorithm that operates as follows
- If the node has migrated through all 3 channels without staying on any single channel for more than
rcnFAShortDurationThduration (default 60 seconds), then the node will temporarily suspend the basic algorithm operation for
rcnFASuspendDurduration (default 60 seconds). During this time, the node will migrate to the channel that had the best conditions (minimum number of noisy samples) in the most recent round of measurements.