IEC 62106-6:2023
(Main)Radio data system (RDS) - VHF/FM sound broadcasting in the frequency range from 64,0 MHz to 108,0 MHz - Part 6: Compilation of technical specifications for Open Data Applications in the public domain
Radio data system (RDS) - VHF/FM sound broadcasting in the frequency range from 64,0 MHz to 108,0 MHz - Part 6: Compilation of technical specifications for Open Data Applications in the public domain
IEC 62106-6:2023 contains the technical specifications for Open Data Applications in the public domain. This document is maintained by the RDS Forum Office. The RDS Forum Office applies an easy procedure for registering new Open Data Applications, to ensure that they can be used without the need to change the RDS standard. The ODA feature permits defining new applications that can be decoded on a receiver. The receiver needs to the adequate software handler for the specific AID, which identifies the application. Receivers that have not implemented the software handler needed for decoding are not affected by ODA data received for any of the applications already defined and specified. The procedure for registering a new ODA is described in IEC 62106-3.
IEC 62106-6:2023 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 the previous edition:
a) Annex E: coding of station logo;
b) Annex F: coding of slideshow;
c) Annex G: coding of internet connection;
d) Annex H: ODA tool – RDS data stream NFM.
General Information
Relations
Standards Content (Sample)
IEC 62106-6 ®
Edition 2.0 2023-05
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 6: Compilation of technical specifications for Open Data Applications in the
public domain
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 Secretariat 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 Products & Services Portal - products.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 have
committee, …). It also gives information on projects, replaced 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 300 terminological entries in English
details all new publications released. Available online and once
and French, with equivalent terms in 19 additional languages.
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-6 ®
Edition 2.0 2023-05
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 6: Compilation of technical specifications for Open Data Applications in the
public domain
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 33.160.40 ISBN 978-2-8322-7052-3
– 2 – IEC 62106-6:2023 © IEC 2023
CONTENTS
FOREWORD . 5
INTRODUCTION . 7
1 Scope . 8
2 Normative references . 8
3 Terms, definitions, abbreviated terms and conventions . 9
3.1 Terms and definitions . 9
3.2 Abbreviated terms . 9
3.3 Notation and conventions . 9
4 ODAs in the public domain . 9
4.1 ODAs in the group type A structure . 9
4.1.1 Traffic Message Channel (TMC) . 9
4.1.2 Other public ODAs . 9
4.2 ODAs in the group type C structure for the upper data-streams 1, 2 and 3 . 9
5 Protocol to stream RDS on bearers different from FM (NFM) . 9
Annex A (normative) Coding of RadioText Plus (RT+) tagging information for
RadioText in group type 2A/B . 10
A.1 General . 10
A.2 Terms used . 10
A.3 RT+ tag. 11
A.4 RT+ information elements and data model . 12
A.4.1 General . 12
A.4.2 List of RT content types . 12
A.4.3 Structures of RT+ messages . 13
A.4.4 Receiver data model . 14
A.5 RT+ coding for RT . 15
A.5.1 General . 15
A.5.2 RT+ identification (group type 3A) . 16
A.5.3 Coding of the RT+ tag . 17
A.5.4 Clearing of RT+ messages. 18
A.6 Broadcasting conventions . 22
A.7 Receiving conventions . 22
A.8 Marking . 22
Annex B (normative) Coding of RadioText Plus(RT+) tagging information for
RadioText in the eRT ODA of Annex C . 23
Annex C (normative) Coding of enhanced RadioText (eRT) . 24
C.1 General . 24
C.2 Coding eRT in ODA groups . 24
C.2.1 General . 24
C.2.2 eRT identification (Group type 3A) and coding of the text string . 24
C.2.3 Coding of the eRT text string . 25
C.2.4 UTF-8 decoding problems when used with RT+ . 26
C.3 Broadcasting conventions . 26
C.4 Receiving conventions . 26
C.5 Marking . 26
Annex D (normative) Coding of AF lists in the frequency range 64,1 MHz to
107,9 MHz: ODA-AF . 27
D.1 Objective to be achieved . 27
D.2 Description of the coding process . 27
D.2.1 ODA-AF identification (group type 3A) . 27
D.2.2 AF coding in the application group . 28
D.2.3 AF method A. 30
D.2.4 AF method B. 30
D.2.5 Convention for identification of the AF method used . 32
Annex E (normative) Station logo transmission coded in group type C . 33
E.1 Objective to be achieved . 33
E.2 Application identification code of this ODA . 33
E.3 Station logo requirements . 33
E.3.1 File type . 33
E.3.2 Logo resolution, file ID, file version and file size . 33
E.3.3 File transport . 34
E.3.4 Display mode . 34
E.3.5 Link of the logo with the PI code . 34
Annex F (normative) ODA app – Slideshow transmission coded in C-group type . 35
F.1 Objectives to be achieved . 35
F.2 Application identification code of this ODA . 35
F.3 Image requirements . 35
F.3.1 File type . 35
F.3.2 Resolution and file size . 35
F.4 Text character coding . 36
F.5 Slide structure and file elements used . 36
F.6 Slide carousel used by the broadcaster, file updating and file transmission . 38
F.7 File transport . 38
F.7.1 General . 38
F.7.2 Identification of the files . 38
F.8 Directory trigger group . 39
F.8.1 Function . 39
F.8.2 Specification . 39
F.9 Receiver display mode options . 40
Annex G (normative) Internet connection options coded in C-group type . 41
G.1 Objective to be achieved . 41
G.2 Application identification code of this ODA . 41
G.3 Choice of the ODA channel number . 41
G.4 Coding of IP address with port number . 41
G.4.1 General . 41
G.4.2 IPv4 coding . 41
G.4.3 IPv6 coding . 42
G.4.4 IP address and port number coded as URL text . 43
Annex H (normative) ODA tool – RDS data mode NFM . 44
H.1 Objective to be achieved . 44
H.2 Specification of the NFM protocol . 44
Bibliography . 46
Figure A.1 – Example 1: RT+ information of the category 'Item' (see Table A.2) will be
attached to the programme elements Item 1 and Item 2 . 15
– 4 – IEC 62106-6:2023 © IEC 2023
Figure A.2 – Example 2: RT+ information of the category 'Item' will be attached to the
programme elements Item 1 and Item 2, but not to the programme element News . 15
Figure A.3 – Example 3: RT+ information of the category 'Item' will be attached only to
the programme element Item 1, but not to the programme element Talk . 15
Figure A.4 – Bit allocation for group 3A (message bits and AID) . 16
Figure A.5 – Coding of the message bits of the application group . 17
Figure C.1 – Bit allocation for group 3A (message bits and AID) . 24
Figure C.2 – Coding of the message bits of the application group type A . 25
Figure D.1 – New ODA-AF – group type 3A . 27
Figure D.2 – New ODA-AF application group – group type A . 28
Figure F.1 – Components used in the slideshow . 36
Figure F.2 – Structure of the [PREVIEW] text file . 37
Figure F.3 – Structure of the [URLS] text file . 37
Figure F.4 – Directory trigger group . 39
Figure G.1 – Coding of IPv4 address with port number . 42
Figure G.2 – URL text coding to connect to an application data server . 43
Figure H.1 – NFM message format. 44
Table A.1 – RT+ information elements for RT . 10
Table A.2 – Code list and 'RT+ class' description of RT content types . 19
Table B.1 – RT+ information elements for eRT . 23
Table C.1 – eRT information elements . 24
Table D.1 – 9-bit AF code table for VHF Band I (64,0 MHz to 88,0 MHz) . 28
Table D.2 – 9-bit AF code table for VHF Band II (87,5 MHz to 108 MHz) . 28
Table D.3 – 9-bit special meanings code table . 29
Table D.4 – LF/MF code table – ITU regions 1 and 3 (9 kHz spacing) . 29
Table D.5 – MF code table – ITU region 2 (10 kHz spacing) . 29
Table E.1 – File ID station logo options . 33
Table F.1 – Start position of each file element within [PREVIEW] . 37
Table F.2 – Start position of each file element within [URL] . 38
Table F.3 – File numbering system used . 39
Table F.4 – Parameters used in the directory trigger group . 40
Table G.1 – Address type code . 42
Table G.2 – Link ID code of IP connection . 42
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
RADIO DATA SYSTEM (RDS) – VHF/FM SOUND BROADCASTING
IN THE FREQUENCY RANGE FROM 64,0 MHz TO 108,0 MHz –
Part 6: Compilation of technical specifications
for Open Data Applications in the public domain
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-6 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 the previous
edition:
a) Annex E: coding of station logo
b) Annex F: coding of slideshow
c) Annex G: coding of internet connection.
d) Annex H: ODA tool – RDS data stream NFM
– 6 – IEC 62106-6:2023 © IEC 2023
The text of this International Standard is based on the following documents:
Draft Report on voting
100/3807/CDV 100/3871/RVC
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
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.
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/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 document 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.
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 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.
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
NOTE 1 The Part numbers 7 and 8 will not be used.
The original specifications of the RDS system have been maintained and the extra
functionalities of RDS2 have been added.
– 8 – IEC 62106-6:2023 © IEC 2023
RADIO DATA SYSTEM (RDS) – VHF/FM SOUND BROADCASTING
IN THE FREQUENCY RANGE FROM 64,0 MHz TO 108,0 MHz –
Part 6: Compilation of technical specifications
for Open Data Applications in the public domain
1 Scope
This part of IEC 62106 contains the technical specifications for Open Data Applications in the
public domain. This document is maintained by the RDS Forum Office. The RDS Forum Office
applies an easy procedure for registering new Open Data Applications, to ensure that they can
be used without the need to change the RDS standard. The ODA feature permits defining new
applications that can be decoded on a receiver. The receiver needs to the adequate software
handler for the specific AID, which identifies the application. Receivers that have not
implemented the software handler needed for decoding are not affected by ODA data received
for any of the applications already defined and specified.
The procedure for registering a new ODA is described in IEC 62106-3.
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-1, Radio data system (RDS) – VHF/FM sound broadcasting in the frequency range
from 64,0 MHz to 108,0 MHz – Part 1: Modulation characteristics and baseband coding
IEC 62106-2: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 definition of RDS
features
IEC 62106-3, Radio data system (RDS) – VHF/FM sound broadcasting in the frequency range
from 64,0 MHz to 108,0 MHz – Part 3: Usage and registration of Open Data Applications (ODAs)
IEC 62106-4, Radio data system (RDS) – VHF/FM sound broadcasting in the frequency range
from 64,0 MHz to 108,0 MHz – Part 4: Registered code tables
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 terminology databases for use in standardization at the following
addresses:
• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.2 Abbreviated terms
For the purposes of this document, the abbreviated terms given in IEC 62106-1 and
IEC 62106‑2 apply.
3.3 Notation and conventions
The notation and conventions given in IEC 62106-1 apply.
4 ODAs in the public domain
4.1 ODAs in the group type A structure
4.1.1 Traffic Message Channel (TMC)
This ODA has been standardized in ISO 14819 (all parts).
4.1.2 Other public ODAs
There exist four other public ODAs:
• Annex A: Coding of RadioText Plus (RT+) tagging information for RadioText in group type
2A/B.
• Annex B: Coding of RadioText Plus (RT+) tagging information for enhanced RadioText
(eRT).
• Annex C: Coding of enhanced RadioText (eRT) using UTF-8 coding as standardized in
ISO/IEC 10646.
• Annex D: Coding of AF lists in the frequency range 64,1 MHz to 107,9 MHz.
4.2 ODAs in the group type C structure for the upper data-streams 1, 2 and 3
Three public ODAs exist in this category:
• Annex E: Coding of Station logo
• Annex F: Coding of Slideshow
• Annex G: Coding of Internet connection.
5 Protocol to stream RDS on bearers different from FM (NFM)
The NFM protocol is specified in Annex H. It is an ODA development tool.
– 10 – IEC 62106-6:2023 © IEC 2023
Annex A
(normative)
Coding of RadioText Plus (RT+) tagging information
for RadioText in group type 2A/B
A.1 General
RT+ is designed to let the listener (or user) take additional benefit from the RadioText (RT)
service by enabling receivers to offer direct access to specific elements of RadioText messages
(e.g. to the title of the broadcast song transmitted at the same time, to news, to telephone
numbers such as those used for voting, to web addresses for browsing web content offered by
the radio programme provider, etc.).
These RT+ messages carried in the RadioText messages are identified by their location within
the message and by the class code of their RT content type (see Table A.2). Thus, a receiver
is able to store the different RT+ messages, and the listener may then select and request a
specific content type from the storage at any instant in time that fits the user's needs. The
advantage of this method is that a user is no longer forced to watch a lot of information passing
by. The listener rather gets the opportunity to select specifically any favourite information to be
shown on a static display.
Moreover, RT+ gives the possibility to present selected RT message elements to car drivers on
a quasi−static display without any major risk of distracting the attention of the driver.
Furthermore, RT+ is well suited for mobile phones with built-in RDS FM receivers: telephone
numbers may be routed directly from the RadioText to the dialer.
RT+ is based on RT messages and is completely backwards compatible. All additional
information necessary for implementing the RT+ service is carried as an Open Data Application
in group type 3A and in an associated ODA application group (see Table A.1).
The Application Identification (AID) assigned to RT+ for RT in group type 2A/B is 0x4BD7.
Table A.1 – RT+ information elements for RT
RT+ information elements
RT message RT+ identification RT+ tags
Group type 2A/B (see IEC 62106-2) AID in group type 3A ODA application group type A
A.2 Terms used
Category: The 'RT content types' listed in Table A.2 are grouped into categories: Item
(information on programme element), Info (general information services), Programme
(information on the programme), Interactivity (related information), Descriptors (places and
addresses, date, time, etc.) and Private classes (to be defined by individual broadcasters) and
reserved codes for future amendments.
Descriptor: a category of 'RT content types' used for describing places and addresses, date
and time, specific identifiers, etc.
Length marker: part of the RT+ information element which describes the additional length of
the tagged RadioText message. Counted are characters (64 maximum), not bytes. The
addresses of the RadioText characters range from 0 to 63.
Programme item: time-slice of a programme, for example a piece of music or a documentary
report.
RT+: an extension of the RT RadioText feature, which allows storing and filtering of parts of the
RadioText messages in the receiver terminal as RT+ objects that then can be displayed,
selected and accessed by the listener, also independently from the transmitted RadioText
messages sent at the same time.
'RT content type': the content of an RT+ message is characterized by an RT+ class code,
listed in Table A.2. Sixty-four different codes exist in this table.
RT+ information elements: these are all RT+ elements for any given RT+ message, i.e. the
RT+ element defined for group 3A, the RT+ ODA application group elements and the
corresponding tagged RadioText elements (RT).
RT+ message: the basic information entity that is sent by the broadcaster to the listener. The
listener can select the RT+ messages by their content type.
RT+ content: the RT+ content consists of one or two tagged RadioText elements (RT in group
type 2A/B).
RadioText: feature of RDS for providing a programme with text messages.
RadioText message: text messages that are associated with a programme. One single RT
message is not likely to be sufficient for complete comprehension by the user.
Start marker: part of the RT+ information element which describes the start position (number
found by counting the text character positions within a text string) of the respective tagged
RadioText message element (RT).
A.3 RT+ tag
When a RadioText message like "You are listening to 'House of the rising sun' by Eric Burdon"
is sent out, the RT+ information elements 'Title' and 'Artist' are marked by two RT+ tags.
An RT+ tag consists of three elements:
a) RT content type;
b) start marker pointing to the position (inside the RT) of the first character of that RT+
message;
c) length marker indicating the additional length (in addition to the character at the start
position) of that RT+ message.
The 'RT content type' is taken from a list with 64 entries (see Table A.2).
For the example given below, the two tags are as follows:
RT content type ITEM.TITLE
Start marker 22
Length marker 22
RT content type ITEM.ARTIST
Start marker 50
Length marker 10
– 12 – IEC 62106-6:2023 © IEC 2023
Start marker and length marker can be derived from the following scheme below:
You are listening to 'House of the rising sun' by Eric Burdon
0----0----1----1----2----2----3----3----4----4----5----5----6---
0----5----0----5----0----5----0----5----0----5----0----5----0---
The addresses of the RadioText characters range from 0 to 63, so the start marker can take
the same values.
The length marker is ranging from 0 to 63 and from 0 to 31 respectively (see A.5.3).
If two RT+ messages are contained in the RadioText, they shall not overlap.
The tag information sent out should not change during the lifetime of the associated RadioText.
A.4 RT+ information elements and data model
A.4.1 General
The content of RT+ messages is carried in the RadioText (RT) messages. Their content is
described by RT content type code (see Table A.2) in each RT+ tag.
A.4.2 List of RT content types
The list of defined RT content type codes, grouped in categories, is given in Table A.2. There
are 64 RT+ classes of content type available, which a programme service provider can offer
and the listener can select from, each with a specific RT+ class. The classes can be grouped
into the following categories.
a) Item
The programme is made up of a sequence of programme items (see NOTE), corresponding
to an entry in a programme schedule. A programme item may consist again of several
programme elements. For all programme elements which can be designated by RT+ classes
of the category "Item" in Table A.2, this document uses the term "Item". In popular music
programmes, an item is a song; in a programme with classical music, it can be a complete
symphony. A speech-based programme item may also be assembled from different items
(see the NOTE below). Programme elements like News and Talk as shown in Figure A.2
and Figure A.3 are not "Items", as there do not exist any appropriate RT+ classes of the
category "Item" in Table A.2. A programme item can be described by one, several or even
all classes of this category, but for the duration of the "Item", the associated RT+ message
of each class can only have a single value, for example the RT+ message classified as
"Item". "Title" will remain fixed to "House of the rising sun" until the start of the next song.
NOTE A programme item can consist of only one element (e.g. radio drama) and can also be designated by
RT+ classes of the category "Item" in Table A.2.
b) Info
RT+ messages of this category carry textual service information that is more or less
unrelated to the audio service, but is offering important additional information to the listener,
including info about alarms, advertisements and events.
c) Programme
RT content types of this category describe the programme service.
d) Interactivity
Telephone numbers, short message text SMS used for mobile phone services addressed
with SMS numbers, e-mail addresses or web addresses (URLs) are given. The listener can
send contributions for chat conversations to a chat centre. These contributions can be
broadcast by the radio station. Questions for voting may be sent as RT+ content. The
listener can send a response back to the voting centre.
e) Private classes
While all other RT+ classes describe precisely the RT content type, also to permit their
interpretation by automatic routines within the receiver terminal or by a human user, the
Private classes can be freely defined just as required for a specific programme service
provider. The interpretation is then dependent on the programme service and does require
a template on the receiver terminal. Alternatively, a program provider may supply his
customers with special receivers, where the facilities to interpret own Private classes are
already built in. In this particular case, no template is required.
f) Descriptors
An RT+ message belonging to one of the categories above can be complemented by an
information element of the category Descriptor. Both shall always be transmitted in the same
RadioText just as the corresponding tags in the same application group. As an example: the
Descriptor GET_DATA contains the URL-address or the SMS number for retrieving more
data describing the RT+ message the Descriptor is referring to. The listener can then get
access to more information for the music item, special news, events, etc.
A.4.3 Structures of RT+ messages
For some classes, RT+ messages may be structured by the programme service provider
following a general pattern, for example results of football matches may be given as RT content
type INFO.SPORT with two parts, one indicating the match and the other the result.
"Bayern München:AC Milano 5:5"
This specification generalizes the scheme given above as follows:
The two different parts are separated by two or more consecutive space characters (see NOTE
below), that are redundant spaces. The redundant spaces serve as a delimiter between these
two parts. The first part is called the key word and will be used primarily for explanation of the
text which follows.
NOTE In the examples given in this text, a space character is represented by the symbol "".
The key word carries an explanation for the user, whereas the second part may also carry a
phone number, the SMS- or MMS-telephone number or the email address to be contacted.
This scheme permits an advanced receiver to accumulate all information (carried in the
sequence of RT+ messages of the same RT content type) and then to build one table for
presentation to the user.
This scheme may be used for the categories 'Info', 'Programme', and 'Interactivity', and shall
not be used for the categories 'Item' and 'Descriptor' for the specific RT+ classes, identified in
Table A.2 with footnote d.
For explanation, the following examples are given for different classes, first lines indicating the
structure, and then a line giving a specific example:
• INFO.STOCKMARKET
[NameLatest value in €] or more extended:
[NameLatest value in €ChangeHighLowVolume] e.g.
'Nokia12,270,4112,3112,1523 332 238'
• INFO.SPORT
[MatchResult] or more extended:
[Kind of sportMatchResult] e.g.
'FootballBayern München:AC Milano5:5'
– 14 – IEC 62106-6:2023 © IEC 2023
• INFO.WEATHER
[DescriptionTemperature] e.g.
'Raining16 degrees C' or
'Munich23 degrees C'
• Interactivity
• PHONE.OTHER
[DescriptionPhone Number] e.g.
'Deutsches Museum089323990'
If it makes sense, elements may be omitted from the right in a given structure
(e.g. INFO.STOCKMARKET: 'Nokia12,270,4112,3112,15')
Alternatively, the description of the classes PHONE.OTHER, SMS.OTHER, EMAIL.OTHER and
MMS.OTHER may be put into tag 1 and the second part, i.e. the phone number or the address,
will be put into tag 2. This then gives the text editor more freedom to introduce some additional
glue words in the RadioText message.
EXAMPLE 'The match Bayern München:AC Milano ended 5:5'
RadioText messages may contain several space characters for optimizing the layout in static
displays. However, if the RT messages are used in context with an RT+ service, redundant
spaces in parts marked by RT+, are only allowed for the purpose of delimiting two or more parts
of the RT+ content.
A.4.4 Receiver data model
The RT+ feature is designed to allow a broad range of receiver models with different display
capabilities and memory complexity to be used. The broadcaster may provide special radio
skins (templates) for presenting RT+ information on the receiver display. Each programme
provider may deposit various templates for different programme types on a web server (to be
defined). This web server can be addressed by the receiver for downloading a particular
template (see also A.5.2). This requires the receiver to be able to download actively external
data (pull information by unicast, for example to download templates using a telephone
connection).
A simple receiver will store a small selection of RT+ classes only. The storage will contain only
the current content of the 'RT+ classes'. The storage of a given class will be overwritten by a
new version of that same class. The receiver may offer a choice to the listener to enable a
selection of any particular 'RT+ class' to be presented on the display. For example, a listener
might want to see one or several 'RT+ classes' of the category 'Item'
...
IEC 62106-6 ®
Edition 2.0 2023-05
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 6: Compilation of technical specifications for Open Data Applications in the
public domain
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 Secretariat 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 Products & Services Portal - products.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 have
committee, …). It also gives information on projects, replaced 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 300 terminological entries in English
details all new publications released. Available online and once
and French, with equivalent terms in 19 additional languages.
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-6 ®
Edition 2.0 2023-05
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 6: Compilation of technical specifications for Open Data Applications in the
public domain
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 33.160.40 ISBN 978-2-8322-7088-2
– 2 – IEC 62106-6:2023 RLV © IEC 2023
CONTENTS
FOREWORD . 5
INTRODUCTION . 2
1 Scope . 8
2 Normative references . 8
3 Terms, definitions, abbreviated terms and conventions . 9
3.1 Terms and definitions . 9
3.2 Abbreviated terms . 9
3.3 Notation and conventions . 9
4 ODAs in the public domain . 9
4.1 ODAs in the 37-bit ODA application group type A structure . 9
4.1.1 Traffic Message Channel (TMC) . 9
4.1.2 Other public ODAs . 9
4.2 ODAs in the group type C structure for the upper data-streams 1, 2 and 3 . 9
5 Protocol to stream RDS on bearers different from FM (NFM) . 9
Annex A (normative) Coding of RadioText Plus (RT+) tagging information for
RadioText in group type 2A/B . 10
A.1 General . 10
A.2 Terms used . 10
A.3 RT+ tag. 11
A.4 RT+ information elements and data model . 12
A.4.1 General . 12
A.4.2 List of RT content types . 12
A.4.3 Structures of RT+ messages . 13
A.4.4 Receiver data model . 14
A.5 RT+ coding for RT . 15
A.5.1 General . 15
A.5.2 RT+ identification (group type 3A) . 16
A.5.3 Coding of the RT+ tag . 17
A.5.4 Clearing of RT+ messages. 18
A.6 Broadcasting conventions . 19
A.7 Receiving conventions . 22
A.8 Marking . 22
Annex B (normative) Coding of RadioText Plus(RT+) tagging information for
RadioText in the eRT ODA of Annex C . 23
Annex C (normative) Coding of enhanced RadioText (eRT) . 24
C.1 General . 24
C.2 Coding eRT in ODA groups . 24
C.2.1 General . 24
C.2.2 eRT identification (Group type 3A) and coding of the text string . 24
C.2.3 Coding of the eRT text string . 25
C.2.4 UTF-8 decoding problems when used with RT+ . 26
C.3 Broadcasting conventions . 26
C.4 Receiving conventions . 26
C.5 Marking . 26
Annex D (normative) Coding of AF lists in the frequency range 64,1 MHz to
107,9 MHz: ODA-AF . 27
D.1 Objective to be achieved . 27
D.2 Description of the coding process . 27
D.2.1 ODA-AF identification (group type 3A) . 27
D.2.2 AF coding in the application group . 28
D.2.3 AF method A. 30
D.2.4 AF method B. 30
D.2.5 Convention for identification of the AF method used . 32
Annex E (normative) Station logo transmission coded in group type C . 33
E.1 Objective to be achieved . 33
E.2 Application identification code of this ODA . 33
E.3 Station logo requirements . 33
E.3.1 File type . 33
E.3.2 Logo resolution, file ID, file version and file size . 33
E.3.3 File transport . 34
E.3.4 Display mode . 34
E.3.5 Link of the logo with the PI code . 34
Annex F (normative) ODA app – Slideshow transmission coded in C-group type . 35
F.1 Objectives to be achieved . 35
F.2 Application identification code of this ODA . 35
F.3 Image requirements . 35
F.3.1 File type . 35
F.3.2 Resolution and file size . 35
F.4 Text character coding . 36
F.5 Slide structure and file elements used . 36
F.6 Slide carousel used by the broadcaster, file updating and file transmission . 38
F.7 File transport . 38
F.7.1 General . 38
F.7.2 Identification of the files . 38
F.8 Directory trigger group . 39
F.8.1 Function . 39
F.8.2 Specification . 39
F.9 Receiver display mode options . 40
Annex G (normative) Internet connection options coded in C-group type . 41
G.1 Objective to be achieved . 41
G.2 Application identification code of this ODA . 41
G.3 Choice of the ODA channel number . 41
G.4 Coding of IP address with port number . 41
G.4.1 General . 41
G.4.2 IPv4 coding . 41
G.4.3 IPv6 coding . 42
G.4.4 IP address and port number coded as URL text . 43
Annex H (normative) ODA tool – RDS data mode NFM . 44
H.1 Objective to be achieved . 44
H.2 Specification of the NFM protocol . 44
Bibliography . 46
Figure A.1 – Example 1: RT+ information of the category 'Item' (see Table A.2) will be
attached to the programme elements Item 1 and Item 2 . 15
– 4 – IEC 62106-6:2023 RLV © IEC 2023
Figure A.2 – Example 2: RT+ information of the category 'Item' will be attached to the
programme elements Item 1 and Item 2, but not to the programme element News . 15
Figure A.3 – Example 3: RT+ information of the category 'Item' will be attached only to
the programme element Item 1, but not to the programme element Talk . 15
Figure A.4 – Bit allocation for group 3A (message bits and AID) . 16
Figure A.5 – Coding of the message bits of the application group . 17
Figure C.1 – Bit allocation for group 3A (message bits and AID) . 24
Figure C.2 – Coding of the message bits of the application group type A . 25
Figure D.1 – New ODA-AF – group type 3A . 27
Figure D.2 – New ODA-AF application group – group type A . 28
Figure F.1 – Components used in the slideshow . 36
Figure F.2 – Structure of the [PREVIEW] text file . 37
Figure F.3 – Structure of the [URLS] text file . 37
Figure F.4 – Directory trigger group . 39
Figure G.1 – Coding of IPv4 address with port number . 42
Figure G.2 – URL text coding to connect to an application data server . 43
Figure H.1 – NFM message format. 44
Table A.1 – RT+ information elements for RT . 10
Table A.2 – Code list and 'RT+ class' description of RT content types . 19
Table B.1 – RT+ information elements for eRT . 23
Table C.1 – eRT information elements . 24
Table D.1 – 9-bit AF code table for VHF Band I (64,0 MHz to 88,0 MHz) . 28
Table D.2 – 9-bit AF code table for VHF Band II (87,5 MHz to 108 MHz) . 28
Table D.3 – 9-bit special meanings code table . 29
Table D.4 – LF/MF code table – ITU regions 1 and 3 (9 kHz spacing) . 29
Table D.5 – MF code table – ITU region 2 (10 kHz spacing) . 29
Table E.1 – File ID station logo options . 33
Table F.1 – Start position of each file element within [PREVIEW] . 37
Table F.2 – Start position of each file element within [URL] . 38
Table F.3 – File numbering system used . 39
Table F.4 – Parameters used in the directory trigger group . 40
Table G.1 – Address type code . 42
Table G.2 – Link ID code of IP connection . 42
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
RADIO DATA SYSTEM (RDS) – VHF/FM SOUND BROADCASTING
IN THE FREQUENCY RANGE FROM 64,0 MHz TO 108,0 MHz –
Part 6: Compilation of technical specifications
for Open Data Applications in the public domain
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-6: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.
– 6 – IEC 62106-6:2023 RLV © IEC 2023
IEC 62106-6 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 the previous
edition:
a) Annex E: coding of station logo
b) Annex F: coding of slideshow
c) Annex G: coding of internet connection.
d) Annex H: ODA tool – RDS data stream NFM
The text of this International Standard is based on the following documents:
Draft Report on voting
100/3807/CDV 100/3871/RVC
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
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.
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/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 document 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.
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 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.
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
NOTE 1 The Part numbers 7 and 8 will not be used.
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.
– 8 – IEC 62106-6:2023 RLV © IEC 2023
RADIO DATA SYSTEM (RDS) – VHF/FM SOUND BROADCASTING
IN THE FREQUENCY RANGE FROM 64,0 MHz TO 108,0 MHz –
Part 6: Compilation of technical specifications
for Open Data Applications in the public domain
1 Scope
This part of IEC 62106 contains the technical specifications for Open Data Applications in the
public domain. This document is maintained by the RDS Forum Office. The RDS Forum Office
applies an easy procedure for registering new Open Data Applications, to ensure that they can
be used without the need to change the RDS standard. The ODA feature permits defining new
applications that can be decoded on a receiver. The receiver needs to the adequate software
handler for the specific AID, which identifies the application. Receivers that have not
implemented the software handler needed for decoding are not affected by ODA data received
for any of the applications already defined and specified.
The procedure for registering a new ODA is described in IEC 62106-3.
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
IEC 62106-1, Radio data system (RDS) – VHF/FM sound broadcasting in the frequency range
from 64,0 MHz to 108,0 MHz – Part 1: Modulation characteristics and baseband coding
IEC 62106-2: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 definition of RDS
features
IEC 62106-3, Radio data system (RDS) – VHF/FM sound broadcasting in the frequency range
from 64,0 MHz to 108,0 MHz – Part 3: Usage and registration of Open Data Applications (ODAs)
IEC 62106-4, Radio data system (RDS) – VHF/FM sound broadcasting in the frequency range
from 64,0 MHz to 108,0 MHz – Part 4: Registered code tables
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 terminology databases for use in standardization at the following
addresses:
• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.2 Abbreviated terms
For the purposes of this document, the abbreviated terms given in IEC 62106-1 and
IEC 62106‑2 apply.
3.3 Notation and conventions
The notation and conventions given in IEC 62106-1 apply.
4 ODAs in the public domain
4.1 ODAs in the 37-bit ODA application group type A structure
4.1.1 Traffic Message Channel (TMC)
This ODA has been standardized in ISO 14819 (all parts).
4.1.2 Other public ODAs
There exist four other public ODAs:
• Annex A: Coding of RadioText Plus (RT+) tagging information for RadioText in group type
2A/B.
• Annex B: Coding of RadioText Plus (RT+) tagging information for enhanced RadioText
(eRT).
• Annex C: Coding of enhanced RadioText (eRT) using UTF-8 coding as standardized in
ISO/IEC 10646.
• Annex D: Coding of AF lists in the frequency range 64,1 MHz to 107,9 MHz.
4.2 ODAs in the group type C structure for the upper data-streams 1, 2 and 3
Such applications are still under development.
Three public ODAs exist in this category:
• Annex E: Coding of Station logo
• Annex F: Coding of Slideshow
• Annex G: Coding of Internet connection.
5 Protocol to stream RDS on bearers different from FM (NFM)
The NFM protocol is specified in Annex H. It is an ODA development tool.
– 10 – IEC 62106-6:2023 RLV © IEC 2023
Annex A
(normative)
Coding of RadioText Plus (RT+) tagging information
for RadioText in group type 2A/B
A.1 General
RT+ is designed to let the listener (or user) take additional benefit from the RadioText (RT)
service by enabling receivers to offer direct access to specific elements of RadioText messages
(e.g. to the title of the broadcast song transmitted at the same time, to news, to telephone
numbers such as those used for voting, to web addresses for browsing web content offered by
the radio programme provider, etc.).
These RT+ messages carried in the RadioText messages are identified by their location within
the message and by the class code of their RT content type (see Table A.2). Thus, a receiver
is able to store the different RT+ messages, and the listener may then select and request a
specific content type from the storage at any instant in time that fits the user's needs. The
advantage of this method is that a user is no longer forced to watch a lot of information passing
by. The listener rather gets the opportunity to select specifically any favourite information to be
shown on a static display.
Moreover, RT+ gives the possibility to present selected RT message elements to car drivers on
a quasi−static display without any major risk of distracting the attention of the driver.
Furthermore, RT+ is well suited for mobile phones with built-in RDS FM receivers: telephone
numbers may be routed directly from the RadioText to the dialer.
RT+ is based on RT messages and is completely backwards compatible. All additional
information necessary for implementing the RT+ service is carried as an Open Data Application
in group type 3A and in an associated ODA application group (see Table A.1).
The Application Identification (AID) assigned to RT+ for RT in group type 2A/B is 0x4BD7.
Table A.1 – RT+ information elements for RT
RT+ information elements
RT message RT+ identification RT+ tags
Group type 2A/B (see IEC 62106-2) AID in group type 3A ODA application group type A
A.2 Terms used
Category: The 'RT content types' listed in Table A.2 are grouped into categories: Item
(information on programme element), Info (general information services), Programme
(information on the programme), Interactivity (related information), Descriptors (places and
addresses, date, time, etc.) and Private classes (to be defined by individual broadcasters) and
reserved codes for future amendments.
Descriptor: a category of 'RT content types' used for describing places and addresses, date
and time, specific identifiers, etc.
Length marker: part of the RT+ information element which describes the additional length of
the tagged RadioText message. Counted are characters (64 maximum), not bytes. The
addresses of the RadioText characters range from 0 to 63.
Programme item: time-slice of a programme, for example a piece of music or a documentary
report.
RT+: an extension of the RT RadioText feature, which allows storing and filtering of parts of the
RadioText messages in the receiver terminal as RT+ objects that then can be displayed,
selected and accessed by the listener, also independently from the transmitted RadioText
messages sent at the same time.
'RT content type': the content of an RT+ message is characterized by an RT+ class code,
listed in Table A.2. Sixty-four different codes exist in this table.
RT+ information elements: these are all RT+ elements for any given RT+ message, i.e. the
RT+ element defined for group 3A, the RT+ ODA application group elements and the
corresponding tagged RadioText elements (RT).
RT+ message: the basic information entity that is sent by the broadcaster to the listener. The
listener can select the RT+ messages by their content type.
RT+ content: the RT+ content consists of one or two tagged RadioText elements (RT in group
type 2A/B).
RadioText: feature of RDS for providing a programme with text messages.
RadioText message: text messages that are associated with a programme. One single RT
message is not likely to be sufficient for complete comprehension by the user.
Start marker: part of the RT+ information element which describes the start position (number
found by counting the text character positions within a text string) of the respective tagged
RadioText message element (RT).
A.3 RT+ tag
When a RadioText message like "You are listening to 'House of the rising sun' by Eric Burdon"
is sent out, the RT+ information elements 'Title' and 'Artist' are marked by two RT+ tags.
An RT+ tag consists of three elements:
a) RT content type;
b) start marker pointing to the position (inside the RT) of the first character of that RT+
message;
c) length marker indicating the additional length (in addition to the character at the start
position) of that RT+ message.
The 'RT content type' is taken from a list with 64 entries (see Table A.2).
For the example given below, the two tags are as follows:
RT content type ITEM.TITLE
Start marker 22
Length marker 22
RT content type ITEM.ARTIST
Start marker 50
Length marker 10
– 12 – IEC 62106-6:2023 RLV © IEC 2023
Start marker and length marker can be derived from the following scheme below:
You are listening to 'House of the rising sun' by Eric Burdon
0----0----1----1----2----2----3----3----4----4----5----5----6---
0----5----0----5----0----5----0----5----0----5----0----5----0---
The addresses of the RadioText characters range from 0 to 63, so the start marker can take
the same values.
The length marker is ranging from 0 to 63 and from 0 to 31 respectively (see A.5.3).
If two RT+ messages are contained in the RadioText, they shall not overlap.
The tag information sent out should not change during the lifetime of the associated RadioText.
A.4 RT+ information elements and data model
A.4.1 General
The content of RT+ messages is carried in the RadioText (RT) messages. Their content is
described by RT content type code (see Table A.2) in each RT+ tag.
A.4.2 List of RT content types
The list of defined RT content type codes, grouped in categories, is given in Table A.2. There
are 64 RT+ classes of content type available, which a programme service provider can offer
and the listener can select from, each with a specific RT+ class. The classes can be grouped
into the following categories.
a) Item
The programme is made up of a sequence of programme items (see NOTE), corresponding
to an entry in a programme schedule. A programme item may consist again of several
programme elements. For all programme elements which can be designated by RT+ classes
of the category "Item" in Table A.2, this document uses the term "Item". In popular music
programmes, an item is a song; in a programme with classical music, it may can be a
complete symphony. A speech-based programme item may also be assembled from
different items (see the NOTE below). Programme elements like News and Talk as shown
in Figure A.2 and Figure A.3 are not "Items", as there do not exist any appropriate RT+
classes of the category "Item" in Table A.2. A programme item can be described by one,
several or even all classes of this category, but for the duration of the "Item", the associated
RT+ message of each class can only have a single value, for example the RT+ message
classified as "Item". "Title" will remain fixed to "House of the rising sun" until the start of the
next song.
NOTE A programme item can consist of only one element (e.g. radio drama) and can also be designated by
RT+ classes of the category "Item" in Table A.2.
b) Info
RT+ messages of this category carry textual service information that is more or less
unrelated to the audio service, but is offering important additional information to the listener,
including info about alarms, advertisements and events.
c) Programme
RT content types of this category describe the programme service.
d) Interactivity
Telephone numbers, short message text SMS used for mobile phone services addressed
with SMS numbers, e-mail addresses or web addresses (URLs) are given. The listener may
can send contributions for chat conversations to a chat centre. These contributions may can
be broadcast by the radio station. Questions for voting may be sent as RT+ content. The
listener may can send a response back to the voting centre.
e) Private classes
While all other RT+ classes describe precisely the RT content type, also to permit their
interpretation by automatic routines within the receiver terminal or by a human user, the
Private classes can be freely defined just as required for a specific programme service
provider. The interpretation is then dependent on the programme service and does require
a template on the receiver terminal. Alternatively, a program provider may supply his
customers with special receivers, where the facilities to interpret own Private classes are
already built in. In this particular case, no template is required.
f) Descriptors
An RT+ message belonging to one of the categories above can be complemented by an
information element of the category Descriptor. Both shall always be transmitted in the same
RadioText just as the corresponding tags in the same application group. As an example: the
Descriptor GET_DATA contains the URL-address or the SMS number for retrieving more
data describing the RT+ message the Descriptor is referring to. The listener can then get
access to more information for the music item, special news, events, etc.
A.4.3 Structures of RT+ messages
For some classes, RT+ messages may be structured by the programme service provider
following a general pattern, for example results of football matches may be given as RT content
type INFO.SPORT with two parts, one indicating the match and the other the result.
"Bayern München:AC Milano 5:5"
This specification generalizes the scheme given above as follows:
The two different parts are separated by two or more consecutive space characters (see NOTE
below), that are redundant spaces. The redundant spaces serve as a delimiter between these
two parts. The first part is called the key word and will be used primarily for explanation of the
text which follows.
NOTE In the examples given in this text, a space character is represented by the symbol "".
The key word carries an explanation for the user, whereas the second part may also carry a
phone number, the SMS- or MMS-telephone number or the email address to be contacted.
This scheme permits an advanced receiver to accumulate all information (carried in the
sequence of RT+ messages of the same RT content type) and then to build one table for
presentation to the user.
This scheme may be used for the categories 'Info', 'Programme', and 'Interactivity', and shall
not be used for the categories 'Item' and 'Descriptor' for the specific RT+ classes, identified in
Table A.2 with footnote d.
For explanation, the following examples are given for different classes, first lines indicating the
structure, and then a line giving a specific example:
• INFO.STOCKMARKET
[NameLatest value in €] or more extended:
[NameLatest value in €ChangeHighLowVolume] e.g.
'Nokia12,270,4112,3112,1523 332 238'
• INFO.SPORT
[MatchResult] or more extended:
[Kind of sportMatchResult] e.g.
– 14 – IEC 62106-6:2023 RLV © IEC 2023
'FootballBayern München:AC Milano5:5'
• INFO.WEATHER
[DescriptionTemperature] e.g.
'Raining16 degrees C' or
'Munich23 degrees C'
• Interactivity
• PHONE.OTHER
[DescriptionPhone Number] e.g.
'Deutsches Museum089323990'
If it makes sense, elements may be omitted from the right in a given structure
(e.g. INFO.STOCKMARKET: 'Nokia12,270,4112,3112,15')
Alternatively, the description of the classes PHONE.OTHER, SMS.OTHER, EMAIL.OTHER and
MMS.OTHER may be put into tag 1 and the second part, i.e. the phone number or the address,
will be put into tag 2. This then gives the text editor more freedom to introduce some additional
glue words in the RadioText message.
EXAMPLE 'The match Bayern München:AC Milano ended 5:5'
RadioText messages may contain several space characters for optimizing the layout in static
displays. However, if the RT messages are used in context with an RT+ service, redundant
spaces in parts marked by RT+, are only allowed for the purpose of delimiting two or more parts
of the RT+ content.
A.4.4 Receiver data model
The RT+ feature is designed to allow a broad range of receiver models with different display
capabilities and memory complexity to be used. The broadcaster may provide special radio
skins (templates) for presenting RT+ information on the receiver display. Each programme
provider may deposit various templates for different programme types on a web server (to be
defined). This web server can be addressed by the receiver for downloading a particular
template (see also A.5.2). This requires the receiver to be able to download actively ext
...
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...