Internet Telephony
Time Synchronization for VoIP Quality of Service Time synchronization provides receivers with precise information about end-to-end delays, enabling effective playout of time-sensitive voice data over the Internet.
A
lthough packet-based and unmanaged networks like the Internet are ideal for delivering timeinsensitive data such as e-mail or static Web traffic, the growing demand for Web-based multimedia data exposes the limitations of core Internet protocols. With no end-to-end delay bounds, the public Internet’s best-effort service is unsuitable for delivering time-sensitive data and for interactive applications such as voice-over-IP. Normal speech consists of talkspurts, which typically last a few hundred milliseconds, and silence periods, which occur both within a spoken word and between words. In a packet-based network, voice packets are generated periodically at the sender and transmitted across the network. To cope with the packet interarrival variance inherent in besteffort service, current VoIP implementations generally implement fixed buffer schemes. Fixed buffer schemes make no attempt to match receiver operation to IEEE INTERNET COMPUTING
current network performance. An alternative approach is to use a more complex adaptive buffer scheme. This continuously matches playout delay to network conditions, at the expense of some packet loss due to late arrivals and some distortion of intertalkspurt silence periods. Various approaches seek to optimize the quality of service of VoIP applications (see the sidebar, “Quality of Service for VoIP,” next page, for a categorization of QoS approaches). We propose a system that uses synchronized time to combine the useful characteristics of both fixed and adaptive buffer strategies, thereby improving VoIP quality of service. Using a combination of global positioning system (GPS) technologies and the network time protocol (NTP), hosts can learn the precise end-to-end delay for each packet. This information can benefit both domestic and business Internet telephony users. In this article, we outline our proposed system and discuss issues arising from the use of synchronized time. 1089-7801/02/$17.00©2002 IEEE
Hugh Melvin and Liam Murphy University College Dublin, Ireland
http://computer.org/internet/
MAY • JUNE 2002
57
Internet Telephony
Quality of Service for VoIP We categorize QoS for VoIP approaches by whether they involve measures taken at the sender, network, or receiver.
■
Sender-Initiated Approaches New bandwidth-efficient codecs reduce VoIP bandwidth requirements (from the G.711 64-Kbps POTS standard to G.723 6.4 Kbps or even lower, for example). Lower bandwidth requirements reduce the likelihood of congestion, and thus delay. In another scheme, the sender codec bit rate reacts to congestion feedback obtained via RTP control protocol (RTCP) packets.1
Network-Level Solutions Many network-level solutions, such as the Internet Engineering Task Force’s integrated services, differentiated services, and multiprotocol label switching, offer varying QoS regimes within the network depending on data requirements.2 ■
Intserv allows routers to classify traffic
■
flows, specify QoS, and reserve bandwidth for each flow. Diffserv uses a subset of the IPv4 typeof-service field (or IPv6 traffic class field) to distinguish between traffic flows. Routers use this information to implement a certain agreed-on per-hop behavior (PHB). MPLS is essentially a switching architecture that implements a labeling system with which routers engineer traffic in an MPLS-enabled network.
For Internet telephony, these approaches can, as part of a service-level agreement (SLA), offer faster network transit times to real-time traffic. In addition, much research attempts to derive accurate models of network performance from both delay and loss perspectives.3
Receiver-Based Strategies Receiver-based strategies focus on optimizing the buffer design (and thus application
Multimedia Data Delivery In assessing VoIP viability, consumers will undoubtedly compare its services to those of the existing “carrier-grade” plain old telephone system, or POTS. The International Telecommunications Union’s (ITU-T) recommendation G.114 (www.itu. int/ITU-T/) specifies that one-way delays should not exceed 150 milliseconds. With the exception of satellite links, POTS easily meets these limits. POTS presents minimal end-to-end delays, of which propagation time forms a significant and consistent proportion. The Internet, on the other hand, through its best-effort service offers much higher and inconsistent delays where propagation time is often dwarfed by congestion delays. The real-time transport protocol (RTP),1 RTP control protocol (RTCP),1 and real-time streaming protocol (RTSP)2 were developed to facilitate multimedia data delivery across the Internet. In RTP and RTCP, payload identification, time stamps, sequence numbers, and feedback allow receivers to reconstruct media streams at the destination host for playout, and also allow senders to adapt to congestion problems. These protocols add minimal overhead to multimedia traffic and adequately address multimedia streaming require58
MAY • JUNE 2002
http://computer.org/internet/
delay) to strike the correct balance between packet loss due to late arrival and overall delay.A larger receiver buffer means that the receiver can wait longer for delayed packets, but it also increases the overall end-toend delay. Setting a fixed buffer size in a besteffort environment is unsatisfactory because of its inflexibility, so a lot of research focuses on adaptive buffer strategies. References 1. A. Barberis et al.,“A Simulation Study of Adaptive Voice Communication on IP Networks,” Computer Comm., vol. 24, 2001, pp. 757-767. 2. A. Dutta-Roy,“The Cost of Quality in Internet-Style Networks,” IEEE Spectrum, vol. 37, no.9, Sept. 2000. 3. J. Rosenberg, L. Qiu, and H. Schulzrinne, “Integrating Packet FEC into Adaptive Voice Playout Buffer Algorithms on the Internet,” Proc. IEEE Infocom 2000, IEEE Press, Piscataway, N.J., Mar. 2000, pp. 1705-1714.
ments. However, interactive applications such as conferencing (video-voice over IP, whiteboard, and so on) demand an even higher level of service. Because the Internet was not designed to deliver such services, Internet telephony, though generating a lot of interest in recent years, faces many challenges. Principal among these is the need to keep end-to-end delay within the G.114 limit. Jiang and Schulzrinne outline the total end-to-end delay in a VoIP session,3 which includes: ■ ■
■ ■
■
Operating system delays Host hardware input/output delays, including packetization delay, which depends on the codec employed Possible look-ahead delay Network delays, including fixed propagation delay; transmission delay, which is set by the interface speed; and variable queuing delays at intermediate routers or switches Application delay, which is introduced by the receiver to allow for the variance in interpacket arrival times, or jitter
Of these, the queuing delay (which is a manifestation of best-effort service) is often the most sigIEEE INTERNET COMPUTING
Time Synchronization 100 90 Playout time Arrival time
80 Jitter (milliseconds)
nificant, and its variability results in the need for application delay. A receiver buffer is thus required to deal with jitter, and applications differ on whether the size of this buffer is fixed or adaptive. A fixed buffer is simple to implement but is obviously inflexible, whereas an adaptive buffer, though more complex, reacts to changing network conditions.
70 60 Late packet loss rate = 7percent
50 40 30 20
Adaptive Buffer Strategies
10
The receiver-based approach of adaptively adjusting the playout buffer to match network conditions and optimize performance makes no assumptions about end-host clock synchronization. Ramjee and colleagues compare four algorithms to determine optimum playout delay.4 All four algorithms calculate the playout time of packet i, where pi is the first packet in a talkspurt, as pi = t i + dˆ i + 4 ∗ vˆ i
(1)
In this calculation, ti is the time the packet was sent (with reference to the sender clock), d^ i is the estimated mean end-to-end delay, and v^ i is the estimated end-to-end delay variation. The playout time of all subsequent packets in the talkspurt is calculated by adding to pi the time between the first and subsequent packets’ generation according to the sender time stamps — that is, pj = pi + tj – ti .
0
20
40
60
80 100 120 140 160 180 200 Packet number
Figure 1. Adaptive buffer performance.We recorded the trace illustrated here from our testbed implementation. (as seen by the receiver at NUI, G) The y-axis scale illustrates the interpacket arrival-time variance (jitter) resulting principally from variable queuing delays.The dark line indicates the playout time of each packet relative to its arrival time. Testbed Implementation
GPS satellite
GPS satellite
GPS Receiver NTP primary server, NUI,G
(2) NTP signalling
This guarantees the integrity of speech within a talkspurt. The exact determination of d^i depends on the particular algorithm employed, whereas all four algorithms derive the factor v^i in a similar fashion. Although the values of d^ i and v^ i are updated for every packet, the formula in equation 1 is only invoked for the first packet in a talkspurt; otherwise the playout time is determined by equation 2. In this way, the receiver playout time is adjusted between talkspurts to reflect changing network conditions. The factor 4 * v^i is critical in determining the playout time for the first packet in a talkspurt. It must be large enough to ensure that only a small percentage of packets arrive after the scheduled playout time (and thus get dropped), yet small enough to minimize overall delay. The algorithms therefore build in a late packet loss percentage, regardless of the true delay. RTCP feedback enables senders to generate periodic values for round-trip time and thus estimate one-way delay. The adaptive receiver buffer algorithms described by Ramjee and colIEEE INTERNET COMPUTING
NTP VoIP VoIP PC, NUI,G
Internet
NTP VoIP VoIP PC, UCD
Figure 2.Testbed implementation.The global positioning system (GPS) receiver provides the time source for a network time protocol (NTP) server, which in turn acts as the primary time server for the end hosts. leagues do not use such estimates, however. Figure 1 illustrates the performance of the first of Ramjee and colleagues’ four algorithms. We generated these results using actual traces recorded from our testbed, shown in Figure 2, and processed using a Matlab-based simulator. The yaxis scale illustrates the interpacket arrival-time variance that principally results from variable queuing delays. Because the clocks are not synchronized, the y-axis values do not reflect actual http://computer.org/internet/
MAY • JUNE 2002
59
Internet Telephony 190 180
Playout time Arrival time G.114 constraint on endtoend delay
Time (milliseconds)
170 160 150
Changeover from adaptive to fixed playout delay
140 130 120 110 100 90
20
40
60
80 100 120 140 160 180 200 Packet number
Figure 3. Proposed system operation.With time synchronization, switching from an adaptive to a fixed playout delay prevents late-arriving packet loss and silence period distortion. It results in an end-to-end delay of 135 milliseconds. end-to-end delays. The dark line, which we adjust on a per-talkspurt basis, simply indicates each packet’s playout time relative to its arrival time. Note that packets above the line are dropped (those that arrive after scheduled playout time), and that playout time adjustments will either shorten or lengthen intertalkspurt silence periods. Moon and colleagues indicate that frequency differences in consumer-grade clock oscillators introduce errors into this analysis, and propose an algorithm for removing this clock skew.5 They focus on addressing the problems arising from different clock frequencies rather than removing any clock offsets that might remain.
Time Synchronization Current fixed buffer or adaptive buffer strategies make no assumptions about synchronized time. We propose synchronizing end-host clocks (effectively removing clock skew and offset) to provide receivers with precise information on end-to-end delays, with which they can deliver better QoS to their end users. Consider a network connecting two Internet hosts in a VoIP session (with unsynchronized clocks) in which actual end-to-end delays are variable but within 90 to 120 milliseconds in both directions. Although the outer bound of one-way delay (120 milliseconds) is within the G.114 limit, adaptive receiver buffer algorithms are unaware of the actual one-way delay. They will therefore try to reach what they see as the optimum operating point, trading a percentage of dropped packets due to late arrival for prompt playout. If, however, we 60
MAY • JUNE 2002
http://computer.org/internet/
synchronize end-host clocks, a playout mechanism at either end that waits 135 milliseconds will avoid any packets being dropped. With synchronized clocks, receivers can use actual delay measurements to predict network performance and impose a fixed limit, if possible, within the G.114 requirement (as in this example). Such a system also eliminates the distortion caused by the lengthening or shortening of silence periods between talkspurts, which is an inevitable side effect of adaptive receiver buffer algorithms. Figure 3 illustrates how synchronized time might be applied to the trace shown in Figure 1. With synchronized clocks, the receiver at the National University of Ireland, Galway, knows each incoming packet’s end-to-end delay. The testbed end hosts — one at NUI, Galway, and the other at University College Dublin — are 220 kilometers apart and connected via high-bandwidth links, which generally results in end-to-end delays of at worst a few tens of milliseconds. We thus use a conservative 90 milliseconds as the y-axis baseline (including a sender packetization delay of 30 milliseconds). From Figure 1, the maximum jitter for the trace amounts to less than 40 milliseconds (between 0 and 40 milliseconds on the y-axis). Adding a 45-milliseconds delay (the amount required to capture all packets yet still result in an overall delay less than G.114 specifies) to the 90milliseconds baseline results in a total delay of 135 milliseconds. Figure 3 shows that by applying a fixed end-to-end delay value of 135 milliseconds results in zero late packet loss and, by definition, no silence period distortion. Both domestic and business VoIP users could benefit from a synchronized time strategy. In effect, this strategy combines useful characteristics of both fixed and adaptive buffer strategies, as receivers respond dynamically to precise network information while imposing a fixed playout delay. If receiver-based intelligence controls the session, the synchronized time implementation is transparent to the user. Another option is to allow users to set parameters for implementing their desired playout policy — for example, by choosing between low late packet loss, high delay (by setting a higher fixed end-to-end delay) or higher late packet loss, lower delay (by setting a lower value). With synchronized time, we can guarantee users a service level that precisely matches the underlying network conditions. Alternatively, end users who receive network information can proactively set receiver policy and thus know exactly what to expect. IEEE INTERNET COMPUTING
Time Synchronization x 105 2 Drift (microseconds)
Private IP networks with managed performance are in a better position than unmanaged networks to benefit from synchronized time. In a commercial service-level agreement (SLA) environment, the availability of synchronized time would also facilitate precise monitoring of latency and jitter specifications. Customers could use such monitoring to ensure that they get what they pay for, and SLA providers could use precise network information as a network-policy feedback mechanism to ensure compliance with SLA terms.
4 Drift = 18 µs/sec (ppm) = 1.55 sec./day
6 8 10 12 14 16 1
Internet Time Synchronization Issues Several issues related to implementing time synchronization across the Internet exist. First, the quality of consumer-grade clocks found in standard PCs leaves a lot to be desired. Second, there is an obvious need for localized access to accurate and standardized time sources. Finally, such time needs to be distributed effectively to participating hosts and used to synchronize host clocks. Clocks and Operating Systems Conventional PC software clocks generally consist of a low-grade quartz resonator-stabilized oscillator and a hardware counter that interrupts the processor at regular intervals. At these intervals, the operating system adds a time quantity known as a tick to a system variable representing the software clock time. Software clocks accumulate errors for a variety of reasons, principally incorrect oscillator frequency. Oscillators are also affected by ambient temperature and aging. For example, Mills reports a median clock drift of 78 microseconds per second (ppm) in a survey of 20,000 Internet hosts.6 Figure 4 illustrates an 18ppm clock drift (equivalent to approx. 1.5 seconds per day) reported in earlier work.7 Both RFC 2330 8 and RFC 2679 9 detail conventional end-host clock measurement errors. RFC 2679, in particular, looks at the sources of error and uncertainty that arise in measuring end-to-end delays for Internet traffic. It recommends combining GPS clocks with high-resolution software clocks to minimize clock-related uncertainty. As mentioned previously, packetization, codec-processing, and operating-system delays occur at the sender host. Operating system issues in particular can lead to significant uncertainties. Real-time operating systems (RTOS) offer better bounds on processor scheduling (see Melvin and Shearer for a more detailed discussion7). Another way to reduce this uncerIEEE INTERNET COMPUTING
2
3
4
5 6 Seconds
7
8
9 4 x 10
Figure 4. Measured PC clock drift.The graph shows a clock drift averaging 18 ppm, or 1.5 seconds per day. tainty is to use specific hardware/software. This involves moving away from a PC operating system, which schedules multiple applications including VoIP, to a system that provides dedicated VoIP hardware/software. GPS and NTP An obvious requirement for Internet time synchronization is access to accurate and standardized time sources with which to synchronize VoIP host clocks. A related issue is the synchronization level required in a VoIP environment. NTP synchronizes computer clocks throughout the Internet, delivering single-millisecond synchronization on local-area networks and, at worst, a few tensof-milliseconds synchronization across wide-area networks.6,10 For VoIP hosts connected via good Internet links, NTP should provide adequate synchronization. Improved versions of NTP and enhanced Internet infrastructure continuously improve NTP performance. (See the sidebar “Network Time Protocol”, next page, for a brief overview of NTP.) Many NTP primary time servers derive their time from GPS receivers. The newer GPS satellite clocks have an error rate of one second every six million years, and most commercial GPS receivers with time-synchronization capability are accurate to +/–1 microsecond or better. Host computer hardware and operating systems can introduce latencies and uncertainties, however, when synchronizing clocks with a GPS receiver. Mills and Kamp report that with specific operating system and hardware support, NTP can deliver better than microsecond-level synchronization,11 which is beyond VoIP synchronization http://computer.org/internet/
MAY • JUNE 2002
61
Internet Telephony
Network Time Protocol ■
NTP is a complex protocol that has been fine-tuned over the past 20 years to its present state, NTP version 4. It enables any Internet-connected PC to synchronize to Universal Coordinated Time (UTC). In its simplest form (client-server association mode), a client PC will have the addresses of a number of NTP servers in its NTP configuration file. At regular intervals, the client asks each server what time it is. From the responses, it selects the best candidates (based on a number of factors including round-trip time to each server). From these candidates the client selects the best single candidate, and NTP adjusts the client clock accordingly, using a weighted mechanism. NTP quickly ascertains the client clock drift and stores this value in a driftfile, updating it regularly. The NTP architecture is hierarchical. Primary NTP servers are directly connected to a UTC source. Secondary NTP servers are sychronized to UTC via primary servers or other secondary servers. Server accuracy is categorized by stratum level (1 … n) with primary servers assigned stratum 1. Secondary servers are assigned stratum level (2 … n).
precision requirements. Until recently, access to millisecond-level globally synchronized time has been limited, but the falling cost of GPS devices is rapidly reversing this trend. Additionally, the ongoing roll-out of asymmetric digital subscriber lines (ADSL) and general packet radio service (GPRS) in the terrestrial and mobile telephony markets, respectively, will lead to extensive always-on Internet connection capabilities, which will allow for NTP’s increasingly widespread deployment. Such trends promise to open up enhanced VoIP services through synchronized time to a much wider audience.
Testbed Implementation and Open Issues Figure 2 shows our testbed implementation. A Trimble AcuTime GPS receiver provides the time source for a Stratum 1 NTP server, which acts as the primary time server for the testbed end hosts. With this arrangement, we expect to achieve millisecond-level time synchronization. A Matlabbased simulator allows us to more effectively compare algorithm performance using captured network traces. Signaling Protocols Much discussion in the VoIP field centers on the merits of the session initiation protocol (SIP) and H.323, the Internet and ITU-T signaling protocols, respectively. We use an open-source implementation of H.323 (www.openh323.org), and are currently modifying it to implement our proposal. In our system, 62
MAY • JUNE 2002
http://computer.org/internet/
■ ■ ■
■
each end communicates synchronized time availability to the other end, and performs some simple validation tests; the session commences using an adaptive buffer algorithm for playout; receivers monitor and store packets’ end-to-end delays; if, during initial packet exchanges, delays are well within G.114 and variance is low, receivers estimate a fixed-delay value; and receivers switch to fixed-delay playout.
Throughout this process, VoIP receivers constantly monitor performance. Time Stamp Synchronization The RTP header time stamp is not an absolute time stamp but a number that increases at a rate dependent on the payload format. If we use codec G.711 (sample rate 8,000 Hz), for example, and each packet contains 240 samples (equivalent to 30-millisecond packetization), the time-stamp value is increased by 240 per packet. To avail of synchronized clocks, we need a mechanism that relates this time stamp to absolute time. RTCP sender reports are currently used to provide lipsynch for audio/video sessions by relating RTP timestamps to NTP time, and thus provide a solution. RTCP packets also currently allow senders to periodically determine round-trip time. In a synchronized time environment, RTCP packets will let a sender determine the delay for both legs of the round trip because the sender already knows about incoming one-way delays from incoming packets’ RTP time stamps. Continuous Monitoring Time synchronization provides receivers with precise information on end-to-end delays. As outlined earlier, receiver-based intelligence can use such information transparently or can pass it to the end user. If network conditions deteriorate to the point where a previously determined fixed end-to-end delay causes significant late packet loss, receiverbased intelligence will either change over smoothly to existing adaptive algorithms or increase the absolute limit accordingly. Improved network conditions should also trigger a reduction in the absolute limit.
Conclusion Internet telephony, for many people, has failed to live up to its hype — mainly due to unrealistic expectations. Too much emphasis was placed on IEEE INTERNET COMPUTING
Time Synchronization
its cost effectiveness without considering its technical problems. As Maxemchuk and Lo suggest, the Internet with its current best-effort service model might not be suited to long-distance international VoIP connections because end-to-end delays often exceed the G.114 limits and jitter is generally high.12 As the Internet’s core infrastructure has developed, however, localized or national sections of the Internet that have good-quality links can often easily meet G.114 limits. But for domestic users, which still rely on dial-up links via an Internet service provider, high and inconsistent delays remain a serious problem. Some commentators claim that the Internet’s current best-effort service model cannot hope to achieve a QoS level comparable with POTS, whereas managed IP networks can successfully meet and exceed it. Many organizations and institutions with private IP networks are actually integrating such networks with their existing PSTN connections. We believe that synchronized time has much to offer IP networks, whether managed or unmanaged.
9. G. Alms, S. Kalidindi, and M. Zekauskas, “A One-Way Delay Metric for IPPM,” IETF RFC 2679, Sept. 1999, available at www.ietf.org/rfc/rfc2679.txt. 10. D. Mills, “Network Time Protocol: Specification, Implementation, and Analysis,” IETF RFC 1305, Mar. 1992, available at www.ietf.org/rfc/rfc1305.txt. 11. D. Mills and P.H. Kamp, “The Nanokernel,” Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting, Reston, Va., Nov. 2000. 12. N. Maxemchuk and S. Lo, “Measurement and Interpretation of Voice Traffic on the Internet,” Proc. 1997 IEEE Conf. Comm., IEEE Press, Piscataway, N.J., June 1997.
References
Liam Murphy is a lecturer in the Department of Computer Science at University College Dublin, Ireland, and the director of UCD’s Performance Engineering Laboratory. His research interests include multimedia networking and performance evaluation of computer networks. He obtained a PhD in electrical engineering and computer sciences from the University of California at Berkeley. Dr. Murphy is a member of the Institution of Engineers of Ireland and the IEEE.
1. H. Schulzrinne et al., “RTP: A Transport Protocol for RealTime Applications,” Internet Engineering Task Force RFC 1889, Jan. 1996, available at www.ietf.org/rfc/rfc1889.txt. 2. H. Schulzrinne, A. Rao, and R. Lanphier, “Real Time Streaming Protocol (RTSP),” IETF RFC 2326, Apr. 1998, available at www.ietf.org/rfc/rfc2326.txt. 3. W. Jiang and H. Schulzrinne, “QoS Measurement of Internet Real-Time Multimedia Services,” tech. report CUCS015-99m, Columbia Univ., New York, Dec. 1999. 4. R. Ramjee et al., “Adaptive Playout Mechanisms for Packetized Audio Applications in Wide-Area Networks,” Proc. Conf. Computer Comm. (IEEE Infocom), IEEE CS Press, Los Alamitos, Calif., June 1994, pp. 680-688. 5. S. Moon, P. Skelly, and D. Towsley, “Estimation and Removal of Clock Skew from Network Delay Measurements,” Proc. IEEE Infocom 99, IEEE Press, Piscataway, N.J., Mar. 1999, pp. 227-234. 6. D. Mills, “Adaptive Hybrid Clock Discipline Algorithm for the Network Time Protocol,” IEEE/ACM Trans. Networking, vol. 6, no. 5, Oct. 1998, pp. 505-514. 7. H. Melvin and A. Shearer, “Delivery of Cost-Effective Global Information Systems over Nondeterministic Networks,” Proc. Int’l Conf. Information Systems Analysis and Synthesis (ISAS 2000), vol. IV, Comm. Systems and Networks, Int’l Inst. of Informatics and Systemics (IIIS)/IEEE Computer Soc., July 2000, pp. 297-301. 8. V. Paxson et al., “Framework for IP Performance Metrics,” IETF RFC 2330, May 1998; available at www.ietf.org/ rfc/rfc2330.txt. IEEE INTERNET COMPUTING
Hugh Melvin is a lecturer in the Department of Information Technology at the National University of Ireland, Galway. His research interests include Internet multimedia, time synchronization, and real-time systems. He received a BE degree from University College Dublin, Ireland, an MBA from the University of Limerick, Ireland, and an MSc in applied computing from the National University of Ireland, Galway. He is currently a PhD candidate in the Performance Engineering Laboratory at UCD. He is a member of the Institution of Engineers of Ireland and the IEEE.
Readers can contact Hugh Melvin at
[email protected].
New for 2002! the IEEE Computer & Communications Societies present
MOBILE AND UBIQUITOUS SYSTEMS
This new quarterly magazine aims to advance mobile and ubiquitous computing by bringing together its various disciplines, including peer-reviewed articles on:
• Hardware and Software Technologies • Human-Computer Interaction • Security, Scalability, and Privacy • Real-World Sensing http://computer.org/pervasive/ http://computer.org/internet/
MAY • JUNE 2002
63
