IEC 62106-2:2021
(Main)Radio data system (RDS) - VHF/FM sound broadcasting in the frequency range from 64,0 MHz to 108,0 MHz - Part 2: Message format: coding and definition of RDS features
Radio data system (RDS) - VHF/FM sound broadcasting in the frequency range from 64,0 MHz to 108,0 MHz - Part 2: Message format: coding and definition of RDS features
IEC 62106-8:2021 defines the coding and definition of features for the Radio Data System (RDS). IEC 62106-8:2021 cancels and replaces the first edition published in 2018. This edition constitutes a technical revision. This edition includes the following significant technical changes with respect to IEC 62106‑2:2018:
a) Subclause 4.2.4 has been added;
b) Tables 1 and 13 have been modified;
c) The new function RDS2 file transfer has been added and it is detailed in Annex C; this uses a CRC-16, which is specified in Annex D.
General Information
Relations
Standards Content (Sample)
IEC 62106-2 ®
Edition 2.0 2021-02
INTERNATIONAL
STANDARD
Radio data system (RDS) – VHF/FM sound broadcasting in the frequency range
from 64,0 MHz to 108,0 MHz –
Part 2: Message format: coding and definitions of RDS features
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.
IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.
About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.
IEC publications search - webstore.iec.ch/advsearchform IEC online collection - oc.iec.ch
The advanced search enables to find IEC publications by a Discover our powerful search engine and read freely all the
variety of criteria (reference number, text, technical publications previews. With a subscription you will always
committee, …). It also gives information on projects, replaced have access to up to date content tailored to your needs.
and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished
The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published
containing more than 22 000 terminological entries in English
details all new publications released. Available online and
and French, with equivalent terms in 18 additional languages.
once a month by email.
Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer Service
Centre: sales@iec.ch.
IEC 62106-2 ®
Edition 2.0 2021-02
INTERNATIONAL
STANDARD
Radio data system (RDS) – VHF/FM sound broadcasting in the frequency range
from 64,0 MHz to 108,0 MHz –
Part 2: Message format: coding and definitions of RDS features
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 33.160.40 ISBN 978-2-8322-9426-0
– 2 – IEC 62106-2:2021 © IEC 2021
CONTENTS
FOREWORD . 6
INTRODUCTION . 8
1 Scope . 9
2 Normative references . 9
3 Terms, definitions, abbreviated terms and conventions . 9
3.1 Terms and definitions . 9
3.2 Abbreviated terms . 9
3.3 Notation and conventions . 11
4 Message format . 11
4.1 Design principles . 11
4.2 Group structure . 12
4.2.1 Group type A structure . 12
4.2.2 Group type B structure . 13
4.2.3 Group type C structure . 13
4.2.4 RFT ODA pipe/channel . 14
4.3 Group type A and B usage . 15
4.4 Group type C usage . 16
4.4.1 Transmitting legacy data using data-streams 1, 2 and 3. 16
4.4.2 Transmitting group type C ODA data . 16
4.4.3 AID and channel number assignment for group type C ODAs. 17
5 Description of the RDS features. 18
5.1 Alternative Frequencies list (AFs) . 18
5.2 Clock Time and date (CT) . 18
5.3 Dynamic PTY Indicator (PTYI) using DI . 18
5.4 Extended Country Code (ECC) . 18
5.5 Enhanced Other Networks information (EON) . 18
5.6 Linkage information . 19
5.7 Open Data Applications (ODAs) . 19
5.8 Programme Identification (PI). 19
5.9 Programme Service name – (PS) . 20
5.10 Long Programme Service name – (LPS) . 20
5.11 Programme Type (PTY) . 20
5.12 Programme Type Name (PTYN) . 20
5.13 RadioText (RT) . 21
5.14 enhanced RadioText (eRT) . 21
5.15 RadioText Plus (RT+ and eRT+) . 21
5.16 Traffic Programme identification (TP) . 21
5.17 Traffic Announcement identification (TA) . 21
5.18 Traffic Message Channel (TMC) . 22
6 Coding of the group types . 22
6.1 Groups of type 0A and 0B: Basic tuning and switching information with PS
name . 22
6.2 Group type 1A: Slow labelling codes . 23
6.3 Group type 2A and 2B: RadioText . 24
6.4 Group type 3A: Application identification for any specific ODA using groups
of type A or B . 25
6.5 Group type 4A: Clock-Time and date. 25
6.6 Group type 10A: Programme Type Name PTYN . 26
6.7 Group type 14A and B: Enhanced Other Networks information (EON) . 27
6.8 Group type 15A: Long Programme Service name – 32 bytes with UTF-8
coding . 27
6.9 Group type 15B: Fast basic tuning and switching information . 28
7 Coding of RDS features for control . 29
7.1 Programme Identification (PI) codes and Extended Country Codes (ECC) . 29
7.1.1 PI structure . 29
7.1.2 Country Identifier (CI) codes: 'Nibble 1' . 29
7.1.3 Extended Country Codes (ECC) . 29
7.1.4 Programme service in terms of area coverage (codes for fixed location
transmitters only): 'Nibble 2' . 30
7.1.5 Programme reference number: 'Nibbles 3 and 4' . 30
7.1.6 PI codes for low-power short range transmitting devices . 30
7.2 Programme Type (PTY) codes . 31
7.3 Traffic Programme (TP) and Traffic Announcement (TA) codes . 31
7.4 Decoder Identification (DI) and dynamic PTY Indicator (PTYI) codes . 31
7.5 Coding of Alternative Frequencies (AFs) . 32
7.5.1 AF code tables . 32
7.5.2 Use of Alternative Frequencies in group type 0A. 34
7.5.3 Use of AF codes in group type 14A . 36
7.6 Coding of Enhanced Other Networks information (EON) . 37
7.6.1 General . 37
7.6.2 Coding of frequencies for cross-referenced programme services in EON . 38
7.6.3 Use of the TP and TA features with EON . 38
7.6.4 Use of PTY with EON . 38
8 Required main RDS feature repetition rates on data-stream 0 . 39
Annex A (normative) Method for linking RDS programme services – Linkage
information – Group type 1A and 14A . 44
A.1 General . 44
A.2 LA – Linkage Actuator . 45
A.3 EG – Extended Generic indicator . 45
A.4 ILS – International Linkage Set indicator . 45
A.5 LSN – Linkage Set Number . 45
Annex B (informative) Conversion between time and date conventions . 47
Annex C (normative) RDS2 File Transfer protocol RFT for files up to 163 kB . 49
C.1 Group coding of the ODA-AID assignment groups . 49
C.1.1 General principles . 49
C.1.2 Variant 0 . 49
C.1.3 Variant 1 . 50
C.1.4 Variants 2 to 15 . 51
C.2 Coding of the RFT data group used to carry the file data bytes . 51
Annex D (informative) CRC-16 ITU-T/CCITT checkword calculation . 53
D.1 General . 53
D.2 PASCAL listing of CRC-16-calculation routine . 53
D.3 C listing of the CRC-16 calculation routine . 53
D.4 Fictitious example . 54
Bibliography . 55
– 4 – IEC 62106-2:2021 © IEC 2021
Figure 1 – Group type A structure . 12
Figure 2 – Group type B structure . 13
Figure 3 – Group type C structure . 13
Figure 4 – Tunnelling structure for group types A and B . 16
Figure 5 – Basic tuning and switching information – Group type 0A . 22
Figure 6 – Basic tuning and switching information – Group type 0B . 23
Figure 7 – Slow labelling codes – Group type 1A . 23
Figure 8 – RadioText – Group type 2A . 24
Figure 9 – RadioText – Group type 2B . 25
Figure 10 – Application identification for any specific ODA – Group type 3A . 25
Figure 11 – Clock-Time and date transmission – Group type 4A . 26
Figure 12 – Programme Type Name PTYN – Group type 10A . 26
Figure 13 – Enhanced Other Networks information – Group type 14A . 27
Figure 14 – Enhanced Other Networks information – Group type 14B . 27
Figure 15 – Long PS, UTF-8 coded – Group type 15A . 28
Figure 16 – Fast basic tuning and switching information – Group type 15B . 28
Figure 17 – PI code structure . 29
Figure A.1 – Structure of group type 1A, block 3 . 44
Figure A.2 – Structure of group type 14A variant 12, block 3 (Linkage information) –
National link . 45
Figure A.3 – Structure of group type 14A variant 12, block 3 (Linkage information) –
International link . 46
Figure B.1 – Conversion routes between Modified Julian Date (MJD) and Coordinated
Universal Time (UTC) . 47
Figure C.1 – AID assignment group coding for variant 0. 49
Figure C.2 – AID assignment group coding for variant 1. 51
Figure C.3 – AID assignment group coding for variant 2 to 15 . 51
Figure C.4 – RFT data group . 52
Table 1 – Group type C Function Header definition . 14
Table 2 – Group type A and B usage . 15
Table 3 – Group type C assignment methods used to connect channel numbers with
one or more AIDs . 17
Table 4 – Assignment of up to three successive channel numbers to multiple AIDs. 18
Table 5 – Area coverage codes . 30
Table 6 – Programme service reference number codes . 30
Table 7 – PI codes for short range transmitting devices . 31
Table 8 – Codes for TP and TA . 31
Table 9 – Meaning of bits d to d . 32
0 3
Table 10 – VHF frequencies 87,6 MHz to 107,9 MHz code table . 32
Table 11 – Special meanings AF code table . 33
Table 12 – LF/MF code table – ITU regions 1 and 3 (9 kHz spacing) . 33
Table 13 – MF code table – ITU region 2 (10 kHz spacing) . 33
Table 14 – Example including AFs for the extended FM Band . 37
Table 15 – Data-stream 0 group repetition rates: Transmitter not part of a
multi-programme service network: no TMC and only 'basic' RDS features . 39
Table 16 – Data-stream 0 group repetition rates: Transmitter part of a multi-programme
service network: no TMC . 40
Table 17 – Data-stream 0 group repetition rates: Transmitter not part of a multi-
programme service network: with TMC . 41
Table 18 – Data-stream 0 group repetition rates: Transmitter not part of a multi-
programme service network: no TMC and with support for UTF-8 coded characters . 42
Table 19 – Data-stream 0 group repetition rates: Transmitter part of a multi-programme
service network: with TMC . 43
Table B.1 – Symbols used for time and date calculation. 47
Table C.2 – Relation between chunk size, max. file size and max.chunk address . 50
– 6 – IEC 62106-2:2021 © IEC 2021
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
RADIO DATA SYSTEM (RDS) –
VHF/FM SOUND BROADCASTING IN THE FREQUENCY
RANGE FROM 64,0 MHz TO 108,0 MHz –
Part 2: Message format: coding and definitions of RDS features
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC Publication(s)"). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent
rights. IEC shall not be held responsible for identifying any or all such patent rights.
IEC 62106-2 has been prepared by technical area 1: Terminals for audio, video and data
services and contents, of IEC technical committee 100: Audio, video and multimedia systems
and equipment. It is an International Standard.
This second edition cancels and replaces the first edition published in 2018. This edition
constitutes a technical revision.
This edition includes the following significant technical changes with respect to
IEC 62106‑2:2018:
a) Subclause 4.2.4 has been added;
b) Tables 1 and 13 have been modified;
c) The new function RDS2 file transfer has been added and it is detailed in Annex C; this uses
a CRC-16, which is specified in Annex D.
The text of this International Standard is based on the following documents:
CDV Report on voting
100/3464/CDV 100/3547/RVC
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
A list of all parts in the IEC 62106 series, published under the general title Radio data
system (RDS) – VHF/FM sound broadcasting in the frequency range from 64,0 MHz to
108,0 MHz, can be found on the IEC website.
The language used for the development of this International Standard is English,
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/standardsdev/publications.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
– 8 – IEC 62106-2:2021 © IEC 2021
INTRODUCTION
Since the mid-1980s, a fascinating development has taken place. Most of the multimedia
applications and standards have been created or redefined significantly. Hardware has become
extremely powerful with dedicated software and middleware. In the mid-1980s, Internet as well
as its protocols did not exist. Navigation systems became affordable in the late 1990s, and a
full range of attractive smartphones now exist. The computing power of all these new products
is comparable with that of the mainframe installations in that era.
Listener expectations have grown faster than the technology. Visual experience is now very
important, like the Internet look and feel. Scrolling text or delivering just audio is nowadays
perceived as insufficient for FM radio, especially for smartphone users. New types of radio
receivers with added value features are therefore required. RDS has so far proven to be very
successful.
FM radio with RDS is an analogue-digital hybrid system, which is still a valid data transmission
technology and only the applications need adaptation. Now the time has come to solve the only
disadvantage, the lack of sufficient data capacity. With RDS2, the need to increase the data
capacity can be fulfilled.
RDS was introduced in the early 1980s. During the introductory phase in Europe, the car
industry became very involved and that was the start of an extremely successful roll-out. Shortly
.
afterwards, RDS (RBDS) was launched in the USA [1, 2, 3, 4, 5]
The RDS Forum has investigated a solution to the issue of limited data capacity. For RDS2,
both sidebands around the RDS 57 kHz subcarrier can be repeated a few times, up to three,
centred on additional subcarriers higher up in the FM multiplex while still remaining compatible
with the ITU Recommendations.
The core elements of RDS2 are the additional subcarriers, which will enable a significant
increase of RDS data capacity to be achieved, and then only new additional data applications
will have to be created, using the RDS-ODA feature, which has been part of the RDS standard
IEC 62106 for many years.
In order to update IEC 62106:2015 to the specifications of RDS2, IEC 62106 has been
restructured as follows:
Part 1: Modulation characteristics and baseband coding
Part 2: RDS message format, coding and definition of RDS features
Part 3: Usage and registration of Open Data Applications ODAs
Part 4: Registered code tables
Part 5: Marking of RDS and RDS2 devices
Part 6: Compilation of technical specifications for Open Data Applications in the public domain
Part 9: RBDS – RDS variant used in North America
Part 10: Universal Encoder Communication Protocol UECP
The original specifications of the RDS system have been maintained and the extra
functionalities of RDS2 have been added.
The presentation in Parts 1, 2 and 3 follows the OSI basic reference model for information
processing systems [6].
_______________
Numbers in square brackets refer to the Bibliography.
RADIO DATA SYSTEM (RDS) –
VHF/FM SOUND BROADCASTING IN THE FREQUENCY
RANGE FROM 64,0 MHz TO 108,0 MHz –
Part 2: Message format: coding and definitions of RDS features
1 Scope
This part of IEC 62106 defines the coding and definition of features for the Radio Data System
(RDS).
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC 62106 (all parts), Radio Data System (RDS) – VHF/FM sound broadcasting in the frequency
range from 64,0 MHz to 108,0 MHz
ISO/IEC 10646, Information technology – Universal Coded Character Set (UCS)
ISO 14819 (all parts), Intelligent transport systems – Traffic and travel information messages
via traffic message coding
3 Terms, definitions, abbreviated terms and conventions
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62106-1 apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.2 Abbreviated terms
For the purposes of this document, the abbreviated terms given in IEC 62106-1 and the
following apply.
AF Alternative Frequency
NOTE 1 Alternative Frequencies are given in the form of lists (method A or B or mapped).
AID Application IDentification for ODAs
CI Country Identifier
CRC-16 16 bit Cyclic Redundancy Check
– 10 – IEC 62106-2:2021 © IEC 2021
CT Clock Time
NOTE 2 In RDS, Clock Time includes the date.
DI Decoder Identification
ECC Extended Country Code
EG Extended Generic indicator
EON Enhanced Other Network information
eRT enhanced RadioText
EWS Emergency Warning System
NOTE 3 EWS was used in previous editions of IEC 62106. It can now be an ODA.
FH Function Header in group type C composed of FID and FN
FID Function Identifier
FN Function Number
hex hexadecimal
IH In-House application
NOTE 4 IH was used in previous editions of IEC 62106. It can now be an ODA.
ILS International Linkage Set indicator
LA Linkage Actuator
LI Linkage Indicator
LPS Long Programme Service name
lsb least significant bit or least significant byte
LSN Linkage Set Number
MS Music Speech switch
NOTE 5 MS was used in previous editions of IEC 62106. It is now obsolete.
msb most significant bit or most significant byte
ODA Open Data Application
ON Other Network
PI Programme Identification
PIN Programme Item Number
NOTE 6 PIN was used in previous editions of IEC 62106. It is now obsolete.
PS Programme Service name
PTY Programme Type
PTYI Programme Type Indicator
PTYN Programme Type Name
RFT RDS2 File Transfer protocol
rfu reserved for future use
RP Radio Paging
NOTE 7 RP was used in previous editions of IEC 62106. It is now obsolete.
RT RadioText
RT+ RadioText plus
TA Traffic Announcement
TDC Transparent Data Channel
NOTE 8 TDC was used in previous editions of IEC 62106. It can now be an ODA.
TMC Traffic Message Channel
TN Tuned Network
TP Traffic Programme
3.3 Notation and conventions
The notation and conventions given in IEC 62106-1 apply.
4 Message format
4.1 Design principles
The basic design principles underlying the message format and addressing structure are as
follows:
a) The original single RDS data-stream (now referred to as data-stream 0) has been
supplemented by three new RDS data-streams referred to as data-streams 1, 2 and 3.
Data-stream 0 will continue to only carry group types A and B (referred to as legacy data).
Data-streams 1, 2 and 3 will only carry a new group type C. Legacy data groups A and B
can be carried on data-streams 1, 2 and 3, but first need to be packaged within a type C
group, using a mechanism referred to as "tunnelling".
b) The mixture of different kinds of messages within any type A or B group is minimized. For
example, one group type is reserved for basic tuning information, another for RadioText,
etc. This is important so that broadcasters, who do not wish to transmit messages of certain
kinds, are not forced to waste channel capacity by transmitting groups with unused blocks.
Instead, they are able to repeat more frequently those group types which contain the
messages they want to transmit.
c) Data that has to be acquired quickly for receiver operation and for which a short acquisition
time is required, for example Programme Identification (PI), Programme Type (PTY), and
Traffic Programme flag (TP) are transmitted frequently and are always transmitted in data-
stream 0. In data-stream 0, these features are present in every group and occupy the same
fixed positions. They can therefore be decoded without reference to any block outside the
one which contains the information.
d) The Programme Service name (PS), a fundamental feature of RDS, is also always
transmitted in data-stream 0, using a fixed group type – 0A or 0B for the short form, 15A for
the longer (UTF-8, see ISO/IEC 10646) form. By having a fixed group type (i.e. not an ODA),
the PS name can be decoded without reference to any other group.
e) For compatibility with existing receivers, other RDS features will continue to use fixed group
types and be transmitted in data-stream 0. These include Slow-labelling (1A), Clock-time
(4A), RadioText (2A or 2B), PTYN (10A), EON (14A and 14B) and TA status control bursts
(15B).
f) The practice of allowing future applications to be defined by using an Open Data Application
has been extended, and the data formatting has been made more flexible. In addition to an
Open Data Application (see IEC 62106-3) using legacy group types A or B in data-stream 0
(see Table 2), a new group type C Open Data Application has been specified to allow greater
data capacity in data-streams 1, 2 and 3.
g) Open Data Applications defined by group types A or B can be carried in any data-stream 0,
1, 2 and 3, although use of data-streams 1 – 3 requires the use of tunnelling.
h) Open Data Applications defined by group type C can only be carried in data-streams 1, 2
and 3. The essential core RDS features (PI, PTY, PS, etc.) will always be transmitted in
data-stream 0 in every programme service using group types A or B.
– 12 – IEC 62106-2:2021 © IEC 2021
i) The application identification AID which identifies an Open Data Application shall be sent
at least once every 5 s.
j) There is no fixed rhythm of repetition of the various types of groups, i.e. there is ample
flexibility to interleave the various kinds of messages to suit the needs of the user at any
given time and to allow for future developments. However, on data-stream 0, the main RDS
features need to use minimum repetition rates specified in Clause 8.
4.2 Group structure
4.2.1 Group type A structure
The group type A structure is illustrated in Figure 1. The main features are the following.
a) The first block in every group always contains a Programme Identification (PI) code.
b) The first four bits of the second block of every group are allocated to a 4-bit code which
specifies the application of the group. Groups will be referred to as 0 to 15 according to the
binary weighting A = 8, A = 4, A = 2, A = 1. For each group (0 to 15) two 'versions' can
3 2 1 0
be defined. The 'version' is specified by the fifth bit (B ) of block 2 as follows:
c) B = 0: Defines group type A. The PI code is inserted in block 1 only. This will be called
version A, for example group type 0A, 1A, etc.
d) B = 1: Defines group type B (see 4.2.2).
e) The Programme Type code (PTY) and Traffic Programme identification (TP) occupy fixed
locations in block 2 of every group.
Within the group type A structure, the PI, PTY and TP codes can be decoded without reference
to any block outside the one that contains the information. This is essential to minimize
acquisition time for these kinds of messages and to retain the advantages of the short (26-bit)
block length.
NOTE 1 Block size = 26 bits.
NOTE 2 Checkword + offset 'N' = 10 bit added to provide error protection and block and group synchronization
information (see IEC 62106-1).
NOTE 3 t < t : block 1 of any particular group is transmitted first and block 4 last.
1 2
Figure 1 – Group type A structure
Group type A can be used directly in data-stream 0 and has an application data capacity of
37 bits. To use group type A in the upper data-streams 1, 2 and 3, the PI code in block 1 needs
to be replaced by 0x0000 to re-define the group as type C utilizing the tunnelling mechanism
(see 4.4.1).
4.2.2 Group type B structure
The group type B structure is illustrated in Figure 2. It is similar to the group type A structure
with the following differences.
a) The first and third block in every group always contain the Programme Identification (PI)
code.
b) The 'version' is specified by bit B of block 2 as follows:
B = 0: Defines group type A (see 4.2.1).
B = 1: Defines group type B.
c) In addition to B = 1 a special offset word (which is called C') is used in block 3 of version
B groups. The occurrence of offset C' in block 3 of any group can be used to indicate directly
that block 3 is a PI code, without any reference to the value of B in block 2.
Figure 2 – Group type B structure
The group type B can be used directly in data-stream 0 and has an application data capacity of
21 bits. To use group type B in the upper data-streams 1, 2 and 3, the PI code in block 1 needs
to be replaced by 0x0000 to re-define the group as type C utilizing the tunnelling mechanism
(see 4.4.1). The PI code in block 3 will be left unchanged.
4.2.3 Group type C structure
The group type C structure is illustrated in Figure 3.
NOTE The Function Header (FH) fully determines the identification of the group.
Figure 3 – Group type C structure
– 14 – IEC 62106-2:2021 © IEC 2021
The group type C can only be used on data-streams 1, 2 and 3 and has an application data
capacity of 56 bits considered as a 7-byte contiguous data group.
The Function Header (FH) consists of two elements, see Table 1.
– Function Identifier (FID) (2 bits) indicates one of four types of usage (Functions) of the
accompanying data contained in the group.
– Function Number (FN) (6 bits) indicates a sub-function of the main Function Identifier and
allows for different features of each function. For a given Function Identifier, not all Function
Numbers are defined. Undefined Function Numbers are reserved for future use.
Table 1 – Group type C Function Header definition
FID FN Meaning of Function Header (FH)
FID and FN
b b b b b b b b
15 14 13 12 11 10 9 8
0 0 0 0 0 0 0 0 Legacy group type A or B transmission, see 4.4.1
0 0 1 0 y y y y RFT data group for ODA pipe yyyy, see Annex C
16 pipes/channels are available across data-streams 1 to 3
0 1 y y y y y y Group type C ODA channel, see 4.4.2
64 channels (6 bit: yyyyyy) are available across data-streams
1 to 3. Channels 0 to 15 are reserved for providing additional
data. These 16 channels are reserved for ODAs that require
additional data in the form of files. This additional data will be
sent in FH=0010yyyy using the RFT protocol.
1 0 0 0 0 0 0 0 AID and channel number assignment for group type C ODAs,
see 4.4.3
1 1 x x x x x x rfu
4.2.4 RFT ODA pipe/channel
Channel numbers 0 …15 are reserved for ODAs that use external data in the form of files, which
are provided using the RFT protocol. The RFT data is transported using a pipe number that
equals the ODA channel number.
The assignment of these ODAs will always use assignment method 1, allowing 4 bytes of
additional data, see 4.4.3.
For the channel range 0 …15, the data in these bytes is organized in 16 variants, where the
first eight variants are reserved for the RFT protocol and the other eight are free to be used by
the ODA designer (see Annex C).
4.3 Group type A and B usage
Table 2 – Group type A and B usage
Group
Group type
Description
type code and
version
0A 0000 0 Basic tuning and switching information with Programme Service name
0B 0000 1 Basic tuning and switching information with Programme Service name
1A 0001 0 Slow labelling codes
1B 0001 1 Open Data Applications
2A 0010 0 RadioText
2B 0010 1 RadioText
3A 0011 0 Application Identification for ODA and 16 bits of ODA data
3B 0011 1 Open Data Applications
4A 0100 0 Clock-time and date
4B 0100 1 Open Data Applications
5A 0101 0 Open Data Applications
5B 0101 1 Open Data Applications
6A 0110 0 Open Data Applications
6B 0110 1 Open Data Applications
7A 0111 0 Open Data Applications
7B 0111 1 Open Data Applications
8A 1000 0 Open Data Applications: Traffic Message Channel or if TMC not used, any other ODA
8B 1000 1 Open Data Applications
9A 1001 0 Open Data Applications
9B 1001 1 Open Data Applications
10A 1010 0 Programme Type Name
10B 1010 1 Open Data Applications
11A 1011 0 Open Data Applications
11B 1011 1 Open Data Applications
12A 1100 0 Open Data Applications
12B 1100 1 Open Data Applications
13A 1101 0 Open Data Applications
13B 1101 1 Open Data Applications
14A 1110 0 Enhanced Other Networks information
14B 1110 1 Enhanced Other Networks information
15A 1111 0 Long Programme Service name
15B 1111 1 Fast switching information
– 16 – IEC 62106-2:2021 © IEC 2021
4.4 Group type C usage
4.4.1 Transmitting legacy data using data-streams 1, 2 and 3
FID = 00
FN = 000000
All legacy data (any group type A or B) can be transmitted using the upper data-streams 1, 2
and 3 within the group type C structure.
The two bytes of block 1, traditionally representing the PI code, are both set to 0x00. This
"deleted" PI code is always the same as the PI code simultaneously transmitted in block 1 of
data-stream 0.
This process of transmitting legacy data using the upper data-streams 1, 2 and 3 is known as
"tunnelling".
If the application software at the receiving end requires fully defined groups of type A or B, the
PI code from data-stream 0 may be reinserted in block 1, replacing the two 0x00 bytes.
Figure 4 shows the tunnelling structure for group types A and B.
Figure 4 – Tunnelling structure for group types A and B
4.4.2 Transmitting group type C ODA data
FID = 01
FN = yyyyyy (0 … 63)
This Function Header allows group type C ODA data to be sent using channel yyyyyy (0 …63)
indicated by the 6 bits of FN, 64 channels in total on data-streams 1, 2 and 3.
The ODA application data content is 7 bytes.
The channel number associates the accompanying 7 bytes of data with a particular AID of a
group type C ODA. This is similar to the association made (using group 3A) between the group
number and a particular AID of a legacy group type A or B ODA in data-stream 0. For group
type C ODAs, the channel number is assigned to an AID as defined below in 4.4.3.
------------
...
IEC 62106-2 ®
Edition 2.0 2021-02
REDLINE VERSION
INTERNATIONAL
STANDARD
colour
inside
Radio data system (RDS) – VHF/FM sound broadcasting in the frequency range
from 64,0 MHz to 108,0 MHz –
Part 2: Message format: coding and definitions of RDS features
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.
IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.
About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.
IEC publications search - webstore.iec.ch/advsearchform IEC online collection - oc.iec.ch
The advanced search enables to find IEC publications by a Discover our powerful search engine and read freely all the
variety of criteria (reference number, text, technical publications previews. With a subscription you will always
committee, …). It also gives information on projects, replaced have access to up to date content tailored to your needs.
and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished
The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published
containing more than 22 000 terminological entries in English
details all new publications released. Available online and
and French, with equivalent terms in 18 additional languages.
once a month by email.
Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer Service
Centre: sales@iec.ch.
IEC 62106-2 ®
Edition 2.0 2021-02
REDLINE VERSION
INTERNATIONAL
STANDARD
colour
inside
Radio data system (RDS) – VHF/FM sound broadcasting in the frequency range
from 64,0 MHz to 108,0 MHz –
Part 2: Message format: coding and definitions of RDS features
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 33.160.40 ISBN 978-2-8322-9484-0
– 2 – IEC 62106-2:2021 RLV © IEC 2021
CONTENTS
FOREWORD . 6
INTRODUCTION . 2
1 Scope . 10
2 Normative references . 10
3 Terms, definitions, abbreviated terms and conventions . 10
3.1 Terms and definitions . 10
3.2 Abbreviated terms . 10
3.3 Notation and conventions . 12
4 Message format . 12
4.1 Design principles . 12
4.2 Group structure . 13
4.2.1 Group type A structure . 13
4.2.2 Group type B structure . 14
4.2.3 Group type C structure . 14
4.2.4 RFT ODA pipe/channel . 15
4.3 Group type A and B usage . 16
4.4 Group type C usage . 17
4.4.1 Transmitting legacy data using data-streams 1, 2 and 3. 17
4.4.2 Transmitting group type C ODA data . 17
4.4.3 AID and channel number assignment for group type C ODAs. 18
5 Description of the RDS features. 19
5.1 Alternative Frequencies list (AFs) . 19
5.2 Clock Time and date (CT) . 19
5.3 Dynamic PTY Indicator (PTYI) using DI . 19
5.4 Extended Country Code (ECC) . 19
5.5 Enhanced Other Networks information (EON) . 19
5.6 Linkage information . 20
5.7 Open Data Applications (ODAs) . 20
5.8 Programme Identification (PI). 20
5.9 Programme Service name – (PS) . 21
5.10 Long Programme Service name – (LPS) . 21
5.11 Programme Type (PTY) . 21
5.12 Programme Type Name (PTYN) . 21
5.13 RadioText (RT) . 22
5.14 enhanced RadioText (eRT) . 22
5.15 RadioText Plus (RT+ and eRT+) . 22
5.16 Traffic Programme identification (TP) . 22
5.17 Traffic Announcement identification (TA) . 22
5.18 Traffic Message Channel (TMC) . 23
6 Coding of the group types . 23
6.1 Groups of type 0A and 0B: Basic tuning and switching information with PS
name . 23
6.2 Group type 1A: Slow labelling codes . 24
6.3 Group type 2A and 2B: RadioText . 25
6.4 Group type 3A: Application identification for any specific ODA using groups
of type A or B . 26
6.5 Group type 4A: Clock-Time and date. 26
6.6 Group type 10A: Programme Type Name PTYN . 27
6.7 Group type 14A and B: Enhanced Other Networks information (EON) . 28
6.8 Group type 15A: Long Programme Service name – 32 bytes with UTF-8
coding . 28
6.9 Group type 15B: Fast basic tuning and switching information . 29
7 Coding of RDS features for control . 30
7.1 Programme Identification (PI) codes and Extended Country Codes (ECC) . 30
7.1.1 PI structure . 30
7.1.2 Country Identifier (CI) codes: 'Nibble 1' . 30
7.1.3 Extended Country Codes (ECC) . 30
7.1.4 Programme service in terms of area coverage (codes for fixed location
transmitters only): 'Nibble 2' . 31
7.1.5 Programme reference number: 'Nibbles 3 and 4' . 31
7.1.6 PI codes for low-power short range transmitting devices . 31
7.2 Programme Type (PTY) codes . 32
7.3 Traffic Programme (TP) and Traffic Announcement (TA) codes . 32
7.4 Decoder Identification (DI) and dynamic PTY Indicator (PTYI) codes . 32
7.5 Coding of Alternative Frequencies (AFs) . 33
7.5.1 AF code tables . 33
7.5.2 Use of Alternative Frequencies in group type 0A. 35
7.5.3 Use of AF codes in group type 14A . 37
7.6 Coding of Enhanced Other Networks information (EON) . 38
7.6.1 General . 38
7.6.2 Coding of frequencies for cross-referenced programme services in EON . 39
7.6.3 Use of the TP and TA features with EON . 39
7.6.4 Use of PTY with EON . 40
8 Required main RDS feature repetition rates on data-stream 0 . 40
Annex A (normative) Method for linking RDS programme services – Linkage
information – Group type 1A and 14A . 45
A.1 General . 45
A.2 LA – Linkage Actuator . 46
A.3 EG – Extended Generic indicator . 46
A.4 ILS – International Linkage Set indicator . 46
A.5 LSN – Linkage Set Number . 46
Annex B (informative) Conversion between time and date conventions . 48
Annex C (normative) RDS2 File Transfer protocol RFT for files up to 163 kB . 50
C.1 Group coding of the ODA-AID assignment groups . 50
C.1.1 General principles . 50
C.1.2 Variant 0 . 50
C.1.3 Variant 1 . 51
C.1.4 Variants 2 to 15 . 52
C.2 Coding of the RFT data group used to carry the file data bytes . 52
Annex D (informative) CRC-16 ITU-T/CCITT checkword calculation . 54
D.1 General . 54
D.2 PASCAL listing of CRC-16-calculation routine . 54
D.3 C listing of the CRC-16 calculation routine . 54
D.4 Fictitious example . 55
Bibliography . 56
– 4 – IEC 62106-2:2021 RLV © IEC 2021
Figure 1 – Group type A structure . 13
Figure 2 – Group type B structure . 14
Figure 3 – Group type C structure . 14
Figure 4 – Tunnelling structure for group types A and B . 17
Figure 5 – Basic tuning and switching information – Group type 0A . 23
Figure 6 – Basic tuning and switching information – Group type 0B . 24
Figure 7 – Slow labelling codes – Group type 1A . 24
Figure 8 – RadioText – Group type 2A . 25
Figure 9 – RadioText – Group type 2B . 26
Figure 10 – Application identification for any specific ODA – Group type 3A . 26
Figure 11 – Clock-Time and date transmission – Group type 4A . 27
Figure 12 – Programme Type Name PTYN – Group type 10A . 27
Figure 13 – Enhanced Other Networks information – Group type 14A . 28
Figure 14 – Enhanced Other Networks information – Group type 14B . 28
Figure 15 – Long PS, UTF-8 coded – Group type 15A . 29
Figure 16 – Fast basic tuning and switching information – Group type 15B . 29
Figure 17 – PI code structure . 30
Figure A.1 – Structure of group type 1A, block 3 . 45
Figure A.2 – Structure of group type 14A variant 12, block 3 (Linkage information) –
National link . 46
Figure A.3 – Structure of group type 14A variant 12, block 3 (Linkage information) –
International link . 47
Figure B.1 – Conversion routes between Modified Julian Date (MJD) and Coordinated
Universal Time (UTC) . 48
Figure C.1 – AID assignment group coding for variant 0. 50
Figure C.2 – AID assignment group coding for variant 1. 52
Figure C.3 – AID assignment group coding for variant 2 to 15 . 52
Figure C.4 – RFT data group . 53
Table 1 – Group type C Function Header definition . 15
Table 2 – Group type A and B usage . 16
Table 3 – Group type C assignment methods used to connect channel numbers with
one or more AIDs . 18
Table 4 – Assignment of up to three successive channel numbers to multiple AIDs. 19
Table 5 – Area coverage codes . 31
Table 6 – Programme service reference number codes . 31
Table 7 – PI codes for short range transmitting devices . 32
Table 8 – Codes for TP and TA . 32
Table 9 – Meaning of bits d to d . 33
0 3
Table 10 – VHF frequencies 87,6 MHz to 107,9 MHz code table . 33
Table 11 – Special meanings AF code table . 34
Table 12 – LF/MF code table – ITU regions 1 and 3 (9 kHz spacing) . 34
Table 13 – MF code table – ITU region 2 (10 kHz spacing) . 35
Table 14 – Example including AFs for the extended FM Band . 38
Table 15 – Data-stream 0 group repetition rates: Transmitter not part of a
multi-programme service network: no TMC and only 'basic' RDS features . 41
Table 16 – Data-stream 0 group repetition rates: Transmitter part of a multi-programme
service network: no TMC . 41
Table 17 – Data-stream 0 group repetition rates: Transmitter not part of a multi-
programme service network: with TMC . 42
Table 18 – Data-stream 0 group repetition rates: Transmitter not part of a multi-
programme service network: no TMC and with support for UTF-8 coded characters . 43
Table 19 – Data-stream 0 group repetition rates: Transmitter part of a multi-programme
service network: with TMC . 44
Table B.1 – Symbols used for time and date calculation. 48
Table C.2 – Relation between chunk size, max. file size and max.chunk address . 51
– 6 – IEC 62106-2:2021 RLV © IEC 2021
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
RADIO DATA SYSTEM (RDS) –
VHF/FM SOUND BROADCASTING IN THE FREQUENCY
RANGE FROM 64,0 MHz TO 108,0 MHz –
Part 2: Message format: coding and definitions of RDS features
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC Publication(s)"). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent
rights. IEC shall not be held responsible for identifying any or all such patent rights.
This redline version of the official IEC Standard allows the user to identify the changes made to
the previous edition IEC 62106-2:2018. A vertical bar appears in the margin wherever a change
has been made. Additions are in green text, deletions are in strikethrough red text.
IEC 62106-2 has been prepared by technical area 1: Terminals for audio, video and data
services and contents, of IEC technical committee 100: Audio, video and multimedia systems
and equipment. It is an International Standard.
This second edition cancels and replaces the first edition published in 2018. This edition
constitutes a technical revision.
This edition includes the following significant technical changes with respect to
IEC 62106‑2:2018:
a) Subclause 4.2.4 has been added;
b) Tables 1 and 13 have been modified;
c) The new function RDS2 file transfer has been added and it is detailed in Annex C; this uses
a CRC-16, which is specified in Annex D.
The text of this International Standard is based on the following documents:
CDV Report on voting
100/3464/CDV 100/3547/RVC
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
A list of all parts in the IEC 62106 series, published under the general title Radio data
system (RDS) – VHF/FM sound broadcasting in the frequency range from 64,0 MHz to
108,0 MHz, can be found on the IEC website.
The language used for the development of this International Standard is English,
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/standardsdev/publications.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates that it
contains colours which are considered to be useful for the correct understanding of its
contents. Users should therefore print this document using a colour printer.
– 8 – IEC 62106-2:2021 RLV © IEC 2021
INTRODUCTION
Since the mid-1980s, a fascinating development has taken place. Most of the multimedia
applications and standards have been created or redefined significantly. Hardware has become
extremely powerful with dedicated software and middleware. In the mid-1980s, Internet as well
as its protocols did not exist. Navigation systems became affordable in the late 1990s, and a
full range of attractive smartphones now exist. The computing power of all these new products
is comparable with that of the mainframe installations in that era.
Listener expectations have grown faster than the technology. Visual experience is now very
important, like the Internet look and feel. Scrolling text or delivering just audio is nowadays
perceived as insufficient for FM radio, specifically especially for smartphone users. New types
of radio receivers with added value features are therefore required. RDS has so far proven to
be very successful.
FM radio with RDS is an analogue-digital hybrid system, which is still a valid data transmission
technology and only the applications need adaptation. Now the time has come to solve the only
disadvantage, the lack of sufficient data capacity. With RDS2, the need to increase the data
capacity can be fulfilled.
RDS was introduced in the early 1980s. During the introductory phase in Europe, the car
industry became very involved and that was the start of an extremely successful roll-out. Shortly
.
afterwards, RDS (RBDS) was launched in the USA [1, 2, 3, 4, 5]
The RDS Forum has investigated a solution to the issue of limited data capacity. For RDS2,
both sidebands around the RDS 57 kHz subcarrier can be repeated a few times, up to three,
centred on additional subcarriers higher up in the FM multiplex while still remaining compatible
with the ITU Recommendations.
The core elements of RDS2 are the additional subcarriers, which will enable a significant
increase of RDS data capacity to be achieved, and then only new additional data applications
will have to be created, using the RDS-ODA feature, which has been part of the RDS standard
IEC 62106 for many years.
In order to update IEC 62106:2015 to the specifications of RDS2, IEC 62106 has been
restructured as follows:
Part 1: Modulation characteristics and baseband coding
Part 2: RDS message format, coding and definition of RDS features
Part 3: Usage and registration of Open Data Applications ODAs
Part 4: Registered code tables
Part 5: Marking of RDS and RDS2 devices
Part 6: Compilation of technical specifications for Open Data Applications in the public domain
The following future parts are planned:
Part 79: RBDS – RDS variant used in North America
Part 810: Universal Encoder Communication Protocol UECP
The original specifications of the RDS system have been maintained and the extra
functionalities of RDS2 have been added.
_______________
Numbers in square brackets refer to the Bibliography.
Obsolete or unused functions from the original RDS standard IEC 62106:2015 have been
deleted. The presentation in Parts 1, 2 and 3 follows the OSI basic reference model for
information processing systems [6].
– 10 – IEC 62106-2:2021 RLV © IEC 2021
RADIO DATA SYSTEM (RDS) –
VHF/FM SOUND BROADCASTING IN THE FREQUENCY
RANGE FROM 64,0 MHz TO 108,0 MHz –
Part 2: Message format: coding and definitions of RDS features
1 Scope
This part of IEC 62106 defines the coding and definition of features for the Radio Data System
(RDS).
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC 62106 (all parts), Radio Data System (RDS) – VHF/FM sound broadcasting in the frequency
range from 64,0 MHz to 108,0 MHz
ISO/IEC 10646, Information technology – Universal Coded Character Set (UCS)
ISO 14819 (all parts), Intelligent transport systems – Traffic and travel information messages
via traffic message coding
3 Terms, definitions, abbreviated terms and conventions
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62106-1 apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.2 Abbreviated terms
For the purposes of this document, the abbreviated terms given in IEC 62106-1 and the
following apply.
AF Alternative Frequency
NOTE 1 Alternative Frequencies are given in the form of lists (method A or B or mapped).
AID Application IDentification for ODAs
CI Country Identifier
CRC-16 16 bit Cyclic Redundancy Check
CT Clock Time
NOTE 2 In RDS, Clock Time includes the date.
DI Decoder Identification
ECC Extended Country Code
EG Extended Generic indicator
EON Enhanced Other Network information
eRT enhanced RadioText
EWS Emergency Warning System
NOTE 3 EWS was used in previous editions of IEC 62106. It can now be an ODA.
FH Function Header in group type C composed of FID and FN
FID Function Identifier
FN Function Number
hex hexadecimal
IH In-House application
NOTE 4 IH was used in previous editions of IEC 62106. It can now be an ODA.
ILS International Linkage Set indicator
LA Linkage Actuator
LI Linkage Indicator
LPS Long Programme Service name
lsb least significant bit or least significant byte
LSN Linkage Set Number
MS Music Speech switch
NOTE 5 MS was used in previous editions of IEC 62106. It is now obsolete.
msb most significant bit or most significant byte
ODA Open Data Application
ON Other Network
PI Programme Identification
PIN Programme Item Number
NOTE 6 PIN was used in previous editions of IEC 62106. It is now obsolete.
PS Programme Service name
PTY Programme Type
PTYI Programme Type Indicator
PTYN Programme Type Name
RFT RDS2 File Transfer protocol
rfu reserved for future use
RP Radio Paging
NOTE 7 RP was used in previous editions of IEC 62106. It is now obsolete.
RT RadioText
RT+ RadioText plus
TA Traffic Announcement
– 12 – IEC 62106-2:2021 RLV © IEC 2021
TDC Transparent Data Channel
NOTE 8 TDC was used in previous editions of IEC 62106. It can now be an ODA.
TMC Traffic Message Channel
TN Tuned Network
TP Traffic Programme
3.3 Notation and conventions
The notation and conventions given in IEC 62106-1 apply.
4 Message format
4.1 Design principles
The basic design principles underlying the message format and addressing structure are as
follows:
a) The original single RDS data-stream (now referred to as data-stream 0) has been
supplemented by three new RDS data-streams referred to as data-streams 1, 2 and 3.
Data-stream 0 will continue to only carry group types A and B (referred to as legacy data).
Data-streams 1, 2 and 3 will only carry a new group type C. Legacy data groups A and B
can be carried on data-streams 1, 2 and 3, but first need to be packaged within a type C
group, using a mechanism referred to as "tunnelling".
b) The mixture of different kinds of messages within any type A or B group is minimized. For
example, one group type is reserved for basic tuning information, another for RadioText,
etc. This is important so that broadcasters, who do not wish to transmit messages of certain
kinds, are not forced to waste channel capacity by transmitting groups with unused blocks.
Instead, they are able to repeat more frequently those group types which contain the
messages they want to transmit.
c) Data that has to be acquired quickly for receiver operation and for which a short acquisition
time is required, for example Programme Identification (PI), Programme Type (PTY), and
Traffic Programme flag (TP) are transmitted frequently and are always transmitted in data-
stream 0. In data-stream 0, these features are present in every group and occupy the same
fixed positions. They can therefore be decoded without reference to any block outside the
one which contains the information.
d) The Programme Service name (PS), a fundamental feature of RDS, is also always
transmitted in data-stream 0, using a fixed group type – 0A or 0B for the short form, 15A for
the longer (UTF-8, see ISO/IEC 10646) form. By having a fixed group type (i.e. not an ODA),
the PS name can be decoded without reference to any other group.
e) For compatibility with existing receivers, other RDS features will continue to use fixed group
types and be transmitted in data-stream 0. These include Slow-labelling (1A), Clock-time
(4A), RadioText (2A or 2B), PTYN (10A), EON (14A and 14B) and TA status control bursts
(15B).
f) The practice of allowing future applications to be defined by using an Open Data Application
has been extended, and the data formatting has been made more flexible. In addition to an
Open Data Application (see IEC 62106-3) using legacy group types A or B in data-stream 0
(see Table 2), a new group type C Open Data Application has been specified to allow greater
data capacity in data-streams 1, 2 and 3.
g) Open Data Applications defined by group types A or B can be carried in any data-stream 0,
1, 2 and 3, although use of data-streams 1 – 3 requires the use of tunnelling.
h) Open Data Applications defined by group type C can only be carried in data-streams 1, 2
and 3. The essential core RDS features (PI, PTY, PS, etc.) will always be transmitted in
data-stream 0 in every programme service using group types A or B.
i) The application identification AID which identifies an Open Data Application shall be sent
at least once every 5 s.
j) There is no fixed rhythm of repetition of the various types of groups, i.e. there is ample
flexibility to interleave the various kinds of messages to suit the needs of the user at any
given time and to allow for future developments. However, on data-stream 0, the main RDS
features need to use minimum repetition rates specified in Clause 8.
4.2 Group structure
4.2.1 Group type A structure
The group type A structure is illustrated in Figure 1. The main features are the following.
a) The first block in every group always contains a Programme Identification (PI) code.
b) The first four bits of the second block of every group are allocated to a 4-bit code which
specifies the application of the group. Groups will be referred to as 0 to 15 according to the
binary weighting A = 8, A = 4, A = 2, A = 1. For each group (0 to 15) two 'versions' can
3 2 1 0
be defined. The 'version' is specified by the fifth bit (B ) of block 2 as follows:
c) B = 0: Defines group type A. The PI code is inserted in block 1 only. This will be called
version A, for example group type 0A, 1A, etc.
d) B = 1: Defines group type B (see 4.2.2).
e) The Programme Type code (PTY) and Traffic Programme identification (TP) occupy fixed
locations in block 2 of every group.
Within the group type A structure, the PI, PTY and TP codes can be decoded without reference
to any block outside the one that contains the information. This is essential to minimize
acquisition time for these kinds of messages and to retain the advantages of the short (26-bit)
block length.
NOTE 1 Block size = 26 bits.
NOTE 2 Checkword + offset 'N' = 10 bit added to provide error protection and block and group synchronization
information (see IEC 62106-1).
NOTE 3 t < t : block 1 of any particular group is transmitted first and block 4 last.
1 2
Figure 1 – Group type A structure
Group type A can be used directly in data-stream 0 and has an application data capacity of
37 bits. To use group type A in the upper data-streams 1, 2 and 3, the PI code in block 1 needs
to be replaced by 0x0000 to re-define the group as type C utilizing the tunnelling mechanism
(see 4.4.1).
– 14 – IEC 62106-2:2021 RLV © IEC 2021
4.2.2 Group type B structure
The group type B structure is illustrated in Figure 2. It is similar to the group type A structure
with the following differences.
a) The first and third block in every group always contain the Programme Identification (PI)
code.
b) The 'version' is specified by bit B of block 2 as follows:
B = 0: Defines group type A (see 4.2.1).
B = 1: Defines group type B.
c) In addition to B = 1 a special offset word (which is called C') is used in block 3 of version
B groups. The occurrence of offset C' in block 3 of any group can be used to indicate directly
that block 3 is a PI code, without any reference to the value of B in block 2.
Figure 2 – Group type B structure
The group type B can be used directly in data-stream 0 and has an application data capacity of
21 bits. To use group type B in the upper data-streams 1, 2 and 3, the PI code in block 1 needs
to be replaced by 0x0000 to re-define the group as type C utilizing the tunnelling mechanism
(see 4.4.1). The PI code in block 3 will be left unchanged.
4.2.3 Group type C structure
The group type C structure is illustrated in Figure 3.
NOTE The Function Header (FH) fully determines the identification of the group.
Figure 3 – Group type C structure
The group type C can only be used on data-streams 1, 2 and 3 and has an application data
capacity of 56 bits considered as a 7-byte contiguous data group.
The Function Header (FH) consists of two elements, see Table 1.
– Function Identifier (FID) (2 bits) indicates one of four types of usage (Functions) of the
accompanying data contained in the group.
– Function Number (FN) (6 bits) indicates a sub-function of the main Function Identifier and
allows for different features of each function. For a given Function Identifier, not all Function
Numbers are defined. Undefined Function Numbers are reserved for future use.
Table 1 – Group type C Function Header definition
FID FN Meaning of Function Header (FH)
FID and FN
b b b b b b b b
15 14 13 12 11 10 9 8
0 0 0 0 0 0 0 0 Legacy group type A or B transmission, see 4.4.1
0 0 1 0 y y y y RFT data group for ODA pipe yyyy, see Annex C
16 pipes/channels are available across data-streams 1 to 3
0 1 y y y y y y Group type C ODA channel, see 4.4.2
64 channels (6 bit: yyyyyy) are available across data-streams
1 to 3. Channels 0 to 15 are reserved for providing additional
data. These 16 channels are reserved for ODAs that require
additional data in the form of files. This additional data will be
sent in FH=0010yyyy using the RFT protocol.
1 0 0 0 0 0 0 0 AID and channel number assignment for group type C ODAs,
see 4.4.3
1 1 x x x x x x rfu
4.2.4 RFT ODA pipe/channel
Channel numbers 0 …15 are reserved for ODAs that use external data in the form of files, which
are provided using the RFT protocol. The RFT data is transported using a pipe number that
equals the ODA channel number.
The assignment of these ODAs will always use assignment method 1, allowing 4 bytes of
additional data, see 4.4.3.
For the channel range 0 …15, the data in these bytes is organized in 16 variants, where the
first eight variants are reserved for the RFT protocol and the other eight are free to be used by
the ODA designer (see Annex C).
– 16 – IEC 62106-2:2021 RLV © IEC 2021
4.3 Group type A and B usage
Table 2 – Group type A and B usage
Group
Group type
Description
type code and
version
0A 0000 0 Basic tuning and switching information with Programme Service name
0B 0000 1 Basic tuning and switching information with Programme Service name
1A 0001 0 Slow labelling codes
1B 0001 1 Open Data Applications
2A 0010 0 RadioText
2B 0010 1 RadioText
3A 0011 0 Application Identification for ODA and 16 bits of ODA data
3B 0011 1 Open Data Applications
4A 0100 0 Clock-time and date
4B 0100 1 Open Data Applications
5A 0101 0 Open Data Applications
5B 0101 1 Open Data Applications
6A 0110 0 Open Data Applications
6B 0110 1 Open Data Applications
7A 0111 0 Open Data Applications
7B 0111 1 Open Data Applications
8A 1000 0 Open Data Applications: Traffic Message Channel or if TMC not used, any other ODA
8B 1000 1 Open Data Applications
9A 1001 0 Open Data Applications
9B 1001 1 Open Data Applications
10A 1010 0 Programme Type Name
10B 1010 1 Open Data Applications
11A 1011 0 Open Data Applications
11B 1011 1 Open Data Applications
12A 1100 0 Open Data Applications
12B 1100 1 Open Data Applications
13A 1101 0 Open Data Applications
13B 1101 1 Open Data Applications
14A 1110 0 Enhanced Other Networks information
14B 1110 1 Enhanced Other Networks information
15A 1111 0 Long Programme Service name
15B 1111 1 Fast switching information
4.4 Group type C usage
4.4.1 Transmitting legacy data using data-streams 1, 2 and 3
FID = 00
FN = 000000
All legacy data (any group type A or B) can be transmitted using the upper data-streams 1, 2
and 3 within the group type C structure.
The two bytes of block 1, traditionally representing the PI code, are both set to 0x00. This
"deleted" PI code is always the same as the PI code simultaneously transmitted in block 1 of
data-stream 0.
This process of transmitting legacy data using the upper data-streams 1, 2 and 3 is also known
as "tunnelling".
If the application software at the receiving end requires fully
...










Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...