02
Mar 1997
This is a WWW version of a document. You may copy it.
How to refer to it.
by Steve Draper
It is unnecessary to know about most of the technical background. This primer is for those who used to know something about communications technology but have been overtaken by recent developments.
1a Part of this is due to the spread of fibre optic cables, with their
big bandwidth. Since much of the cost of long distance cables is in laying
them (digging the trench etc.), then carrying more bandwidth in one cable
makes it cheaper.
1b But it is important to realise that recently and for the near future,
increases in bandwidth are often obtained by using the same old cables
but new electronics at either end. For instance, ISDN uses the same copper
wires as ordinary telephone lines: just new electronics. Similarly the
UTP (unshielded twisted pair) wiring that has recently replaced coaxial
ethernet network connections in many offices is in itself technically much
lower performance (and so cheaper) than the coaxial cable, but gives about
the same performance (10 Mbps i.e. Mega bits per second) by using clever
electronics at both ends. Furthermore you can buy a 10 fold performance
upgrade to 100 Mbps without changing the cabling by paying for more expensive
electronics at both ends. (Part of the increases come from faster electronics;
part from adaptive echo cancelling which retrieves the signal despite poor
intrinsic performance from the wires; part comes from limiting the cable
lengths: you can't run UTP as far as coaxial cable between the electronics;
part comes from the use of 4 pairs of wires per network connection i.e.
4 parallel circuits in each cable and wall socket outlet connecting one
computer; part comes from having only 1:1 communication on each piece of
wire with collision detection done only by detecting one's own transmission
on one wire simultaneously with reception on another wire.)
There are two basic kinds of communication circuit, but now in addition new hybrids between them are being developed. Originally there are (a) "circuit switching" systems like the phone system, where during communication a whole circuit with fixed bandwidth adequate to the task is dedicated to the users; and this is set up separately before/when the call begins. (b) "Packet switching" systems like postal mail and email over the internet, where everyone may be connected all the time to a single network, and individual packets follow each other down the routes, queueing as necessary when the load is high, each carrying their destination address, and each individually sorted at each node.
Type (a) systems are good for audio and video connections because once set up there are no delays, and especially not a varying delay, in delivering the signal. On the other hand they are very inefficient on use of cables and bandwidth: your phone wires are unused most of the time, then when in use they totally block any extra incoming calls. Type (b) systems are more efficient in using bandwidth, but at the cost of unpredictable delays partly due to heavy traffic, and partly because each node must read and process the address of every packet.
ATM is a hybrid made possible by new fast electronics. It is intended to support simultaneously both kinds of traffic. Type (a) traffic is handled by setting up a route before the connection starts which reserves bandwidth over the route for this call, and sets up hardware switches to handle the packets (called frames) for the call. At each switch the decision on where to send each packet for that call is taken once during call setup; this decision is then entered in a lookup table; each incoming frame is then read by hardware and switched according to the table with "no" delay: that is with a speed independent of traffic density or queue sizes, giving a speed independent of traffic (no variable delays) and guaranteeing that frames arrive in the order they were sent. See also.
The ATM literature seems never to mention hardware and software in the way I have, perhaps because in theory they are an interchangeable implementation detail. This seems to me to be economical with the truth to the point of being grossly misleading. ATM technology is expensive because it requires special hardware. If you did it in software, e.g. emulated it with a 386 processor, you would lose all the properties that are essential: huge and totally predictable speed. An ATM switch is characterised by its (guaranteed) speed; currently this depends mainly on hardware design, although of course this will probably change.
Advances are still being made, and big compression factors have already been achieved. This is important because video and even audio require big bandwidths and big storage, even by current standards.
Broadcast quality colour video requires about 5Mhz bandwidth (analogue) or 224Mbps (= 28Mbyte/sec = 1.7 GigaBytes for a minute of video) digital without compression; while VHS (i.e. domestic videotape) is 4 times less than that (1.25 Mhz, 56Mbps, 7Mbyte/sec, 420Mbyte for a minute). Audio requires 22KHz analogue, 0.7 Mbps CD quality digital audio (1.4 for stereo), 10 Mbytes for a minute of stereo. Telephone quality is 3-4kHz analogue 64kbps digital.
However from an information point of view these signals are highly redundant, and could be enormously compressed without losing any resolution/information/accuracy. This is because almost all the time each frame is only slightly different from the one before: scene changes are rare e.g. every few thousand frames. Thus if you were going to compress a whole video, transmit it to a remote store or pack it on a disk, decompress it at leisure, then play it, you could probably achieve 1000:1 compression. However if you want to play it as it is transmitted, either to save remote local storage or because you want it for a real time application like video conferencing, then there is a problem. Compression imposes a delay partly for the processing time, partly because compression means representing say 100 frames by a single block of information that represents what is common across the block and what the differences are. On a simple view, you have to impose a delay of 100 frames. The reason you can never wholly get around this is that to transmit the very first frame (which could be anything at all) requires either the whole uncompressed bandwidth for a moment or else a delay while the information is transmitted at a reduced rate. Thus compression must always introduce a delay: a