EnOcean Radio Protocol, ERP

- the EnOcean Radio Protocol defines the way in which data is exchanged between devices - frames; subtelegrams and telegrams..

EnOcean protocol for ensuring the correct delivery of the required data appears across several layers of the OSI layer model.

Entitled the EnOcean Radio Protocol, ERP, it covers the way in which data is assembled for transmission.

The requirements for the EnOcean Radio Protocol, REP have been devised to ensure that it gives reliable transmission of the data using a minimal power level. This a key requirement as many remote nodes will not have access to mains power and will need to use energy harvesting techniques to gain their power.

EnOcean radio protocol basics

The key areas for the EnOcean Radio Protocol are the data link and network layers.


EnOcean Radio Protocol
Protocol Layers
Layer Service addressed Data Units
7. Application (API) EnOcean Equipment Profiles (EEP); RPC/RMCC handling Data
6. Presentation Radio Telegram Processing; Encryption Data
5. Session Not used  
4. Transport Smart Ack; Remote Management Telegram / message
3. Network Addressing telegrams; (ADT Encapsulation/Decapsulation); Switch telegram conversion; (choice/status processing); Repeating (status processing) Telegram
2. Data link Subtelegram Structure; Control Sum Calculation Subtelegram; Timing; Listen before talk Sub-Telegram
1. Physical Encoding/Decoding (inverse bits) Radio reception/transmission Bits; frame

Data unit description

The EnOcean radio protocol, ERP is packet based. Dependent upon the area of the OSI stack the data units can be of three different types:

  • Frame:   A frame is the format of the physical layer encoded. The EnOcean frame includes control and synchronization information for the receiver.

    A frame is transmitted as a bit by bit serial sequence. A subtelegram is the result of a decoding process, in which this control and synchronization information are removed from the frame. The reverse mechanism to get a frame from a subtelegram is the encoding process.
  • Subtelegram:   The EnOcean subtelegrams are the part of the EnOcean Radio Protocol that are handled in the data link layer.

    The EnOcean Radio Proptocol ERP protocol is designed to work mostly as a unidirectional protocol without handshaking. To ensure transmission reliability three identical subtelegrams are transmitted within a certain time range. Each transmitted subtelegram is an atomic unit and contains all the information the composed telegram contains.
  • Telegram:   The telegram is used as the data format for the network layer.

EnOcean frame

The EnOcean radio protocol defines that the data to be transmitted is assembled into frames. These frames have a distinct structure to enable the receiver to be able to receive and decode them correctly.

There are several sections within each EnOcean frame.

  • Preamble:   At the beginning of each EnOcean frame there is a preamble. This is used for bit synchronization and the generation of the data slicing thresholds.
  • Synchronisation Word:   A synchronisation word follows the preamble and this enables the receiver to synchronize to the data bytes.
  • Length:   The first byte transmitted after the synchronization word indicates the length of the data payload, Data_PL. Its value is the number of the bytes transmitted in the Data_PL.
  • Data Payload:   The data payload, Data_PL is transmitted after the length byte, and the end of the data is the end of the frame.

The length information and the data payload, Data_PL are transferred to the Data Link Layer up from the Physical Layer as defined by the EnOcean Radio Protocol. Vice versa the Length followed by the Data_PL, have to be transferred from the upper lying Data Link Layer.


EnOcean Protocol Frame Parameters
Parameter value
Endianness The MSB is transmitted first, i.e. Big-Endian.
Preamble 16 bit
0b1010101010101010
(0xAAAA)
Synchronisation word 16 bit
0b1010100100111100
(0xA93C)
Length 1st Byte after the synchronisation word contains the number of data bytes to be transmitted
Data_PL The data payload: the bytes containing the data for transmission,
Minimum number of data bytes 1
Maximum number of data bytes 255

EnOcean subtelegram

This part of the EnOcean radio protocol gives the data being handled at the higher layers.

Accordingly, the subtelegrams are handled in the data link layer. To achieve the required performance, the ERP protocol is designed to work mostly as a unidirectional protocol without handshaking. This considerably reduces the amount of data needed to be transmitted in a basic subtelegram. However, to ensure transmission reliability, three identical subtelegrams are transmitted within a certain time range. Each transmitted subtelegram is an atomic unit and contains all the information required.

There are several fields that are contained within the EnOcean subtelegram. The EnOcean radio protocol defines them as the following:

  • RORG/CHOICE   This element of the subtelegram identifies the subtelegram type.
  • DATA   This is the payload of the transmitted subtelegram.
  • TXID/SourceID   This element of the subtelegram used within the EnOcean protocol identifies the transmitter, each having a unique 4 byte identity.
  • STATUS   This identifies if the subtelegram is transmitted from a repeater and the type of integrity control mechanism used. This field is not present in a switch telegram.
  • HASH/Checksum   This is used to check the data integrity. It is a check value of all the bytes.

Note: The length of the subtelegram is not transmitted in the subtelegram structure. The length is determined by counting the number of bytes starting with RORG and ending with HASH.

By Ian Poole


<< Previous   |   Next >>


Share this page


Want more like this? Register for our newsletter






Fans in Digital Signage Players Are a Lose/Lose Proposition Jeff Hastings | BrightSign LLC
Fans in Digital Signage Players Are a Lose/Lose Proposition
Jeff Hastings of BrightSign has some interesting ideas on why fans should not be used in digital signage, and how to avoid using them.









Radio-Electronics.com is operated and owned by Adrio Communications Ltd and edited by Ian Poole. All information is © Adrio Communications Ltd and may not be copied except for individual personal use. This includes copying material in whatever form into website pages. While every effort is made to ensure the accuracy of the information on Radio-Electronics.com, no liability is accepted for any consequences of using it. This site uses cookies. By using this site, these terms including the use of cookies are accepted. More explanation can be found in our Privacy Policy