IEC 62106-2:2018
(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-2:2018 defines the coding and definition of features for the Radio Data System (RDS).
IEC 62106-2:2018 together with IEC 62106-1, IEC 62106-3, IEC 62106-4, IEC 62106-5 and IEC 62106-6, cancels and replaces IEC 62106:2015, and constitutes a technical revision.
This edition includes the following significant technical changes with respect to IEC 62106:2015:
• Provision has been made to carry RDS on multiple data-streams (RDS2).
• Data in the additional data-streams is using a newly defined group type C data structure.
• AF coding below 87,6 MHz (down to 64,1 MHz) using ODA-AID 0x6365 (see IEC 62106-6).
• Long PS (UTF-8) support has been added using group type 15A.
• Coding for the following applications is no longer detailed in the RDS standard as these can use in future the ODA concept: EWS, TDC, IH and RP.
• Obsolete and no longer part of the RDS standard are: MS (Group 0A, 0B and 15B) certain DI codes (mono/stereo, artificial head, compression), Language code, and PIN (Group 1A).
General Information
Relations
Standards Content (Sample)
IEC 62106-2 ®
Edition 1.0 2018-10
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 corrigenda or an amendment might have been published.
IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing 21 000 terms and definitions in
Technical Specifications, Technical Reports and other English and French, with equivalent terms in 16 additional
documents. Available for PC, Mac OS, Android Tablets and languages. Also known as the International Electrotechnical
iPad. Vocabulary (IEV) online.
IEC publications search - webstore.iec.ch/advsearchform IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a 67 000 electrotechnical terminology entries in English and
variety of criteria (reference number, text, technical French extracted from the Terms and Definitions clause of
committee,…). It also gives information on projects, replaced IEC publications issued since 2002. Some entries have been
and withdrawn publications. collected from earlier publications of IEC TC 37, 77, 86 and
CISPR.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: sales@iec.ch.
IEC 62106-2 ®
Edition 1.0 2018-10
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-6067-8
– 2 – IEC 62106-2:2018 © IEC 2018
CONTENTS
FOREWORD . 5
INTRODUCTION . 7
1 Scope . 8
2 Normative references . 8
3 Terms, definitions, abbreviated terms and conventions . 8
3.1 Terms and definitions . 8
3.2 Abbreviated terms . 8
3.3 Notation and conventions . 10
4 Message format . 10
4.1 Design principles . 10
4.2 Group structure . 11
4.2.1 Group type A structure . 11
4.2.2 Group type B structure . 12
4.2.3 Group type C structure . 12
4.3 Group type A and B usage . 14
4.4 Group type C usage . 15
4.4.1 Transmitting legacy data using data-streams 1, 2 and 3. 15
4.4.2 Transmitting group type C ODA data . 15
4.4.3 AID and channel number assignment for group type C ODAs. 16
5 Description of the RDS features. 17
5.1 Alternative Frequencies list (AFs) . 17
5.2 Clock Time and date (CT) . 17
5.3 Dynamic PTY Indicator (PTYI) using DI . 17
5.4 Extended Country Code (ECC) . 17
5.5 Enhanced Other Networks information (EON) . 17
5.6 Linkage information . 18
5.7 Open Data Applications (ODAs) . 18
5.8 Programme Identification (PI). 18
5.9 Programme Service name – (PS) . 19
5.10 Long Programme Service name – (LPS) . 19
5.11 Programme Type (PTY) . 19
5.12 Programme Type Name (PTYN) . 19
5.13 RadioText (RT) . 20
5.14 enhanced RadioText (eRT) . 20
5.15 RadioText Plus (RT+ and eRT+) . 20
5.16 Traffic Programme identification (TP) . 20
5.17 Traffic Announcement identification (TA) . 20
5.18 Traffic Message Channel (TMC) . 21
6 Coding of the group types . 21
6.1 Groups of type 0A and 0B: Basic tuning and switching information with PS
name . 21
6.2 Group type 1A: Slow labelling codes . 22
6.3 Group type 2A and 2B: RadioText . 23
6.4 Group type 3A: Application identification for any specific ODA using groups
of type A or B . 24
6.5 Group type 4A: Clock-Time and date. 24
6.6 Group type 10A: Programme Type Name PTYN . 25
6.7 Group type 14A and B: Enhanced Other Networks information (EON) . 26
6.8 Group type 15A: Long Programme Service name – 32 bytes with UTF-8
coding . 26
6.9 Group type 15B: Fast basic tuning and switching information . 27
7 Coding of RDS features for control . 28
7.1 Programme Identification (PI) codes and Extended Country Codes (ECC) . 28
7.1.1 PI structure . 28
7.1.2 Country Identifier (CI) codes: ‘Nibble 1’ . 28
7.1.3 Extended Country Codes (ECC) . 28
7.1.4 Programme service in terms of area coverage (codes for fixed location
transmitters only): ‘Nibble 2’ . 29
7.1.5 Programme reference number: ‘Nibbles 3 and 4’ . 29
7.1.6 PI codes for low-power short range transmitting devices . 29
7.2 Programme Type (PTY) codes . 30
7.3 Traffic Programme (TP) and Traffic Announcement (TA) codes . 30
7.4 Decoder Identification (DI) and dynamic PTY Indicator (PTYI) codes . 30
7.5 Coding of Alternative Frequencies (AFs) . 30
7.5.1 AF code tables . 30
7.5.2 Use of Alternative Frequencies in group type 0A. 32
7.5.3 Use of AF codes in group type 14A . 34
7.6 Coding of Enhanced Other Networks information (EON) . 35
7.6.1 General . 35
7.6.2 Coding of frequencies for cross-referenced programme services in EON . 36
7.6.3 Use of the TP and TA features with EON . 36
7.6.4 Use of PTY with EON . 36
8 Required main RDS feature repetition rates on data-stream 0 . 37
Annex A (normative) Method for linking RDS programme services – Linkage
information – Group type 1A and 14A . 41
A.1 General . 41
A.2 LA – Linkage Actuator . 42
A.3 EG – Extended Generic indicator . 42
A.4 ILS – International Linkage Set indicator . 42
A.5 LSN – Linkage Set Number . 42
Annex B (informative) Conversion between time and date conventions . 44
Bibliography . 46
Figure 1 – Group type A structure . 11
Figure 2 – Group type B structure . 12
Figure 3 – Group type C structure . 12
Figure 4 – Tunnelling structure for group types A and B . 15
Figure 5 – Basic tuning and switching information – Group type 0A . 21
Figure 6 – Basic tuning and switching information – Group type 0B . 22
Figure 7 – Slow labelling codes – Group type 1A . 22
Figure 8 – RadioText – Group type 2A . 23
Figure 9 – RadioText – Group type 2B . 24
Figure 10 – Application identification for any specific ODA – Group type 3A . 24
Figure 11 – Clock-Time and date transmission – Group type 4A . 25
– 4 – IEC 62106-2:2018 © IEC 2018
Figure 12 – Programme Type Name PTYN – Group type 10A . 25
Figure 13 – Enhanced Other Networks information – Group type 14A . 26
Figure 14 – Enhanced Other Networks information – Group type 14B . 26
Figure 15 – Long PS, UTF-8 coded – Group type 15A . 27
Figure 16 – Fast basic tuning and switching information – Group type 15B . 27
Figure 17 – PI code structure . 28
Figure A.1 – Structure of group type 1A, block 3 . 41
Figure A.2 – Structure of group type 14A variant 12, block 3 (Linkage information) –
National link . 42
Figure A.3 – Structure of group type 14A variant 12, block 3 (Linkage information) –
International link . 43
Figure B.1 – Conversion routes between Modified Julian Date (MJD) and Coordinated
Universal Time (UTC) . 44
Table 1 – Group type C Function Header definition . 13
Table 2 – Group type A and B usage . 14
Table 3 – Group type C assignment methods used to connect channel numbers with
one or more AIDs . 16
Table 4 – Assignment of up to three successive channel numbers to multiple AIDs. 17
Table 5 – Area coverage codes . 29
Table 6 – Programme service reference number codes . 29
Table 7 – PI codes for short range transmitting devices . 29
Table 8 – Codes for TP and TA . 30
Table 9 – Meaning of bits d to d . 30
0 3
Table 10 – VHF frequencies 87,6 MHz to 107,9 MHz code table . 31
Table 11 – Special meanings AF code table . 31
Table 12 – LF/MF code table – ITU regions 1 and 3 (9 kHz spacing) . 31
Table 13 – MF code table – ITU region 2 (10 kHz spacing) . 32
Table 14 – Data-stream 0 group repetition rates: Transmitter not part of a
multi-programme service network: no TMC and only ‘basic’ RDS features . 37
Table 15 – Data-stream 0 group repetition rates: Transmitter part of a multi-programme
service network: no TMC . 38
Table 16 – Data-stream 0 group repetition rates: Transmitter not part of a multi-
programme service network: with TMC . 38
Table 17 – 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 . 39
Table 18 – Data-stream 0 group repetition rates: Transmitter part of a multi-programme
service network: with TMC . 40
Table B.1 – Symbols used for time and date calculation. 44
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.
International Standard 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.
This first edition, together with IEC 62106-1, IEC 62106-3, IEC 62106-4, IEC 62106-5 and
IEC 62106-6, cancels and replaces IEC 62106:2015, and constitutes a technical revision.
This edition includes the following significant technical changes with respect to
IEC 62106:2015:
• Provision has been made to carry RDS on multiple data-streams (RDS2).
• Data in the additional data-streams is using a newly defined group type C data structure.
• AF coding below 87,6 MHz (down to 64,1 MHz) using ODA-AID 0x6365 (see IEC 62106-6).
– 6 – IEC 62106-2:2018 © IEC 2018
• Long PS (UTF-8) support has been added using group type 15A.
• Coding for the following applications is no longer detailed in the RDS standard as these
can use in future the ODA concept: EWS, TDC, IH and RP.
• Obsolete and no longer part of the RDS standard are: MS (Group 0A, 0B and 15B) certain
DI codes (mono/stereo, artificial head, compression), Language code, and PIN
(Group 1A).
The text of this International Standard is based on the following documents:
CDV Report on voting
100/2910/CDV 100/3056/RVC
Full information on the voting for the approval of this International Standard can be found in
the report on voting indicated in the above table.
This document has been drafted in accordance with the ISO/IEC Directives, Part 2.
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 committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under "http://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.
A bilingual version of this publication may be issued at a later date.
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 for smart phone 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 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 7: RBDS
Part 8: Universal Encoder Communication Protocol UECP
The original specifications of the RDS system have been maintained and the extra
functionalities of RDS2 have been added.
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].
_______________
Numbers in square brackets refer to the Bibliography.
– 8 – IEC 62106-2:2018 © IEC 2018
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 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
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.
– 10 – IEC 62106-2:2018 © IEC 2018
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) 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
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 seconds.
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’
3 2 1 0
) of block 2 as follows:
can be defined. The ‘version’ is specified by the fifth bit (B
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.
B = 1: Defines group type B (see 4.2.2).
c) 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).
– 12 – IEC 62106-2:2018 © IEC 2018
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 contains 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 then 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 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
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
– 14 – IEC 62106-2:2018 © IEC 2018
4.3 Group type A and B usage
Table 2 – Group type A and B usage
Group
Group type
Description
code and
type
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 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.
– 16 – IEC 62106-2:2018 © IEC 2018
4.4.3 AID and channel number assignment for group type C ODAs
FID = 10
FN = 000000
Conventionally, using group type 3A, a specific ODA is assigned to a group number which is
available for ODA use by providing the Application Identification (AID) number and the target
group number. An example is 0xCD46 to group type 8A, meaning TMC data (AID=0xCD46)
will be transmitted using group type 8A.
Block 3 of group type 3A is available, if required, for 16bits of application data which belongs
to the application which is being assigned.
In data-stream 0 only specific groups are available for ODA use (see Table 2).
Across data-streams 1, 2 and 3 there are in total 64 channels available for ODA use.
Four variants of FID = 10 and FN = 000000 are reserved to assign AIDs to channel numbers,
see Table 3 and Table 4. Method 2, 3 or 4 from Table 3 will result in successive channel
numbers using an auto-increment function.
Table 3 – Group type C assignment methods used to connect channel numbers
with one or more AIDs
Method Function Header Variant + Channel id. AID connection with data channel
Block 1 Blocks 2, 3 and 4
1 10 000000 00 yyyyyy Connect data channel yyyyyy with a 16-bit
ODA AID in block 2 and provide in addition
four application data bytes in blocks 3 and
4.
2 10 000000 01 yyyyyy Connect two successive data channels
(yyyyyy and yyyyyy+1) with a 16-bit ODA
AID in block 2 and a second ODA AID in
block 4, respectively, and provide in addition
two application data bytes in block 3 for the
first ODA.
3 10 000000 10 yyyyyy Connect two successive data channels
(yyyyyy and yyyyyy+1) with a 16-bit ODA
AID in block 2 and a second ODA-AID in
block 3, respectively, and provide in addition
two application data bytes in block 4 for the
second ODA.
4 10 000000 11 yyyyyy Connect three successive data channels
(yyyyyy, yyyyyy+1 and yyyyyy+2) with a
16-bit ODA AID in block 2, a second ODA
AID in block 3 and a third ODA AID in block
4, respectively.
Table 4 shows the four methods described in Table 3 in more detail.
Table 4 – Assignment of up to three successive channel numbers to multiple AIDs
Block 1 Block 2 Block 3 Block 4
10 000000 00yyyyyy AID Data (for AID) Data (for AID)
10 000000 01yyyyyy AID1 Data (for AID1) AID2
10 000000 10yyyyyy AID1 AID2 Data (for AID2)
10 000000 11yyyyyy AID1 AID2 AID3
EXAMPLE: When using method 4 in Table
...








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