| 1. |
Introduction
The RF4CE standard defines an RC network that defines a simple, robust and low-cost communication network that allows wireless connectivity in applications in the CE domain. The RF4CE standard enhances the IEEE 802.15.4 standard by providing a simple networking layer and standard application profiles that can be used to create a multi-vendor interoperable solution for use within the home.
Some of the characteristics of an RC network are as follows:
• Operation in the 2.4GHz frequency band according to IEEE 802.15.4.
• Frequency agile solution operating over 3 channels.
• Incorporates power saving mechanisms for all device classes.
• Discovery mechanism with full application confirmation.
• Pairing mechanism with full application confirmation.
• Multiple star topology with inter-PAN communication.
• Various transmission options including broadcast.
• Security key generation mechanism.
• Utilizes the industry standard AES-128 security scheme.
• Specifies a simple RC control profile for CE products.
• Allows standard or vendor specific profiles to be added. |
| |
|
| 2. |
Network topology
An RC PAN is composed of two types of device: a target node and a controller node. A target node has full PAN coordinator capabilities and can start a network in its own right. A controller node can join networks started by target nodes by pairing with the target. Multiple RC PANs form an RC network and nodes in the network can communicate between RC PANs.
In order to communicate with a target node, a controller node first switches to the channel and assumes the PAN identifier of the destination RC PAN. It then uses the network address, allocated through the pairing procedure, to identify itself on the RC PAN and thus communicate with the desired target node.
Figure 1 illustrates an example RF4CE topology which includes three target nodes: a TV, a DVD and a CD player and each target node creates its own RC PAN. The TV, DVD and CD player also have dedicated RCs which are paired to each appropriate target node. A multi-function RC, capable of controlling all three target nodes itself, is added to the network by successively pairing to the desired target nodes.
Figure 1 – Example RC network topology
As a consequence, this RC network consists of three separate RC PANs: one managed by the TV (PAN 1), containing the TV RC and the multi-function RC; a second managed by the CD player (PAN 2), containing the CD RC and the multi-function RC and a third managed by the DVD (PAN3), containing the DVD RC and the multi-function RC. |
| |
|
| 3. |
Architecture
The RF4CE architecture is defined in terms of a number of blocks or layers in order to simplify the standard. Each layer is responsible for one part of the standard and offers services to the next higher layer and utilizes services from the next lower layer. The interfaces between the layers serve to define the logical links that are described in this standard. The layout of the layers is based on the open systems interconnection (OSI) seven-layer model.
Figure 2 illustrates the RF4CE stack architecture. The RF4CE protocol is designed to be built onto the IEEE 802.15.4 standard MAC and PHY layers and provides networking functionality and standard application profiles which can interface to the end user application. Manufacturer specific extensions to standard profiles can be defined by sending vendor specific data frames within a standard profile. In addition, vendor specific profiles can also be defined.
Figure 2 – The RF4CE stack architecture |
| |
|
| 4. |
The RF4CE NWK layer
The NWK layer provides two services: the NWK layer data service, interfacing to the NWK layer data entity (NLDE) and the NWK layer management service, interfacing to the NWK layer management entity (NLME). These services are accessed through the NWK layer data entity SAP (NLDE-SAP) and the NWK layer management entity SAP (NLME-SAP).
The NWK layer data service enables the transmission and reception of NWK protocol data units (NPDUs) across the MAC data service. The NWK layer management service permits service discovery, pairing, unpairing, receiver control, node initialisation and NIB attribute manipulation.
4.1 2.4GHz band frequencies
An RF4CE node operates in the 2.4GHz frequency band, as specified by IEEE 802.15.4. However, in an attempt to be robust against other common sources of interference in this band, only a small subset of channels is used - namely channels 15, 20 and 25. A target node can choose to start its network on the best available channel at startup time and so an RC network may operate over one or more of the available three channels.
4.2 Frequency agility
All RF4CE nodes support frequency agility across all three permitted channels. As described above, a target node selects its own initial channel, based on the channel conditions during startup. During the course of the life of the target node, however, the channel conditions may vary to such an extent that the channel becomes compromised and communication becomes problematic. If this happens, the target node can elect to switch to another channel that may provide a better level of service.
Each node paired to the target records the channel on which communication is expected. However, in the event that the target switches to another channel, the node can attempt transmission on the other channels until communication with the target is reacquired. The node can then record the new channel accordingly for the next time communication is attempted.
4.3 Node initialisation
An RF4CE node initialises itself according to whether it is a target or a controller. Controller nodes simply configure the stack according to this standard and start operating normally. Target nodes configure the stack as controller nodes do but then attempt to start a network.
To do this, the target node first performs an energy detection scan which allows it to obtain information on the usage of each available channel, thus allowing it to select a suitable channel on which to operate. The target node then performs an active scan which allows it to determine the identifiers of any other IEEE 802.15.4 PANs (RF4CE or otherwise) operating on the selected channel, thus allowing a unique PAN identifier to be selected for its network. The target node then begins operating normally.
4.4 Power saving
Power saving is an important consideration for an RF4CE node. As a consequence, this standard defines a power save mechanism that allows both controller nodes as well as target nodes to manage their power consumption by entering a power saving mode. The power saving mechanism is under the control of each application.
A node can manipulate its receiver in a number of ways:
• The receiver can be enabled until further notice (e.g. when a TV comes out of standby).
• The receiver can be enabled for a finite period (e.g. when a TV enters standby mode and wants to engage the power saving mode).
• The receiver can be disabled until further notice (e.g. when an RC enters a dormant state due to none of its buttons being pressed)
When the power saving mode is engaged, the receiver is enabled for an application defined duration (known as the active period) and then disabled. This mechanism is then repeated at an application defined interval (known as the duty cycle). Other nodes can still communicate with a node in power saving mode by targeting the transmission during the active period. The result is a node that periodically enables its receiver for only a short time, hence allowing it to conserve power but still be able to be active on the network.
4.5 NWK frames
The RF4CE NWK layer defines three frame types: standard data, network command and vendor specific data. Standard data frames transport application data from standard application profiles. Network command frames transport frames which allow the network layer to accomplish certain tasks such as discovery or pairing. Vendor specific data frames transport vendor specific application data.
The general NWK frame format is illustrated in Figure 3.
| Octets: 1 |
4 |
0/1 |
0/2 |
Variable |
0/4 |
Frame
control |
Frame
counter |
Profile
identifier |
Vendor
identifier |
Frame
payload |
Message
integrity code |
| Header |
Payload |
Footer |
Figure 3 – General schematic view of a NWK frame
The fields of the general NWK frame are described below:
• Frame control: control information for the frame
• Frame counter: incrementing counter to detect duplicates and prevent replay attacks (security)
• Profile identifier: the application frame format being transported
• Vendor identifier: to allow vendor extensions
• Frame payload: contains the application frame
• Message integrity code: to provide authentication (security)
4.6 Transmission options
The RF4CE protocol defines a number of transmission options that can be used by an application and combined as appropriate:
• Acknowledged: Originator data is confirmed by the recipient
• Unacknowledged: Originator data is not confirmed by the recipient
• Unicast: Originator data is sent to a specific recipient
• Broadcast: Originator data is sent to all recipients
• Multiple channel: Originator attempts transmission using frequency re-acquisition mechanism
• Single channel: Originator attempts transmission on the expected channel
4.7 Discovery
An RF4CE node can perform discovery in an attempt to find other suitable nodes that can be paired to. Discovery can be attempted repeatedly on all three channels for a fixed duration or until a sufficient number of responses have been received. Service discovery is only available to nodes that are not currently in power saving mode.
During discovery, a number of pieces of information are exchanged between both devices. This information is passed to the application which can then make a decision whether it should respond.
The information exchanged is as follows:
| • |
Node capabilities: The type of the node (i.e. target or controller), whether the node is mains or battery powered and whether it supports security. |
| • |
Vendor information: The RF4CE allocated vendor identifier and a freeform vendor string specifying vendor specific identification (e.g. a serial number). |
| • |
Application information: A short user defined which describes the application functionality of the node (e.g. “lounge TV”), a device type list specifying which types of device are supported (e.g. a combo device may support both “TV” and “DVD” functionality) and a profile identifier list specifying which application profiles are supported by the node (e.g. the CERC profile or a vendor specific profile). |
| • |
Requested device type: The type of device being requested through the discovery (e.g. a multifunction remote control may be searching for “TV” functionality). |
4.8 Pairing
Once a node has determined, through discovery, that there is another node within communication range offering compatible services, it can set up a pairing link in order to begin communication. Nodes within an RC network may only communicate directly with other nodes on the network if a pairing link exists between the originator and the target nodes.
A pairing link can be established on request from the application by exchanging a similar set of information as was exchanged during discovery. The application on the target node can choose whether to accept the pair (e.g. only if it has capacity to store the pairing link) and confirms the pairing request back to the originator node.
If the pairing request was successful, both nodes store a pairing link in their respective pairing tables. This allows an originator to communicate with a target and the target to communicate back to the originator. Each entry in the pairing table contains all the information necessary for the network layer to transmit a frame to the target node. This removes the burden of addressing, etc. from the application layer which can simply supply an index into the pairing table in order to communicate with another device.
Each entry in the pairing table contains the following information:
• Pairing reference
• Source network address
• Destination logical channel
• Destination IEEE address
• Destination PAN identifier
• Destination network address
• Recipient node capabilities
• Recipient frame counter
• Security link key
4.9 Security
Like any other wireless network, an RC network could be vulnerable to both passive eavesdropping and unauthorised tampering of the messages being transferred between nodes. To solve this, the RF4CE standard provides a cryptographic mechanism to protect the transmissions. This mechanism provides the following security services:
| • |
Data confidentiality: To ensure that the data contained in an RF4CE transmission can only be disclosed to the intended recipient. |
| • |
Data authenticity: To ensure that the intended recipient of an RF4CE transmission knows that the data was sent from a trusted source and not modified during transmission. |
| • |
Replay protection: To ensure that a secure transmission cannot simply be repeated by an attacking device if overheard. |
128-bit cryptographic keys are generated by each end of a pairing link and stored in the pairing table for future use. |
| |
|
| 5. |
The RF4CE application layer
The application layer of an RF4CE node is composed of a profile component and an application specific component. The profile component can be thought of as a common language that nodes implementing the profile exchange to accomplish certain tasks, e.g. switching the channel on a TV. The application component is provided by the end manufacturer in order to add specific functionality to the commands request through the profile.
The RF4CE standard defines standard profiles (e.g. CERC) but also permits vendors to either extend standard profiles or to define completely proprietary profiles.
The Consumer Electronics Remote Control (CERC) profile is once such standard profile defined by the RF4CE standards organisation. This profile defines commands and procedures to enable CE devices (e.g. a TV, DVD or CD player) to be controlled by remote control devices. |
|
