The RDS specification EN 50067: Specification of the radio data system (RDS), April 1992 (and the earlier version) has successfully permitted many RDS systems around the world to be implemented but it was developed with the idea that long term flexibility for new RDS applications must be expected. Indeed in the intervening period several new applications have been proposed, undergone trials and brought into service. As a result the RDS Forum embarked in 1995 on the process of reviewing these developments with a view to issuing through CENELEC a new specification in 1996 or 1997. Among the new applications are the Traffic Message Channel (TMC) feature, Differential GPS correction data services (DGPS) and the Enhanced Paging Protocol (EPP); all were being designed to use an individual RDS Group and it soon became clear that the rare resource of RDS Groups would be fully used and then there would be no more long term flexibility.
Consequently RDS Forum Working Group 2 was established to examine the situation and develop solutions. This Group was quickly amalgamated with another, RDS Forum Working Group 3 which had the brief to examine DAB cross references, since both could find common solutions. The key outcome of this work has been the development of the so called Open Data Applications (ODA) which will be included in the next update of the RDS standard (future EN 50067:1996).
At this stage there are still some detailed aspects to be clarified and the last RDS Forum meeting, held in Turin, confirmed that WG2 should continue their work as soon as possible. Specifically this involves the use of a Type A Group for ODA identification and NOT a Type B group as originally proposed by the WG2. Some extracts from WG2/3 Paper 16, modified to include the latest proposals, describing ODA and the necessary registration process follow.
Open Data Applications (ODA) are not explicitly specified in the RDS standard (future EN 50067:1996). They are subject to a registration process and registered applications are listed in the EBU/RDS Forum ODA Directory (to be established), which references appropriate standards and normative specifications. These specifications may however be public (specification in the public domain) or private (specification not in the public domain). The terms public and private do not imply the degree of access to services provided by an application, for example a public service may include encryption.
An ODA may use type A and/or type B groups, however it must not be designed to operate with a specific group type The specific group type used by the ODA in any particular transmission is signalled in the Applications Identification (AID) carried in type 3A groups.
The following type A and type B groups may be allocated to Open Data Applications:
| Group Type | Availability for Open Data Applications |
| 5A | Available when not used for TDC |
| 5B | Available when not used for TDC |
| 6A | Available when not used for IH |
| 6B | Available when not identified as IH by type 1A group (Variant 6) |
| 7A | Available when not identified as RP by type 1A group (Variant 2) |
| 7B | Available unconditionally |
| 8A | Available when not identified as TMC by type 1A group (Variant 1) |
| 8B | Available when not identified as TMC by type 1A group (Variant 1) |
| 9A | Available when not identified as EWS by type 1A group (Variant 7) |
| 9B | Available when not identified as EWS by type 1A group (Variant 7) |
| 10A | Available unconditionally |
| 10B | Available unconditionally |
| 11A | Available unconditionally |
| 11B | Available unconditionally |
| 12A | Available unconditionally |
| 12B | Available unconditionally |
| 13A | Available when not identified as RP (EPP) by type 1A groups (Variant 2) |
| 13B | Available unconditionally |
The type 3A group conveys to a receiver information about which Open Data Applications are carried on a particular transmission and in which groups they will be found. The type 3A group comprises two elements: the Applications Identification (AID) code and the Application Group Type code used by that application. Applications which actively utilise both type A and B groups are signalled using two type 3A groups.
The Application Group Type code indicates the group type used, in the particular transmission, to carry the specified ODA. The AID determines which "software handler" a receiver needs to use.
This supplements information carried in the type 1A group and permits groups specified in the RDS standard (future EN 50067:1996) for EWS, IH, RP and TMC to be re-allocated when these features are not used. This method of allocating and defining Open Data Applications in an RDS transmission allows the addition and subtraction of ODAs, without constraint or the need to await new standards being published.
The type 3A group structure is as follows:
For each group type addressed by the Application Group Type Codes of a particular transmission, only one application may be identified as the current user of the channel (C/F = 0). Other applications may be identified for future use(C/F = 1).
The AID code Hex 0000 may be used to indicate that the respective group type is being used for the normal feature specified in this standard. Application Identification codes Hex 0001 to 7FFF indicate applications as specified in the ODA Directory (to be established).
The ODA Directory (to be established) specification associated with a particular AID code defines the use of type A and type B groups as follows: -type A groups used alone (mode 1a) -type B groups used alone (mode 1b) -type A groups and type B groups used as alternatives (mode 2) -type A groups and type B groups used together (mode 3)
It is important to note that the ODA Directory (to be established) specification must not specify the actual type A and type B groups to be used, since these are assigned in each transmission by the type 3A group.
The AID feature indicates that a particular ODA is being carried in a transmission. Each application will have unique requirements for transmission of its respective AID, in terms of repetition rate and timing. These requirements must be detailed in the respective ODA specification. The specification must also detail the AID signalling requirements for such times when an application assumes or loses the use of a group type channel. Some applications may not allow reconfiguration in this way.
| L.1 | Every data application using the Open Data Applications (ODA) feature (see prEN
50067:1997, 3.1.4) must be transmitted together with an Application Identification (AID)
number (see prEN 50067:1997, 3.1.5.4). The AID number, for each ODA, is allocated by the
RDS Registrations Office at the address shown in the following Registration Form. Forms
must be completed fully (every question must be answered - the RDS Registrations Office
will advise, if difficulty is experienced) and sent to the RDS Registrations Office,
together with the nominal fee of CHF 500, which is payable in advance. Subject to
satisfactory completion, an AID number will be allocated and a copy of the Form will be
returned to the applicant. |
| Transmissions carrying an AID must adhere fully to the details, specifications
and references of the relevant registration. (Any subsequent updates, that do not change
the fundamental requirements for the transmission of that ODA, may allow continued use of
the same AID, but advice should be sought from the RDS Registrations Office.) |
|
| Details will be kept in the EBU/RDS Forum ODA Directory, which will be published, from
time to time, and an up-to-date version of the Directory will be maintained on the RDS
Forum Web site at URL: http://www.rds.org.uk/. |
|
| Users of an AID must satisfy themselves as to the validity of using it and the accuracy of all related information and must accept all due consequence. The RDS Registrations Office is not liable for any incidental, special or consequential damages arising out of the use or inability to use an AID, whether in transmission or reception equipment. |
RDS Open Data Applications - Registration Form This Form will be published in full, except last two answers, if specifically not permitted |
| To: | RDS Registrations Office European Broadcasting Union / Union Européenne de Radio-Télévision Ancienne Route 17A Case postale 67 CH-1218 Grand Saconnex GE SWITZERLAND - SUISSE |
Application Date: |
| Question | Information | Comment |
| Applicants Name: | Title/Name of contact | |
| Organisation: | Company Name | |
| Organisation Address: | Street 1 | |
| Street 2 | ||
| Town/City | ||
| Area/County | ||
| Postal Code | ||
| Country | ||
| Application Name: | 5 or 6 words, maximum | |
| Application Description: | Please use additional pages if desired. |
Give as much detail as possible. |
| Open Data mode: (see prEN 50067:1997, 3.1.5.4) |
Choose one mode, only | |
| ODA details, specifications and references: | Tick, if publication not permitted [ ] Please attach additional pages. |
Give all details, proprietary documents and references. |
| Capacity requirement for both the ODA and AID groups: | Tick, if publication not permitted [ ] a) .............. ODA groups/second b) .............. type 3A groups/minute Please use additional pages if desired. |
Indicate: ODA groups/second and type 3A groups/minute. Describe any constraints. |
| L.2 | Data application designers need to consider a number of questions regarding their application and the RDS system interface, so that the RDS bearer is kept in conformity with best implementation practice. The following questions should be carefully considered (the RDS Registrations Office will advise, if difficulty is experienced) and the following Check List must be completed and attached to all applications. |
RDS Open Data Applications - Check List This Check List will not be published. |
| Question | Considered | Notes |
| Does the application behave correctly when not all RDS groups are received? | Tick, if considered [ ] | Necessary for mobile RDS applications |
| Does the application provide the means to identify the Service Provider? | Tick, if considered [ ] | |
| Does the application allow for future proofing, by upgrading? | Tick, if considered [ ] | |
| Does the application require sub-sets of associated applications? | Tick, if considered [ ] | Use of variant codes and/or other groups (eg clock-time) |
| Does the application include provision to reference other transmissions carrying the same service? | Tick, if considered [ ] | PI and AF |
| Does the application include an additional layer of error protection? | Tick, if considered [ ] | RDS already has considerable capability |
| Does the application include encryption? | Tick, if considered [ ] | |
| Does the application include data compression? | Tick, if considered [ ] | |
| Have you defined the capacity requirements for the application? | Tick, if considered [ ] | |
| Have you defined the capacity requirements for the AID under normal conditions? | Tick, if considered [ ] | |
| Is your application able to assume and lose the use of a group type? | Tick, if considered [ ] | |
| If so, have you defined the AID signaling when use of a channel is assumed? | Tick, if considered [ ] | |
| If so, have you defined the AID signaling when use of the channel ceases? | Tick, if considered [ ] |
When the application is considered satisfactory, an Application Identification code (Hex) will be allocated, the applicant will be notified and the registration will appear in the EBU/RDS Forum ODA Directory (to be established), which will also be published on the World Wide Web.
For registrations outside the USA, Canada or Mexico contact the EBU/RDS Registrations Office, by using the forms given above or using the registration information contained in a downloadable PDF document.
 |
Click here to download this document as an Acrobat PDF file (i.e. odareg.pdf 8,967 bytes) or click here for help on Adobe Acrobat. | |
Issue Date 15 November 2004
Copyright © 1997, 1998 EBU and RDS Forum. All rights reserved.