Network basics for telemedicine

EDUCATION AND PRACTICE

Technology

...................................................................................................................................................

" Network basics for telemedicine Jill Gemmill University of Alabama at Birmingham, USA

Summary Early telemedicine networks employed dedicated telecommunications circuits (e.g. leased digital lines) in which the sender and receiver were connected by a private circuit. More recently, the Internet has become widely available for general use, including telemedicine. The Internet was engineered to permit network paths to be shared by all users, so data transmission is fundamentally different from traditional, circuit-switched networks. Early telemedicine applications demonstrated the feasibility of Internet Protocol transmission. The basic performance criteria to use in evaluating newer digital communications technologies that carry both voice and data are: (1) bandwidth; (2) packet loss; (3) end-to-end delay; (4) jitter; (5) privacy and security. Network engineering involves performance trade-offs between the hardware, architecture, security and the budget available. A telemedicine application may be running over a network whose design is entirely under the user’s control, or the application may employ some part of the Internet whose design is unknown to the user. If an application is not running to satisfaction, then a network engineer should be consulted.

Introduction

From circuits to packets

In telecommunications generally, convergence is taking place between video, voice and data networks. For example, telephone companies now offer Internet services in addition to voice, and Internet service providers (ISPs) are offering digital voice services. Convergence of the various technologies used for health care at a distance can also be expected to occur. Early telemedicine networks employed dedicated telecommunications circuits. The underlying communications medium was some form of digital line, typically Integrated Services Digital Network (ISDN) or T-1 lines. These special lines were required because the transmission capacity of an ordinary telephone line is not adequate for most telemedicine applications. Permanent circuits, such as a T-1 line, are paid for at a fixed annual cost and the charge is the same whether the circuit is used a lot or a little. Dial-up ISDN lines are usually paid for like telephone lines where there is a fixed monthly rental and then a fee per call.

Digital lines, such as T-1 or ISDN lines, are examples of circuit-switched telecommunication. The sender and receiver are connected by a private circuit. More recently, the Internet has become widely available for general use, including telemedicine. Data transmission via the Internet is an example of packet-switching, i.e. it takes place in a fundamentally different way from transmission in circuit-switched networks. The Internet was engineered to permit network paths to be shared by all users. The Internet Protocol (IP) is a standard that segments all data, voice and video into a series of variable-sized chunks of information called packets. Each packet has the destination address added as a header. In the Internet itself, devices called routers read the address on a data packet and forward it in the general direction of the final destination. Ultimately, after passing through several routers, an individual packet will reach its destination. Packets from multiple locations become interspersed as they flow along the Internet, something like a conveyor belt that is being fed packages from many delivery trucks at the same time. Some packets are sent with delivery guaranteed, and some are not (the reasons for not wanting a guarantee in some cases are explained below). Information sent along a circuit remains in order and travels along the path defined by that circuit; in contrast, consecutive IP

.......................................................................

Correspondence: Jill Gemmill, IT Academic Computing, 701 20th Street South AB 719-B, Birmingham, AL 35294-0107, USA (Fax: þ 1 205 975 2855; Email: [email protected])

Journal of Telemedicine and Telecare 2005; 11: 71–76

.......................................................................

J Gemmill Network basics for telemedicine

packets may or may not take the same route to reach a destination, and they may also arrive in any order. All these delivery details occur invisibly to the user. This IP engineering allows the Internet to be used by millions of people simultaneously for multiple purposes such as email, Web browsing, watching videos, telephone and videoconferencing activities to and from any other Internet-connected location. The routers can reconfigure themselves to avoid network paths that may have become blocked due to damage or equipment failure; this improves the resilience of the Internet. Early telemedicine applications demonstrated the feasibility of IP transmission. The basic performance criteria to use in evaluating newer digital communications technologies that carry both voice and data are: (1) (2) (3) (4) (5)

bandwidth; packet loss; end-to-end delay; jitter; privacy and security.

Bandwidth Bandwidth refers to the space required in the network path so that all packets can get through – think of that

conveyor belt full of packages: the wider the belt, the more packages that can be carried along without delay and without falling off. If the conveyor belt is too narrow for the number of trucks attempting to place packages on it, there will be overcrowding and packages will fall off or be delayed while waiting for space to open up. Bandwidth must be available end to end; if there is a bandwidth-limited segment anywhere along the path, then it will act as the limiting bottleneck. Think of six lanes of cars negotiating their way into a two-lane tunnel; eventually, they will all get through the tunnel but not at the speed at which they were originally travelling on the six-lane highway. Network engineers agree that it is not a good idea to operate network segments at maximum capacity (an average bandwidth utilization rate of 100%). However, there are differences of opinion as to what average utilization is the best – 65–70% is frequently cited.1 In other words, IP networks work best with at least onethird excess average bandwidth available in order to keep packets flowing and prevent congestion. Bandwidth may not be provisioned symmetrically at the edges of the Internet. For example, Figures 1 and 2 show real network utilization data from the University of Alabama at Birmingham. The bandwidth available at

Figure 1 A network utilization graph. This is a snapshot of a gigabit router port connecting one building to the campus network backbone at the University of Alabama. Note that this link is full duplex and the average utilization as seen in 5-min sampling intervals was less than 1%. This graph was produced by open source software called Multi Router Traffic Grapher (MRTG), available at http:// people.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html

Figure 2 This graph shows utilization at the point that the entire campus backbone connects to the public Internet. This connection currently operates at 100 Mbit/s and at this location in the same network, utilization averages 70% of what is available

72

Journal of Telemedicine and Telecare Volume 11 Number 2

2005


the edge of the campus, at the connection point to the public Internet, is only a tenth of what is available at the core of the campus network. Symmetric bandwidth means that each end can send and receive the same quantity of data at about the same rate. In contrast, home ADSL lines, for example, usually provide more bandwidth into the home than out of it. Table 1 lists the common types of non-wireless Internet connections, their associated bandwidth and example applications that work well with that bandwidth available. Note that a ‘bit’ is the smallest unit of digital information; eight bits are required to represent one character such as ‘a’ or ‘z’.

Packet loss Packet loss occurs when packets fail to arrive at the destination. Packet loss errors occur most commonly on network links that are noisy, such as microwave, satellite or other wireless links, but loss can occur in any type of network. Over reliable transmission media such as copper wires or optical fibres, packet loss is usually the result of inadequate bandwidth somewhere along the path. The Internet routers mentioned earlier have a finite amount of storage space in which to temporarily hold incoming packets while the destination address is scanned and the appropriate outgoing route is determined. Congestion causing packet loss occurs when a large number of incoming packets arrive faster than the router can handle them; soon there is no more temporary storage in the router and any additional incoming packets are discarded. Packet loss is not necessarily cause for alarm because the engineering of the Internet provides methods for recovering from the problem. As mentioned above, the Internet supports both reliable and unreliable packet delivery. Reliable delivery makes use of the IP Transmission Control Protocol (TCP). If TCP finds that a packet on the receiving side is missing, incomplete or corrupted, it will request that this packet be resent. In addition, packets that have been successfully received are acknowledged back to the sending side. Because of TCP, data files such as email messages or images can be transferred across the Internet with both sender and receiver assured that the material has arrived exactly as sent. Where TCP is used, any packet loss that occurs will cause the TCP to request retransmission. All the data will eventually be delivered, but the total transfer time may be longer than expected. There are certain situations, however, where unreliable Internet delivery is desirable. This is usually for applications where near realtime delivery is needed, for example when live audio and/or video is being transmitted. If you are watching a live conference over Journal of Telemedicine and Telecare Volume 11 Number 2

the Internet, and some packets get lost on their way to you, the unreliable transport would skip over what is missing and keep going – this makes sense, since you want to keep up with the live content and are not interested in a piece of sound or image that arrives 1 s out of sequence. Audio and video that are streamed across the Internet for live listening and viewing are typically sent using unreliable transport, the User Datagram Protocol (UDP) rather than TCP (see Figure 3). In summary, some minor packet loss can occur for both reliable and unreliable transport without ill effect on the application. Obviously, if the rate of packet loss is too high, it will result in excruciatingly slow file transfer or unintelligible audio/video, either of which would be unacceptable for telemedicine.

End-to-end delay Delay, sometimes referred to as latency, is the interval between sending a packet and its reception at the far end. Digital telecommunication, particularly over long distances, depends on optical fibre transmission, where information is transmitted at the speed of light. Even at light speed, on a very long distance network path there may be a latency of several tens of milliseconds.

Jitter Jitter refers to the random variation in packet delay. This delay is principally due to the length of time that a packet spends waiting inside routers. Traffic patterns on the Internet have been studied extensively and the pattern of activity is bursty in nature, meaning that longer periods of brief activities are interspersed with big traffic spikes. A high rate of jitter corresponds to a ‘jerky’ arrival rate that could be unsuitable for operating a sensitive remote instrument or for satisfactory videoconferencing. Jitter is one of the reasons that packets may arrive in a different order than they were sent.

Security and privacy Part of the challenge in moving from circuit to packet transmission is that rather than having a private communication channel, the packets traverse a very public network, the Internet. Because of privacy and confidentiality concerns, any telehealth application will require assurance that the information in transit is secure. A common solution is to use a virtual private network (VPN). VPNs provide an encrypted communication channel from the Internet to the edge of an institution’s network. This approach would be 2005

73


Figure 3 Functional layers of an Ethernet network. Each layer has a well-defined interface to the layer above and the layer below; the application and other upper layers have no need to know about what physical medium (e.g. copper wire or optical fibre) may lie below

suitable for a doctor to use when accessing records held at his/her clinic from home. An encryption scheme such as the Federal Information Processing Standard (FIPS) for the Advanced Encryption Standard (AES) encodes the content of each packet so that it is unreadable while transiting the Internet. Note that encryption adds about 30% overhead to the size of a transmission, and some additional delay is added due to the time it takes to encrypt and then decrypt each packet. Using Public Key Infrastructure (PKI), it is possible to sign email messages, encrypt messages and guarantee that only one specific person can decode and read the message. PKI relies on digital certificates provided by a certificate authority which (1) vouches that it has verified your identity and (2) issues you with a pair of digital keys, the private and public keys. You can then sign messages with your private key, and recipients can use your public key to verify the validity of your signature. By using the public key A of the person to whom your message is addressed and your own private key B, it is possible to encrypt a message so that only the holder of the private key A matching public key A can decipher the message. Securing general communication from any location to any other location is, however, still a difficult problem. VPNs are created so that you can access one particular location securely, but not any location you like. PKI is not yet widely deployed and is not yet well integrated with video and voice applications. An excellent description of how difficult it is to secure Voice Over IP communications entitled Security Considerations for Voice Over IP Systems was recently published by the National Institute of Standards.2 In taking the steps necessary to secure enterprise networks or important application servers from breakins or ‘denial of service’ attacks, you may feel that the cure is worse than the disease. Security devices such as Journal of Telemedicine and Telecare Volume 11 Number 2

firewalls and network address translator (NAT) devices protect your important network elements by hiding them and making them inaccessible from the public Internet. Unfortunately, some applications such as video and voice are likely to stop working. The ViDe Videoconferencing Cookbook3 section entitled ‘Network Matters’ contains a good description of what causes firewalls and NATs to behave as insurmountable or at least very unfriendly obstacles for videoconferencing and voice over IP. One possible solution is to establish a ‘demilitarized zone’ (DMZ) outside the firewall to host services that are expected to be more publicly accessible. A slightly different approach uses a gateway or proxy to more carefully manage inbound traffic that might be eligible to pass through the firewall.

Evaluating networks for telemedicine

....................................................................... Network engineering involves performance trade-offs between the hardware, architecture, security and the budget available. In general, you will want to obtain as much bandwidth as possible, monitoring average utilization to make sure that you have adequate but not excessive capacity. Where it is not possible to obtain the necessary bandwidth, it may be possible to use special router techniques, such as tagging video and voice packets so that they are treated as priority traffic. In a recent project in Alabama, the use of packettagging was demonstrated in a teledermatology project using only a T-1 Internet connection that was simultaneously being used for other purposes. If a specific application does not seem to be performing well over your network, a network engineer who understands the characteristics of the applications may be able to solve the problem. The ‘duplex mismatch problem’ is a fairly common and even frequently 2005

75


undiagnosed problem. Most workstations, servers and other network equipment are fitted with internal network cards that are factory configured to ‘autonegotiate’ a correct setting when connected to your network. Auto-negotiation is a protocol to determine the highest speed available at both ends of the link (the standard speeds being 10,100 or 1000 Mbit/s). Autonegotiation also involves selecting either half duplex (the link is in either send or receive mode, but never both simultaneously) or full duplex (the link can both send and receive at the same time, which effectively doubles the available bandwidth). Unfortunately, auto-negotiation does not always work correctly and a bad choice can cause terrible and perplexing performance issues. The speed is usually negotiated correctly, but the duplex may not be correctly matched. ‘One of the most common causes of performance issues on 10/100 Mbit/s ethernet links is when one port on the link is operating at half duplex while the other port is operating at full duplex’.4 Microsoft workstations will display the configuration you requested, but not the configuration the devices may have actually selected. Re-negotiation of settings at a router may introduce a significant amount of jitter into a previously well-behaved application. It is possible to detect duplex mismatch errors by examining network and router switch statistics. If one end of a link is set to full duplex while the other end is half duplex, statistics on the full duplex side will show a high level of CRC or alignment errors while the half duplex side reports a high number of late collisions. Vigilant monitoring of all network devices, and even automated monitoring with alarm conditions, is a good management practice.

76

Conclusion

....................................................................... A telemedicine application may be running over a network whose design is entirely under your control, or your application may use some part of the Internet whose design is unknown to you. If your application is not running to your satisfaction, then a network engineer should be consulted. There are a number of tests5 that can be run by the user which may help diagnose whether there is a bandwidth bottleneck, duplex mismatch or other identifiable problem in the path of interest. Everyone involved should have a common understanding of what is meant by ‘secure’ and ‘satisfactory performance’. Guidelines for specific telemedicine applications, such as dermatology or psychiatry, may be available.6

References 1 Lantronix: Learning Center. http://www.lantronix.com/learning/ net-tutor-switching.html (last checked 22 December 2004) 2 Kuhn RD, Walsh TJ, Fries S. Security Considerations for Voice Over IP Systems Recommendations of the National Institute of Standards and Technology. http://csrc.nist.gov/publications/drafts/NIST_SP800-58040502.pdf (last checked 15 November 2004) 3 ViDe Videoconferencing Initiative. ViDe VideoConferencing Cookbook. http://www.vide.net/cookbook/ (last checked 22 December 2004) 4 Cisco Systems. Configuring and Troubleshooting Ethernet 10/100/ 1000Mb Half/Full Duplex Auto-Negotiation. Document ID: 10561. http://www.cisco.com/warp/public/473/3.html (last checked 18 January 2005) 5 Burgiss S, Sprang R, Tracy J, eds. Telehealth: Technology Guidelines. http://telehealth.hrsa.gov/pubs/tech/techhome.htm (last checked 18 January 2005) 6 SURFnet Detective. http://detective.surfnet.nl/en/ (last checked 22 December 2004)

Journal of Telemedicine and Telecare Volume 11 Number 2

2005