Bev Marks, EBU; Olivier Perrault, CNET/DSM/REN; Tristan Ferne, BBC R&D
The European Broadcasting Union (EBU), headquartered in Geneva, is the largest professional association of national broadcasters in the world. Working on behalf of its 69 active members from 50 countries in the European area, it negotiates broadcasting rights for major sports events, operates the Eurovision and Euroradio networks, organizes programme exchanges, stimulates and coordinates co-productions, and provides a full range of operational, commercial, technical, legal and strategic services. At its office in Brussels, the EBU represents the interests of public service broadcasters before the European institutions.
The EBU was founded in 1950 by the pioneers of radio and television in western Europe. It merged with the OIRT – the former union of eastern European broadcasters - in 1993. Apart from its active members in Europe, North Africa and the Middle East, the Union has 49 associate members in 30 countries further afield. At a global level, it works in close collaboration with sister unions on other continents. These include the Asia Pacific Broadcasting Union (ABU), the North American Broadcasters’ Association (NABA), the Union of National Radio & Television Organizations of Africa (URTNA), the Arab States Broadcasting Union (ASBU), and the Organizacion de la Television Iberoamericana (OTI).
Co-operation in the technical sphere is one of the EBU’s major activities. The Union is in the forefront of research and development of new broadcast media, and has led or contributed to the development of many new radio and TV systems: radio data system (RDS), digital audio broadcasting (DAB), digital television (DVB), high-definition TV (HDTV).
The EBU, having recognized that many developments in multimedia broadcasting and the Traffic and Travel Information (TTI) sphere are converging, seeks to develop a bearer independent TTI delivery technology which builds on the members national network infrastructures, but which will be more flexible. The technology envisaged is one for a near universal protocol. This is important, both from an end-user viewpoint and from a Service Provider’s need to deliver services via one or more delivery technologies as the multimedia age develops.
Transport Protocol Experts Group - explanation
As a result in 1997 the EBU established, through its normal procedures, the B/TPEG Project Group, with wide sectoral interests, including: Consumer Electronics Manufacturers, Digital Mapping companies, Service Providers, Transmission Operators and Broadcasters. Reminiscent of other technologies which seek bearer independence and universal applicability, the name: Transport Protocol Experts Group, was derived. The vision of this Project Group is:
|
The work of B/TPEG, commissioned by the EBU’s Broadcast Management Committee, is to develop a new protocol for Traffic and Travel Information, for use in the multimedia broadcasting environment. B/TPEG will develop applications, service and transport features which will enable travel-related messages to be coded, decoded, filtered and understood both by humans (visually and/or audibly) and by agent systems. |
The TPEG Specifications comprise a number of parts, defining the mechanisms that permit Service Providers to operate services which can use one or more delivery technologies (eg DAB, Internet, etc.) from one message generation process. Furthermore, they will allow a range of receiver types to be used simultaneously, ranging from sophisticated agent receivers serving navigation systems, through to simple receivers (eg perhaps a Personal Digital Assistant plug-in receiver/decoder card) only able to decode ‘top level’ information.
The TPEG Specifications are being designed to allow an existing Service Provider (eg an RDS-TMC operator), to migrate towards the multimedia age by employing TPEG Applications to achieve the delivery of several services, yet only undertake a single message generation process, and be able to offer services for significantly different End-user situations, such as the in-vehicle situation as well as a home-based internet user, planning a journey. One of the key objectives is to free the End-user from the need to have a location database, on a smart card or CD-ROM, before using a service.
TPEG is an open protocol which is designed to send unidirectional multi-lingual information over a transparent data channel.
It uses a hierarchical data frame structure which permits :
a large number of possible applications
a receiver to be synchronised anytime with syncwords
the error detection
an upwards compatibility of all receivers by providing the length of each frame’s component (thus which can be ignored if not known).
Different applications can be multiplexed and thus the receiver is able to decode only the useful information.
TPEG has been designed to be usable for a wide range of applications that require the efficient transmission of point to multi-point over potentially unreliable broadcast channels. Thanks to its independence on bearers, it is also suitable for point-to-point and multicast applications and may easily be encapsulated in IP.
The following diagram presents how TPEG can be adapted over different media.
The output of a TPEG service is a stream, that is to say a flow of bytes with their own synchronisation and verification features. To map the stream onto a bearer, an adaptation layer (packetisation…) may be required, but TPEG does not rely on bearers’ mechanisms to present, synchronise and secure its stream. Thus TPEG can transparently use any data channel. The benefits are important, since :
a single source can be used to publish on many different bearers,
a service provider can combine different bearers to build his service
e.g. basic information on a narrow-band broadcast medium, and detailed information on a point-to-point medium
the same TPEG receiver can be used to decode information coming from different bearers
ÞRTM (Road Traffic Message)
The RTM application is intended to convey traffic information to road users. The information provided relates to events on the road network and on associated infrastructure affecting a road journey. A hierarchical methodology has been developed to allow the creation of messages from a set of tables which are essentially word orientated and cover most needs. Most of these tables were obtained from the dictionary used by traffic Information Centres in Europe to communicate between each other.
ÞSNI (Service and Network Information)
As stated in the design criteria, TPEG is a unidirectional bearer-independent system. The SNI application provides information to describe the services presently on air, the tuning information for similar services outside the reception area(handover), as well as the programme schedule in the near future. It also provides some rules to establish the relation of the same service on different bearers.
Therefore with SNI, it is possible to combine different bearers to build a complex service (ex : basic information on a broadcast narrow-band medium with links to rich services accessible via a point-to-point medium).
ÞRoad locations
TPEG supports both spatial location and descriptive location. The former is based on the geographical co-ordinates of the location, and may be used by map-based systems such as in-car navigation systems. The latter if formed from the numbers or names of up to three roads at the intersection location.
On the decoder, both representations may be converted into a ‘standardised’ machine-readable format for direct presentation of the location name to the user and for machine internal use.
ÞComing soon PTI (Public Transport Information), STI (Status and Travel Time Information)
In a similar way as RTM, PTI will provide information on public transport network making TPEG the first multi-modal protocol for transport information.
STI will provide a permanent eye on always changing phenomena such as road status, travel times, car park occupancy, waiting time for a bus…
TPEG and WAP standards have addressed independently some common needs such as :
open standard : the wap stack could be used for applications and service outside wap
bearer independence : the WAP is designed to work optimally with many air interfaces
device independence : WAP has been designed to accommodate any functionality above a minimum that any WAP-device must have.
The relationship between WAP and TPEG can provide important gains to both protocols. For instance, a XML application for TPEG applications (RTM in the first place) could be useful in many ways, particularly for generating and exchanging content for both completely computerised systems and systems with human input. For example, an XML representation could be used for passing RTM content between a TPEG content generator and a TPEG service provider or it could be used in receivers for storing RTM messages. Many tools already exist for generating and browsing XML content and WAP devices are likely to already contain basic code for XML parsing.
TPEG and WAP being very open, the consequence is that they can inter-operate in many ways. Some possible scenarios are presented in the following sections.
TPEG in WAP
The WAP layered architecture (see Figure below) enables other services and applications to utilise the features of the WAP stack through a set of well defined interface. By using these interfaces, TPEG could use the WAP stack to address a larger number of end-users accessible via different point-to-point air standards.
The WAP stack
Different possibilities :
In the Wireless Application Environment (WAE): TPEG messages can be integrated as a new WAE supported data format (such as vCard…),
Using different elements of the stack : TPEG could be conveyed over different bearers using the WAP abstraction and functionality (security, transaction..)
WAP applications could be integrated in TPEG as standard applications (WML, and WMLscript)
The WAP stack could support a new bearer : TPEG
This position paper intends to give some clues on how WAP Forum could embrace TPEG and vice-versa. It may be necessary to recognise further the design constraints and goals of each protocol before being able to define an overall architecture or adaptation guidelines.