redictable amount of time'. Handset hardware and software engineers, for example, need to make sure that application layer and physical layer functions are executed within known and predictable time scales in response to known and predictable external events and requests - this is often described as a deterministic process. We can apply a similar definition to a real-time network as 'A network that can provide throughput to asynchronous traffic in a predictable amount of time'. Network hardware and software engineers need to make sure that router processors can process offered traffic within known and predictable time scales. This in turn requires an understanding of the offered traffic Making Telecoms Work: From Technical Innovation to Commercial Success, First Edition. Geoff Varrall. © 2012 John Wiley & Sons, Ltd. Published 2012 by John Wiley & Sons, Ltd. Making Telecoms Work mix and offered traffic properties, particularly any time interdependencies present between different channel streams. 17.2 Switching or Routing The general assumption was, and is, that there will be more routing and less switching over time and less use of hardware, greater use of software to reduce cost and improve flexibility. However, software-based routing introduces delay and delay variability - the time taken to capture a packet, the time taken to check the header and routing table, the time packets spend in buffers waiting for the router to deal with other packets and the time packets spend in buffers waiting for egress bandwidth to become available (queuing delay). Traffic-shaping protocols such as Diffserv and MPLS can help manage queuing delay (i.e. reduce delay for some packets by increasing delay for other packets) but queuing delay can still be 20 or 30 milliseconds and varies depending on traffic load. Transmission retries (using TCP/IP) introduce additional variable delay. IP Switching as an Option Rather than treating packets individually, a sequence of packets can be processed as a complete entity - the first packet heade