Interconnecting Haptic Interfaces with High Update Rates through the Internet ^†

Abstract

Real-time transferring of the haptic sense over the Internet is quite a challenging task. This paper outlines the proposed protocols for transferring haptic streams over the Internet. Moreover, it describes the Quality of Service requirements that a network has to fulfill in order to successfully use haptic interfaces with high update rates over the Internet. Extensive simulations and experiments for the performance evaluation of transport protocols for real-time transferring haptic data are carried out. Complements between simulation and real world experiments are discussed. The metrics that are measured for the performance evaluation are delay, jitter, throughput, efficiency, packet loss and one proposed by the authors, packet arrival deviation. The simulation tests reveal which protocols could be used for the transfer of real-time haptic data over the Internet.

1. Introduction

This paper is an extended version of the paper, presented at IEEE International Symposium on Broadband Multimedia Systems and Broadcasting (BMSB), 2017 [1]. It presents the existing transport protocols that could be used for transferring haptic streams with high update rates over the Internet. Simulation and emulation tests for transferring haptic streams over the Internet are undertaken. A thorough analysis of these results is presented.

Real-time multi-sensory streams carry audio, video, haptics, and other sensory data [2]. Supermedia data obtain massive variety and volume. This increase of data deteriorates the network status of the Internet.

Researchers [3,4,5,6] try to determine the QoS of the network, in order to maximize the Quality of Experience (QoE) of the user [7] in a real-time internet haptic application. In order to maximize the QoE of the user in a haptic application, the update rate of the haptic stream should rather high, close to 1 KHz. This high update rate should be supported by the QoS requirements of the network, in order to successfully transfer online the haptic feeling real-time. The network performance of the Internet is not stable. It is changing from one area to another and from one hour to another. The recent network conditions of the Internet might permit online real-time haptic applications to flourish. This paper investigates whether the Internet is capable of transferring real-time the haptic sense.

In order to transfer haptic data through the Internet, specific transport protocols should be enforced. Several protocols have been developed for transferring haptic data. The most important are the Application Layer Protocol for Haptic Networking (ALPHAN) Protocol [8], the Smoothed—Synchronous Collaboration Transport Protocol (S-SCTP) [9], the Efficient Transport Protocol (ETP) [10,11], the Interactive Real-time Protocol (IRTP) [12], the Real Time Application Level Protocol For Distributed Interactive Media protocol (RTP/I) [13] and the Real Time Network Protocol (RTNP) [14].

Other protocols that are being widely used to transfer real-time multimedia data, such as UDP, RTP [15], Datagram Congestion Control Protocol (DCCP) [16] and Stream Control Transmission Protocol (SCTP) [17], should be tested for haptic data transferring as well. All the above protocols have been proposed for transferring real-time streams of voice and video, but they have not been tested for transferring the haptic sense. This research tries to investigate whether some of the above real-time protocols could be used for transferring real time the haptic sense. Taking into account the special features of each protocol, the authors will try to propose which protocol suits best for the real-time transfer of the haptic feeling.

The rest of this paper is organized as follows. Section 2 outlines the most recent haptic applications. Section 3 depicts the network conditions that are met in the Internet today. Section 4 presents the simulation scenario that is used for the evaluation of transport protocols. Section 5 analyses the results of the simulation testing. Section 6 discusses the complements, differences and relevancies between simulation and real world experiments. Finally, Section 7 concludes the paper.

2. Internet-Based Haptic Applications

The expansion of the Internet has led to the emergence of haptic applications. Researchers in [18] try to transfer the haptic feeling over the Internet. Network performance, which is often measured through delay and jitter is playing a crucial role in QoE of the user [19]. Other factors that can deteriorate the QoE is the scaling factor in macro-micro teleoperations [20,21] and the inertia of the haptic system [22,23]. Some interesting techniques that can compensate the delay of the network are shown in [24,25,26]. Moreover Fuzzy algorithms [27,28] can be used when the network performance is not sufficient. Computer grids [29] can also offer sufficient computational power to process the demanding Fuzzy algorithms.

Haptic applications could be used to military operations [30], education [31], telesurgery [32], video games [33], and video enhancement [34]. Motion-copying systems (MCS) [35] also use haptics to copy movements of skill experts for mentoring. Emotional communication can be enhanced among users with the use of haptic devices [36]. The virtual reality in now evolving to augmented virtuality [37].

Haptics can help people with visual problems. Navigation and spatial information is offered through haptic sticks to blind people [38,39]. Tactile sensors [40] can be used for remote manipulation and tele-operations. Kinesthetic disabilities can be overcomed with the help of haptic devices [41]. Humanoid robots can imitate the human walking by using haptic sensors [42].

In order to use haptic devises through websites HTML5 offers new java script modules called Web Graphic Library (WebGL). WebGL can manipulate 3D models in a web browser. Researchers in [43] created an HTML5 Haptics (H5H) Plugin. It is compatible with almost all browsers, and it uses “HAPI” to render haptics. It supports almost all haptic devices.

3. The Network Conditions of the Internet

A lot of research [44,45,46] has been conducted for the network conditions of the Internet. Network conditions refer to the amount of traffic that is being transferred through the Internet, the End to End delay, as well as the jitter between source and destination, and the available bandwidth for data transport.

The results from research [3,4,5,6] have concluded that in order to maximize the Quality of Experience (QoE) of the user for haptic streams, the network conditions should satisfy the Quality of Service (QoS) requirements of

Table 1. QoS requirements for supermedia streams [3,4,5,6,7].

QoS	Haptics	Video	Audio	Graphics
Jitter (ms)	≤2	≤30	≤30	≤30
Delay (ms)	≤50	≤400	≤150	≤100–300
Packet Loss (%)	≤10	≤1	≤1	≤10
Update Rate (Hz)	≥1000	≥30	≥50	≥30
Packet Size (bytes)	64–128	≤MTU	160–320	192–5000
Throughput(kbps)	512–1024	25,000–40,000	64–128	45–1200

.

All the above metrics vary in time and space. They depend on the number of online users, the amount of data that is being transferred at the specific moment of the measurement, and the available equipment of lines and routers. It has been recorded that the amount of data transferred through the web is constantly increasing [47]. Apart from that, the number of online users is increasing as well. The growth of data transfer is compensated by continuing infrastructure upgrades of computer networks.

There are two methods for measuring the network performance. The one is the active and the other is the passive method [44]. As far as the active monitoring is concerned, ICMP packets are sent over the network to monitor the delay, the round trip time, the jitter and the packet loss. Other active monitoring tools for network performance are the ping tool, the traceroute, the capprobe, the dummynet, the netem and the pathchar [45]. The passive method observes the network traffic using some tools that are called sniffers. The most known of them are the Tcpdump, the Wireshark, the Ethereal, the Netflow and the JFlow [44].

In order to monitor the network status, the authors actively measured the average and the standard deviation of the delay, the packet loss rate, and the number of hops of networks between countries and continents. Measurements for the above metrics were made by the authors between Japan and Korea, and between Japan and Greece [48]. A recent measurement has also been made between two cities of Greece, Grevena and Thessaloniki [49]. The distance between those two cities is 175 Km. Two different networks were used for this measurement, the private optical network, GRNET [50], part of the pan-European GEANT network with speeds up to 4 × 10Gbps, on the one hand and one simple 8 Mbps Adsl connection on the other. The results of these measurements are shown in

Table 2. Internet status for intercontinental communication [48].

Countries Connected	Avg. Delay (ms)	Standard Delay Deviation (ms)	Packet Loss (%)	No. Hops
Japan–Korea	27.01	0.19	0.02	11
Japan–Greece	331.10	6.30	1.53	26

and

Table 3. Internet status for communication between cities.

Connected Cities	Avg. Delay (ms)	Standard Delay Deviation (ms)	Packet Loss (%)	No. Hops
Grevena—thessalonikh through grnet [50]	19.12	1.70	0	5
Grevena—thessalonikh through adsl line	53.19	5.31	0.11	8

. For the above experiments, 3000 ICMP packets for each of 0, 6, 11, 15 and 19 o’ clock standard time were sent from one destination to the other.

It is understood that the Internet connection between Japan and Korea satisfy all the restrictions of Table 1 for transferring haptic data through the Internet. For the Internet connection between Japan and Greece, the values of Table 2 are relatively high because they refer to intercontinental pings. The average delay exceeds the limit of Table 1. This is due to the fact that the physical distance between Japan and Greece is much larger than Japan and Korea. That’s why the number of hops is much bigger in this intercontinental connection.

For the Internet connection between the two cities of Greece the results are shown in Table 3. In the case of the simple 8 Mbps Adsl connection the results are slightly worse than the limits in Table 1 for the average delay and jitter. The packet loss is within the limits of Table 1. On the other hand, in the case of the private optical network, GRNET, the results are encouraging. The average delay is only 19.12 ms, the jitter is only 1.70 ms and packet loss is 0.00%. All the above results are much lower than the limits in Table 1, which means that the transport of haptic data through the Internet is feasible under some circumstances.

Another important factor that describes the network conditions of the Internet is the connection speed of the end user. The recent spread of ADSL and VDSL connections provide consumers with connections up to 50 Mbps bandwidth. This bandwidth is by very sufficient for the requirement of 1 Mbps throughput that is being produced from haptic applications, based on Table 1.

We can conclude that the Internet network conditions are now suitable for online real-time haptic applications, especially when these applications take place in near regions.

4. Simulation Scenarioof Existing Protocols

In order to monitor the performance metrics of Table 1 and evaluate the transport protocols, simulations are undertaken. The network simulator that is used is the Network Simulator 2 (NS2) [51]. It is a widely used open source simulator. A lot of common protocols have already been implemented and tested in the NS2. Unfortunately, not many haptic protocols have been applied in NS2 so far.

One transport protocol for haptic applications that havebeen implemented in NS2 is the ETP. Apart from that, a lot of real-time protocols that could be used for haptic applications have been applied in the NS2. Some of them are the RTP, SCTP, DCCP and UDP.

All the above protocols were attached to different nodes in the NS2, as shown in Figure 1. The protocol TCP was mainly applied to the simulation scenario as a traffic generator. All the other protocols try to send a stream of packets with a packet rate of 1000 packets per sec. Most of them have a congestion control algorithm and minimize their sending rate in case of congestion. The haptic packet size that every protocol sends is 64 bytes of data payload [12] plus the overhead of the protocol.

The sample video for the HEVC encoding was the mobile_cif YUV series [52] with 352 × 288 resolution at 24 Hz. The data rate of this video sample after the HEVC encoding with Quantization Parameter QP = 27 and Low-Delay inter-prediction is 642 kbps [53]. This data stream sent over the RTP protocol with a packet size of 1500 bytes.

The audio stream was sent over the RTP protocol with 128 kbps bit rate, packet size 320 bytes and sending rate 50 packets per second.

4.1. Static Network Bandwidth, Delay and Internet Traffic

The square nodes in Figure 1 are routers that are connected with each other through the Internet.

The connection speed between those routers is set to 1, 5, 10, 15, and 20 Mbps for each simulation and is stable for the whole simulation period. The Internet bandwidth of 1 Mbps has been chosen so that a fully congested network can be represented. The Internet bandwidth of 20 Mbps corresponds to a network with no congestion. The Internet bandwidth of 5 Mbps corresponds to a network with low congestion. The connection between the server nodes 6 and 7 is regarded to be the Internet bottleneck of the simulation.

The end to end delay in the connection between nodes 6 and 7 was set to 5, 10, 20, 30, 40, 50, and 60 ms for each simulation and was stable for the whole simulation period. The 5 ms delay is a very small delay that rarely occurs in Internet connections. On the other hand, 50 ms is regarded to be the upper tolerable limit of delay, based on Table 1, that’s why the 60 ms is set as the maximum delay of the simulations. Of course, the end to end delay is changing dynamically in the real world connections. The authors deliberately kept the end to end delay constant throughout each simulation so as to study the behavior of each protocol at the specific delays. This would help the researchers decide which protocols are preferable when the characteristics of the network delay are known. Most of the diagrams depicted in this paper are for an Internet delay of 40 ms which is an acceptable delay, based on Table 1, and commonly encountered in the network. The simulations tests undertaken were 5 (scales for the Internet speed) × 7 (scales for the delay) = for a total of 35 tests.

The connection speed between the nodes 0–5 and server 6, as well as nodes 8–13 and server 7, is 100 Mbps as they are considered to be in the same local area network. The delay in those connections was 1 ms.

The simulation time for each simulation was 20 s. At time 0.5 s the FTP application which was attached at node 0 started to send data. At time 2 s all the other Constant Bit Rate (CBR) applications which were attached to nodes 1–5 will start to send packets with a rate of 1000 packets per second. The packet size varied from node to node depending on the header of the transport protocol.

4.2. Dynamic Network Bandwidth, Delay and Internet Traffic

In order to simulate the dynamic Internet network and test the response of the examined protocols, dynamic traffic generators such as the DelayBox [54] and the TMIX [55] ns2 modules are used. These modules dynamically change the packet loss, the delay and the packet loss of the network. The dynamic traffic is being fed with the help of TMIX through the node 14 and is being channeled to the node 17 of Figure 2. Moreover two Delayboxes are inserted to the main line in order to dynamically change the delay from 1 to 20 ms, the bandwidth from 1 to 20 Mbps and the packet loss from 0 to 1%. The DelayBoxes enforce dynamic network conditions on the TCP flows of the network. The monitored UDP flows are affected indirectly as the TCP flows alter the network conditions.

5. Simulation Results

5.1. Protocol Efficiency

Protocol efficiency is uninfluenced by the network status and is determined by the payload of each application and the header of each protocol Equation (1). As real-time haptic applications enforce very high update rate, the protocol efficiency should be examined. Haptic applications use small payloads The transport protocols should use as small overhead as possible so as not to overshadow the payloads of the haptic applications.

Table 4. Protocol Efficiency.

	ETP	UDP	RTP	SCTP	DCCP
Header (bytes)	12 + 8(UDP)	8	12 + 8(UDP)	12 + 4(Chunk INF.)	12
Haptic Payload (bytes)	64	64	64	64	64
Efficiency	76.19%	88.88%	76.19%	80%	84.21%

illustrates the efficiency of the examined protocols. The UDP protocol shows the highest efficiency As it has the smallest header.

5.2. Packet Loss

Figure 3 and Figure 4 depict the percentage of packet loss inrelation to the delay of the network. This diagram is important as it reveals the correlation between the network delay and the packet loss for each protocol. If the characteristics of the End-to-End delay of the network are known, it can be decided which protocol should be used for the transport of haptic data so as to avoid high values of packet loss.

In Figure 3 the Internet bottleneck is 20 Mbps for all simulations. The delay was set to 5, 10, 20, 30, 40, 50, and 60 ms for each simulation and was stable for the whole simulation period. All the protocols present quite a low packet loss, lower from the limit of 10% of Table 1. The worst performance is presented by protocol the SCTP and the DCCP, but still they have a packet loss lower than 0.76%.

On the other hand, Figure 4 presents much higher values of packet loss. In this scenario, the Internet bottleneck has only 1 Mbps bandwidth for all simulations. It is obvious that the network is congested. Six protocols are trying to send a throughput of at least 3 Mbps over the network with a bandwidth of 1 Mbps. The protocol with the smallest percentage of packet loss is the UDP protocol. The protocol with the higher packet loss is again the SCTP and the DCCP.

Figure 5 and Figure 6 depict the interaction between the packet loss and the bandwidth of the network. Figure 5 depicts a network with static network conditions while Figure 6 depicts a network with dynamic delay and bandwidth. Both charts have similar behavior for bandwidth higher than 5 Mbps. From these charts one can conclude that as the bandwidth increases, the packet loss decreases. For bandwidth over 5 Mbps the packet loss is lower than 1%. When the bandwidth is 1 Mbps, the packet loss is very high, which means that the network is congested. Figure 3, Figure 4 and Figure 5 shows that the DCCP and the SCTP show the worst performance, as far as, the packet loss is concerned when the network is congested. The SCTP and the DCCP protocol use a TCP-like Congestion Control. The sender uses a congestion window and transmits packets until that window is closed. When congestion occurs the congestion window is lowered to half. The DCCP and the SCTP protocols send their packets in bursts. The buffers of the intermediate routers are overflowed and many packets are dropped.

5.3. Throughput

The throughput of a protocol is crucial as higher throughput means higher possibilities for congestion. When the bandwidth of the network is low, protocols with small throughput must be used.

Figure 7 illustrate the throughput of the protocols when the Internet bandwidth is 20 Mbps, so that no congestion should occur in the network. The delay of the Internet is set to 40 ms, as 50 ms is the maximum acceptable delay, based on Table 1. TCP throughput varies between 1660 Kbps and 3300 Kbps, because of the congestion window of the TCP’s congestion control. UDP and RTP protocols pose a steady throughput of 576 and 672 Kbps for haptic data respectively. This means that their sending rate is constant. The higher throughput of RTP is due to the higher header of the protocol. Protocol ETP tries to reach its highest sending rate, but its growth is very slow, due to its congestion control. After 20 s of simulation time it had not yet reached the sending rate of 1000 packets per second. The SCTP protocol presents the highest throughput, after TCP, among the other protocols. Apart from that, it also presents the highest deviation of the throughput. DCCP for the first 6 s presents quite a big deviation of the throughput and it is not stabilized before the 8th second.

Figure 8 illustrates protocols behavior in a dynamic network. The big difference between Figure 7 and Figure 8 is the behavior of the TCP, the ETP, the SCTP, and the DCCP protocol. All the above protocols enforce a tcp-friendly congestion control. When the network bandwidth changes, these protocols changes their transmission rate so as to avoid congestion. The UDP and the RTP protocol show a steady behavior, as they don’t enforce any congestion control.

Figure 9 displays the throughput of the protocols for Internet bandwidth 5 Mbps and delay 40 ms. The bandwidth of 5 Mbps is chosen so that the network is under low congestion. TCP has lowered its throughput that now varies from 1660 Kbps to 2160 Kbps. UDP and RTP protocols display almost the same steady throughput with very small deviations as they do not have a TCP-Friendly rate control. ETP protocol adapts the smallest throughput. It cannot increase its sending rate, because there is some congestion on the network. It can be seen that the congestion control of TCP binds more bandwidth than that of ETP. DCCP shows almost the same performance with the previous simulation. It adapts almost the same steady throughput, with very small deviations, 2 s later than in the previous simulation. SCTP still presents the biggest deviation and does not manage to obtain a steady throughput.

5.4. Jitter

System instability is vulnerable to high values of jitter. Based on Table 1, haptic applications are more sensitive to jitter than other multimedia.

Figure 10 illustrates the jitter of the protocols for an network bandwidth 20 Mbps and delays from 5 to 60 ms. At this high bandwidth no congestion occurs. Almost all of the protocols show very small jitter, lower than 0.6 ms.

Figure 11 shows the jitter for network bandwidth 1 Mbps. It is a fully congested network with a lot of packets lost. The jitter is now much higher than in Figure 10. The protocols with the highest jitter are the DCCP, the TCP and the SCTP. RTP, UDP and ETP protocol have smaller jitter than 6.7 ms, with the ETP exhibiting the best performance with a jitter smaller than 2.6 ms. According to Table 1, the jitter should be lower than 2 ms, a goal that most of the protocols could not achieve, due to the congestion of the network. An interesting observation is that the protocols TCP, SCTP, and DCCP lower their jitter as the delay of the Internet bandwidth increases. All these protocols almost have the same tcp-like congestion control algorithm.

Figure 12 and Figure 13 depict the jitter of the protocols when the Internet bottleneck bandwidth varies from 1 to 20 Mbps. The average Internet delay is near 40 ms. All the protocols show a different behavior when the Internet bandwidth is 1 Mbps and the Network is heavily congested. For higher bandwidth values all protocols present almost the same behavior. As the Internet bandwidth increases, the congestion and as a consequence the jitter effect, are decreasing.

5.5. Packet Arrival Deviation

Packet Arrival Deviation (PAD) is a metric proposed by the authors for the performance evaluation of real-time haptic protocols. It is similar to jitter, but it can offer more precise picture of the real-time network delay conditions than jitter, since it can take into account both the receiver end for the time variation of received packets (packet reception jitter at the receiver end), as well as the ACK packets reception time variation at the sender (packet reception jitter at the sender end). Moreover, it takes also into account the changes in the sending rate of the source focusing on the fluctuations of the Internet bandwidth. Table 1 does not include the PAD, as it is only presently proposed by the authors. The upper limit of PAD should be equal to jitter’s, which is 2 ms.

Figure 14 displays the standard deviation of the packet arrival for different delays. The Internet bandwidth is 20 Mbps. The protocols with the higher standard deviation are the TCP, SCTP and the DCCP protocols. UDP and RTP and ETP protocols present very small standard deviation of packet arrival, lower than 2.5 ms. This difference between TCP, SCTP, DCCP and the UDP, ETP, RTP is the way they send their packets. The first group sends its packets in burst inside a congestion window (CWND), while the second group sends its packets with an almost steady inter packet gap.

Figure 15 and Figure 16 show the Packet Arrival Deviation when the bandwidth of the network changes from 1 to 20 Mbps. SCTP and DCCP and TCP have been excluded from Figure 15 and Figure 16 for 1 Mbps as they showed unacceptable values of PAD. The conclusions of this graph are similar to those of Figure 14. TCP shows the highest PAD as it uses the congestion control windows. UDP and RTP show very little PAD because they do not enforce any congestion control algorithm. For network bandwidth higher than 10 Mbps, there is no network congestion and all protocols show the same behavior.

Summarizing, not all transport protocols should be used for transferring haptic data over the Internet. Protocols that include TCP-like congestion control algorithms, such as the TCP, the SCTP and the DCCP, should be avoided in heavily congested networks. Timely delivery protocols such as the UDP, the ETP and the RTP are more suitable for real-time haptic data transferring. The UDP protocol is being used both by the ETP and the RTP protocol. When the haptic payload is 64 bytes, the efficiency of UDP is 88.88%. This is very crucial, as haptics demand very high sending rate. When the network is congested, the packet loss is rather high (Figure 4). Figure 7 and Figure 9 illustrate network behavior for 20 and 5 Mbps bandwidth with 40 ms delay. In these network conditions the UDP and the RTP protocols have steady throughput. The UDP protocol consumes lower bandwidth, as it is more efficient. The ETP protocol interacts very well when the network conditions are sufficient. UDP and RTP retain lower jitter and PAD from the other protocols in all network conditions. The ETP outperforms the UDP and the RTP when the network is heavily congested (Figure 11 and Figure 12). ETP in order to avoid congestion, it decreases its sending rate by increasing the inter packet gap. Lower packet loss, jitter and PAD are the outcome of this reduction. The RTP and the UDP have better performance in most network conditions. The ETP protocol applies congestion control algorithms and should be used in heavily congested networks.

6. Complements, Differences and Relevancies Between Simulation and Real World Experiments

In Section 3, our previous real world experiment is described, while in Section 4 and Section 5 a simulation experiment has taken place. The simulation tests complement real word experiments.

The real world scenario helped us understand the status of the Internet and define the values of the variables for the simulation experiment. The only variable that is difficult to define is the available bandwidth of the Internet for the whole path. It is a metric that is changing rapidly as it is based on the number of online users and the data that are exchanged.

The real world scenario revealed that a real teleoperation task through the Internet is feasible, while the simulation experiment helped us conclude which protocols suits better for these teleoperation tasks under specific network conditions.

In the real world experiment, it is understood that the experiment results are depending on the physical distance between the source and the destination and the ambiguous network conditions of the Internet. In the simulation tests network conditions are fully controlled, so more accurate results can be produced.

The real world experiment helped the authors define the mean end to end delay, the standard delay deviation (jitter) the packet loss and the number of hops between source and destination. For this experiment the UDP transport protocol was chosen. It is the simplest transport protocol and it is being used for most cases of real-time multimedia applications. Two completely different pairs of source and destination were chosen, in order to examine the dependency between the results on the distance between source and destination.

Despite the ambiguous network condition of the Internet the simulation results of the UDP protocol matches the results of the real world scenario for the connection between Korea and Japan,

Table 5. Similarities between simulation and real world experiments.

	Delay (ms)	Jitter (ms)	Packet Loss (%)
Connection between Japan and Korea	27.01	0.19	0.02
Simulation of Udp Protocol with 20 Mbps Internet Bandwidth	32.10	0.19	0.02

. At the specific simulation, the Internet end to end delay was set 32 ms. The Internet bandwidth was set to 20 Mbps. These settings depict a network with no congestion. Both simulation and experiment transport data over the UDP protocol. For the connection between Japan and Greece there were no corresponding simulation tests as the results from the real world experiment were outside the acceptable limits of Table 1.

7. Conclusions

The interconnection of haptic interfaces with high update rate through the Internet is feasible. Haptic data should be transferred by specific timely delivery protocols. Haptic transport protocols should be standardized. Strict QoS requirements should be enforced by Internet Service Providers in order to transfer the haptic feeling over the internet. Simulation and real world experiments revealed which transport protocols should be used for real-time haptic data delivery with high update rates over the Internet. Real-time, lightweight, unreliable, protocols outperform heavyweight reliable protocols. UDP, RTP and ETP protocols are more suitable for interconnecting haptic interfaces than the TCP, the DCCP and the SCTP protocol.