IP datacasting represents a prime example of the growing convergence between the traditionally separate worlds of broadcasting, telecommunications and computing. The process of making the most of the strengths of each technology is well summarised by the DVB vision statement: "to build a content environment that combines the stability and interoperability of the world of Broadcast with the vigour, innovation and multiplicity of services of the world of the Internet".

The first generation of IP services was targeted at personal computers coupled with low bandwidth transmission channels. Such systems are suitable for basic web browsing, but struggle to cope with the higher bandwidths required for video streaming. Furthermore, these systems are not well suited to the delivery of popular live content, when a large number of users would receive identical content by means of individual point-to-point links. These scalability problems were well-illustrated by the pioneering web "events", such as the EBU’s webcast of the Eurovision Song Contest in 2000 when the majority of the potential users received nothing more than error messages due to server timeout.

By contrast, scalability is the great strength of a traditional broadcast network. Increasing the number of users within a service area has no impact on the downstream network capacity and hence the network cost per user can be very low. The weakness of the broadcasting systems lies in the difficulty in providing one-to-one connections. This was not particularly an issue for the first generation of digital broadcast services, as these attempted to do little more than provide a larger number of programme channels that to the user were virtually indistinguishable from their analogue predecessors.

IP and the MPEG Transport Stream are both packet-based systems, but they were designed for very different uses and have very different characteristics.

The MPEG Transport Stream was designed to provide a robust, one-way pipe for the delivery of one-to-many data streams over an error-prone transmission channel. The timestamps and the virtual decoder buffer model in the specification are used to ensure that time-critical data streams, such as compressed audio and video, are delivered within the tight constraints required to ensure reliable decoding. The system uses fixed-length 188 byte packets that map directly onto forward error correction systems, facilitating detection and concealment of packet loss. However, there is no direct support for one-to-one communications, e.g. there is no concept of receiver address at Transport Stream level.

By contrast, Transmission Control Protocol / Internet Protocol (TCP/IP) was designed to provide a bi-directional pipe for the point-to-point exchange of data files on a computer network, where each device has a unique IP address. TCP/IP packets are variable-length, typically much larger than MPEG packets. This reduces the percentage overhead due to the packet header, but it makes the system less suitable for carrying data over an error-prone transmission channel. The original assumption was that the network would be virtually error-free and the data would not be time-critical; the rare corrupt packet was detected by failed acknowledgement and could simply be re-transmitted.

This approach does not lend itself to audio or video streaming, as the time discontinuity caused by retransmission usually causes more problems than the packet loss itself. The alternative User Datagram Protocol (UDP) does not establish a bi-directional session between two clients, but delivers data without requiring acknowledgements. It includes the ability to define the address of a recipient (unicast) or group of recipients (multicast), as well as pure broadcast. The Real Time Protocol (RTP) specification, which runs on UDP, includes timestamps to allow clock recovery and inter-stream synchronisation. However, it does not provide a complete end-to-end solution and many quality-of-service issues remain to be resolved. For example, there is no equivalent of the MPEG virtual decoder buffer model to allow the encoder to pre-emptively manage the decoder buffer.

To summarise, the MPEG Transport Stream was designed as a real-time broadcast system whilst IP was designed as a general computer network system. Either protocol can be layered on top of the other, which leads to the concept of IP data-casting over terrestrial, satellite or cable digital broadcast networks.

The IP Datacast (IPDC) Forum was launched by the ten Founder Members at IBC 2001 to help promote the implementation of IP-based services over digital broadcast platforms. Membership has grown rapidly since then to include companies representing most aspects of the broadcast and multimedia industries.

The Forum members share a common vision of using DVB and DAB broadcasting networks to deliver IP-based audio, video, data, graphics and other broadband information directly to the end user, whether at home, at work or on the move. The potential applications range from entertainment (e.g. networked games) to information (e.g. stock market information) and business services (e.g. product updates to a closed user group).

True interactive services require a return channel, although a form of pseudo-interactivity can be provided by data storage at the user end. These issues are best illustrated by looking at a specific example: data-casting over a digital terrestrial network using DVB-T.

DVB-T can be used to provide services to fixed receivers, but a particularly interesting application is the distribution of IP services to users on the move. For example, imagine the convenience of being able to act on the latest stock market information whilst being driven to a meeting.

The DVB-T specification allows a trade-off between robustness and the data capacity provided in an RF channel. The parameters chosen in the UK for fixed reception give just over 24Mbit/s, whilst a typical mode for robust mobile reception would give about 10Mbit/s.

10Mbit/s could be used to provide web-based teletext services on a data carousel. Assuming very little storage in the receiver and hence a 30 second cycle time for the carousel, this would provide a magazine of about 500 web pages: sufficient for basic information services.

The service could be greatly enhanced by adding hard disk storage to the receiver. A 40Gbyte hard disk could store a library of about 700,000 web pages to give pseudo on-demand web-browsing, or to play video clips of news or sports. The 10Mbit/s data channel would be sufficient to update the entire contents three times a day.

Finally, UMTS could be added to provide a return channel for true on-demand services and greater capacity for downstream multicast or unicast services, e.g. to download the local traffic information into the car’s navigation system. In principle, either the UMTS channel or else the DVB-T channel could be used to carry unicast data. However, the typical DVB-T infrastructure has cell sizes of about 30km radius, compared to about 1km for UMTS. The larger number of users who share a DVB-T cell means that unicast data by DVB-T is likely to be best suited to areas of low population density, with today's infrastructure.

IP data-casting promises of to deliver services that make the most of the combination of broadcasting, telecommunications and computing technologies. Such services are already being tested and can be expected to be launched in the near future.