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.

RemoTI Developers Guide

From Texas Instruments Wiki
Jump to: navigation, search


RemoTI Developer’s Guide

Acronyms and Definitions

API Application Programming Interface
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.
CERC Consumer Electronics for Remote Controls, the standard application profile defined by the RF4CE consortium
Controller A Node that implements the Controller functionality as defined in the RF4CE specification ( for example, a remote control )
Device A physical object consisting of an IEEE 802.15.4 radio
GDP Generic Device Profile, a profile to support compatibility, as well as collect common functionality, between current and future profiles.
ICall Indirect Call Framework
IEEE Institute of Electrical and Electronics Engineers
MAC Medium Access Control ( layer 2 of a communication protocol stack )
Node A device containing RF4CE functionality.
Originator The node from which a GDP transmission is sent.
OS Operating system ( software )
PAN Personal Area Network
PHY Physical layer ( layer 1 of a communication protocol stack )
RCN RF4CE Network Layer
Recipient The node to which a GDP transmission is directed.
RNP RemoTI Network Processor. An application configuration of the RemoTI stack that configures the CC253x or CC26xx device as a network processor
RSA Remote control Sample Appliciation example module
RTI RemoTI Application Framework
SoC System-on-chip, an IC consisting of micro-controller as well as the radio transceiver like the CC253x and CC26xx devices.
SPI Serial Peripheral Interface
STB Set top box
Target A Node that implements the Target functionality as defined in the RF4CE specification ( for example, a TV )
TV Television
UART Universal Asynchronous Receiver/Transmitter
ZRC ZigBee Remote Control, the standard remote control application profile defined by the ZigBee RF4CE consortium


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,
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, -
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,
RemoTI SimpleApp App Note, SWRA286,
RemoTI Power Consumption App Note, SWRA263,
RemoTI Coexistence Testing App Note, 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

RF4CE architecture

Figure 1: RF4CE protocol stack

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

  1. Node discovery mechanism
  2. Pairing features to allow simple, foolproof way of connecting appropriate nodes together
  3. Power savings features to maximize battery life on remote controls and minimize standby power consumption on appliances
  4. Frequency agility mechanism to dynamically detect and avoid interference
  5. Security features
  6. 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.

RF4CE certification

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 CC262x, and CC265x devices, which are true SoC (System-On-Chip) solutions for 2.4-GHz 802.15.4 applications [R5].

The CC262x and CC265x devices combine an 802.15.4 RF transceiver, a 32-bit ARM micro-controller, up to 128-KB of in-system programmable flash memory, up to 20-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.

RemoTI Software architecture

ICall Architecture

Projects in RemoTI 2.0 are structured to use the Indirect Call Framework (ICall) architecture that provides a mechanism for the Application to interface with the RF4CE protocol stack and other Real-time operating system (RTOS) primitives.

Indirect Call Framework (ICall) is an module that provides a mechanism for the Application to interface with the RF4CE protocol stack services (i.e, RF4CE-Stack APIs) as well as certain primitive services provided by the RTOS (e.g., thread synchronization). Combined, ICall allows both the Application and protocol stack to efficiently operate, communicate and share resources in a unified RTOS environment. The central component of the ICall architecture is the dispatcher which facilitates the application program interface between the Application and the RF4CE protocol stack task across the dual-image boundary. Although most of the ICall interactions are abstracted within the RF4CE protocol stack APIs, it is important for the application developer to understand the underlying architecture such that proper RF4CE protocol operation is achieved in the multi-threaded RTOS environment. The ICall module source code is provided in the “ICall” & “ICallRemoTI” IDE folders within the Application project.

ICall protocol stack abstraction.png

ICall RF4CE Protocol Stack Service

As depicted above, the ICall core use case involves messaging between an ICall server entity (i.e. the RF4CE Stack task) and a client entity (e.g. the Application task). The reasoning for this architecture is twofold: to enable independent updating of the application / RF4CE protocol stack and to maintain API consistency as the software is ported from legacy platforms (e.g. OSAL for the CC254x) to the CC2640’s TI-RTOS. The ICall RF4CE Protocol Stack Service serves as the Application interface to all RF4CE-Stack APIs. Internally, when a RF4CE protocol stack API is called by the Application, the ICall module routes (i.e. dispatches) the command to the RF4CE protocol stack, and where appropriate, routes messages from the RF4CE protocol stack to the Application. Since the ICall module is part of the Application project, the Application task can access ICall with direct function calls. Note that since the RF4CE protocol stack executes at the highest priority, the Application task will block until the response is received. Certain protocol stack APIs may respond immediately, however the Application thread will block as the API is being dispatched to the RF4CE protocol stack via ICall. Other RF4CE protocol stack APIs may also respond asynchronously to the application via ICall (e.g. event updates) with the response sent to the application task’s event handler.

ICall Primitive Service

In addition, ICall includes a primitive service that abstracts various operating system related functions. Due to shared resources and to maintain interprocess communication, the Application should use the following ICall primitive service functions:

  • Messaging and Thread Synchronization
  • Heap Allocation / Management

Messaging and Thread Synchronization

The Messaging and Thread Synchronization functions provided by ICall enable designing an application to protocol stack interface in the multi-threaded RTOS environment. Within ICall, messaging between two tasks is achieved by sending a block of messages from one thread to the other via a message queue. The sender allocates a memory, writes the content of the message into the memory block and then sends (i.e, enqueues) the memory block to the recipient. Notification of message delivery is accomplished using a signalling object such as semaphore or event object. The receiver wakes up on the posted signal, copies the message memory block(s), processes the message and returns (frees) the memory block to the heap.

The signalling mechanism used by ICall is determined via C pre-processor option ICALL_EVENT.

The Stack uses ICall for notifying and sending messages to the Application. These “service messages” (e.g. state change notifications, etc.) are received by the Application task are delivered by ICall and processed in the Application’s task context.

Heap Allocation and Management

ICall provides the Application with a global heap APIs for dynamic memory allocation. The size of the ICall heap is configured with the HEAPMGR_SIZE preprocessor define in the Application project. ICall uses this heap for all protocol stack messaging as well as to obtain memory for other ICall services. It is also recommended that the Application utilize these ICall APIs for dynamic memory allocation within the Application.

ICall Initialization and Registration

To instantiate and initialize the ICall service, the following functions must be called by the application in main() before starting the SYS/BIOS kernel scheduler:

   /* Initialize ICall module */
   /* Start tasks of external images - Priority 5 */

Calling ICall_init() initializes the ICall primitive service (e.g., heap manager) and framework. Calling ICall_createRemoteTasks() creates, but does not start, the RF4CE protocol stack task.

Prior to using ICall protocol services, both the server and client must enroll and register with ICall. The server enrolls a service which is enumerated at build time. Service function handler registration uses a globally defined unique identifier for each service. For example, RF4CE uses ICALL_SERVICE_CLASS_REMOTI_RTI for receiving RF4CE protocol stack messages via ICall.

The following is a call to enroll the RF4CE protocol stack service (server) with ICall:

   /* Enroll the service that this stack represents */
   ICall_enrollService(ICALL_SERVICE_CLASS_REMOTI_RTI, NULL, &entity, &signal);

The registration mechanism is used by the client to send and/or receive messages via the ICall dispatcher.

In order for a client (e.g., Application task) to utilize the RF4CE-Stack APIs, it must first register its task with ICall. This registration is usually done in the application’s task initialization function.

    * Register the current thread as an ICall dispatcher application 
    * so that the application can send and receive messages.
   ICall_registerApp(&selfEntity, &signal);

The Application supplies the selfEntity and signal inputs which, upon return of ICall_registerApp(), are initialized for the client’s (e.g., Application) task. These objects are subsequently used be ICall to facilitate messaging between the Application and server tasks.

The signal argument represents the semaphore or event used for signalling, whereas the selfEntity represents the task’s destination message queue. Each task registering with ICall will have unique signal and selfEntity identifiers.

ICall Thread synchronization

The ICall module switches between Application and Stack threads through Preemption and Semaphore/Event Synchronization services provided by the RTOS.

The two ICall functions to retrieve and enqueue messages, as mentioned previously, are not blocking functions. That is, they will check whether there is a received message in the queue and if there is no message, the functions will return immediately with ICALL_ERRNO_NOMSG return value. To allow a client or a server thread to block till it receives a message, ICall provides the following function which will block untill the semaphore or event associated with the caller RTOS thread is posted:

   /* static inline ICall_Errno ICall_wait(uint_fast32_t milliseconds) */
   ICall_Errno errno = ICall_wait(ICALL_TIMEOUT_FOREVER);

“milliseconds” is timeout period in milliseconds, after which if the function is not already returned, the function will return with ICALL_ERRNO_TIMEOUT. If ICALL_TIMEOUT_FOREVER is passed as “milliseconds”, the ICall_wait() shall block forever till the signal is posted. Allowing an application or a server thread to block is important in order to yield the processor resource to other lower priority threads or to conserve energy by shutting down power and/or clock domains whenever possible. The signal associated with an RTOS thread is determined by either of the following conditions:

  • A new message is queued to the Application’s RTOS thread queue.
  • ICall_signal() is called for the semaphore/event

ICall_signal() is provided so that an application or a server can add its own event to unblock the ICall_wait() and synchronize the thread. ICall_signal() accepts signal handle as its sole argument as follows:

   /* static ICall_Errno ICall_signal(ICall_SyncHandle msgSyncHdl) */

The signal handle associated with the thread is obtained through either ICall_enrollService() call or ICall_registerApp() call.

Note that it is not possible to call an ICall function from a stack callback. This will cause ICall to abort (with ICall_abort()) and break the system.


RemoTI 2.0 Architecture.png

RemoTI 2.0 uses the ICall framework which abstracts TI-RTOS operating system primitives and other utility functions. As a result, RemoTI 2.0 projects are split into two image types; application and stack images. The various components used in these images are described below.

Sample applications

These consist of sample code demonstrating how to easily build different applications with the RemoTI stack.

  • Remote control Sample Application (RSA) implements features such as voice over RF4CE. For more details please see the RemoTI CC2650RC User's Guide.
  • RemoTI Network Processor (RNP) application implements either a Originator or Recipient node that communicates with a host processor via Unified NPI protocol, over UART or SPI interface.

More details on the sample applications are available in the RemoTI Sample Applications User’s Guide document [R10].

Remote sample application dispatcher

The ICall application dispatcher API wraps interfaces the remote sample application API with the ICall dispatcher. The remote control example implements this for the RTI layer. Users requiring access to the RCN layer from the application image, need to create develop a seperate ICall application dispatcher.

ICall Services

At times there may be some instances where the stack image requires features that are defined only in the application image. For instance, the RF4CE stack utilizes en/decryption services provided by the TI-RTOS Crypto driver. ICall services are registered by the service supplier, which means that the application registers it's crypto services for the stack to use.

TI-RTOS Drivers

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 TI-RTOS Driver API document [R9].


ICall dispatcher

Similar to the sample application dispatcher in the application image, the stack image also has a layer to interpret ICall messages to proper RTI API function calls.

RTI profile

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].

RCN library

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 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].

Software API

The RemoTI software API is described in detail in the doxygen documentation provided with RemoTI 2.0. Note that the sample remote control only exposed the API at the RTI layer. Users that wish to access the RCN layer need to implement their own RCN ICall dispatchers.

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

Figure 3: Logical node types
Figure 4: Example RF4CE topologies

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.

Node configuration


IEEE Address

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

Each CC26xx device comes pre-programmed with its own unique 64-bit IEEE address. This is located within the Factory configuration area (FCFG1) 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 this address in the .ccfg file (SET_CCFG_IEEE_MAC_0 and SET_CCFG_IEEE_MAC_1).

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 CC26xx information page.

Short Address

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.

Stack initialization

Start Modes

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 RTI_InitReq()

 rtiWriteItem_t writeItem;
 rtiStatus_t status = CLEAR_STATE;
 writeItem.profileId = RTI_PROFILE_RTI;
 writeItem.itemId = RTI_CP_ITEM_STARTUP_CTRL;
 writeItem.len = 1;
 writeItem.pValue = &status;

Typical node start-up sequence using RTI interface

Figure 5: Initialization

The application has to perform the following task sequence to start as an RF4CE node, see Figure 5. See the SimpleApp application note [R11] for example software to configure and initialize a node.

Medium Sharing

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 2.0 this threshold is accessible via RTI_WriteItem()

 rtiWriteItem_t writeItem;
 int8_t value = -75; // Set new CCA threshold; -75dBm
 writeItem.profileId = RTI_PROFILE_RTI;
 writeItem.itemId = RTI_SA_ITEM_CCA_THRESHOLD;
 writeItem.len = 1;
 writeItem.pValue = &value;

Since it is accessible via RTI_WriteItem() it can be controlled in Network Processor configurations as well.

Data transmission


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.

Figure 6: RF4CE data packet capture

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.

Transmission options


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.

Table 1: Transmission Options for RF4CE
Options Usage Application
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 RTI_SA_ITEM_MAX_FIRST_ATTEMPT_FRAME_RETRIES times if acknowledgment is not received from the destination. 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 (RTI_SA_ITEM_DUTY_CYCLE time) or until an acknowledgment is received. 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 RTI_SA_ITEM_CURRENT_CHANNEL). 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 RTI_SA_ITEM_CURRENT_CHANNEL). This is used to reach all nodes within radio range.

User considerations


To transmit a data packet, use the RTI_SendDataReq() function.

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 application task is unblocked from calling Event_pend() via an even 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.

Standby mode

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.


GDP 2.0

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 using RTI_WriteItem() and RTI_ReadItem() 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.

ZRC 2.0

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_ReadItem() and RTI_WriteItem() 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:

  • Discovery
  • 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 gdpDo_StartDiscoveryProcedure() function.

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 an RCN_NLME_PAIR_CNF() is generated where the binding process moves to the configuration process by calling gdpBo_StartProfileConfigurationProcedure() function.

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 an RTI_CMD_START_VALIDATION_IND() event.

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 associated with the RTI_CMD_BIND_CNF event. This RTI event is triggered from the GDP profile when validation is successful.

The binding process at binding originator node is shown in figure below.

Binding Originator Binding Recipient
Binding Originator Node.png Binding Recipient Node.png

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 aplcMaxNormalValidationDuration for completion of validation process
  • Extended validation mode - In this mode aplBindingRecipientValidationWaitTime beyond aplcMaxNormalValidationDuration to 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 RSA_buildAndSendZrc20Report() function of remote_control.c file. At the binding recipient node, the stack function RTI_OnNldeDataInd() passes the received the code keys to recipient application by calling RTI_ReceiveDataInd() function.

ZRC “push button” pairing

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 RTI_BindReq(BINDING_TYPE_NORMAL) function.

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 remote control application as an 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.

Proxy binding

Proxy binding is useful in cases where it is possible to share information out-of-band. This could for example be via NFC (Near Field Communication), BLE or IR (Infrared). With proxy binding one skips the Discovery Phase, and moves directly onto Pairing. In order to do so

  • the Recipient must be fed with the IEEE address of the Originator, and
  • the Originator must be fed with the IEEE address and Pan ID of the Recipient.

This is done via RTI_WriteItem(0, GDP_PROFILE_GDP, GDP_ITEM_PROXY_PAIR_INFO, 10, {ieee, panId}). To start proxy pairing call RTI_BindReq(BINDING_TYPE_PROXY)

User considerations

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 69 bytes of data memory and non-volatile memory space.

The pairing table entries can be accessed via the RTI_ReadItem(), RTI_WriteItem() functions.

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 gRCN_CAP_MAX_PAIRS constant parameter.

This is set to 5 in most of the sample application projects. However, some projects like the remote control application sets it to 3. 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.

Matching configuration

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.

ZRC Features

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].

Action Mapping

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 RTI_SetAttributeReq() function.

Figure 9: Action mapping

Bidirectional Communication

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 aplGDPCapabilites.

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(), via gdpBr_ReceiveDataInd(). 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.

Figure 10: Polling and Identification Configuration

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.

Figure 11: Identify at Polling‎

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.

Figure 12: Poll negotiation at polling

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.

Figure 13: Recipient Initiated Action Mapping Negotiation Procedure

Power savings


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].

Radio control


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.

Figure 12: StandBy mode receiver duty-cycle

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 leverages TI-RTOS' ability to put the CC26xx processor into low power modes automatically based on software activity. The MCU sleep mode APIs RTI_EnableSleepReq() and RTI_DisableSleepReq() functions from previous RemoTI 1.x versions are retained for legacy support only. The TI-RTOS Power driver allows to kernel to put the processor automatically 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 Power driver, refer to the TI-RTOS Power Management documentation [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].

SPI interface

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.

UART interface

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 CC26xx devices have hardware AES and CCM engines that are used to apply security as well as hardware true random number generator that is used to generate random keys.

Configuration options

Enabling security

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.

Key distribution

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 CC26xx hardware random number generator is used to generate the security material.

Enhanced Security

The optional enhanced security key negotiation feature can be enabled by setting the enhanced security GDP capabilities attribute via RTI_WriteItem 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_WriteItem of the GDP_ITEM_DEFAULT_SECRET.

By default enhanced security is enabled and compiled in the stack. To disable, set to FALSE the RCN_FEATURE_ENHANCED_SECURITY pre-processor define. A stack library with enhanced security disabled will also be needed.

User considerations

Key compromise

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 ( -25dbm on the CC26xx 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.

Payload overhead

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.

Broadcast packets

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.

Frequency Agility


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.

Frequency Agility

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.


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 rcnFALQITh level (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 rcnFAShortDurationTh duration (default 60 seconds), then the node will temporarily suspend the basic algorithm operation for rcnFASuspendDur duration (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.