IEC 62106-6:2018

IEC 62106-6 ®
Edition 1.0 2018-09
INTERNATIONAL
STANDARD
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 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-6 ®
Edition 1.0 2018-09
INTERNATIONAL
STANDARD
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-6071-5

– 2 – IEC 62106-6:2018 © IEC 2018
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Terms, definitions, abbreviated terms and conventions . 7
3.1 Terms and definitions . 7
3.2 Abbreviated terms . 7
3.3 Notation and conventions . 8
4 ODAs in the public domain . 8
4.1 ODAs in the 37-bit ODA application group structure . 8
4.1.1 Traffic Message Channel (TMC) . 8
4.1.2 Other public ODAs . 8
4.2 ODAs in the group type C structure for the upper data-streams 1, 2 and 3 . 8
Annex A (normative) Coding of RadioText Plus (RT+) tagging information for
RadioText in group type 2A/B . 9
A.1 General . 9
A.2 Terms used . 9
A.3 RT+ tag. 10
A.4 RT+ information elements and data model . 11
A.4.1 General . 11
A.4.2 List of RT content types . 11
A.4.3 Structures of RT+ messages . 12
A.4.4 Receiver data model . 13
A.5 RT+ coding for RT . 15
A.5.1 General . 15
A.5.2 RT+ identification (group type 3A) . 15
A.5.3 Coding of the RT+ tag . 16
A.5.4 Clearing of RT+ messages. 17
A.6 Broadcasting conventions . 20
A.7 Receiving conventions . 20
A.8 Marking . 20
Annex B (normative) Coding of RadioText Plus(RT+) tagging information for
RadioText in the eRT ODA of Annex C . 21
Annex C (normative) Coding of enhanced RadioText (eRT) . 22
C.1 General . 22
C.2 Coding eRT in ODA groups . 22
C.2.1 General . 22
C.2.2 eRT identification (Group type 3A) and coding of the text string . 22
C.2.3 Coding of the eRT text string . 23
C.2.4 UTF-8 decoding problems when used with RT+ . 24
C.3 Broadcasting conventions . 25
C.4 Receiving conventions . 25
C.5 Marking . 25
Annex D (normative) Coding of AF lists in the frequency range 64,1 MHz to 107,9
MHz: ODA-AF . 26
D.1 Objective to be achieved . 26
D.2 Description of the coding process . 26

D.2.1 ODA-AF identification (group type 3A) . 26
D.2.2 AF coding in the application group . 27
D.2.3 AF method A. 29
D.2.4 AF method B. 29
D.2.5 Convention for identification of the AF method used . 30

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 . 14
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 . 14
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 . 14
Figure A.4 – Bit allocation for group 3A (message bits and AID) . 15
Figure A.5 – Coding of the message bits of the application group . 16
Figure C.1 – Bit allocation for group 3A (message bits and AID) . 23
Figure C.2 – Coding of the message bits of the application group type A . 24
Figure D.1 – New ODA-AF – group type 3A . 26
Figure D.2 – New ODA-AF application group – group type A . 27

Table A.1 – RT+ information elements for RT . 9
Table A.2 – Code list and 'RT+ class' description of RT content types (1 of 3) . 18
Table B.1 – RT+ information elements for eRT . 21
Table C.1 – eRT information elements . 22
Table D.1 – 9-bit AF code table for VHF Band I (64,0 MHz to 88,0 MHz) . 27
Table D.2 – 9-bit AF code table for VHF Band II (87,5 MHz to 108 MHz) . 27
Table D.3 – 9-bit special meanings code table . 28
Table D.4 – LF/MF code table – ITU regions 1 and 3 (9 kHz spacing) . 28
Table D.5 – MF code table – ITU region 2 (10 kHz spacing) . 28

– 4 – IEC 62106-6:2018 © IEC 2018
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.
International Standard 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.
This first edition, together with IEC 62106-1, IEC 62106-2, IEC 62106-3, IEC 62106-4 and
IEC 62106-5, 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);
• New are AF coding below 87,5 MHz (down to 64,0 MHz) using ODA-AID 0x6365;

• RT+ can now be used simultaneously for RT and eRT, each having its own RT+ ODA;
• Data-streams 1, 2 and 3 are exclusively UTF-8 coded. For backwards compatibility, UCS-2
encoded eRT on data-stream 0 is retained.
The text of this International Standard is based on the following documents:
CDV Report on voting
100/2912/CDV 100/3060/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.

– 6 – IEC 62106-6:2018 © IEC 2018
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 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.
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
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
IEC 62106-2 apply.
– 8 – IEC 62106-6:2018 © IEC 2018
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 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.

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

– 10 – IEC 62106-6:2018 © IEC 2018
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
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 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.
– 12 – IEC 62106-6:2018 © IEC 2018
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 send contributions for chat conversations to a chat centre. These contributions may
be broadcast by the radio station. Questions for voting may be sent as RT+ content. The
listener may 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), 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
[NameLatest value in €] or more extended:
[NameLatest value in €ChangeHighLowVolume] e.g.
'Nokia12,270,4112,3112,1523 332 238'
• INFO.SPORT
[MatchResult] or more extended:
[Kind of SportMatchResult] e.g.
'FootballBayern München:AC Milano5:5'
• INFO.WEATHER
[DescriptionTemperature] e.g.
'Raining16 degrees C°' or
'Munich23 degrees C°'
• Interactivity
• PHONE.OTHER
[DescriptionPhone Number] e.g.
'Deutsches Museum089323990'
If it makes sense, elements may be omitted from the right in a given structure
(e.g. INFO.STOCKMARKET: 'Nokia12,270,4112,3112,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

– 14 – IEC 62106-6:2018 © IEC 2018
a selection of any particular 'RT+ class' to be presented on the display. For example, a
listener may want to see one or several 'RT+ classes' of the category 'Item' simultaneously,
i.e. 'Title' and 'Artist' of the 'Item' received at that moment.
More complex receivers will store not only the current content of several classes, but will use
a memory to keep the information collected during the past. For reviewing the list of earlier
received 'Items', it is essential for the receiver that it can combine the different RT+
information elements (received at different times) correctly, so that elements of different
'Items' are not mixed. For that purpose, an 'Item toggle bit' changes every time a new 'Item'
starts and the 'Item running bit' indicates whether the 'Item' is still running. Both bits are sent
continuously together with every pair of the RT+ tags.
The examples in Figure A.1, Figure A.2 and Figure A.3 show the setting of the 'Item toggle bit'
and the 'Item running bit' for different audio sequences.

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

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

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
Receivers can provide more convenience by assembling an ordered cumulative list of all RT+
content of a specific class. For example, the class INFO.SPORT may be displayed as a list of
the football match results. This is easy to implement for those classes of the category 'Info'
that use redundant space characters as a delimiter between several parts of the text. The first
part, the keyword, can then be used to establish a table which is ordered according to the
keywords. Updating is also possible, if the keyword is not changed.

NOTE 1 The broadcaster can set the 'Item toggle bit' and the 'Item running bit' as required.
NOTE 2 The default setting for both the 'Item toggle bit' and the 'Item running bit' is '0'.
A.5 RT+ coding for RT
A.5.1 General
To transmit the RT+ tags, the ODA feature is used and the necessary details are defined by
A.5.2 to A.5.4.
The message bits of group type 3A in block 3 carry control data for the application AID
0x4BD7 in block 4. The tag information, to identify the RT+ messages within the RadioText, is
carried by the RT+ ODA application group, signalled in block 2 of the 3A group. Only type A
groups can be used for the application group.
A.5.2 RT+ identification (group type 3A)
The coding of the message bits in group type 3A and the Application Identification (AID) for
the ODA RT+ is shown in Figure A.4.

Figure A.4 – Bit allocation for group 3A (message bits and AID)
Application group type code:
• The group type for transmitting the RT+ application data can be chosen from IEC 62106-3.
• The group type code is signalled in block 2 of the 3A group.
The meaning of the message bits of group type 3A is as follows:
a) rfu
Reserved for future use, and not affecting any of the functions of the other bits. The rfu
bits shall be set to zero until they are defined.
b) CB flag
The CB flag gives the information, if there is a template available for the ongoing
programme. The template may already be present in the receiver (downloaded previously)
or can be downloaded at that moment, if the user wants it. The identification of the desired
template is accomplished by sending back from the receiver terminal to the web server the
PI code and the Extended Country Code (ECC), the 'Server Control Bits' and the
'Template number'.
If the CB flag is set to '0', no special radio skin (template) is available and 'Server Control
Bits' and 'Template number' bits are reserved for future use.

– 16 – IEC 62106-6:2018 © IEC 2018
If the CB flag is set to '1', a special radio skin (template) is available for the ongoing
transmission.
c) Server Control Bits (SCB)
It may occur, that the same PI code is used repeatedly within a national area (e.g. for local
programme stations far away from each other). In these cases, the Server Control Bits are
used to distinguish between programmes using the same PI code.
NOTE The Server Control Bits are allocated by the operator of the web server.
d) Template number
The Template number gives the number of a specific template, from a choice of templates
provided by the broadcaster. Up to 256 templates per programme service can be
addressed.
A.5.3 Coding of the RT+ tag
The coding of the message bits of the application group is shown in Figure A.5.
In the message bits of the RT+ application group two RT+ tags are conveyed. All 'RT+
classes' or 'RT content types' can be put into the one or the other tag of the application group.
If an RT+ message contains more than 32 characters, the associated tag information shall be
coded in tag 1. Content types of the category 'Descriptor' are always referring to the content
type in the other tag (in the same application group) and this gives additional information.
The start addresses in the tags may be chosen according to the needs during the RT
generation. Therefore, the sequence of the tags in the application group does not determine
the sequence of the information elements in the RT.

Figure A.5 – Coding of the message bits of the application group
The meaning of the message bits is as follows:
a) 'Item toggle bit'
This bit shall be toggled when a new 'Item' starts.
NOTE 1 Item means a specific programme element (see also A.4.2 and Table A.2).
b) 'Item running bit'
This bit shall be set to 1 if an 'Item' is running. Otherwise, it shall be set to 0.
NOTE 2 The 'Item toggle bit' and the 'Item running bit' will be set or reset independently from the tag
information sent out at the same time.
NOTE 3 In the receiver, these two bits can be used to group all 'RT/eRT content types' of the category 'Item'
sent for one item and store them in memory (subsequently for several items) or, when storing and presenting
information for only one item, to delete all information belonging to the elapsed item before starting to gather
information for the new one.
NOTE 4 Even though not intended by this document, these bits can be used for recording purposes.
c) 'RTcontent type'
This 6-bit value specifies the tags by assigning to them a content type according to the
'RT+ class' codes given in Table A.2. If only one RT+ information element (tag) is used,
then the content type in the second tag shall be set to 'Dummy'. If no RT+ information
element is existing, the content type in both tags shall be set to 'Dummy'
...