http://joshuafan.blogbus.com/logs/8256103.html
RDS-TMC简介 （参见文档 RDS-TMC通讯方案.doc）
RDS是于1984年由欧洲广播联盟（EBU）制定的数据广播系统的欧洲规范，1986年国际无线电咨询委员会（CCIR）通过了有关RDS的643号建议书，1990年正式通过和出版“实施RDS的准则”EN50067。自此欧洲各国纷纷开设RDS的广播业务。
与中波相比，RDS城市交通信息广播的主要特点是利用现有的调频广播资源，通过广播信号里插入数字码实现，只需少量的投资即可建成广播发射端。它与音频信号是分开的，丝毫不会干扰收音，也不会影响收音机音质。当收音机检测和解调这些数字码后，便能提供相应的功能。
RDS接收机的调频波段在87.5～108.0 MHz范围，相邻电台波段间隔至少100 kHz，在57 kHz上加载副载波数据。数据内容可以包括电台类型、节目类型、交通公告、广告信息、标准时间、天气预报等，同时提供了开放式数据接口，为特殊要求用户提供数据文本应用通道。
TMC（Traffic Message Channel，交通信息频道）是一个数字编码系统。TMC能产生连续的交通信息流，如交通拥塞或事故，可报告出事地点与时间结果。信息包括了一定地域范围内的交通状况。将TMC信息与地图导航结合到一起，提高了车辆导航对前方路况预测的准确性。同时，在很多地区，建立DGPS数据的FM 负载波广播服务，提供广播电台周围的GPS差分校正数据，大大提高了GPS的位置定位精度。
RDS-TMC是采用RDS技术实现信息发布的应用之一。交通信息在广播前按照标准编码，采用RDS技术发布。车载终端设备可接收该码型信息，并可选择信息的实现方式，如文本、简单图形和语言等。接收RDS-TMC需要一个特别的无线电接收机，其最主要部分就是TMC卡，该卡包含了具体的路线信息等。假如要从甲地到乙地，在离开甲地前，先购买或租用甲地到乙地路线的TMC卡，这样就会收到路线中最新的交通信息。在进入其他国家时，接收机就会自动转到提供TMC信息流的另一个无线电台。
经过20年左右的发展，目前RDS-TMC技术已经成熟，相关产品在全球已经形成了年销售上百亿欧元的产业规模。在我国，该技术起步较晚，目前只有个别地区和单位建立了一些特殊用途的RDS电台，但是作为一种成本低廉、技术成熟、覆盖范围广的无线广播数据系统，其中孕育的市场商机是不可估量的。
RDS-TMC是目前欧洲唯一的大规模交通信息解决方案
| DAB-TMC(TPEG)简介 |
|
◆DAB-TMC(TPEG)产生的背景
DAB（Digital Audio Broadcast）即数字广播，目前无线电广播已进入数字化时代，即FM的模拟服务转变成了一系列字节，因而，即使在山区或高楼中，信号也能被接收到，这些字节即使在有干扰情况下也能被识别，它能被分解成1536种不同的频率，如同穿越一个个时间间隔，在短时间失去信号的情况下，接收机仍能恢复原有信号，这个子系统叫做COFDM（Coded Orthogonal Frequency Division Multiplex），号码正交频率分配多路传输。COFDM允许在全国各个无线电站点使用一个频率，这就避免了正在行驶的车辆接收机进行反馈的必要性。
◆TPEG协议
TPEG是欧洲广播联盟EBU所制定的协议，可透过各种数字媒介，如：互联网络、数字广播、数字电视等，发布交通与旅游信息。同时TPEG是欧洲广播联盟致力于发展“交通与旅游信息”传输协议的研究群体。这个研究群体于1997年成立，总计超过60家来自消费电子产品、电子地图、服务提供、广播等领域的欧洲公司与组织参与制定TPEG协议，不论是道路交通、公共交通、天气状况等信息，都在TPEG制定标准的范畴之内，以提供完整的交通与旅游信息。TPEG的信息具有语言无关（language independent）、传输载质无关（bearer independent）、多模应用（multimodal application）等特性。
TPEG协议共分为三层（同步层、封包层、应用层），对应至OSI七层模型的第三至第七层。TPEG第一层为同步层，对应至OSI的网络层，处理网络同步的问题。第二层为封包层，对应至OSI的第四至第六层，负责将TPEG应用层的数据串连成TPEG stream，TPEG stream可被加密或压缩。第三层为应用层，对应至OSI的应用层。
TPEG应用层标准目前已制定的有：服务与网络信息（TPEG-Service and Network Information；TPEG-SNI），道路交通信息（TPEG-Road Traffic Message；TPEG-RTM）以及公共交通信息（TPEG-Public Transport Information，TPEG－PTI）；TPEG-PTI，TPEG-SNI提供有关服务提供者的各项信息，以及服务内容的信息。TPEG-RTM提供有关道路交通的讯息，如：交通事件、交通阻塞等；TPEG-PTI则提供公共交通工具的相关信息，如：班次信息，班次延误信息等。TPEG-RTM与TPEG-PTI共享用来描述地理信息的TPEG-LOC 协议。另外还有一些正在制定的应用层协议，如：气象资讯（TPEG-Weather；TPEG-WEA）、停车信息（TPEG-Parking Information；TPEG-PKI）等。
交通及旅游信息并非一成不变，它们会因为国家、地点、时间、人物、车辆、环境等因素而有所不同，TPEG所制定的这些标准不一定会完全符合每个道路使用者的需求，因此TPEG标准是可修改的，今后会再加上一些尚在制定中的TPEG应用层标准。因此，若TPEG编解码器设计不恰当，会导致编译码器不适用新的标准而需要重新设计。
◆RDS-TMC与TPEG之间的差别
无线电广播的发展趋势是从模拟向数字转变，DAB将在今后的市场中得以应用，同时，RDS-TMC， DAB－TMC接收机也像普通收音机一样普及。TPEG具有发送大容量信息的特点。RDS的发送速率是1.1875kbps，而TPEG可以在Internet上运行，有可能达到8000bps，且能发送巨大的信息量，未来发展前景光明。RDS编码信息将随着TPEG的发展而被取代，这是因为TPEG更简洁，无须配备一个复杂的数据库。
|
| DAB-TMC服务构成与信息编码 |
|
TMC技术能够为用户提供动态信息，而DAB-TMC和RDS-TMC比较起来，其传输速度更快，传输效率相对也较高，因此，基于DAB-TMC的发送周期较短的特点，使得大范围内统一的交通报告成为可能。与RDS-TMC比较起来，DAB-TMC具有以下几个方面的优点：
现有文件中定义的DAB-TMC可以通过DAB中的快速信息频道（FIC）来传输TMC信息。依据ISO14819-4中协议进行编码的系统信息和用户信息在DAB-TMC中，负载在FIG5/1中。
在DAB中，每项服务可以包括几个服务Component，最主要的即主要服务Component ，一般大多为音频方式，但数据服务同样可以作为主要Component；其他的被称之为次要Component内容，一般是可以选择的。下图1是一个关于服务结构的示例，标为ALPHA1广播的服务包括两个部分：主要音频广播部分和次要数字广播部分，而数字部分则被用来传输DAB-TMC信息。音频信息通过主要信息频道（MIC）里的子频道携带，而TMC信息则由快速信息频道(FIC)中的快速信息数据频道（FIDC）负载。
一个服务Component可以被不同的服务共享，而服务通过改变结构，也可以更改自己的服务Component。如图中所示，ALPHA1和ALPHA2共同拥有ALPHA-TMC Component，而ALPHA2可以选择不同的音频部分作为其Component。
交通信息在FIG5/1中编码，图2显示了其中TMC信息区域的结构。FIG的类型成分检验区域用来识别能共存于一个多元体中的8种不同类型的信息。下面是D1和D2的定义：
D1 这个1比特的标识用来指示FIG中是否包含着37位或者16位的TMC信息：
0――――37位TMC信息
1――――16位TMC信息
D2 总是被标定为0
37位TMC信息必须包括以下的一种：
TMC用户信息：ISO14819－1 (4)中定义的包含位置和事件编码等参数。
TMC调谐信息：由ISO14819－1 (4)中定义，当信号变弱时，TMC产品需要调换接收器。
加密管理组：由ISO14819－1 (6)中定义，包含一些诸如SID(Service Identifier)、ENCID(Encryption Identifier)、LTNBE(Location Table Number before Encryption)等的加密参数。
16位TMC信息：必须包括ISO14819－1(4)中定义的系统信息。
|
IMPLEMENTING TPEG AND MULTIMEDIA SERVICES FOR DIGITAL
参见文档IMPLEMENTING TPEG AND MULTIMEDIA SERVICES FOR DIGITAL.pdf
INTRODUCTION
For the past few years much work has been done in both the Digital Television and Digital Radio arenas to develop new types of service that will fully exploit the benefits of digital transmission. As part of its drive towards new services, the BBC has been at the forefront of this work and this is reflected in the launch of several new types of service on both Digital Radio and Digital Television.
In the UK, Digital Terrestrial Television (DTT) now offers the capability to deliver MHEG 5 based services, notably BBC Digital Text launched earlier this year. Complementing this, the BBC has also launched two pilot data services on its Digital Radio platform: a ‘TPEG’ service for providing Traffic and Travel Information (TTI) and an HTML based service analogous to BBC Digital Text.
BBC Travel, the BBC’s ‘TPEG’ service is the result of the work of the Transport Protocol Experts Group (TPEG) of the European Broadcasting Union (EBU), and is now entering a validation phase in preparation for full services. At the same time, Eureka and WorldDAB have provided the transport protocols to allow TPEG data to be carried using the Digital Audio Broadcasting (DAB) Digital Radio standard, as well as developing the Broadcast Web Site (BWS) application to the point where Radio can genuinely compete in a multimedia environment.
Tracking the work of technical specification and standardisation (in which the BBC has been deeply involved), the BBC has developed the equipment and infrastructure required to effectively implement, manage and test these and future services.
TPEG
The TPEG protocol was conceived by the EBU with a number of key goals in mind. The first, and most obvious, of these was to develop a protocol for delivering TTI and other information for the support of Intelligent Transportation Systems (ITS) in a rich and flexible manner. In addition to this, however, was the desire to create an open specification, free of Intellectual Property Rights (IPR) issues and license fee considerations, for a broadcast system that could easily be adapted to a wide range of potential digital bearers.
As with any initiative aimed at developing new broadcasting standards, it was very important for the work of the TPEG project to have support from all appropriate industry sectors. Fortunately, TPEG has easily achieved this with involvement from information providers, broadcasters, map makers and, importantly, receiver manufacturers.
Digital Radio and TPEG
From its inception, the DAB Digital Radio standard was developed with mobile reception in mind. The combination of parameters for the Coded Orthogonal Frequency Division Multiplex (COFDM) modulation scheme ensure that a robust digital signal can be delivered to mobile receivers in a Single Frequency Network (SFN), which has been
reflected in the network planning for the BBC’s national Digital Radio multiplex. This suitability for mobile reception makes Digital Radio an ideal partner for a TTI service using TPEG since the question that needs to be answered is:
“How do I get from where I am to where I want to be - given the state of the road network at this precise moment?”
Part of this question can be answered by navigation systems and another part can be answered with positioning systems such as the Global Positioning System (GPS). The picture can only be completed, however, with an accurate and timely TTI service that can be delivered to where it is needed - i.e. to a vehicle.
Relating TPEG to other TTI protocols for Radio
An examination of the emerging market for navigation products that incorporate some form of TTI reveals a number of candidate protocols that could be used without ‘re-inventing the wheel’. In the UK and elsewhere, several commercial closed user group systems have been set up using GSM channels, but these are generally client-server systems where a user terminal requests information. In such cases, the protocols rely on bi-directional communication and are not suitable for use in broadcast environments. A more promising avenue is the Traffic Messaging Channel (TMC) application for the Radio Data System (RDS), which is part of many analogue FM radio broadcasts. Unfortunately, there are some obstacles that make it undesirable for some broadcasters to use a TMC based protocol for TTI in Digital Radio. TMC was developed to use a very narrow channel offered by FM/RDS where events are coded into 37 bit messages and one message can be sent per second. With such restrictions, the coding of TMC messages has had to be made extremely efficient but this has necessarily led to several restrictions. One of the principle restrictions imposed on TMC is the need to use a location coding table in the receiver to allow a 16 bit location code to be converted into its geographical representation. This leads on to the other problem with using TMC, as the location coding scheme involves the use of proprietary technology for which licenses must be paid. It is difficult for public service broadcasters like the BBC to support proprietary technology in this way, and the license fee payable by receiver manufacturers has led to a very slow development of the receiver market.
DAB Digital Radio has the potential to deliver bit rates that are orders of magnitude greater than those available with FM/RDS and so it was recognised that there was a need for a richer, more flexible system for higher bit rate broadcast digital bearers such as Digital Radio. At the same time, a great deal of investment has been made in the development of RDS/TMC services and decoders. The TPEG project has sought to be as compatible with TMC as is possible, while at the same time making best use of the available bit-rate.
The basics of TPEG
While TPEG is generally aimed at delivering information to support ITS applications, there are a number of different classes of information that are being considered. This, combined with the desire to have a single TPEG stream be able to carry a variety of different types of information, potentially from a variety of service providers led to the concept of a TPEG multiplex. The need to be readily portable between different broadcast digital bearers suggested the use of a simple asynchronous stream format, and so a framing protocol layer for transporting TPEG data was developed, within which a multiplex of different TPEG services can be delivered.
Recognising the importance of supporting subscription services as well as free to air services, the framing protocol layer provides support for conditional access layers. Clearly, future navigation systems will be able to take information from a variety of sources, and it is important that TPEG is able to ensure that both public service broadcasters and commercial service providers can compete in the normal way. Such an open market for TTI guarantees that the overall winner will always be the end user.
The Road Traffic Message application
While it is intended that TPEG should ultimately support delivery of a wide range of types of information, the initial focus of the TPEG project was the ability to describe the state of a road network. As a result of this, the first TPEG application that was developed was the Road Traffic Message (RTM) application. Within the RTM application, a carousel of messages is broadcast where each message describes an event on the road network. For example, a message might describe an accident, road works or even escaped animals! Each message can be tagged with an expiry time and a version number which can be used to ensure that receivers always maintain an up to date record of all messages.
A hierarchical approach to event coding
A great deal of TPEG’s flexibility derives from the use of a hierarchical event coding scheme that allows a variable level of detail to be used with the RTM application. This is extremely useful for three reasons: First, it allows receivers to easily filter out the information that is appropriate to the receiver implementation. Second it allows service providers to trade off detail level against number of messages or bit rate, which allows the RTM application to scale well according to the size of the channel. Third, it makes content generation simpler as more levels of detail can be supplied as more information becomes available. For example, when an accident occurs, the first reports received by a TTI provider will probably enable them to say that an accident has occurred at a particular location. Quarter of an hour later, the TTI provider may know more about the incident and so can add further detail to the RTM event description that indicates that the accident involved a two vehicles. Later still the TTI provider may know enough about the incident to say that the accident involved a bus, an articulated lorry and a deer and that the lorry is now blocking all 6 lanes and there is a 10 mile tailback.
While the hierarchical coding structure is not something that is common to RDS/TMC, the basic ‘data dictionary’ for describing events is the same. This means that there should be a high degree of compatibility between origination systems for TMC services and origination systems for TPEG. For example, although the actual coding of information about vehicles is different, the concept of a ‘heavy goods vehicle and trailer’ is common to both and has the same semantic definition in both.
A universal coding scheme for location coding Another important feature of the TPEG RTM application is the use of a location coding scheme that is independent of any proprietary mapping system. The TPEG RTM application uses the concept of Intersection Location (ILoc) codes to represent locations which consist of a longitude and latitude, together with up to three 5 character strings giving the first 5 characters of the names of the roads that define the intersection. Using longitude and latitude allows the coordinates of the location to be easily transformed to any desired coordinate system. The three road names make it easy for navigation systems to precisely locate the incident when there are minor discrepancies in the map database, due to the resolution or quality of the map data.
Validating TPEG with the ‘BBC Travel’ service
For the BBC, TPEG is ideal. The BBC Travel unit currently deals with up to 1200 events in the UK road network, with many information sources ranging from police control rooms to the general public. The output from the travel unit takes a number of forms - Internet, Teletext and, naturally, scripts for radio and television travel bulletins. Radio is the only way to deliver this to a vehcle but radio travel bulletins are necessarily limited to a tiny fraction of the total information available. Out of the 1200 or so events that are known about, only 4 or 5 will be mentioned in each bulletin. By delivering all of the BBC content directly to mobile receivers in a form that can be interpreted electronically, TPEG allows the BBC to provide a valuable public service based on content that we already own.
With such compelling arguments in favour of using TPEG with Digital Radio, the BBC decided to launch a pilot TPEG service with three basic aims in mind:
. To gain experience with using TPEG
. To promote and validate the TPEG standard
. To allow receiver manufacturers access to a stream of TPEG data for development purposes
The pilot TPEG service has been running since early February and uses live content generated by the BBC Travel Unit to create a TPEG stream that is both broadcast using Digital Radio and accessible over the Internet. The provision of the Internet service illustrates the bearer independence of TPEG and also allows receiver manufacturers to develop TPEG decoders against
the service, even if they cannot receive the BBC’s Digital Radio signal.
Simply providing a stream of TPEG data is useful for developers but does not demonstrate the capabilities of the protocol. In order to overcome this, the BBC has also developed an example TPEG receiver that has been written in Java. The receiver shows a variety of ways in which the TPEG service can be used, including showing the events on a map. Writing the receiver in Java means that it can be delivered as part of a normal web site for decoding the Internet version of the service, as well as being used to decode the Digital Radio service.
How the pilot TPEG service works
The TPEG service starts with BBC Travel Unit on the seventh floor of London’s Television Centre where events in the UK road network are collated into a single database. This database is capable of
supporting all of the Travel Unit’s outputs and, in particular, can generate a file representation of the complete database as TPEG RTM messages. This RTM file is transferred to the Digital Radio system at Broadcasting House across the BBC Intranet using FTP. Whenever a new RTM file is transferred, the TPEG software for the Digital Radio system reads the new content and spools it into a ‘TPEG multiplexer’. The output of the TPEG multiplexer is a complete TPEG stream that is fed to both the Digital Radio equipment and the Internet. The general arrangement is shown in Figure 1.
Figure 1 Architecture for the BBC TPEG pilot 略
Plans for the future
The TPEG project is continuing to develop new applications for the TPEG protocol and will soon have completed the specification a ‘Service and Network’ application in addition to the RTM application. The Service and Network application will allow the TPEG stream itself to be completely described, including information to allow service following between different TPEG bearers. Once this work has been completed, work is already in preparation to define and application for describing public transport networks to complement the RTM application.
All of this future work will continue to maintain the central ideas of an open, license free specification together with rich and flexible structures for describing problems with the various transport networks.
The TPEG library
All of the software for the BBC TPEG pilot service has been developed using a library of code for manipulating TPEG data structures. The language chosen for writing this library was C++ as TPEG lends itself naturally to object-oriented programming techniques, and the library was structured to allow the development of three types of application: TPEG application sources (such as the RTM spooler in Figure 1), TPEG multiplexers and TPEG decoders.
Having developed the TPEG software library, the BBC has made this software freely available to the TPEG community under a ‘copyleft’ style license, as advocated by the Free Software Foundation. This was done in order to stimulate the development of both TPEG receivers and TPEG services. More information about both the TPEG software library and the BBC TPEG pilot service can be obtained from the BBC’s TPEG web site at http://www.bbc.co.uk/rd/projects/tpeg
THE BROADCAST WEB SITE AND BEYOND
About a year ago the concept of a ‘Broadcast Web Site’ (BWS) was introduced, where a data carousel protocol is used to deliver a set of files for web site. Receivers of various types can then recreate and browse the service to give the same experience as if connected to the Internet - only without the wait or the connection charges. Since then, Eureka and WorldDAB have proceeded to rapidly develop concrete specifications for this application, with the result that we now have a genuinely interoperable standard for multimedia services in Digital Radio.
Specification issues
While the current DAB Digital Radio standard is a mature and established mechanism for robustly delivering high quality audio, it does not provide complete support for other forms of service. This has required the development of additional features for Digital Radio that have been successfully introduced without affecting the established DAB Digital Radio standard in any way.
Application signalling
The first important feature that has been introduced is the concept of application signalling. Within the DAB Digital Radio specification, MPEG-2 audio is carried in specially constructed audio channels whose ‘protection profile’ is tailored to the audio frames but non audio services such as TPEG and BWS services are carried in channels with even protection applied to the data. Receivers are easily able to identify this difference in the way the digital information is delivered, and so distinguishing between an audio service and a non-audio service is straightforward. With the recent advances in the development of non-audio services, however, the need has been recognised for receivers to be able to differentiate between various types of non-audio service. The problem can be expressed simply as: ‘The receiver needs to know where to find the data for a service and what to do with it -i.e. which software to use to decode it’.
The Service Information (SI) structures for DAB Digital Radio are carried in the Fast Information Channel (FIC) using Fast Information Group (FIG) structures. Thus, application signalling has now been defined in the form of a new FIG (FIG0/13). This FIG allows an association to be made between the location of a data service, an application identifier to identify the software needed to decode the service, and a variable amount of application specific data. The application specific data field can be used in any way, as determined by the application specification for the indicated application identifier and, as will be seen, can be used where different profiles or contours for the service are used.
The BWS application and profile specifications
Having introduced the concept of an application identifier as part of the DAB Digital Radio SI, it necessarily follows that the application identifier must refer to some application specification that completely and unambiguously describes the operation of the service. The BWS application is no exception and so considerable effort has gone into the development of the BWS application specification. The BWS specification consists, in large part, of a description of the interface between the Multimedia Object Transfer (MOT) data carousel containing the files for the web site and the presentation engine. For example, the way the BWS decoder resolves Uniform Resource Locators (URLs) within the service content to file names within the carousel is part of this interface description.
One of the peculiarities of the Digital Radio situation is that a wide variety of receiver platforms are being considered for many services. These range from in-car and domestic portable/hi-fi integrated receivers - some with graphics displays, some without -through to PC card receivers. Clearly, presenting a BWS service on such a wide variety of platforms requires careful consideration as not all types of receiver will have the same presentation capabilities. This leads to the concept of signalled profiles - equivalent to the DAVIC concept of contours -which describe the constraints on the content for a service that must be applied for a given type of receiver. It is not in the interests for broadcasters to be required to support a large number of profiles, so the BWS application has been developed with two profiles currently in mind: An integrated receiver profile and a PC decoder profile. The PC profile is a pseudo profile that imposes no explicit constraints as the presentation capabilities of the decoder are dependent only on the web browser installed on the receiver PC. In addition to the PC profile, however, a basic integrated receiver profile has been developed and both of these profiles are associated with profile identifiers that can be carried in the FIG0/13 application signalling. The result of this is that a scalable service can easily be provided where more capable receivers (such as PC based receivers) present more of the overall service than less capable receivers.
The BBC pilot BWS service
For exactly the same reasons as for the TPEG pilot service, a BWS pilot service has been created by the BBC. Once again, this pilot service makes heavy use of automatic translation of existing content wherever possible. Because the BWS application uses HTML as a content format, the natural source for a large proportion of the service is the BBC’s extensive online service. In particular, it is relatively straightforward take BBC News stories from BBC News Online to make use of one of the BBC’s strongest brand images. With the development of suitable receivers, which are anticipated in the very near future, the stage will be set for developing this pilot service into a full time multimedia service for Digital Radio.
The VIADAB API
An important activity that has recently been initiated is the development of an Application Programming Interface (API) for Digital Radio receivers in a PC environment. This work, as part of a UK Department of Trade and Industry (DTI) funded project, aims to produce a completely open specification that can be adopted by all manufacturers of Digital Radio PC cards without a license fee. The result of this work will provide broadcasters with an unprecedented level of flexibility as service providers will be able to write their own data service decoding software. Also, a ‘virtual sockets’ layer built into the API will allow BWS services to make use of Java functionality within web browsers to allow dynamic
presentations to be created in an HTML framework.
The core of the API is a D-COM interface specified in Interface Definition Language (IDL). This makes the API entirely language independent, as well as allowing Digital Radio receivers to be seamlessly integrated with Local Area Networks (LANs).
CONCLUSIONS
The slow take up of Digital Radio has been seen as a problem for a number of years. Much has
been said about the impact that ‘data’ services might have on the appeal of Digital Radio. Now, thanks to extensive work by the Digital Radio community as a whole, the new pilot services offered by the BBC clearly demonstrate that DAB Digital Radio is now in a position to deliver on this potential.
扫一扫
2918
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
