As we all know, IP (Internet protocol) has seen off proprietary and open rivals alike, and has won the battle to become the de facto standard in data communication protocols. With the growing availability of broadband, the potential for IP to deliver ‘rich’ content, particularly audio and video, is becoming a reality, both on the Internet and within corporate networks.
Indeed, the fact that audio/video streaming originally evolved in times that were more bandwidth-constrained is now an advantage, because the latest codecs mean that acceptable sound and picture quality is possible using data rates well below those used for conventional radio and TV. It is therefore surprising that the broadcast capability of IP is so often overlooked.
Broadcast was fundamental to radio and TV services from the start, so much so that the word is often part of the name of a service (eg, SABC). The possibility that each listener or viewer might have their own unique on-demand channel was never considered, as the available radio spectrum could not possibly support more than a handful of channels, so broadcasting a few channels to many people was the only option. Now that broadband Internet is making it possible for us to pick our own selection of video clips, and watch them when we choose, does that mean there is no need for broadcasting within IP networks?
Our need for group communication
We need to distinguish between things we want to hear or view individually, and things we listen to or watch as part of an audience, a differentiation as applicable in the workplace or school as it is in the home. You might stream a music clip of a favourite artist from their website, but the choice and convenience of the 'net does not means you would not watch their concert in a scheduled TV broadcast. It is useful to be able to refer to a company's marketing material on a new product, but the product's launch is better as a live event with the possibility for interaction between colleagues and possibly customers. As part of human nature, we find some experiences are better shared with others, and in realtime.
The use of business TV for training and corporate communication is well proven, but constrained by being too expensive and impractical for most organisations. The convenience of using IP as a transport for business TV services and the like would be considerable, especially as most medium-to-large organisations have already wired their buildings with high-bandwidth local area networks, and put a PC screen in front of many of us. Combined with efficient encoding, IP has the potential to make business TV and radio a practical and affordable proposition.
Even if an organisation has decided it has no use for audio and video at this time, many do have large data distribution needs, whether they be software or parts catalogues on CD-ROMs, or promotional material to point of sale displays. As businesses grow to more locations, and file sizes increase, and users' requirements become more immediate, so traditional distribution methods such as couriers or overnight FTP transfers become incompatible with business needs, so why not exploit the efficiency of broadcast to distribute those files?
Internet content can also be broadcast, for caching nearer to the edge of the 'net, and for feeding intranets with content from the web. Multicasting offers a comparatively low cost means of giving schools without Internet connections the capability to browse selected websites, without any risk of students straying onto the wrong content. Caching services targeted at ISPs have provided substantial savings to the Internet industry, and although some of these services collapsed in the dotcom crash, this was due more to the excesses induced by years of easy venture capital, than to a failure of the concept itself.
Sometimes we need to step back and consider how processes work, to identify better ways of doing things. Whether it is streaming audio and video, or transferring files to ISPs, offices, shops and schools, currently most data distribution takes place as individual transfers, repeated again and again for the number of sites. It is obvious that such a process is wasteful of bandwidth, because the same data is being sent - often down the very same circuits - on a recurring basis. As bandwidth in packet switching networks is shared at some points, normally acceptable contention ratios become untenable when large numbers of users attempt prolonged bandwidth-intensive transfers such as streaming video. Would a paperboy collect single newspapers from a newsagent and deliver each individually? - there has to be a better alternative!
Multicasting
IP multicasting neatly sidesteps the issue of repeated transmissions, and the efficiency of only transporting the data once, regardless of the number of recipients, means that multicasting can enable services that would otherwise be untenable. The more sites, the more appropriate multicasting becomes, because a transmission to a thousand sites is little different than to just one.
Multicasting is recognised within the IP specifications as the approach for group communication, and multicast packets are allocated their own address range within the familiar IP addressing scheme. The normal concept of an explicit destination address is irrelevant to multicasting services, so multicast streams contain information akin to a television channel 'ident', to which receivers can 'tune'. In the IP world, these receivers are client applications that look for multicast streams with the required 'ident', and decode and play audio and video, or reconstruct files from the incoming data stream.
Multicast traffic also behaves differently to conventional TCP/IP. Like broadcasting, multicasting is essentially a one-way process, requiring only a simplex data circuit. A return channel can be used if an application requires and supports it, but is not inherent in the process. Flow control of traffic is unwelcome for multicasting and likely to lead to packet loss, which raises issues for conventional data networks.
Compatibility with data networks?
The evolution of data networks has largely ignored multicast services, often for good reason. Datacoms people naturally think in terms of circuits, connecting one place to another, because that is the only type of service they can lease from their local telco. This point-to-point topology works with traditional applications, but struggles to cope with broadcast-type services. Ask most datacoms managers about multicasting, and if you get more than a blank look it will probably be one of fear. Multicast packets tend to propagate down every link in a network, and unless filtered will clog up expensive wide area circuits and jeopardise the mission critical IT systems that justify those circuits. However, on a typical 100 Mbps office LAN, running a few multicast channels is rarely a problem, because the bandwidth available is more than sufficient to carry both types of traffic.
The issue for a distributed organisation therefore becomes one of delivering multicast traffic to 'islands of bandwidth', without overwhelming the comparatively slow and expensive wires that make up the wide area network. Well, if the point-to-point nature of wires is the problem, dispensing with wires might offer the solution. It is no coincidence that radio and TV channels work in a wireless environment, because it allows an audience of unlimited size, all watching and sharing the same channels, and each without any impact on their fellow viewers. Just like broadcasting, when used in wireless networks, the multicast model allows streams - channels of data - to be transported to an unlimited number of recipients in a one-off transmission.
Satellite delivery
With terrestrial radio spectrum already crowded with traditional communications, satellite should be an obvious place to turn for wireless bandwidth for commercial, industrial and educational multicasting services. A single satellite footprint covers not just a city, nor even a country, but entire regions and continents.
As you might expect with a protocol designed for realtime streams in often bandwidth-constrained environments, multicasting prioritises temporal accuracy above error correction, so applications using multicasting have to adopt a different strategy for erroneous or lost packets, depending on the nature of the application. For audio/video streaming, it is normal to avoid requesting retransmission, which would interrupt the flow of the transmission. File transfers sometimes raise other dilemmas, although there are often situations where systems can revert to the previous generation of a file (eg, yesterday's parts catalogue or web pages), or one site can request retransmission on an exception basis via the existing network. These are areas is which satellite ideally complements multicasting, as the single channel required can be economically engineered for zero congestion, and layers of forward error correction offer quasi error-free data transmission.
Multicast streams of almost any bandwidth can also be easily multiplexed together, providing anything from a trickle-fed file transfer running around the clock at 64 Kbits/secs, to a bouquet of MPEG-4 video channels totalling 40 Mbits/sec or more.
As most satellite multicasting services are based on the same standards used for digital TV, the receiving equipment is inexpensive and reliable. Most organisations would use a small satellite dish and a DVB/IP receiver attached directly to a building's LAN, working as a local gateway for incoming multicast traffic, and with routers configured to stop multicast packets getting out onto the wide area network's circuits. Standalone PCs, such as for point of sale displays, are economically catered for with PCI-bus cards. Increasingly, satellite data receivers offer the familiar SNMP and web-based management tools associated with conventional datacomms equipment, allowing diagnostics and remote configuration from a central IT department using the existing network infrastructure.
More complex is uplinking such services to satellite, due to the cost and complexity at the hub, the need for operating licences, and that most satellite operators get nervous about inexperienced people squirting signals around the sky. Uplinking is therefore normally best left to specialised satellite service providers, with the customer feeding the data to a provider's teleport using a terrestrial 'backhaul' circuit or a broadband Internet connection.
High power Ku-band satellites are most appropriate to services like these, as quality of service can be assured with discretely sized dishes, in addition to cost savings and ease of deployment.
Conclusion
This synergy between IP multicasting and satcoms has been obvious to the satellite industry from the start. The industry keeps assuring itself about the potential for multicast services, yet has made an appalling job of communicating the advantages to the outside world. As someone who spent many years in datacoms prior to finding myself in the satellite business, the simplicity and possibilities of multicasting initially came as a real eye opener, and I remain an unapologetic evangelist on the subject.
Multicasting via satellite is in use today, from the example of preloading ISP's caches mentioned earlier, to technically advanced multinationals using it to deliver training material to users' desktops, through to satellite-aware organisations such as financial information providers who understand its capabilities. For many other organisations, it sometimes seems ignorance is to blame, and companies either live without the types of services that multicasting would enable, or waste expensive terrestrial bandwidth sending the same information again and again.
Any organisation with intimidating data distribution requirements should be looking to multicasting via satellite. Satellite services are rarely 'cheap', but as broadcasters discovered years ago, satellites offer a ruthlessly efficient way of delivering massive quantities of data to innumerable locations, all at the speed of light. As organisations look to integrate various forms of multimedia into our everyday working lives, multicasting via satellite offers a proven option beyond conventional data networks.
For more information contact Roy Ingle, Europe*Star, 021 421 9991, [email protected]
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version